Loading Form...
Sep 9, 2021 | 9 minute read
written by Hannah Jarrett
This post was originally published on June 9th, 2020 and has been updated for relevancy and accuracy on September 9th, 2021.
There is a lot of buzz in the commerce market about "Packaged Business Capabilities". But, having talked to prospects and customers, it became clear that many folks are confused about this topic. While technical teams are onboard with the microservices concept, they are less familiar with this new term. What are Packaged Business Capabilities? Are they different from microservices? How do Packaged Business Capabilities relate to microservices or other architecture patterns?
This article provides answers to those questions, and places Packaged Business Capabilities among the modern architecture terminology.
Packaged Business Capabilities are a part of Composable Commerce approach and are used to create a best-of-breed commerce solution.
According to Gartner: Packaged business capabilities (PBCs) are software components representing a well-defined business capability, functionally recognizable as such by a business user. Technically, a PBC is a bounded collection of a data schema and a set of services, APIs, and event channels. The well-implemented PBCs are functionally complete to ensure autonomy (no critical external dependencies, no need for direct external access to its data). PBCs are meant to be used as building blocks for application product suites and custom-assembled application experiences.
Microservices have many definitions. We will take the one by Sam Newman: microservices are small, autonomous services that work together. A straightforward explanation, but several characteristics in the image below compliment it.
As you can see, there are a lot of similarities: modeled around the business domain, decentralized, isolated. Because there is no defined size for microservices and Gartner says that PBCs can also vary in size, it can become confusing.
The key to establishing a relation between the two terms is to understand that microservices are an architectural style that defines how you break down the application into "services" – a well-defined software term. While PBCs are defined as building blocks for applications or suites. From this perspective, they are complimentary, and PBCs can be considered aggregations of microservices. The number of microservices can be one or more, as depicted in the image below. Now all the similarities in definitions make sense.
The difference in principle between the two is that microservices are an architectural style loved by developers while PBCs tie more directly to the business team’s needs. Microservices are embraced by developer teams as independent components with lightweight APIs that make building solutions faster and easier.
They are fantastic for tech team’s speed and efficiency but on a day-to-day basis, they don’t mean much to a business leader (like a CDO or CMO) or user (like a merchandiser or marketing manager).
On the other hand, PBCs are created to directly align to a business use case or outcome, and therefore they provide tangible value for business teams. For example, order management.
At this point, you might be asking questions: "why do I need PBCs? What is the point? Where is the value?".
Theoretically, in the microservices world, you can create a best of breed solution consisting of 50 microservices, each being from a different vendor. But nobody does it because the integration costs will be sky high and it will outweigh any benefits. Imagine your business users having to deal with 10 UIs from different vendors within a single commerce application. It sounds like a nightmare because it is. This is why businesses usually consume applications in larger pieces.
Consumption includes multiple aspects, including:
In a nutshell:
With PBCs, a business has to deal with a smaller number of building blocks. Think of it as the same way people group animals into six primary animal groups: amphibians, birds, fish, invertebrates, mammals, and reptiles. It is just easier to deal with it this way. Overall it makes it easier to understand the value provided by the application, create a best of breed solution that fits their needs, deploy it, and train their personnel.
While the business application's core capabilities and value won't often change, how it is broken down into microservices will be changing over time. New microservices might appear, and the older ones may be altered to accommodate new technologies and frameworks. In the SaaS environment, the underlying architecture is not exposed to the customer as they consume the APIs. Because of this, PBCs allows the business to maintain their customer-facing.
Access a free Elastic Path trial today to see our leading composable commerce solution in action.
To make it super clear, let me provide you with an example using “Customer & Account Management”, a set of functionalities that is core in eCommerce solutions.
Customer and Account Management is a packaged business capability. It allows business users to manage accounts with complex organizational hierarchies, which include multiple divisions, departments, and buyers.
It will enable them to define and configure users with different roles in the buying process, including buyers, approvers, budget owners. These capabilities provide value for business users because they enable commerce use-cases necessary for a business to sell to customers, especially those in B2B, efficiently.
How it is broken in microservices is an entirely different story. This packaged business capability relies on multiple microservices, including role-based-access control, address management, customer management, and more.
It is important to note that as the packaged business capability evolves, more and more microservices can be added to it if necessary. Whether new microservices will be added or new features will be added to existing microservices is an architectural decision done by vendor product development teams.
PBC size will differ from application to application, and the vendor should define PBCs based on how their customers consume their application, but I will provide some considerations:
The simple answer is – yes. Suppose the application's scope is small enough that it is always consumed as a whole and is virtually indivisible by a business user. In that case, the whole application can be considered a PBC. And of course, the application should satisfy the requirements provided by Gartner. Example: a payment gateway with APIs is a PBC.
The Importance of PBCs & Microservices in eCommerce Software Evaluations
This difference between PBCs and microservices matters for brands evaluating modular eCommerce software because different members of your organization will need to review, understand, and evaluate microservices OR PBCs. As always, you should think about your business goals first. Most of the time brands wants to solve a particular business problem, and business teams will be looking for a specific packaged business capability which does it the best.
How the capability is split into particular microservices is essential for the technical team as they are developing against microservices, and it impacts the overall software design. Many other aspects of the commerce platform, which are impacted by microservices-based architecture such as operational costs, composability, high availability, extensibility can be understood during a solution demonstration or a trial.
In the end, most often, customers make purchasing decisions based on their need to meet particular business goals, versus their preference for a technical architecture. If you are leading an eCommerce software evaluation remember that it is all about the business value delivered by the specific architectural approaches, principles, and concepts.
Throughout the evaluation you should be mindful of educating the right teams on the right terms and technology. For the most part, developers & tech teams care about microservices and business teams will care more about PBCs.
Explore how Elastic Path Commerce Cloud microservices-based architecture provides benefits for business and technical teams by enabling superior technical agility.
Subscribe to our blog to stay up-to-date with the latest commerce industry insights, tips & tricks, merchandising and development best practices, and more!
You'll receive a welcome email shortly.