MACH early adopters beat a path to the composable future of ERP

Bringing composable architecture to online commerce and digital experience platforms has helped consumer brands and retailers provide a more flexible, scalable and responsive experience to their customers — often replacing or sidelining incumbent monolithic systems. But there's growing frustration at the contrast between these highly adaptable, fast-moving front-end platforms and the back-end systems they have to co-exist with. Some early adopters are starting to replace conventional ERP systems with more composable alternatives. Could this be a harbinger of a wider trend that will see incumbents sidelined on the back-end, too?

In a panel discussion at the MACH TWO conference in June this year, Mark Elliott, Chief Architect at online fashion retailer Boohoo Group, summed up the frustration. As customer-facing operations increasingly demand real-time data, it exposes front-end dependencies on the back-end that are slowing things down. He explains:

There's some really key parts of the back-end ERP system that work in a batch and you won't get that information to the place you need it for another 12 hours or so. There's a real conflict between that customer-facing or business-facing functionality that the product owners might want to use and the reality of what's going on behind the scenes.

Any attempt to upgrade a back-end ERP system seems to require a two-to-three-year timeline, adds Andreas Westendörpf, CTO at mattress company Emma Sleep, with no value delivered until six to twelve months in. Everyone seems to accept the line that these platforms are like slow-moving oil tankers that can't change course quickly. Yet this is unacceptable by the standards of modern software development, which deploys new features in two-week cycles or even continuously. He goes on:

This is not okay, because the technology is ready also in the ERPs. It's not like the engineers at the ERPs are lazy and are not innovating. They are. But it's just way too convenient and lucrative to stay on the commercial models of the 1990s. I think we need as customers and as partners of ERP vendors to challenge that.

This whole notion of separate back-office and front-office systems that move at different rhythms feels like a hangover from the last century, perpetuated by incumbent ERP vendors who find it more convenient to keep customers locked into this two-speed model. But enterprises whose businesses increasingly revolve around e-commerce platforms and subscription billing systems are wondering why these front-end transactional systems can't also be systems of record. Could it be that the only reason they're excluded is because the ERP vendors had already built their platforms long before the advent of these new transaction models?

Certainly the panelists in the MACH TWO session were in agreement that a truly composable architecture built on MACH principles allows for a different approach. (The acronym stands for Microservices-based, API-first, Cloud-native SaaS and Headless, and was coined by industry advocacy group the MACH Alliance, which hosted the conference.) Rather than dividing the IT landscape into back-end monoliths and front-end platforms, why not build a single architecture composed of autonomous services? Within this unified landscape, each transactional service forms part of the system of record. Elliott says:

We have order services, we have purchase order services, you've got customer services, you've got product services, and they're accessible to the front- and back-end.

So the front-end and the back-end disappears. What you have is a user interface, but actually the rest of it is all services that are available. So actually, [the distinction] goes away. They make the system of record, and they're accessible in real-time from anywhere we call it. That's where we're aiming for and that's where everyone should get to.

Paths from monolithic to composable ERP

Elliott adds that Boohoo is coming to the end of a multi-year journey along these lines. As new business requirements came up, it used each opportunity to gradually build out separate services to replace components of its original monolithic ERP system — for example, building a new stock management service when the group needed to establish a US warehouse. The outcome is a system that allows for rapid releases on the retailer's own timescales, rather than having to conform to an ERP vendor's release cycles. He explains:

We're now bringing the back-end into the same speed of delivery and same ways of working. But we've had to do it in alignment with the projects that are happening. But we are getting to the point now where we've got a service-based architecture, which is running our ERP.

So we've gone from having to restrict some of our front-end changes to align with release cycles to actually now being able to deploy the same-day changes to our back-end ERP as we do to the front-end, and it's all aligned, which is the place that we were aiming for.

He admits that building your own ERP system isn't a walk in the park — specialist expertise is needed to make sure it does the job. He elaborates:

When you buy a package, you don't need to worry how it works under the bonnet, under the hood. When you build it yourself, you suddenly go, how actually does it work? What is the logic that's going on? You've got to make sure that you have availability of subject matter experts who actually understand the financial, stock management, or PO services. All that you have to know. And that's where the challenge is. But I think if you've got the right people, you can build it.

For others on the panel, it's been a matter of integrating their ERP system as one component in the IT landscape rather than replacing it outright. Organic denim brand Nudie Jeans uses a Sitoo point-of-sale system and the Centra headless e-commerce platform as its customer-facing transactional systems, while the ERP system takes more of a behind-the-scenes role. Sandra Hansson, IT Manager, explains:

The way we work with our ERP is that it's the base — it's actually more a monitoring and management tool. And then on top of that, of course, we love to work with MACH functionality ...

We went with the approach where we wanted to source an ERP system that would allow us to change. We began to use a lot in the ERP system for the features that we use to work, but then we work with other services around it.

Emma Sleep has worked with its ERP vendor to adapt the system so that it provides specific services within the overall composable architecture. Westendörpf says this has meant taking more direct responsibility for how the ERP system operates than in a traditional relationship:

We created our own way together with the vendor, bypassing the partner and working directly with the vendor to only take from the ERP certain functionality, and we can attach services that we put our own, or services that are sourced from MACH Alliance members. And [we] built this composable architecture also towards what we call financial and operational support, aka ERP, a bit of breaking with their traditional approach to this stuff ...

In the past it has been very much about outsourcing the problem to the vendor or to their partners. But we see this as a core business capability of ours to also build out our own capacity and have our own ERP software engineers.

Moving faster - stability vs opportunity

The danger of bringing faster release cycles into the ERP realm is that the consequences are more serious if things go wrong. Elliott cites stock levels as a case in point:

On the front end, it has to be good enough. You don't want to sell something that's out of stock, but if it's not quite up-to-date, you can catch it when you check up later, etc. As you go down the stack towards the back end, the accuracy of that stock level has to get to the point where at some point, there's a system that knows exactly what the stock level is, exactly the value of it. First-in, first-out — there's always rules around it, and that has to be corrected.

So I think there's a clear differentiation — it's not bimodal, maybe it is a gradient and a separate area between front-end that moves fast and as you get deeper, you've got to get that reliability and consistency.

But Westendörpf counters that ensuring stability has an opportunity cost that has to be weighed too, especially in a fast-growing business. He says:

What I feel is not really spoken about is loss of opportunity ... You cannot innovate on the front end, because there are some hard dependencies on the back-end. Sometimes it works to make the business case to be rather faster, and even accepting a certain level of instability, even if it goes back to your financial systems, but the cost of opportunity is just so much higher.

This is why Emma Sleep took the decison to adopt a composable architecture right down to the ERP system. He adds:

The worst part of a bigger tech organization is, if people start waiting on each other, to create waiting states in teams. The only way that you avoid that is design the systems but also the team setups in the way that they can move in a decoupled fashion autonomously. This for me is the main benefit of this entire MACH or purpose-built solutions topic because we can deliver increments concurrently, have each team at their own pace and not create these non-working states and have two releases per year.

For Boohoo, it was the ability to move faster that crystallized the decision to build its own system. Elliott says that now that it has moved to a fully composable architecture of reusable services, future innovation will be much faster and less costly. He comments:

We saw benefits from the cost and speed we can do it in, and not having to deal with the big vendors, where the cultures would clash, very much so, with our fast fashion and fast implementation culture.

While it currently requires a lot of expertise and investment to create a system like this, that will change over the next few years as new tools evolve, he believes. He comments:

It doesn't easily all fit together and clip together. There's a lot of work that has to be done to make that happen. I see the way things going in this movement, if you can call MACH a movement, is tools will evolve and develop. It wouldn't surprise me if we were sat here at MACH 4 — maybe not MACH 3, but MACH 4 — and there is these connectors and tools that really easily make it into a big shopping list. 'I want this one, this one and this one,' and it just works.

My take

I've never been a fan of the noton of two-speed enterprise IT, nor of bimodal IT, analyst group Gartner's name for it. But as my late colleague Kurt Marko once argued, it's a necessary segmentation at most organizations. They face the challenge of how to keep pace with today's business needs while still maintaining yesterday's technology systems, which underpin many of the organization's core business processes and hold much of its essential data. Thinking of this as a bimodal quandary oversimplifies the case — it's more a matter of having sufficient gearing throughout the IT infrastructure to allow each component to run optimally.

Gradually surrounding these back-end systems with a composable architecture and incrementally supplementing or replacing their functions seems like a sensible path and, indeed, most ERP vendors seem to be encouraging a version of this approach. However, as I've warned in earlier articles in this series following up on themes from the MACH TWO event, many of the products and platforms that claim to be composable don't necessarily offer the best composition logic or the right kind of APIs.

Nevertheless, these MACH pioneers are showing that it is possible to engineer a composable architecture in which the traditionally back-office functions of an ERP system can be absorbed into the same environment as newer, customer-facing functions that have previously been seen as operating at a more agile pace. Instead of a two-tier architecture, they are creating what I would call a Tierless Architecture in which functions and resources are all available to an engagement layer. This is not easy to engineer today, but the fact that it can and has been done points the way to fully composable ERP becoming a mainstream direction in the future.