This post reflects a view from the field on how composable enterprise is seen by analysts and companies, as well as a consultant’s perspective on various aspects of implementing composable enterprise in an organization.
First of all: You do not have to be Mozart or Beethoven to compose an enterprise, and it does not have to do with music at all, besides the creative elements.
So let us define what a composable enterprise is. SAP’s Board Member Jürgen Müller has emphasized composable business as being “agile and open to change and disruption.” Gartner, among the first to coin the term, has described it in the following way:
“Composability in a business context [means] architecting your business for real-time adaptability and resilience in the face of uncertainty.” Gartner Keynote, 2020
It seems that agility and resilience are the key characteristics of composability, with various technologies that can now be placed behind it. This is also why some bring together the concept of composability with MACH architecture (Microservices, API-first, Cloud-native and Headless).
Let’s take an easy analogy: When you think of your company as a pasta dish (yes, we all like some good Italian food!), what is the first thing that comes into your mind? A multilayer lasagna? Some ravioli? Or maybe slightly disorganized but tasty spaghetti? A short survey of some friends (no scientific basis involved) showed that very few of them think of modular raviolis, rather going for more hierarchical or chaotic comparisons.
Figure 1. What does pasta have to do with composability?
What is behind the big buzz of composability? On the one hand, current system landscapes are too complex, causing slow response to change (which is needed as much as ever in such turbulent times), partially redundant solutions, and vendor dependency. On the other hand, there is a need to be more flexible, to freely choose from millions of solutions and platforms out there, and to focus on outcomes.
Should enterprises become composable if they want to be agile? Is life different in the composable world? For this, let us first understand what being composable means.
Defining composability
There are three key building blocks of composability (as defined by Gartner😞
composable thinking,
focusing on a different (adaptive) approach towards strategy, more flexible organizational structures, and different planning cycles.
composable business architecture,
featuring a value-based approach towards processes, working with business capabilities, and promoting distributed accountability.
composable technologies,
characterized by agile development methodologies, modular architecture, and distributed data processing.
Those building blocks are somewhat similar to existing and well-established methodologies, although now in a composable context. As an example, TOGAF (The Open Group Architecture Framework) highlights the importance of business architecture and technology architecture and the SAP Enterprise Architecture Framework (Figure 2) deals with capability, process, data, and organizational views.
Figure 2. SAP Enterprise Architecture Framework
As a recent methodology, Scaled Agile Framework® (SAFe®) introduces organizational and workflow patterns for implementing agile practices in an enterprise. Does it ‘support’ the principles of composability? Indeed – however, it takes more than a methodology to achieve the desired agility and composability in a company and its enterprise architecture.
So how do those three aspects come together in a composable enterprise?
The key principles of composable business are: modularity, discovery, autonomy, and orchestration (see Figure 3).
Figure 3 Composable Architecture
Let us take the example of a pricing engine, providing price recommendations for various product lines.
In a composable world, Modularity would mean that there is a packaged business capability behind it that would encapsulate this one process (product pricing), have a certain purpose (such as optimizing pricing and maximizing income), and lead to an outcome (price recommendations).
Discovery would mean that the capability relies on a certain information architecture for certain objects (such as products) and is searchable / can be identified by the business and (re)used for certain business purposes (calculating price for a new product line).
Autonomy means that this capability can run independently (from architecture- and deployment perspectives) from other capabilities, have a certain governance process (product owner, lead architect, lead developer), have a certain life cycle (with releases, deployments, updates), and be scalable (cloud-native architecture is key in that case).
Finally, Orchestration focuses on security components, API support, workflow orchestration, and similar topics.
Following these four principles new product lines or businesses would leverage the composable pricing engine capability in their specific composable architecture.
Business perspective
Many organizations are facing an ongoing change from project-centric to product-centric setup. Most of you have heard about design thinking and user-centric design by now, which are yet other principles of how to build products that are truly designed for the customers and their needs. This is where composable thinking comes into play and specific business capabilities in scope of a product “have” to be composable as these serve a consumer and will depend on producers.
Now, what does it mean for a company? Ideally, those characteristics we have just considered should make life as easy as possible. Once a company has a certain need, such as determining flight risk of employees or calculating CO2 footprint of a product, one can easily find a needed capability/solution, integrate it into the process and application landscape, obtain all the required updates, and scale it from one department to all international divisions.
Figure 4 Example for transition to composable business
Martin Heinig, Head of New Ventures and Technologies at SAP, gives yet another example of enterprise benefits from the transition to composable enterprise in his recently released blog post.
“…think about adding a carbon tracker to your supply chain processes or integrating a new infection protection act in response to a pandemic. Today, this would require a long-term integration project, whereas a modular setup might enable a process expert to adapt and change processes easily and quickly — ideally without implementing a single line of code.”
Are all of those principles new? From a pure enterprise architect’s perspective such principles as modularity, autonomy, and orchestration are not really new things. They have been around for a while, however, with a different level of awareness. What is more important for composability (although also not entirely new) is the business- and IT-aligned thinking, including the agility of the thinking and of the processes. This becomes especially important when (in a truly composable way) an enterprise is using multiple modular solutions. While resilience increases this way, the landscape complexity is growing too – so it is important to have focus and a clear ownership, and this is where product-centric organizational setup can support. Furthermore, agile teams (business and IT in one team) are a prerequisite for this setup to work.
Industry view: how widespread is composable principles adoption?
As Vikram Rawal, an ERP Enterprise Architect at Roche mentioned in a SAP Experts podcast episode that every organization has to be agile and flexible to change. Composable ERP should help to switch from the ‘being built to last’ to ‘being built to change’ thinking. This is also where the importance of integration technologies grows.
In addition, this trend is confirmed by other companies. As Rene de Daniel, Principal Process Consultant at SAP says, ‘What I increasingly see at customers and what we are jointly doing with them, is detailing out these principles into tangible guidelines and criteria to assess various solution options or a so-called ‘composability index’. With that, companies can identify the best “fit” in terms of composability and define the next steps.
Interestingly, with the rise of business and industry networks such as Catena-X composability has yet an additional meaning. In an interconnected enterprise world, the topics of interoperability and data sovereignty gain importance. Hence, solutions not only need to be modular but also interoperable between each other, with standardized connectors and data formats to ensure that solutions can communicate no matter which vendor is chosen. On the other hand, those solutions have to ensure that data is shared in the network according to the requirements and regulations of the data providers and they can at any time revoke or modify access and usage policies for various assets, roles, etc. At the same time, this network thinking is a giant step towards collaboration and composability at an enterprise and industry level.
Suite qualities
The transformation is taking place also within SAP – and SAP develops products to best serve the needs of enterprises across the world.
Companies increasingly demand support for their mission critical processes end to end, see Figure 5. Especially in the cloud the whole notion of a product blurs, with almost everything offered as-a-service. Companies run their end-to-end processes, e.g. Hire to Retire (without being concerned which SAP application is touched). In the end, it looks like one end-to-end solution for the customer. It is aligned from an UI perspective, integrated from a process level as well as aligned with data models and life cycle. In that sense, we are moving from integration of applications to integration of processes.
Figure 5 SAP transition to composable enterprise architecture
Business composability – Action guide
While there are certain limits to composable enterprise principles adoption and scaling across industries, with all the necessary adjustments needed and impact on current architecture, processes, and applications, there are certainly huge opportunities in the ‘composable world’. Just a few of them are: fast time to value, easy deployment of modular and integrated solution capabilities, and higher customer satisfaction.
Some interesting insights into how to turn composability into a competitive advantage were delivered by Gartner when companies leading in the composable space were asked “what is of key importance to be successful?” – the learnings are summarized below (Figure 6).
Figure 6 Examples for composability principles and actions in each area.
What can companies do to prepare the journey towards a composable architecture?
First, engage composability champions. Just as there are agile centers of expertise & agile coaches, there can be composability coaches or centers of expertise with a mission to embed composability principles into the DNA of the enterprise.
Second, start small. From prototyping modular applications to re-platforming, there are multiple ways to make first steps in that direction.
Third, assess where you stand (‘composability index’) and detail out composability principles for your enterprise.
Finally (and back to the first point), it is important to keep in mind implications for skills. From methodologies (e.g. agile and scrum), to architecture (e.g. microservices) to business expertise, all this knowledge is needed to be successful in the composable world.
Additional resources:
- SAP Composable Enterprise Solutions
- SAP Experts podcast with Vikram Rawal, ERP Enterprise Architect at Roche
- Blog post – How an enterprise architect shapes the future of ERP by leveraging emerging technologies
- Blog post – SAP Enterprise Architecture Framework
About the authors:
Rene de Daniel, Principal Enterprise Architect at SAP.
Maria Fay, Principal Innovation Architect at SAP.
For any questions or ideas that you have, feel free to reach out to us. We are looking forward to discussing the topic with you.
