Dan Mazzella

Thanks for coming. We're going to be talking about how to have engineering teams, civil engineering teams, mechanical engineering teams, working with software development, using DevOps to provide great value for building the real world.

So, who the heck am I? I am Dan Mazzella. That's M-A-double-Z-E-double-L-A. Don't confuse it with one Z or one L Mazzella, or Ella, or whatever. That guy's a jerk. Don't listen to him.

I started in software a long time ago, and throughout my career, I've been at the intersection between physical infrastructure and software infrastructure. I started with a startup in the early 2000s called TRIRIGA. It was actually founded here in Las Vegas by the company that was building the billion-dollar casinos: the Wynn, the Encore, the Rio, the Mirage, the Treasure Island.

So at a billion dollars a pop, they were looking for ways to save cost on that. They said, "Well, if we can use software to save 10% on building one of these casinos, that's $100 million right there. We have that in our sock," right? So they put $50 million down to fund a software team to create TRIRIGA. And 11 years later, we were sold to IBM for a lot more than the initial investment.

I spent the next few years at IBM working with the IWMS and the physical space. So we integrated with Maximo, which is another asset management software package. And now there's an entire suite at IBM. I don't see any Big Blue people in the crowd here, but my friends at IBM are still going strong with the application suite and the Maximo suite that includes TRIRIGA, which is the code that I helped write.

I then left, went over to Arcadis now, and we are the third largest AEC, that's architecture, engineering, and construction industry player in the world. So if you know of other competitors like Jacobs or AECOM, we're right up there. We do projects all over the place, and what I'll be talking about is how we deliver value of those actual projects using software standardization optimization for that.

Another little bit about myself: I'm a jazz saxophonist. The AI-created dude up there is much better looking than I am, and I use the bari sax, which is an even bigger sax, but the GenAI whatever thing I used to generate that didn't know what a bari sax was, so I got a tenor sax up there.

Anyhow, what is Arcadis? Well, we're a Dutch company. It was founded in 1888, and they were originally founded to reclaim the land for the Netherlands from the sea. So all the waterworks, the dikes, the canals and whatnot, that was started by Arcadis. And it was originally a Dutch, I cannot pronounce their name, Nederlandsche Heidemaatschappij, in the Netherlands. My Dutch ear is pretty good, but don't ask me to pronounce a whole lot of Dutch.

We have about 36,000 people worldwide. We're going on a bit of a buying spree, looking to bring in other software and AEC industry players into the fold to help broaden our horizon, our portfolio. We have lots of projects worldwide, really focused on creating a better usable world for everyone, the actual physical world. And my role as the global software director is to accelerate that by the use of inbuilt software and also third-party software that we bring in.

One thing with Arcadis, since we are dealing with the physical world, is we have a very strong safety culture. So I get brownie points for having a health and safety moment up there. My boss will be glad that I put this in here, and usually my health and safety moments relate to something I'm presenting on. So in this case, it's tangential, but very key. And that is, we use test-driven development in our software practices.

So before a developer goes off and writes a line of code in React and C# or Java or whatever it happens to be, they have to know what are they testing, and write the unit test first. So this helps deliver the package, the story, and ensure the quality is done. And we are all in agreement about what needs to be delivered, from the product owner to the scrum master to the software developers to the SMEs from the business. We all have that agreement on what is actually going to be tested before we actually write the code to go off and do that.

And if you think about this in terms of the MVC pattern, the model-view-controller pattern, I actually like to flip it around a little bit and say you have your view layer, the front end; the control layer is your middleware; and your database is your model. But the APIs that are in between the front end and the back end, and the back end and the database, that is a contract.

And with test-driven development, you can come up with that contract. What is the JSON going to look like that React is going to consume? Or what is the JSON that React is going to push down to that control layer? At the control layer, same thing. I have this JSON, I'm going to consume it, I'm going to push it down to the database. And then at the database level, making sure that the information coming in from JSON matches what is going into the database.

So it's pretty important. And we have something else at Arcadis called the stop-work authority. And what this means is if we see something that is wrong safety-wise, we can stop a project and say, "Hey, we understand the budget is going over, but you can't ask us to skip testing just because the budget is over, just because we're running late on time or whatnot."

So we have that ability to stop work if it's health and safety at all. And I use this quite a bit. If a product owner or program manager is pushing me to get something done faster, I say, "Hey, would you rather have a bridge collapse? Or would you rather have testing done?" And it does help us quite a bit.

So let's talk a little bit more in detail about the AEC industry. And there's a cycle of ideas that have come into the software industry from civil engineering. And then the same thing we are seeing from the software industry maturing and whatnot over the last 40, 50 years, those ideas being brought back into the civil engineering practice.

So some of the problems that we have with the civil engineering and the AEC industry is we have these silos. So we have breakdown in communication between the SMEs, the civils, the mechanicals, our software developers, the clients, all over the place. There's not clear lines of communication.

There's a lot of duplication of efforts even within the same client. A lot of times someone will come up with an Excel spreadsheet, having something done over and over again, and not have it standardized and automated.

We also have time delays. This is probably our number one killer for projects being done on time: things are held up in this wait cycle, waiting for someone to react, waiting for an approval to happen, waiting for a process to complete. And that is partly due to lack of visibility in the systems that we have, both IT systems and project-based systems that deliver the solutions to the project.

And then finally, there is a lack of innovation in our industry. We have some of the big players that do a pretty good job. So the Autodesks, the Esri, that do a good job at delivering some innovation. But the actual people, the consultants, the engineers, there's been a reliance on Excel. So much Excel within our industry that they say, "It's fine. I'll just do it in Excel. Why do I need to standardize something?"

So this is where we came up with the idea at Arcadis of having fusion teams. So this brings in people from the business. And when I say business, those are our civils, our mechanicals, our electrical engineers. We have our software developers, scrum masters, product owners, business people, all together on a team to deliver something, some piece of software, whether it's something on costing, whether it's designing something with GenAI, or some algorithm to collect rainwater in a 3D model.

We put them together in a team, add some DevOps, sprinkle that on top, and then we put together a roadmap and we deliver software in that fashion so that everyone is on the same page. Everyone has a clear understanding about where to go to, who to go to, and when it will be done.

And then we also use Agile. Typically in our own teams, when we are delivering a solution, we have two-week sprint cycles. At that end of the two-week sprint cycles, we have something that is ready for the business to consume and deliver their project on to the client.

So how do we do this? Did I skip a slide? I think I did.

Again, talking about the lessons learned from the software industry, bringing them back into the AEC industry. So the idea of Scrum and the idea of having a short cycle and a turnaround with a backlog that you can work off of and understand what's in the future. But don't hold it to a specific Gantt chart. Don't think that things need to be done in a certain order. Be adaptable and deliver the solution or deliver the product or the project in an adaptable way.

Again, back to the test-driven development, making sure that there is sign-off. So the product owner, we consider almost like a PE, or the professional engineer, when they are closing a story out. That is their stamp. If you know anything about civil engineering, they get a blueprint and the PE puts a stamp on there, says, "Yes, this is good. This bridge isn't going to collapse. This floor isn't going to come down and kill everyone in the room."

So having that collaborative process and quick turnaround, something that we call in the industry the design-build, it's all in-house, all done at once, and it's adaptive. So there may be a general idea about where we're going for building a bridge, for doing a rail line between London and Manchester, whatnot. But we don't have the exact details down for every single square inch or square centimeter. As we're going along, those things are decided as we go along, as we build out the projects.

Having workshops and in-person meetings, or virtual meetings in the light of what happened in COVID, is very important. And this, in turn, allows everyone to have buy-in and understand what the roadmap is. And so the engineers have that sense of ownership, as well as the software developers have that sense of ownership on the thing that they're delivering.

And at the end of a project, the software engineers can say, "Hey, I didn't just write some code. I built that tower. I built that condominium. I built that rail line in the Netherlands." So that's a very powerful thing. And we have some of the highest satisfaction scores when we survey our staff, because there's that overall sense of ownership in understanding what our people are doing.

That product and program roadmap is shared between the business and between tech. So me, as a software engineer and director of software engineering, I have just as much ownership in that roadmap as the people in the business that actually need to deliver for our customers.

And then again, open communication, having Teams open all the time, having email flow through, and then having systems like we use Microsoft DevOps instead of Jira, but having the business people have access to that so they can see where we are at any one point in time.

Also, things like wikis. If you have any documentation about how the software is built, making sure that the business sees that so they can get an understanding about, at least, we can estimate how long something is going to take. If we're deploying a new whatever to Azure, they can see what our process is and how we do things. So they aren't completely in the dark.

All right, so let me go back to test-driven development and a little story about why I think this is so important. A number of years ago, I worked with the head of security. Not cybersecurity, physical security. So this guy was a Navy SEAL. Ex, or retired, I guess they don't like ex. He's a retired Navy SEAL. Big guy. You can look him up on the internet, Chris Karachi. He has his own sword or sword. He sells knives. He has kickboxing videos. Really cool guy, but he's gruff, man, I gotta tell you this.

So we are moving into a new building, and as head of physical security, he said, "Oh, our great partner, well, we need to get cameras up on the roof."

"Come on, Chris. We don't need cameras up on the roof."

Never challenge a Navy SEAL. I have other stories. Treat me to beer and I'll tell you some other stories. But he said, "All right, partner, come outside."

So me and some other people go outside, and he scales it. Now, AI-generated photo up here, but this is as close as I could get AI to generate what I actually saw with my own eyes that day, as he scaled the side of this two-story glass and steel building. And from up on the roof: "See, told you someone could scale it. We need cameras up here."

So that was the test-driven development from the physical infrastructure, right? He proved before we had the cameras in that we needed cameras. So that was an important life lesson to me, to have that proof, to show what you're testing for is actually within the realm of possibilities before going off and wasting money doing something.

So I've taken that life lesson in software development and making sure that I always write tests whenever there's a new story. I tell my staff to write tests before they are implementing something new.

And then also for defects, if you get a bug report in from the field, try to simulate it in your IDE first with a unit test. If you don't have coverage, well, that's a problem. So you write coverage for there, and don't be afraid to refactor your code. Do that concept of cleaning while you code, to refactor your code, to get your mocking straightened out, to make sure you don't need a database to test something. And you get down to that core nugget where your actual problem is, and then you can fix it.

After you fix it, the unit tests run. Now you have that in your suite that you can run on every PR, on whatever your CI/CD process is, so that you can be sure that when someone else comes along and messes up that code, there's a red flag that goes up and says, "Hey, we now have a JUnit that's failing," or, "This NUnit in C# is now failing because someone got this code." And they get the rubber chicken award for breaking a build or having a new unit test that failed.

All right, so let's talk about some case studies. The first one is the Dutch rail, and this is a company known as ProRail in the Netherlands. If you can go ahead and start the video there, I'm just going to have it play so you have something better to look at than me.

What we did is we collaborated with our rail engineers to say, okay, we are building a new line out to the east from Amsterdam. And one of the problems that the actual rail engineers, the people that are in the cockpit of that, had was visibility to the signals.

So we came up with this. This is done in C# and the Unreal Engine, pulling in from Civil 3D. Civil 3D is a product that we used to build linear assets. So we pulled in the drawings and the definition of what the rail looked like from that, combined it with some Esri data, and built a train simulation. Now they could drive the train.

And in about probably 10 or so seconds from now, you'll be able to see the actual conductor, the person that's in the pilot seat, looking at the track and seeing what the signals are to make sure that when we are building out the rail network and putting in the electric lines, that the visibility is clear.

So here's the example. You can see that we even got the windshield wipers there. The Netherlands is a very wet place, if you've ever been there. It rains all the time.

And we did this iteratively. So we first came up with what rail cars do they use the most? And there should be another couple seconds here, a dropdown to see this is the train type that we're using. So we started with the most common one and implemented that, and then worked our way down for that.

So now you can see, there's the red line showing you what the visibility from the conductor is to that signal. And we also give a little graph of what that visibility as a percentage total is. So pretty cool stuff.

Another project I want to talk about is the high-speed rail project. And this is the UK's high-speed rail. You may have heard that it was basically cut in half. The budget was cut in half by the previous administration in the UK, and it was going to go from London all the way up to Manchester. Now it's only from London to Birmingham. So some of the budget has gone away, but we still have something to deliver, and it's a multi-million-pound project in the UK.

So we had a bunch of areas that we needed to accelerate and give visibility. And we used standardization and optimization, looking at the processes and then delivering software solutions to help those processes along. We got buy-in from the business, and we were able to deliver five different solutions to them over the last few years that helped not only them, but also the subcontractors and the UK government see exactly where we were in delivering this real-world program. It's not just a project, it's a program.

And then as they bought the land and started to build out the railway, we used processes internal to that for onboarding new staff and having wikis and document management solutions that adapted over time and would be able to scale over time. And we worked with the business over time to improve those solutions so that we could deliver great value for that product.

All right, next one, not AI-generated. That is an actual photo I took with my phone earlier this summer in Hong Kong. And the housing projects, if you've ever been to Hong Kong and flown into the airport there, as you're coming out either on taxi or using the railway, you'll see that there's some huge condos, huge high-rises. Well, we're the company that builds those.

And we are the main contractor for the Hong Kong Housing Authority. And it is ancient, the way that they work. There is a ton of paper that is just for one building, all the cost estimates for one building, and they insist on having it in paper. So we will have people with carts that go off and have this printed. We will send this over to them, and they will redline stuff, mark it up, and then send it back to us. And then we have another floor of people that just take this information and push back, or push it into our system.

So the key here is, think about how can we convince them that this is not the correct way of doing it? And we were able to at least convince them to install the V6 app that we used to generate this costing information on their systems, so that all we had to do was sneakernet a USB drive over to them so that they could load the data onto their own database, update stuff, redline it, save it back to the USB drive, and hand it back over to us.

