Understanding the Total Cost of Ownership and ROI for MACH Architecture
In this blog post we break down every component to consider when calculating the Total Cost of Ownership (TCO) of a MACH-based architecture. This will enable you to measure macro vs micro level ROI decisions and help your business transparently de-risk, understand and navigate the costs associated with a MACH-based strategy.
The monolithic TCO & ROI problem
In a traditional monolithic platform-centric or suite-based approach, pricing is relatively well defined for core capabilities and you know exactly what you are getting “out of the box”. This is at least true in the beginning - your company needs assurances of costs over time so you have confidence in projecting and executing your business strategy over the next one, three or five years and beyond. This in turns leads you to locking yourself into a large enterprise multi-million dollar contract. The decision making process is elongated to get this over the line and is exacerbated by multiple decision-makers and stakeholders along the way. You can end up spending six months to a year drafting RFPs and evaluating vendors before you pull the trigger. The speed of innovation and pace of change at your business can be constrained by approaching the problem at a macro level and making large sweeping changes and gambles.
The sunk cost fallacy trap
Typically retailers and brands experience large, risky and costly monolithic re-platforming exercises every 3-5 years - this is a macro level investment. It may not be apparent at the initial point of investment but change is constant within your business and externally in the market. New business challenges, competitors, strategies, tactics and requirements constantly arise, leading you to further enhance and extend your existing monolithic platform beyond what it was originally designed to do. Over time these rigid systems can become incredibly costly to customise and extend to meet your exact requirements. Your initial, large and slow macro decision lead to many smaller micro decisions, unforeseen spiralling costs and the potential trap of the sunk cost fallacy.
The cost of maintaining the status quo
The cost of maintaining the status quo is ‘the cost of the current solution’ plus ‘the cost of not being able to adapt your business fast enough and the lost revenues and customers’. Money is not the only resource at your disposal, time is also a limited and rarely appreciated resource. Therefore, the cost of maintaining the status quo needs to be looked at not only in monetary terms, but also in the speed and agility of the execution. But how do you measure the velocity of your business? The variable formula you need to understand is distance = time x speed. Whilst difficult to measure opportunity cost, how fast could you be travelling with the right strategy and underlying technology to get you to your destination in as little time as possible with firm foundations that are flexible enough should you need to adapt during your journey?
The MACH TCO & ROI problem
With MACH architecture there’s potentially a lot of moving parts at play. You’re no longer operating with a single vendor for a whole solution, but multiple vendors all with differing pricing models that comprise a whole solution instead.
To address this MACH vendors work together with solution integrators (SIs) to create compelling packages to compete with monolithic platforms and suites, in turn making it easier for you to understand the TCO. This is one of many reasons why the MACH Alliance exists, to demonstrate to retailers and brands that a new approach is possible and an ecosystem-centric approach with healthy symbiotic relationships is mutually beneficial for vendors and their customers, creating well defined whole solutions.
How to avoid the sunk cost fallacy trap
MACH allows you to break the problem down into smaller business problems by leveraging best-of-breed vendors to solve those challenges, granting increased agility and spreading the cost and risk out over time. We consider these decisions to be smaller and therefore defined as “micro”. Individual vendor ROI also becomes easier to measure in isolation.
If your business requirements change over time or you reach the limitations with a small part of your overall architecture, the problem is compartmentalized for you to address with a micro decision. These decisions can happen much faster, with a smaller pool of stakeholders, unlocking your business from the monolithic decision making paralysis and increasing your businesses velocity to unprecedented levels.
A MACH strategy is, by its nature, transformative. As a result the impact on a business is going to go beyond traditional “hard” ROI measures. There will be an impact on softer factors of creating growth and success within a business. There will also be immediate ROI gains, especially if you prioritise your roadmap based on where the biggest uplift will be. Some of the deeper, more fundamental impacts on ROI will be structural. MACH also represents an increase in complexity with more vendors to manage than a “monolithic” approach, there are initial costs associated with this in the short term.
The benefits of a MACH transformation Strategy fall into three categories:
Licenses - Unless going greenfield or “big-bang” adopting MACH gradually will result in a higher initial License costs as you pay for incumbent and new platforms. Also, license fees are the one cost that vendors distort, especially first year or where they are under threat. Historically this has worked for vendors where a technology decision was planned for a 5-10 year lifespan and they could earn it back, safe in the knowledge that you were not going to be able to get rid of them that easily. MACH changes that and allows for a strategy that supports swapping vendors in and out more easily.
Licenses will contribute to a positive ROI but not initially.
Efficiencies - technology in itself only gets you so far in terms of efficiencies. An API and Cloud led ecosystem will introduce efficiencies in terms of integrations and flexing with demand. However, the largest efficiency gains in a MACH ecosystem come from introducing Ways of Working as a business that make the most of what MACH brings.
In this case it is using the move away from historical waterfall, siloed structures with release cycles and upgrade paths. MACH brings an end to upgrade cycles, in itself a costs saving.
DevOps, Automation and CI/CD combined with Cross-functional Agile teams, Product-led roadmaps and shared KPIs will achieve massive savings. MACH technologies are designed to support this Way of Working.
Test and release automation significantly reduces direct costs. Done properly it can remove any need for rollbacks, reduce development costs and the risk of delayed delivery.
Efficiencies will generate a significant chunk of the ROI and in building this out consider the following:
Salary and team costs - how much do you currently spend on manual testing, release management and fixing bugs post-release.
Reduced upgrades - What is your annual average spend on upgrades? MACH solutions, by definition, have no upgrade overheads.
MACH technologies do not inherently lead to increased conversion rates, traffic uplift or AOV, although a more recent technology may result in an uplift. For example, leveraging a headless frontend or modern JAMstack based site is likely to be highly performant with lightning fast page load speeds resulting in a positive impact on conversion, organic search engine result pages (SERPs) rankings; resulting site visitors; and increased Average Order Value (AOV).
Growth requires a business to be consistently adapting to market needs or taking advantage of new opportunities. Inertia through inability to take advantage of opportunities is one of the biggest challenges a business faces. Adopting a MACH strategy, building out modular, api connected ecosystems can go someway to solving inertia problems, If a module becomes a bottleneck or a better solution comes along, it is easier to replace.
Growth is also a direct result of Ways of Working, discussed earlier. Ensuring that your business can spot an opportunity, react and deliver to address it is as important as the technology enabling this.
Missed Opportunities - how much potential income is lost because your IT, Delivery and Commercial teams are not aligned, have different KPIs or your roadmap is challenged due to current technology?
Speed to Market - if you could deliver more and in shorter time frames, what is the benefit in terms of growth?
More difficult to measure, but an environment where each part of your business is aligned and working to joint goals makes a better working environment. Difficult to pinpoint , but a company that can deliver innovation quickly and without structural frustrations is a more exciting, fulfilling place to work. This will have an impact on productivity, attraction and retention of top talent.
Breaking down the Total Cost of Ownership (TCO)
To break down the TCO we can start by identifying typical cost categories in a MACH based implementation and how each is priced, including;
- Core services
- Complimentary services
- Public and private pricing models
- Implementation costs
* Internal vs external resourcing
* Scope, experience, complexity of solution, number of vendors, existing systems etc..
* Frontend - Buy vs Build
* On-going maintenance & iteration
MACH vendors, services and components
Vendors, services and components all use different variables to determine how they price. Some of these variables are category dependent; though there are additional details worth noting at a vendor level. All information on how vendors price in this section is accurate at the time of writing; for accurate up to date information we highly recommend checking out specific vendor pricing pages if they have one or reaching out to discuss pricing with each vendor you are interested in exploring further.
A few general things I can say about it is:
Commerce platform/orchestration & order management - Typically charge fixed fees and % of GMV.
* commercetools e.g. - Based on monthly AOV and order volume, no self-service offering but an open trial is available.
CMS - Typically priced by traffic and throughput.
* Amplience - Annual subscription fee based on visits per month. The average contract length is 24-36 months. Currently no self-service offering however gated trials are available.
* Contentful - Offers a free community plan, self-service paid plans, custom enterprise plans and open trials.
* Contentstack - Based on traffic but offers no self-service option, although gated trials are available.
DAM - Typically priced by traffic and throughput.
* Amplience - Annual subscription fee based on visits per month. The average contract length is 24-36 months. Currently no self-service option and gated trials are available.
* Cloudinary - Free trial, monthly and annual self-service plans and custom plans are available.
Search & Personalisation - Typically charge by data volume and searches in a given period.
* Algolia - Based on search request volume, monthly and annual plans available; Free plan and open free trial available. Custom enterprise plans are also available and recommended starting at over 500,000 searches per month.
Complementary and ancillary services
Payments providers are unavoidable for any ecommerce business and a primary cost of doing business. Payment gateways typically charge 2-3% per transaction, discounts may be available at scale. Watch out for fixed minimum transaction fees, this is especially relevant for micro-transaction and low-margin businesses. High value luxury goods and those with high average order values might struggle with higher percentage transaction fees too, some payment gateways cap the fee they take too.
Additional services you may already have in your architecture or look to implement with core MACH providers include; PIM, Tax calculation, Shipping, Fulfillment, ERP, OMS, promotion engines, personalization and loyalty systems and robust analytic tools. These should be factored into your overall MACH TCO.
Public and private pricing models
Public pricing can give you a good sense of what to expect from a self-service model and where enterprise pricing plans are likely to begin. If a vendor does not provide a self-service model they may describe how they price or request you speak to their team to discuss your requirements and create a tailored plan that is within your overall budget. Opaque enterprising pricing may be off-putting to some stakeholders within your organization at first but it’s really worth reaching out and having a pricing discussion with several shortlisted vendors.
Implementation costs can vary widely depending on resourcing approach, project management, scope, experience, complexity of solution, number of vendors, existing systems etc..
Internal vs External Development Costs
You will likely work with your internal development team or external systems integrator (SI) to produce a scope of work document that outlines each line item of an integration, the level of effort, time and resources required.
SIs typically offer either fixed price contracts or time and material (T&M) contracts when it comes to implementation of a MACH based architecture. MACH Alliance SIs include E2X, EPAM, Four 51, Mindcurve and Valtech (at the time of writing this piece).
What is a fixed-price contract
A fixed-price contract is a single-sum agreement where the SI completes a project within the agreed sum and the given deadline. Despite what many people think, this pricing model is not always suitable for companies with a limited budget, as a MACH based project may evolve over time. For a fixed-price project to be successful, it demands defining all of the expectations upfront and gives you a clear view of what to expect once the project is complete. A fixed-price agreement will fit a smaller project with fewer best-of-breed components to start out, where you know exactly what you want.
Time and material contracts
A time and material (T&M) contract is completely different from a fixed-price contract as it bills you, the customers, for the amount of hours the SI spends on the project along with the costs of necessary materials. Even though the hourly rate is set, it can be more difficult to estimate the total cost of the project. However, this pricing model offers you much more flexibility when it comes to agility, allowing you to course correct and adjust requirements during the project itself. You then do not need to provide the SI with a clear vision and instead can work with them throughout the course of the project to identify and execute a vision as it unfolds. It is recommended that a T&M contract is chosen for larger and more complex projects with many unknowns at the outset that may arise during the development process.
It may also be prudent to think about a mixed blend of both types of contract to give your business some line-of-sight towards fixed milestones whilst also allowing for increased flexibility and agility mid-contract to make adjustments when required.
Frontend Buy Vs Build
Frontends come in two flavours, open source versions and frameworks that you adopt that provide a great starting point to build from and cloud-based storefronts that you purchase and integrate with your backend technologies.
Vue Storefront - Comes in two flavours, the first being the Open Source Version with a Free, MIT License and the second as a cloud-based approach, charged as a % of other project licenses costs, aligned with payment terms, length, SLAs etc..
Frontastic - Offers a cloud-based frontend with customized pricing plan based on various aspects, including number of monthly page views, number . of domains and number. of users etc, so they grow with the success of the customer. License plans are recurring models with payment plans part of the custom contract. Contract length can vary with usually a minimum of 24 months.
Beyond these approaches you could also choose a DIY build from scratch approach but typically these take longer to execute, cost more money, require your implementation team to understand and execute best-practices to attain world-class frontend performance and in general means you’re adding even more overhead to your MACH architecture that you could likely do without worrying about.
Beyond these considerations you will also need to take into account your existing architecture and vendors that you want to bring forward in your MACH architecture or add new ones that aren’t mentioned in this guide such as your broader Martech stack. Many MACH vendors provide out of the box integrations or guides on how to integrate with other 3rd party services, these can help keep implementation costs down. Some systems may require custom development to integrate with your new set of tools, whilst this may sound like a heavy and complex process can actually be done with relatively lightweight middleware layers, serverless functions and a few lines of code.
When it comes to specific integrations for your use case and architecture you should always approach your selected MACH vendors and request assistance or insights, chances are they either have already seen a customer implement your exact integration scenario or have seen something similar and can provide some level of advice. It is of course in their best interest to help you with your MACH implementations to be successful! Some vendors may also offer integration services to cooperate with your development team or SI.
On-going maintenance & iteration
So you’ve implemented your core MACH services and you’re now in production with a scalable and highly performant MVP. You’re leveraging best-in-class technologies, your sites and shopping experiences are lightning fast, nice work!
From here you will need to factor in additional complimentary services and on-going maintenance costs with an eye towards an agile, rapid and iterative approach. Continue to measure performance, understand and define challenges you face so you can map your business requirements and jobs to be done. Identify bottlenecks in your internal business processes or customer journeys and work closely with your MACH vendors, SIs and solution architects to resolve/optimize issues as they arise.
CloudOps - Once you’re in production monitoring and uptime will become an important pillar of your architecture; plan for this ahead of launch and ensure you have budgeted out the on-going costs. Downtime can have a huge impact on your ROI; vendor SLAs are your insurance policy, make sure you identify critical components of your MACH architecture and agree robust SLAs with those vendors.
Factoring in all of the above, you will likely need a point of contact and small development team on standby for when things go wrong, no solution is 100% perfect but atleast with a MACH based architecture your business will be well positioned to take advantage of the increased agility and reduced time it takes to solve new challenges. These small development teams can be complemented by additional external resources and SIs as required.
Our top ten takeaway tips and recommendations
- Ensure someone within your organization is responsible for measuring ROI (typically a CRO but may fall to the CEO, CIO or CTO). Keep track of vendor, implementation and maintenance cost line items - they can be useful internally and externally!
- Speak to your vendors about pricing and be transparent about your overall budget, vendors may be able to accommodate if they can understand your existing or planned MACH architecture.
- Plan your short vs long term implementation strategy (rip & replace or strangulation/dehydration pattern) and stick to it.
- Align your organisation to the concept of agile best practices within the decision making and implementation process.
- Don’t let perfect get in the way of good enough, rapidly iterate towards where your business needs to be.
- Look to a trusted SI for guidance and ensure they are aligned with your growth objectives, think of them as a trusted advisor.
- Ditch the bloated monolithic RFPs in favour of simple RFPs and scoring exercises to create vendor short-lists to accelerate your decision making process, you’re now making smaller decisions so it’s easier to control your exposure to risk!
- Ensure you agree robust SLAs with critical vendor components.
MACH TCO example and template
Want to apply the principles outlined in this article? You can find an example sheet and template here.
About the Authors
As a founder of Moltin, one of the first headless commerce platforms, Adam Sturrock had to wear many hats over the past 7 years from sales and marketing through to customer success, Adam worked closely with customers to bring their MACH-based architecture into reality. Adam brings some unique insights and a holistic view into understanding the Total Cost of Ownership for a MACH-based solution beyond a single vendor or SI. Adam is now a product marketing consultant (working with Amplience, a MACH Alliance Member) and enterprise solution architect.
Matt Bradbeer is Client Partner at EPAM and has been involved in Digital, DotCom and eCommerce for over 20 years. Starting in product and moving to management and leadership roles across some interesting brands and companies. He has run a multi-billion dollar online business, worked for several start-ups and made a few of his own before jumping the fence to the Agency World.
MACH: Business Technology for 2020 and Beyond
”66% of developers find that maintaining and “paying for” technical debt (aka the money, flexibility, and opportunity lost to a bad technical investment) associated with outdated technology is bad for their productivity at work." State of the Developer report 2109, Devada