By Dan Hebda
We live in uncertain times. Volatility in terms of market, business, and customer needs is here to stay. Thus, we must ask ourselves how do we plan for a future that keeps on changing? One answer is composable architecture. This article discusses the importance of composability and how to use composable architecture to help organizations transform and keep up with change.
Architecture that is composed
At its core, business composability is about reimagining how parts of your business can fit together. Think about this in terms of Legos®, when you buy a pre-packaged Lego® set and it comes with instructions on how to build something very specific – say Darth Vader’s Helmet. So, you buy the box, open it, follow the instructions, and voila – you have a masterpiece!
Now, imagine another scenario. This time you buy the same pre-packaged Lego® set, however halfway through following the instructions and assembling the pieces you decide you really want to build a Lego® airplane. What do you do? You drop the idea of building the helmet and build an airplane of course!
What do these two scenarios have in common? They both share an assumption that by using the same pieces, one can create different “artifacts.” This is the same line of thinking that business composability follows. By using a finite set of enterprise parts (e.g., people, technologies, capabilities, applications, etc.), one can construct an arbitrary number of artifacts. Just like with Legos®, the magic resides in the hand of the creator constructing the experience, and not just a set of instructions.
What is composable architecture? (as defined by Gartner)
Gartner defines the building blocks of composable architecture to include business architecture, technologies, and thinking. As these are foundational to any organization, managing composability is somewhat easy as the pieces are already there.
Enterprise architects focus on aligning Business to IT. Composable architecture brings a new way of understanding how the existing pieces fit together, essentially expanding the way EAs use existing competencies. When shifting the approach towards composability, enterprise architects embed adaptability in design; and enable the enterprise to plan for many futures.
Pragmatically, what does this mean?
Supporting composable architecture doesn’t mean you dissolve your digital business; it is as Gartner says: architecting your business for real-time adaptability and resilience in the face of uncertainty. Certainly, many companies are thinking now about how to rebound from the pandemic and there are elements of enterprise architecture that EAs can use to pivot the business to become composable.
There are four steps to engage in composable architecture:
1. Understand the Ecosystem
In this part of architecting for composability, it is important to turn towards enterprise architects and the existing inventory of capabilities, technologies, and processes that have been built over time. With this view, one can get an understanding of what the organization currently does and what the needs are of the customer. Artifacts such as capability maps, process inventory, customer journey maps, application inventory, etc., provide this baseline.
- The first artifact to consider is your organization’s Business Capability Map. A business capability map breaks down business capabilities into smaller, more manageable elements to identify varying rates of change and need for agility. All capabilities may not be equal, some capabilities will be essential for your business to work; and will need to be assessed, to better understand where to prioritize composability. By decomposing your enterprise and understanding the organization’s current capabilities, as well as the gaps, one is better positioned to understand upstream and downstream impacts as well as the scope of work.
- During this time, it is also important to consider Value Stream Mapping to identify the core products and customers that will be affected when pivoting the architecture. The relationship between value stream maps and business capabilities will highlight potential gaps in efficiency, performance, and value; enabling you to better cater to specific needs.
- Along the same line, it is a good idea to go through the exercise of constructing Customer Journey Maps. The goal of these maps is to highlight the customer perspective and points of impact. By creating and assessing customer journey maps, one can understand how to provide better and more personalized services.
2. Assess the need for composability
The second step is assessing the need for composability and identifying the scope. More specifically, the focus is on understanding what the need is for composability and thinking about questions like, “Where do we need a faster time-to-market?”
In this stage, use the inventories already cultivated (e.g., capabilities, process, customer journeys, value streams, etc.) and begin assessing where to prioritize increased efficiency and time-to-market.
Let’s dive deeper into the capability map to understand how/what to prioritize.
In the capability map above, you can see the assets associated to each capability – applications, process, people, etc. These are the people, process and technologies that are required to make that capability work.
Naturally at this point, it is intuitive to think about, “Are the assets enough to support what is needed from this capability? Can the organization anticipate and adapt to change? Are there redundancies that could be avoided? Where could increased efficiency benefit the company?”
The above capability map shows initial assessments of the efficiency for each asset (depicted by the triangle icon) and provide a head start on where/how to prioritize value, efficiency, cost, and impact on capability. By looking at these two assessments together one can begin to realize the relationships between certain core capabilities and their assets – and how they are critical to the success of the company – indicating that perhaps this type of capability can be a prime candidate for composability.
Next, let’s take a look at the process perspective. Leveraging the organization’s process inventory, it’s time to assess those processes for efficiency, performance, business value, risk, and execution.
These kinds of assessments enable a better understanding of how these processes support the business. It can also begin to identify gaps, and at what level of the enterprise the need for composability is the greatest.
For example, processes that rank very high in efficiency and performance may indicate they are already well taken care of. Perhaps they are already resilient to changes and fluctuations within the enterprise. Conversely, processes that rank lower on the spectrum for efficiency and performance may be causing bottle necks and issues when it comes to being able to adapt quickly.
It is important to leverage these kinds of assessments to ask better questions on what is happening within the enterprise, and by doing so, begin to peel back the layers, getting to the core of the business and the prime use cases for composability.
3. Architect
After understanding where composability needs are greatest based on customer needs, it’s time to make choices on what to work on. These choices need to be dictated by the market and here’s where business architects will be critical.
A Business Architecture practice is no longer a nice to have, rather, it has become a must have to drive transformation as it is essential to know how strategy is put into execution. One key element of the Business Architecture is the Business Capability Map and its connection to Business and IT operations. When going into IT landscape, the goal is to create a situation where IT Architects can define a set of pieces that are independent and deliver a clear business value. These pieces are called Packaged Business Capabilities (PBC). Packaged capabilities in their pure definition are encapsulated software components that represent a well-defined business capability, and are recognizable by a business user.
As architects begin to breakdown the pieces and define the borders, it’s necessary to think about what will be in the inside and what will be on the outside. This is not very easy to do, but there are a few guiding principles:
- Modularity and Autonomy: Modularity means being able to compose and recompose the IT landscape. Modularity is derived from the business models. It is the business who will dictate the modularity of the component driven by the principle of autonomy. They will express their needs for modularity based on their needs and the fact that each team / component should be autonomous and being able to influence their own deliverables. When thinking about the achievement of composability, another thing that comes to mind immediately, is cloud services. The flexibility that cloud services bring is something that CIOs are really keen on as it helps to adapt quickly to market needs. CIOs need to know how the organization can get this kind of flexibility in private (e.g., on-site or on-premise) and traditional IT Architecture. The key is to glue together the pieces (e.g., the PBCs) and other types of IT components such as Micro Services, Apps, Macro Services through APIs. Not everything will be a PBC, but everything will be trending towards being connected.
- Orchestration: Each piece of the system has clearly identified capabilities that are expressed through services, and connectivity between components is standardized and based on patterns. Each piece is managed with a process that orchestrates the way the pieces fit together within the PBC, helping to drive standardization.
- Discovery: Each component needs to be discoverable and understandable by the business within a catalog or a marketplace. Enterprise Architecture provides a catalog of Business Capabilities aligned with IT assets, being able to provide a strong Packaged Business Capability inventory well aligned with the company strategy.
4. Build (and repeat)
So far, the key principles of architecting with Business Composability have been identified. However, the key point to remember is that one needs to think about the business side of the components, and that APIs are the glue that bring everything together. The clear goal is to assemble pieces to provide a new experience for the users that is going to be built on reusable components.
Architecture is managed at different paces:
- Set Foundational Strategy: The first level is setting strategy. It provides architecture guidance for the whole organization. Enterprise architects capture business objectives and regulatory constraints. They also manage a portfolio of emerging technologies and assess business opportunities. Additionally, EAs also define technology standards and patterns that can be reused. The architecture is not static and follows the business roadmap evolution. It integrates the constant changes in business objectives and regulatory requirements, and it is passed on to the organization.
- Set Intentional Architecture: At the next level, solution architects and enterprise architects work together to define the intentional architecture. They also reconcile the emergent design from the dev teams with the intentional architecture, consolidating them into one reference architecture. Imagine a process of “mining” the emergent designs of local teams and automatically detecting the gaps. These architects also manage the IT portfolio and its changes as developments occur.
- Co-develop Emergent Design: Finally, enterprise architects work with dev teams to co-develop the emergent design. The emergent design is stored in a local repository, which is connected to a central repository that contains the intentional architecture. These connections from Emergent Design to Strategy are key to align every development to the strategic vision and understanding the “Why” are we developing the components, and “Why” did we adopt a Composability mindset on specific business domains.
And thus, you have not only a reusable concept, but a reusable system of people working together, learning and feeding information from one business silo to another, to embed composability by design into the ethos of the enterprise.
What comes next?
The future is bright for enterprise architects. The call for resiliency heralds a lot of work for enterprise architects, solution architects, business architects, development teams, and everyone else in between.
To welcome this new composable thinking and enterprise design mindset will require teamwork, the willingness to learn from and with each other, the ability to anticipate and quickly adapt to changes in customer needs, and design systems that avoid redundancy and increase efficiency. The outcome of all these parts working together will be resiliency-by-design.
For more information, please view MEGA’s recent webinar, “Using Composability to drive speed, flexibility, and resiliency.”
