In my previous blog article What does Digital Transformation Truly Mean? I discussed that transformation is a continuous phenomenon and should be a ubiquitous part of an organization’s DNA, and firms that transform sustainably differentiate themselves from the rest. With rapidly shifting consumer preferences and factors such as the pandemic, the ability to respond quickly, sometimes in days or weeks, has become table stakes. Winning in the current environment has depended on being able to assemble new products or businesses versus building them from scratch. Like building a complex lego set starts with standard building blocks, firms that have carefully designed their ecosystem to focus on capabilities that string together to create complex new products or businesses have been the most successful.
Modularity is not a new concept. It’s been used in software development since the first object-oriented programming languages were created. In modern software design, reusable blocks of functionality are exposed via microservices or APIs, allowing for faster development of applications. Such design exhibits architectural composability. Though this concept is powerful and is widely used in development today, in my observation, it often gets limited inside the scope of a product or a business unit, preventing broader reuse. This is especially true in product-based development environments that promote self-sufficiency and limiting of external dependencies. Teams inadvertently develop code without thinking about its reuse outside of their context. When another product team needs similar functionality, it ends up recreating, causing redundancy, but most importantly, not being able to take advantage of modularity and reuse.
Business Composability extends the concept of modularity to business functions that can be expressed as autonomous and reusable vertical slices of functionality via a standard interface comprising data services, APIs, and event channels. Gartner has termed these reusable slices of functionality Packaged Business Capabilities (PBCs). Although I prefer the term Business Capability as a Service (BCaaS) to highlight the true service-oriented nature of such capabilities, we will stick with PBC for ease of reference. Any business unit that provides services to others can essentially be created as a PBC. In most cases, the consumers do not need to know the internal workings of the capability and need to only focus on consuming it. They are primarily internal facing and deliver value when used with other capabilities. For e.g., a business unit that manages payments can offer a standard interface to be consumed by any product requiring consumers to make payments without worrying about the underlying payments technology. Similarly, account management, compliance, analytics, and virtually any other service function, even technical, can be expressed as a PBC. These PBCs are made available throughout the enterprise via an orchestration layer that offers discovery and integration capabilities. Any new product can start by discovering existing PBCs and focusing on assembling them, providing better agility. The autonomous nature of PBCs offers better resiliency.
According to Gartner, business composability comprises three domains:
Composable Thinking:
This starts with the thinking that every business problem can be broken down into smaller parts that can be composed to create new outcomes. This also results in more creatively thinking about organizational design and business services as reusable entities. By bringing together modularity, autonomy, and orchestration principles, firms can create a platform on top of which new products or services can be quickly stood up.
Composable Business Architecture:
The output of the composable thinking process is used to establish a blueprint that informs the PBCs that need to be designed, developed, and orchestrated. The nature of each PBC determines how teams are designed and the collaboration models that should be used. The book Team Topologies offers an excellent framework to organize teams into one of four types depending on the use case. Platform teams fit the context of business composability best as their goal is to enable other team types to drive faster outcomes. Defining an inter-team collaboration model such as inner sourcing is equally important to avoid single point dependencies. This step is an essential part of the process and a key determinant of success.
Composable Technologies:
Business capabilities can be custom-built, bought, or a hybrid of the two and exposed via an abstraction layer with a standard interface that allows easy integration. The goal is to make the capability easy for the consumers and offer access to the entire business stack.
Gartner’s reference model for composable business applications illustrates this concept well:
From a technology leader’s perspective, the concept of business composability presents a pivotal opportunity to partner with stakeholders to carefully design the organizational landscape. When done so, the firm has a well-defined platform-based ecosystem of PBCs, allowing for the rapid development of new products, services, or businesses. The good news is that many firms have already invested in digitization and digitalization of their (legacy) systems which can be extended and exposed via PBCs, creating an opportunity to quickly transform without requiring significant new investments. Transforming into a composable modern enterprise has equally to do with the mindset as much technology, so starting with composable thinking and deliberately designing the business architecture is essential and key to success.
References: