Your built environment design business runs on digital technology. That’s just how it is now. When you’re designing, when you’re invoicing, when you’re interacting with clients, when you’re collaborating on projects. All this digital used to be managed and automated by a process management software called ERP (Enterprise resource planning). ERP is dead, friends. You need to know that to keep your architecture in the now and into the future. Here’s the why and the wherefor:
ERP’s history — the one-stop shop
Historically the one-stop shop was what everybody was talking about. A situation where all the business software you need comes from the one vendor. That had attractive benefits — everything in the same product, supposedly similar user interface, only one company to argue with if there were problems with any of it, a single invoice so there was less paperwork, and theoretically, because it all came from the one vendor, the features of the application integrated with each other better.
Jack of all
That was a really good theory, but it didn’t exactly work out that way. Instead of the one-stop shop, you got the Jack of all trades. One vendor trying to be an expert at everything. That didn’t work out so well. The end of the “jack of all trades” phrase, is “master of none”.
In the hope of more quickly building a broader system software, companies didn’t actually write everything themselves. They started going out and buying third-party systems and bringing them into the fold. Then they had the problem of trying to integrate these things to make them work together.
We really no longer had the one-stop shop benefit, other than the invoicing. You still had a third-party piece of software that wasn’t terribly well integrated, had a different user interface, etc. It had all the same problems. A great idea, that didn’t really work in execution.
Best-of-breed
That’s the ERP side of it. Then there’s the best-of-breed concept. And that’s equally attractive.
We swung the pendulum the other way, and said, “What we should do instead is go out and find the vendor that has the very best of each thing we need, then we’ll build our own ERP by buying dozens of different applications from dozens of different people. Then we’ll work out how to make them all talk to each other, and that’s going to be great!”
And it was great — for the IT department. They now had almost as many staff as you had professionals running the business, and the IT team were probably getting paid more. But then you had the fragility of trying to connect all those different applications. Connecting them together depended on how well they could import and export data. It got a bit easier if they had decent APIs but the complexity there is that every system has different APIs — like a power plug in a power socket. If you take your Australian plug and try and plug it into an American socket, it just won’t work. For the API to work both sides must match up in the right way to get the data to move around correctly.
Let’s say one product has a connector that can export receipts excluding tax. But the other connector that imports receipts wants them including tax. So really, they don’t match up, they’re not going to talk to each other the way you would like them to.
How do you handle exchange rates? What if it’s in a different currency? As soon as you get into the really heavy business kind of stuff, there are a lot more subtleties and complexities, and there just aren’t apps that do those connections.
The platform approach
We started off with the ERP thing where we were going to build one ourselves because we were going to be the single source of truth — the one stop shop. That didn’t work. Then we’ve swung entirely in the other direction and decided on best-of-breed — we’d make them all work with each other. We found that that didn’t work terribly well either.
Where the pendulum has now settled is that it’s good to head in the direction of the best-of-breed, but instead of getting all of those individual products to talk to each other, you’re better off getting them to talk to one central platform, and then the platform coordinates the data between the apps.
If you were to draw it as a diagram, the first one looks like a spiderweb where everything’s trying to talk to everything else — lots of connections in lots of different directions. Difficult!
The other way of looking at it — the platform approach — is more like the hub and spokes of a wheel. You’ve got a central core and everything’s plugging into that. Let’s say that core is Synergy. So long as an app can talk to Synergy, and Synergy has worked out how to move the data appropriately between the two, then anybody who writes the API to connect to Synergy, can also connect that same data through that connected app. Then on top of that we can add a level of built environment business knowledge that says things like, “Well who should be allowed to access this data? Who can read it, who can write, who can change it?” Synergy, your central platform, adds a level of control and sophistication that makes it so much easier to connect these apps together. There is an in-built layer of AEC business knowledge that just isn’t present in other platforms.
You’ve got the benefit of the single source of truth, the one-stop shop, because there’s one company that’s making that data coordinate. But you still get the best-of-breed benefit that you can go out and pick the best add-on apps to suit you perfectly.
Recommended reading
- The importance of upskilling with your software’s updates
- Best practice — Change management for cloud software adoption
- How Salt³ shook up their engineering firm with industry-specific management software
Enjoy this article?
Subscribe to stay up-to-date with our industry specific content
