Moving to MACH should be used by organizations to decentralize decision making, enabling more nimble approaches driven around the core tenet of ownership. MACH can help build flexibility, ownership, and innovation throughout your company.
MACH is a powerful framework for building modern digital architectures. In this article, we’ll look at how this modern architectural framework impacts your organization.
First, let's get some definitions out of the way. What is MACH? MACH is a reference architecture that stands for Microservices-based, API-first, Cloud-native and Headless.
Over the last couple of decades in enterprise architecture, capabilities have typically been built using monolithic application frameworks, either hosted in the enterprise data center or a co-located data center with other organizations. These monolithic applications typically provide application functionality, transactional processing, and user interfaces.
MACH architecture turns this around by building capabilities in functionally devolved services that are optimized for a single piece of functionality - hence the name microservices.
Further, they are API-first: everything the service does is using an API (Application Programming Interface). Most services in this model provide two kinds of APIs:
A good example of the benefits of API-based architecture is DynamoDB, where you use the control plane to create your table structure, set your usage patterns and limits, as well as the data plane that you use to actually read and write data from the tables.
The third component of MACH is cloud-native. To be frank, moving to the cloud doesn‘t make your system inherently better. Instead, moving to the cloud changes two things:
Moving to the cloud forces teams to think about continuous development and deployment, continuous testing, and operational excellence.
The Headless model is in many ways related to the API first approach. Because everything is exposed as an API, you are now free to pick whatever UX framework best suits your needs, knowing that your underlying systems can be accessed just as easily.
Now, let’s talk about what this means organizationally. Typical enterprise organizations, due to their monolithic nature, tend to have monolithic organizations. A central planning team, a central architecture team, a central testing team, a central deployment and operations teams. Developers are typically back-end or front-end and are pulled into projects as the need arises.
MACH architecture upends this organizational structure. No centralized team can make the multiple decisions needed for each microservice - from the language used for development to the data structures used to the data persistence layer. Similarly, centralized testing and deployment teams will struggle in this environment because they will, by necessity, be dealing not with one gigantic monolith, but literally tens of different services.
MACH enables enterprises to move organically to a more ownership-driven culture. In this model, central teams go away, but their capabilities don’t. The capabilities are devolved down to individual teams. Teams own one or more microservices from top to bottom. They define the architecture, the programming language used, and the back-end storage used. They also make the build-vs-buy decisions, test their own services and deploy and operate them independently. Teams go to sleep and wake up in the morning thinking about what they own and what they need to do to make it better, either functionally or operationally (e.g. reducing defects, improving latency). Just as importantly, moving to a MACH architecture enables business productivity improvements via business engagement in application development, resulting in more effective product management.
So how do you structure these decentralized teams for MACH technology? Ideal teams are composed of no less than 5 and no more than 10 developers. If the team also builds user interfaces, these are full-stack developers.
Let’s walk through a typical eCommerce function: the shopping cart. Depending on your use-case, a shopping cart usually fulfills the transactional function of adding items to the “cart” that is then used to check out.
But it also interfaces with a multitude of other services, like:
Furthermore, the cart service itself might be used in other areas. For example, the product detail pages might have a widget displaying the number of items in the cart.
Moving to MACH architecture enables each of these functions to be performed independently by a dedicated service run by a dedicated team. The product service team can improve it’s latency without impacting the cart, the recommendations service can improve its quality of recommendations without impacting the cart, and so on.
One key question around such organizational models is what happens if a team is too busy to take on a functional requirement from another team. This will happen in some cases. A common solution to this is the application of the “Away Team” concept.
For example, if a team needs to add functionality to the shopping cart but the shopping cart team doesn’t have the bandwidth, the team with capacity works on the shopping cart, under the supervision and direction of the cart team; the cart team approves the design, reviews the code and testing, and once complete, takes ownership of the new code.
In conclusion, moving to MACH services should be used by organizations to decentralize decision making, enabling more nimble approaches driven around the core tenet of ownership. Continuing with centralized organizational models in a MACH world will likely not provide the benefits of agility, simplicity and throughput that organizations desire. Instead, MACH can be a part of a program to build flexibility, ownership, and innovation throughout your organization.
