Loading Form...
Thank you! The form was submitted successfully.
Apr 12, 2022 | 4 minute read
written by Tim Norman
It seems the mood music has shifted away from monolith to composable, at least for those organisations looking to gain significant competitive advantage and be able to differentiate themselves by innovative use of technology.
The logic seems clear; select the "best-of-breed" technology at every stage of your development, and progressively up-platform as the requirements grow and change. You may not need a CMS for the MVP / early phases, but you’ll need to plug one in further down the road - that works. Or the tax engine you currently use is OK until you expand into new regions and need to provide additional coverage, no problem.
However, there are two camps emerging in composable which, whilst on the face of it appear similar but can result in radically different outcomes.
Before exploring further, let's look at the typical capabilities that a business needs from a modern commerce solution (in addition to commerce) - front to back:
and of course various back-end ERP, CRM, etc.
A lot of software, but the key thing is that the composable solution should be focused on "what does the business need at this stage of the programme?
Put another way, what is the simplest and easiest way of delivering the business outcome, not "best-of-breed" per se, but "best for me" - and that is critical to your selection of a commerce vendor.
Because, as one starts to review the components and build out a composable commerce solution, it becomes clear that at the very heart, the commerce engine, there are two distinct schools of thought emerging - let's call them minimalist and most complete.
Launch and optimize innovative experiences fast, with a modern, headless, SaaS, API-first, & microservices-based commerce platform.
On the minimalist side we see commerce vendors pushing pretty much all the functionality onto third parties, and I don't mean things that shouldn't be in commerce like Search, CMS, or Marketplace, but core components that any serious organisation needs to operate at the most basic level. In here I put capabilities like Catalogue Management, Pricing data and Product Data (Including Bundles and Variations).
The minimalist approach says "oh, that's OK, all you really need is the cart/checkout and the rest comes from 3rd parties." Which is fine, if you are never going to change your current ways of managing your catalogue, pricing, or product data.
But that's wrong. And the reason is that you are effectively committing to building a bespoke system, from the ground up, from day one. Not only does this dramatically increase the cost, time, and risk to the project, but by its very essence, you are committed to custom build, which means it's not covered by vendor support or SLA, SI/Agency lock-in and growing technical debt.
Of course, it also restricts your choices as you move from MVP through the subsequent phases of your rollout. Without core capabilities you will always have to go outside the commerce engine to manage your catalogues for example - or put another way, you will always have to pay for that capability above and beyond the commerce fee - same for promotions, etc.
The most complete view may look only a little different, but the outcome is radically different. The argument from this camp is that a well-rounded commerce engine will do, functionally, what you need it to do, most of the time, and certainly for the MVP and early phases. Yes, checkout and cart, but also allow you to manage your catalogues, your promotions, your variations, your bundles - you know, the basic things that your merchandising team needs to do to get an offer to your clients and prospects.
The result is a quicker, cheaper, less risky rollout; with more time to spend on innovation, less on heavy lifting, and quicker time to revenue. Not only are you not building core commerce from the ground up, but critically, you get to decide when and if to take on additional functionality - do it when the business requirement is there, not from day one when you must purchase because the capability is lacking in the core commerce platform.
I guess it's OK to just use your commerce system for a cart/checkout and do bespoke build. But if that's all you are going to use it for, then make that decision with open eyes, and pay accordingly. Choose best for me, don't be forced to take best-of- breed due to lack of capability in the core.