Those are some of the challenges that we have in the AEC industry, being so far behind, and especially different regions in the world. And our ultimate goal is to have something cloud-based. They're nowhere near ready to accept something that's cloud-based, so they can just log into one of our systems and be able to consume a SaaS service for that.

So we still have to work with them, but we are trying to be a thought leader and introduce new ways of working to our own customers that are quite a ways behind the times.

So what are some other ways to overcome that resistance to change? Well, obviously you want to talk about sustaining a process, sustaining a solution into the future. You don't want to have something that is hard to maintain, that is hard to use, that people will leave because they are too frustrated, that they'll revert back to Excel or revert back to paper for. You want to make sure that you get that buy-in for that understanding of why something is important to change, why something is being modernized or standardized.

You want to highlight all that time savings and cost savings for them. Some people just look at time savings. Other people look at budget. Some look at both. Some look at neither and just want to do it the way that they've always done it. So you have to be persistent in that ability.

And then lastly, again, back to the health and safety. You want to make sure that you highlight why something, if it's frustrating to use, maybe that's causing stress in your staff, and stress in your staff could lead to higher turnover rate. So thinking about the health and safety impacts of overcoming those resistance, those things that are resistant.

So those are all sort of the carrots that you can throw at people. And then there's a couple sticks that you can whack them with. You can say, "Okay, if you want to work with us, this is the mandate. You must use our system. You must use a SaaS-based system. We have a certain way of operating."

And then the last stick is using legal. So whack them with a contract, okay? Not only is it a mandate, it's in the contract that in order to operate and work with us, this is the way you're going to do it. And use that legal authority, that legal stick, to whack them over the head and say, "Hey, all right, it's in the contract. This is the way you're going to do it."

And that is some of the final things that you can do to eliminate the resistance to change.

So our journey at Arcadis, it started, well, it started in 1888. But really the tech journey started probably in the early 2000s with the introduction of Microsoft Office and the other things. And the real acceleration happened probably in the last five to 10 years with the adoption of the Agile method and the continuous integration and continuous development practices we've implemented within our own company.

You want to monitor and adapt the process. Don't think that just because it's a process, it's something that's set in stone. You can adapt. It's a wiki, right? If you have a document on a wiki, you can change it, you can adapt it. You can document the reality versus documenting what you want to do. Document that reality, and then change it over time and come up with new ways. And if it doesn't work, back it out. Go to the old way of working.

So monitor that and see what changes have a good impact, what changes had a bad impact, and go on the path to make better improvement. So that continual process of trying something, seeing, testing, and then making another change, seeing, testing, reverting back, make another change, is an important way. And it's the way that we've evolved internally.

All right, everyone has the AI slide. So what we see as the future trend from the AEC side, especially in the software engineering or software development side of engineering, number one is Copilot. That has had a large impact just in the last nine months or so that we've been using it. So we had a three-month pilot, it went really well, and we rolled it out in the January, February timeframe to the rest of the developers.

There was a talk yesterday on the main stage that said the senior developers are the ones that get greater use of it. That's absolutely what I have seen within our organization. And so my job as a leader and as a coach to the junior staff is to help them understand what they need to do in order to use Copilot and use those AI tools better.

For the product owners, using the generative AI and the large language models to help them write stories, to help them come up with acceptance criteria, to help them communicate better to the developers or to the SMEs in the business about what it is that we want to accomplish.

Putting the roadmap in our own version of ChatGPT, we have an on-prem ChatGPT, and saying, "Well, what can you do to make this better?" And getting those results, reviewing it. Don't take it for granted, but have a human review it and put that stamp on there as if they were a PE. You say, "Okay, this is what a roadmap is, and we're going to take these first things out as stories to contribute."

And then for adversarial testing, using genetic algorithms to test a whole wide range of things. So in the bridge-building thing, I always like to go back to, if you've ever had a generative AI try to build a bridge, you'll get some really crazy designs, but you'll get a pretty optimized design after a while.

All right, so wrapping up, your industry is probably at a different place in the digital journey than the AEC industry is. Some of you may be much more advanced. Some of you are maybe less advanced and still using Excel or paper. So don't be afraid to experiment. Don't be afraid to leapfrog and jump over some phases.

The thing I saw a few years ago was the use of serverless technology. We jumped straight over Docker and started using serverless stuff. So we don't have any containers. All of our code is serverless-based Azure Functions up in our resource groups.

So don't be afraid to take that step over and to leapfrog. You don't need to do things linearly. Don't be afraid to innovate. Don't be afraid to come to conferences like this, to share ideas, to understand what the state of the art is, and don't be afraid to mash up things, to pull things in from other industries that may not at first seem like it is a fit, but it may be.

And then always open communication and adapt your delivery models.