Loading Form...
Aug 7, 2020 | 5 minute read
written by Linda Bustos
According to Gartner, becoming a composable enterprise is the innovation strategy of leading digital organizations. Gartner believes “by 2023, organizations that have adopted a composable commerce approach will outpace competition by 80% in speed of new feature implementation.” And by 2024, the analyst firm predicts 30% of organizations will embrace modular architecture (by adopting packaged business capabilities) when constructing ecommerce applications.
Composable Commerce means moving away from the full-stack ecommerce platform, and towards building a best-of-breed solution from smaller, “Lego block” components. Ideal applications can be assembled in a way that supports specific business requirements and use cases. Because rarely does a full-stack, all-in-one application (whether home-grown or licensed from a vendor) fully satisfy the unique requirements of a business long-term, adopting Composable Commerce ensures today’s solution can stay in-step with tomorrow’s demands.
The modularity of the Composable Commerce platform is key to supporting more agile delivery, faster time to market and improved customer experiences across all devices and touchpoints.
What are packaged business capabilities?
A term coined by analyst firm Gartner, packaged business capabilities (PBCs) are the building blocks IT leaders use to create and compose new applications.
By definition, they are a “bounded collection of data schema and a set of services, APIs and event channels.” In practical terms, they are smaller applications built around clearly recognized functionality that hold their own data and business logic, rather than share a unified code base with each other (as with monolithic applications).
For example, in ecommerce a suite of packaged business capabilities may include Cart, Checkout, Customers, Account Management, Catalog, Pricing, Promotions, Orders, Payments and Search.
Are PBCs the same as microservices?
You may be thinking -- PBCs sound a lot like microservices! Today’s development and vendor community may refer to packaged business capabilities as microservices, and in many instances they’re not wrong. Some microservices are PBCs, but not all PBCs are microservices. The key difference is business capability, and the acid test is whether a microservice is designed to deliver well-defined business capabilities, recognized as such by business users.
For example, a highly granular microservice like an Address Verification API is an important piece of the checkout process, but the Checkout encapsulates more functionality. The Checkout service is recognized as a packaged business capability, while Address Verification is a microservice, which (according to Gartner) needs only be a “tightly scoped, strongly encapsulated, loosely coupled, independently scalable application component.”
Because the term microservices is common vernacular when referring to modular commerce components, this Composable Commerce series uses PBCs and microservices interchangeably.
Loosely coupled
Unlike tightly coupled monolithic platforms where every service shares the same codebase, loosely coupled services can be independently updated. New code can be delivered in an agile way and debugged without full-system QA. If you’re building services in house, this enables you to take advantage of DevOps and CI/CD (Continuous Integration/Continuous Delivery). If you’re using third-party, vendor managed services, you don’t need to modify any backend code, and you benefit from your vendor’s own ability to leverage DevOps and CI/CD to deliver updates faster than monolithic vendors.
Another benefit of loose coupling is the ability to integrate services closer to the experience layer or “head” through APIs, rather than in the code itself. This supports faster time-to-delivery without adding technical debt to the platform. Innovation can be rolled out to new touchpoints and rolled back just as cleanly.
Independently deployable
Not only can independent components of a composable platform be swapped in and swapped out as needed, they can also be selectively applied to new experiences you build.
With a monolith, a new touchpoint such as mobile self-checkout, curbside pickup or voice-enabled chatbot must be hardwired to the entire backend system (and often, the monolith simply can’t support what the end experience requires). With modular applications, only the required services’ APIs and logic are involved.
Independence also supports efficient reuse across touchpoints. For example, the same Catalog service can power multiple storefronts within your organization or partner network. Cart and checkout can be embedded into a wide range of content, apps and experiences. Inventory can be extended to backoffice systems and dedicated apps for sales reps and dealers. Data and logic can be shared and consistently maintained across touchpoints and channels, or configured with precision to unique requirements.
Independently scalable
Because modular applications are individually deployed to a public cloud, they can scale independently -- indefinitely. This presents a critical advantage over monolithic applications which can only scale up or down as a whole. With a composable application, a spike in demand for one component won’t slow or take down the entire app. Not only does this enhance uptime and customer experience, it keeps hosting costs under control.
For example, if you roll out a new mobile self-checkout solution to 100 physical stores, demand for the feature’s related services can surge, while other pieces of your composable commerce platform remain steady. Or, if you suddenly add one million new SKUs to your catalog with new attribute fields, complex pricing and discounting rules, Catalog and Pricing can scale accordingly, without having to scale Search, Cart, Checkout and Accounts.
Future-proofing commerce technology
A composable commerce application allows an organization to be more flexible and adapt to business change rapidly with less friction, and less risk introduced into the backend environment. Because “lego bricks” can be swapped in and swapped out for best-of-breed, a composable enterprise can stay perpetually modern without having to endure a rip-and-replace replatforming or full-stack upgrade ever again.