Loading Form...
Sep 19, 2020 | 7 minute read
written by Linda Bustos
The shift from monolithic commerce platforms to modular, MACH-based, composable services is well underway for many brands, manufacturers and retailers.
With the release of Gartner’s report Composable Commerce Must Be Adopted for the Future of Applications and the firm’s bold prediction that 30% of digital commerce organizations will use packaged business capabilities (PBCs) to construct their application experiences by 2024, curiosity (and confusion) around how microservices and PBCs play into modern commerce architectures is growing.
So what are packaged business capabilities? Are they the same as microservices? How do you navigate a landscape where commerce technology vendors use these terms somewhat interchangeably, and know what approach is right for you?
A packaged business capability, by Gartner’s definition is a “software component that represents a well-defined business capability, recognizable as such by a business user…[and] consists of a bounded collection comprising a data schema and a set of services, APIs and event channels.”
In simpler terms, a PBC is an application or service built around a specific business function. Rather than the function being one component of a larger, monolithic application (such as an eCommerce platform, CRM or CMS), a PBC is decoupled from other services and communicates with other components through APIs.
If you’re thinking “PBCs sound a lot like microservices” -- you’re not far off. But by Gartner’s definition, a PBC involves a grouping of APIs (a bounded collection) that serve a specific business capability, versus microservices which are more tightly scoped and granular (though microservices may also have multiple APIs and endpoints within them).
However, some microservices do fit the criteria for a PBC. If a microservice represents a business capability in a way that is clear to a business user, it qualifies. Martin Fowler, known for coining the term “strangler pattern” as a metaphor for refactoring a monolith to microservices, asserts the focus on size can be misleading. In his conversations, he sees a range of service sizes and prefers to refer to them all as microservices, rather than argue over what constitutes “micro.” #HowBigIsAMicroservice
Today, many vendors and developers use the vernacular term microservices to refer to the modular, loosely coupled services they provide, regardless of size (or may use the terms microservices and packaged business capabilities interchangeably). As an application leader, it’s important to ask vendors the right questions and ultimately understand how any given modular service should fit within your composable application.
Both PBCs and microservices are headless, strongly encapsulated, loosely coupled, independently deployable and scalable. Thus, they both satisfy the tenet of modularity within the Composable Commerce paradigm. An application constructed PBC-first (focused on the business value of its modular components) has several benefits over one constructed from hundreds of granular microservices:
A commerce application consisting of hundreds of independent microservices, each with their own APIs and logic, requires tremendous effort to stitch together -- even when they come from the same vendor. A complex architecture not only requires an advanced degree of technical maturity and governance, but also larger budgets and resource teams.
Because bounded collections of APIs within a PBC are deployed as a unit, initial set up and maintenance is greatly simplified, as is changing business logic and integrating new components. This supports technical agility, accelerates time-to-market (and time-to-revenue), and can reduce Total Cost of Ownership.
Access a free Elastic Path trial today to see our leading composable commerce solution in action.
A composable architecture constructed with PBCs makes it easier for Business teams to participate in the design and deployment of new experiences. When components are easily recognized for their function in the business, both Business and IT can articulate how requests and requirements translate into the application roadmap.
For example, the Business may desire a mobile self-checkout solution to support social distancing within their physical stores, or to bring digital commerce to live events and trade exhibits. Business envisions Catalog, Pricing and Payments would connect with Cart and Checkout through a progressive web application, integrated with their third party Personalization and Analytics applications.
Packaged business capabilities also make it easier to provide user-friendly business tooling and dashboards for administrators, merchandisers, service reps and back office operations. Building such tools for highly granular microservices is not only a make-work project, but is also far less practical than constructing UIs for PBCs like Catalog, Accounts, Pricing, Promotions, Inventory, Checkout and Payments.
Off-the-shelf vendors are more likely to offer out-of-the-box business tooling if their own applications are PBC-first with a strong set of core capabilities versus highly granular with hundreds of microservices.
Though arguably “modular” and certainly part of a typical Composable Commerce environment, many ecosystem applications like Tax, PIM (or check out our Commerce PIM capability), Reviews, Search and Analytics do not fit the criteria for packaged business capabilities. There are some exceptions, such as headless and API-first solutions such as Voucherify for promotions.
Most ecosystem apps, extensions and “plug ins” are not API-first nor headless and are deployed as monoliths -- however small. They offer APIs to support integration, but their APIs are not configurable the same way as PBCs’ are. Typically delivered as SaaS applications, every customer consumes them in the same way as every other subscriber beyond a predefined set of customizations that the ecosystem vendor controls. If you can extend the application to accommodate your unique requirements, it’s typically achieved through changing code (which the vendor owns), not logic in the API layer.
The benefit of using third-party, bolt-on applications is to leverage best-of-breed within a composable application. A Composable Commerce Enterprise need not reinvent the wheels of highly specialized functions, and can benefit from a vendor’s own innovation and investment at scale. It’s important to ensure these third-party solutions can be configured through your core set of packaged business capabilities through an extensibility framework.
Just like microservices can be too micro and fail to represent clear business capability, PBCs run the risk of becoming little monoliths if they’re too large. For example, if tax capabilities live within Payments, Cart or Checkout services, the organization may lose agility around extending tax logic to the appropriate touchpoints. If tax logic must be continually changed, this can impact agility. The application will also be essentially locked into the tax solution as-is (or require duplication of services by hooking a separate Tax service into the architecture).
IT leaders must take a holistic view of their Composable Commerce environment. The beauty of Composable Commerce is you’re never locked into a specific vendor or service, and you can leverage a mixed portfolio of off-the-shelf PBCs and microservices, in-house services and ecosystem apps. Anything that no longer serves the business can be swapped out for something that does. The right granularity of each PBC at any given time should be determined by business need, and balanced with cost, complexity and time-to-market.
If you want to learn more from our specialist, get in touch. We'd be happy to help