Moving towards MACH

To help us understand this in more detail let's complete a little thought exercise about your existing systems. Let's write down a list, we'll call this the "Nay" list. Maybe draw an angry little face at the top if that takes your fancy. Now on this list write as many negative things you can think of about your existing systems - "I don't like how long it takes to deploy", "that bug in the warehouse interface caused a lot of trouble", "the user interface is clunky when I have to do X", "this new feature is taking ages to implement". Let it all out! Let your pen be a channel for your scorn. Now breathe.

I expect that was an easy list to write (and probably quite cathartic). These are things in the front of your mind because they've likely caused you pain and anguish recently. Now let's make another list, the "Yea" list.

Try and think of some of the things which your existing systems do without fail. Think about parts that work just the way you want. Do you have a system that returns search results that your customers find really useful? Is there a component that ring-fences your stock using that strategy you carefully devised over years of peak trading? Do they allow you to set up promotions the way you want? You are very likely to have come up with a little list of things your systems do well, and that you would really miss if they went away. The Yea list represents just some of the value that's been embedded in your existing systems through many, many years of development.

If you made it this far you are probably starting to guess the point I'm making about a successful MACH strategy. A move to composable commerce is a journey, not a project, and during that journey we want to get rid of as many things from the Nay list as we can, and squeeze as much value out of the things on your Yea list along the way.

It's easy to get excited about MACH principles to the point of zealotry. The advantages it can provide mean that I'm as enthusiastic as you are, but there is a danger of starting to brand everything as bad unless it's MACH. This can lead to a burning desire to cast the majority of your tech landscape into the cracks of Mount Doom at the first opportunity. The problem with a scorched earth approach is that whilst many of your systems have their issues they also hold significant value to your business. Often that value has been forgotten about or overlooked because the systems have been working away diligently doing their unsung tasks for years. Starting from scratch means you need to recreate every single item from a comprehensive Yea list, and that's likely a lot more work than you may think.

There are also options that exist between preserve and replace. As an example, if you have a lot of custom Java code performing a particular task, and that task puts too much load on a core system you don't have to bin it or rewrite it as a MACH service. We can take a middle ground and use your existing code wrapped as a cloud microservice to provide elastic scalability and shed load from your existing systems without requiring you to rewrite something that is entirely fit for purpose.

A balanced MACH strategy will bring MACH principles in to start addressing those items on your Nay list, but it will also focus on maximising the value from systems on your Yea list. Looking at the big picture first allows you to focus on a strategy that delivers returns early and drives you towards both your business and technical objectives.