Introduction to Packaged Business Capabilities

In the digital commerce space, there are a lot of movements around the Packaged Business Capabilities (PBC) concept, as well as countless speculations about what it is and what it isn’t. For that reason, I would like to give an overview of this software organization pattern and also shed some light on how it aids flexibility and agility within a composable enterprise.

When Gartner published an article giving a name to a concept that we had been working on at Spryker in the last few years, we immediately recognized that the problems Gartner was trying to address were not unique to Spryker customers alone. As a matter of fact, they were a set of well-known but yet-to-be addressed industry problems surrounding upgradability, best-of-breed vs “off-the-shelf” selection, customizability, and implementation speed. But let’s start from the beginning.

From the very beginning, Spryker followed a modular architecture approach, even when it was only a single PHP-based framework. In growing the number of frameworks like the back end, front end, data distribution, and API into the Spryker OS, we recognized a huge demand for addressing typical software problems in digital commerce. Some of these problems include: 

• Limited customizability
• Long development cycles
• High coupling of integrating resulting in vendor lock-ins
• Amount of update efforts, that’s quite similar to a replatforming

There are many best practices addressing these problems; one of them is the microservice architecture pattern which tries to solve the problem by decoupling services into independent deployables.

Can microservices alone address these issues?

A few years ago there were many prospects requesting microservices as a must-have for customizing their projects and looking for a silver bullet that would immediately solve all of the organizational, technical, and process issues. Many commerce vendors started offering that desired architecture as a set of distributed services or as an API gateway, while hiding the actual implementation.

One group of vendors broke down their systems according to the microservice approach, leaving their composition, connectivity and ops up to the different client projects decisions. In the beginning of the project, everything looked really nice: clean decoupling and full independence. What no engineer likes to see is dozens of services running and thousands of messages being transferred back and forth on an operator dashboard. There are 3 things people can watch forever: fire burning, water falling and messages flying from one service to another.

After 2-3 years of project development, when the basic commerce commodity was implemented and teams started working on more complex business requirements, it became clear that Microservices did not solve the issues, but rather moved them to infrastructure and operations while increasing complexity. Businesses that wanted to differentiate in their market could not have a small Devops team managing the project, thus, they had to hire a fleet of highly qualified Devops engineers in order to address operational risks and complexities.

Utilizing a microservice approach from day one creates a bunch of complex problems for a technical leader. It could cause a control vs responsibility problem. For instance, having full control over a service such as checkout doesn’t mean you aren’t equally responsible for missing prices on the check out page (which is typically controlled by another team).

Or consider a service communication problem when debugging becomes a cross-team nightmare. Communication can easily get out of hand when multiple teams are involved, and sizing of a service is addressing purely technical issues, such as performance, scalability or security. It happens that an individual deployable service becomes more performant, scalable and secure, while overall system characteristics degrade exponentially as the result of an increasing number of negative contributors and communications between them. In the worst cases this tendency ends up in building a “Death Star”, which is no good until you wear a dark side helmet and driving an Imperial spaceship for living.

“Death Stars” from Amazon and Netflix

Other software vendors hid microservices behind monolithic API gateways, providing to customers the same monolith-like experience as before (“Shelfware” and overprovisioning) but leaving a UI up to the project. While promising the new age of digital commerce, customers of these systems couldn’t fully leverage or even access the microservice architecture itself.

Microservices became more of a developer tool and an exciting playground structured around technical constraints with no standards or expectations to API delivery or events.

Of course it’s not the microservices themselves, an architecture pattern, to blame, but us, people who are in search of said silver bullet to solve all their problems. Sometimes I can also find myself searching for the all-encompassing answer, and it requires discipline to avoid this bias.

Headless, is it really so?

When talking about headless systems, it is easy to lose one’s head – in other words, forget about the initial intention of introducing multiple “heads” and user touchpoints. Projects tend to take months, and millions of euros are often spent in order to launch the first “head” before a go-live date. A brand new, built from scratch front-end, based on a standard commerce API of a SaaS product, only makes the front-end team busy with building a commerce front-end commodity over and over again. Headless commerce APIs that can’t be used in different contexts (such as storefronts, back offices, POS or IoT devices) blur the focus and stagnate businesses.

The Rise of PBCs

In order to address these newly presented operational issues, it is advisable to not only structure services in a standardized way, but to also address connectivity problems between services on a platform level. This is where Packaged Business Capabilities or PBCs come in.

“A service is no longer a developer’s playground, but a tool for business leaders to define value and market differentiation by composing a commerce system.”

The Packaged Business Capabilities (PBC) pattern defines a capability around a business role or a user. This way the size of a capability becomes predictable and recognizable by business users operating digital commerce applications. Therefore, a service is no longer a developer’s playground, but a tool for business leaders to define value and market differentiation by composing a commerce system made of necessary capabilities and reducing operational costs by stripping unnecessary ones. Breaking down into components of an expected size enables frequent releases (eg daily or hourly) for every component in their independent life cycle.

The PBC pattern also assumes technological and functional independence. Every PBC includes persistence, business logic, and standard interfaces (API and events). Such self-inclusivity makes flat PBC hierarchies possible, or at least reduces the depth of request calls, addressing the control vs responsibility concern. Therefore transactional integrations get decoupled from a main commerce suite.

Interface standardization, such as unified API and Events, enables different types of applications from different vendors to work together contributing to a single business vision and bringing synergy to foster a best-of-breed approach. With standardization of communication interfaces it is possible to maintain Backwards compatibility promise for every application in the commerce composition and additional platform features like Platform and Application automatic updates, heavily reducing the amount of update efforts.

With capability size and communication standardization we can address connectivity, discovery and operational concerns through an underlying platform – the composition platform. You can take a closer look on what opportunities are opening for Composition Platforms in our Expert’s Guide to Composable Commerce. Today let’s look inside a single PBC component.

Inside of a Packaged Business Capability

At Spryker, a modular OS with strict HTTP-native communication between modules, we offered the DIY application – the “Define It Yourself” application. Think of modules as Lego blocks – taking one set of modules you get a B2C, taking another B2B, adding some other will give you a B2C / B2B Marketplace – all in a single installation.

A modular approach also allows to combine these modules into independent capabilities, communicating over HTTP.

How Packaged Business Capabilities are realized in Spryker’s modular architecture, their domain decoupling, and other technical insights will be discussed in our next article.