What are Packaged Business Capabilities?
In a previous article, we discussed what Composable Commerce is and why it is essential for businesses to adopt. In short, brands that prioritize infusing digital throughout their entire strategy need a commerce framework that empowers them to build, deploy, and optimize experiences seamlessly.
Packaged Business Capabilities are a part of Composable Commerce and are used to create a best of breed solution. But having talked to prospects and customers, it became clear that there is a lot of confusion. Most industry folks are on-board with the microservices concept, but now there is a new kid on the block, which raises many questions. What are Packaged Business Capabilities? Are they different from microservices? How 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.
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.
PBCs and Microservices
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.
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:
- Microservices are how you design, build, and deploy your application.
- PBCs are how you bring your application to market and how your users consume it.
Reduced Complexity for the business
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.
Streamlined go-to-market for the vendor
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
What is the right size for PBC?
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:
- A PBC is too small if there is no business user or use-case which would need the PBCC separately from the other PBCs. Example: nobody would use eligibility rules without catalog master data management.
- A PBC is too large when you get into a situation where customer consumes separate parts (microservices) instead of the whole PBC. Example: if inventory is often not used and replaced with a 3rd party service, it should be split into a separate PBC.
- A PBC is of the right size when the customer can immediately link it to the business domain and quickly describe what they expect from it. Example: probably, every user will immediately understand what Catalog is about.
Can a monolith application be a PBC?
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.
If you want to learn more about PBCs and Composable Commerce – check here.