In a former article, we discussed what Composable Commerce is and why it is crucial for companies to adopt. In short, brands which prioritize infusing digital throughout their whole strategy require a trade framework that enables them to build, deploy, and optimize encounters effortlessly.
Packaged Business Capabilities are part of Composable Commerce and are utilised to make a best of breed solution. However, having talked to prospects and clients, it became evident that there’s a whole lot of confusion. Most business people are on-board with the microservices concept, but currently there’s a new kid on the block, which raises many questions. What are Packaged Business Capabilities? Are they distinct from microservices? How Packaged Business Capabilities relate to microservices or alternative architecture patterns?
This report provides answers to those questions, and places Packaged Business Capabilities one of the contemporary architecture terminology.
See our products:
Based on Gartner: Packaged business capacities (PBCs) are software elements representing a well-defined business capacity, functionally identifiable as such by a business user. Technically, a PBC is a bounded set of a data schema and a set of services, APIs, and event channels. The well-implemented PBCs are complete to guarantee autonomy (no crucial external dependencies, no need for direct external access to its information ). PBCs are supposed to be utilized as building blocks for application product suites and custom-assembled application encounters.
Microservices have many definitions. We’ll choose the one by Sam Newman: microservices are small, autonomous services that work together. A simple explanation, but many attributes in the picture below compliment it.
As you can see, there are a whole lot of similarities: modeled around the company domain, decentralized, isolated. Because there’s no defined size for microservices and Gartner claims that PBCs may also vary in size, it may get confusing.
PBCs and Microservices
The key to establishing a connection between the two conditions is to understand that microservices are an architectural style that defines the way you divide the application into”services” — a well-defined applications term. While PBCs are described as building blocks for applications or suites. From this standpoint, they are free, and PBCs is considered aggregations of microservices. The amount of microservices could be one or more, as depicted in the picture below. Now all of the similarities in definitions make sense.
Now, you may be asking questions:”why do I want PBCs? What’s the point? Where’s the value?” .
Theoretically, in the microservices world, you can make a best of breed solution comprising 50 microservices, each being from another vendor. But nobody does it since the integration costs will be sky high and it’ll outweigh any benefits. Imagine your business users needing to cope with 10 UIs from different vendors within a single trade application. It appears to be a nightmare as it is. This is the reason why businesses usually consume applications in bigger pieces.
Consumption includes multiple facets, including:
In a nutshell:
- Microservices are the best way to design, construct, and deploy your application.
- PBCs are the way you bring your application to market and how your users consume it.
Reduced Complexity to the Company
With PBCs, a company has to take care of a smaller number of building blocks. Consider it as the exact same way people group animals into six main animal groups: amphibians, fish, birds, invertebrates, mammals, and reptiles. It’s just easier to take care of it this way. Overall it makes it easier to understand the value offered by the application, create a best of breed solution that suits their requirements, deploy it, and train their employees.
Streamlined go-to-market for the vendor
While the company application’s core capabilities and value will not often change, how it’s broken down into microservices will be shifting over time. New microservices may appear, and the older ones could be altered to accommodate new technologies and frameworks. From the SaaS environment, the underlying structure isn’t exposed to the client as they absorb the APIs. Because of this, PBCs enables the business to Keep their customer-facing
What is the correct size for PBC?
PBC size will differ from application to application, and the vendor should specify PBCs based on how their clients have their application, but I will provide a few concerns:
- A PBC is too little if there’s absolutely no business user or use-case that would require the PBCC separately from another PBCs. Case in point: nobody could use eligibility rules without catalogue master data management.
- A PBC is too big once you get into a situation where client absorbs different parts (microservices) rather than the entire PBC. Example: if stock is frequently not used and substituted using a 3rd party service, it ought to be split into a different PBC.
- A PBC is of the perfect size once the client can immediately link it to the business domain and immediately explain what they expect out of it. Case in point: likely, every user will instantly understand what Catalog is all about.
►►► ConnectPOS is a cloud-based POS software compatible with multiple platforms including Magento, Shopify & Shopify Plus, and BigCommerce.
Our Feature Posts: