Beyond Composable Technology: Maximizing Value with a Composable Operating Model
Businesses are increasingly moving toward a composable architectural approach to technology, where new capabilities can easily be plugged in or swapped out. But technology alone isn’t enough. To truly unlock the value the composable can bring requires new ways of thinking about your operating model.
Historically, business have built their commerce and content foundations on monolithic architectures. Rapidly and agilely adding functionality to legacy monoliths is challenging because of their complexity with many tightly coupled, shared engineering dependencies that prevent multiple teams from achieving parallel development of new features, slowing the pace of development and time to market. Monoliths cannot use the latest, modern capabilities struggle to scale along with modern consumer demands.
This is where composable technologies shine, as they enable parallel, simultaneous development of multiple capabilities without negatively impacting the ecosystem. This can drive releasing new features, new products or even whole new channels significantly faster. Composable technologies address these challenges by taking a modular approach, allowing each discrete capability to be treated as an individual component, from search and payment to content management. Each component can deliver its capability through different technologies and simply communicate with other components through APIs. This allows the design to choose the best-of-breed technology that’s ideal for each capability.
However, successfully executing composable architecture doesn’t hinge on tech stack implementation alone. To fully realize the value that a composable architecture can deliver, you also need a composable operating model to support it.
Creating Speed to Market with Product Owners & Multiple Scrum Teams
The way that legacy development teams are structured can hinder development efforts, necessitating a new approach to achieve parallel development in a composable model. Such a change must be planned and coordinated carefully, ensuring that there’s alignment to the overall business goals. This involves designating a clear product owner (PO) on the development team for each capability, who’s responsible to support and enhance said capability by orchestrating collaboration across engineers, quality assurance teams and business analysts. Each capability needs its own scrum team to deliver on its backlog and, in some cases, may even require multiple teams. These scrum teams can now work in parallel.
Through this strategy, multiple teams can work simultaneously and decrease the time to market for new releases and continually improve the components within your composable architecture.
Driving Measurable Growth & Alignment with Shared OKRs
Measures and incentives are a key component of achieving success in your operating model. Without an alignment to your business strategy, teams can find themselves stuck on where to focus or worse still running full tilt in the wrong direction.
To achieve harmony across all your capabilities and unify the customer experience, incentives must align across the ecosystem. It must go beyond individual PO objectives and key results (OKRs). It’s essential to share OKRs across all POs to actively communicate and collaborate.
Otherwise, a siloed way of working leads to a disjointed, disconnected user experience with each PO singularly focused on solely maximizing their own targets, which impacts performance across the ecosystem.
While this supports alignment across your POs, it is also important to provide top-down governance and guidance to ensure further coordination and adherence to a global strategy.
Managing Agility Through a Hybrid Governance Model
Legacy monoliths lead to central governance models where architectural decisions are made by sole chief information officer (CIO) or a global architecture review board.
With a composable architecture, it may be tempting to shift all governance down to the capability level in a fully decentralized model that empowers each PO to make entirely their own decisions about not only features but also the architecture itself.
While a composable architecture greatly accelerates the speed at which vendor solutions can be swapped in or out, it still requires more effort than a simple feature release that create direct business impact, either delaying benefit realization from new features or increasing costs. Changing solutions would require either a code freeze for several sprints, or the addition of further scrum teams dedicated to setting up and testing the new solution. Business impacts at this level must include governance, planning and oversight beyond what a PO would be responsible.
The solution therefore is to take a hybrid approach. Any significate changes to a capability should be weighed up with a cost-benefit analysis carried out by the respective PO but that is reviewed and approved by a central body that can take the holistic view across the ecosystem.
A central body, such as a global architecture review board, can provide both rules and guiderails within which capability teams can operate, allowing for rapid decision making at a team or local level, as long as it falls within the guiderails set while maintaining a holistic view on both standards and costs.
Processes should be clearly defined to enable rapid decision making and implementation at both a capability and central level, providing agility whilst still within the vital oversight of a central, accountable body.
Conclusion
Defining your composable operating model is the start of the journey, not the end.
It can be tempting to think “if we build it they will come,” meaning that implementing a composable architecture will naturally create the change over time to a suitable operating model and all the benefits it brings. It has led to overruns, overspending and failed transformations with businesses stuck in a half-way house architecture: part monolith, part composable and wholly inadequate CX.
Consider your technology, operations, data and experiences together from the start of any composable undertaking, at least you find yourself with a powerful new engine and with no one to drive it.
The move to composable can only be successful if planned carefully. Consider taking an integrated approach. Think carefully from the outset about both your technology decisions and the operating model that will be required to manage, support and drive the greatest value from each of the capabilities.
