Establishing a framework for a composable IT ecosystem.
Recently, we have seen many clients jumping on the move-to-cloud bandwagon. This is primarily out of the need to reduce technical debt and cost and to meet CapEx-to-OpEx objectives. The work involved to move to cloud ranges from lift-and-shift to re-platforming/remediations.
As various practices like DevSecOps, FinOps, cloud-native models, SRE practices, etc. are maturing, the focus is on leveraging them to drive a significant level of automation, speed and agility in IT. This also helps transform the IT organization to an engineering-centric one.
CIOs and CTOs are realizing that the real power of all this lies in transforming the IT organization to a product-centric one while modernizing application portfolios to product- and services-based models. This drives product culture, wherein there is a high degree of business-IT alignment. Product-based teams, full stack squads and applications modernized along the lines of products and services drive significant benefits in terms of agility, speed and time-to-market while also improving macro productivity (reducing redundant capabilities across IT).
A proven way of structuring products is around domains of an organization, and this gives rise to domain-driven design (DDD). This DDD model that aligns business and IT capabilities in a domain-aligned, product-centric way is about establishing a composable IT ecosystem where each application is composed of a set of capabilities that are built and managed by their respective product teams or squads. Hence, domain models are central to transforming an organization to embrace the composable IT ecosystem model.
In this process, many clients under or overestimate the organizational change needed to achieve these objectives. Such initiatives tend to fail due to underestimating the complexity involved in decomposing and constructing applications capabilities along the lines of the identified domain-aligned products and services in the context of associated domains.
This three-part blog series talks about a systematic, disciplined way of applying DDD principles across the enterprise to simplify the complexity of decomposing legacy applications and re-writing them as domain/products and services-aligned capabilities. However, there are significant challenges you will face at different levels that need to be acknowledged first. An executable, step-by-step plan needs to be established to address these challenges. Among those, key ones target operating model transformation, organizational change and re-alignment, the roles of various parts of the IT organization, skilling transformation and so on. This first blog post in the series also stresses the need for a clarity-oriented roadmap (with an incremental approach) of how an enterprise needs to move to the composable IT ecosystem model.
Part 2 of the series details how to decompose applications and align them with appropriate products (within domains). Part 3 will look at facing challenges and prepping for organizational readiness.
An end-to-end process for establishing a domain-led composable IT ecosystem
The end-to-end process for building and establishing a composable IT ecosystem consists of the following three areas:
An enterprise domain framework
Formulate a core domain and design leadership team to further establish the domain model and enterprise framework for adopting domain-driven design (DDD). The team will also design the target organizational model and the initial set of business processes.
DDD-based application and services decomposition (and design)
For each of the domains, the teams will go through DDD sessions to scope processes and conduct event-storming sessions to harvest capabilities (at a high level). Teams will conduct application decomposition workshops/design sessions to decompose current IT applications into sets of capabilities and domains that should provide them. Furthermore, the capabilities are mapped to services that give life to the services (in terms of more specific API contract needs, etc.). You will target owners of the capabilities (by domain) and align their plans to the overall capabilities build-out roadmap. Furthermore, you need to identify dependencies between capabilities (including their data needs), which will further help establish an iterative buildout plan.
Iterative build-deploy of capabilities and transformation to a day 2 operating model
Next is to build and deploy capabilities in an iterative way. Domain teams collaborate to align the build-out of capabilities that need to be integrated to compose the target application – which means their iteration plan needs to be continuously aligned. A day-2 support model for composable applications is different because the capabilities are supported by the respective squads, and you need to restructure incident management and ITSM processes to suit a product and services squad model. This is a big change in the day-2 support model, and it takes fair amount of organizational readiness to move to this model.
When building an iterative incremental roadmap, you must think through coexistence, which is a foundational ingredient for success. It implies the ability for the legacy and modernized capabilities to coexist, with the goal to strangulate legacy capabilities over the period while, at the same time, ensuring that consumer ecosystem(s) for legacy capabilities are not disrupted immediately and are given enough time to move towards modernized domain capabilities. A well-crafted coexistence model allows for uni- or bi-directional data synchronization to achieve such an objective, which needs careful architecture considerations for both functional and non-functional aspects.
The following is the end-to-end process to modernize the IT ecosystem (which is monolith-based) into a composable model as described above:
Based on the above process, there are three parts to this blog series:
- Part 1: Establishing a framework for a composable IT ecosystem
- Part 2: Modernizing applications and services to a composable IT ecosystem
- Part 3: Execution challenges and organization readiness
This blog post talks about establishing the framework, which includes core teams, domain models, organization alignment, business process and alignment with domains (process scoping), establishing products and services and skilling transformation.
Establish the core domain and design leadership group (domain COE)
This requires bringing some of the smartest business (domain) architects and cloud architects together to formulate a design hub that establishes domain models and guides various teams on domain alignments, process mapping, capability harvesting, reference architectures, etc. The initial responsibility of such teams is to establish the domain-model strategy, work with teams to document various business processes, understand the linkage of these processes to various domain areas, etc. This team, subsequently, works as a domain competency center (domain COE) to help drive domain scoping discussions, domain-driven design (DDD) sessions, application decomposition sessions, etc.
Domain model and layered architecture
Enterprises IT portfolios have evolved significantly to a very complex web of applications and data. Most mature customers have structure in their data; this, in turn, provides some discipline in their applications. The key to untangling the complexity is to start abstracting the IT ecosystem and establish a certain model that’s well understood by all and provides guidance to further evolve or modernize applications and data. The best way to establish this is to leverage industry-standard domain models and customize them as appropriate (e.g., TMForum, BIAN, IATA Value Chain, etc.). These models will help structure the IT capabilities in a way that’s naturally aligned with business.
While domain models help abstract various IT capabilities, it is also important to establish a layered architecture model that details how various layers interact and how the domain model is realized. Layered architecture typically talks about a user-experience layer (realized through modern UI frameworks such as React, Angular etc.) and a domain-services layer sitting on top of systems of references.
Aligning IT organizations with business domains
More recently, IT organizations have formed around technologies, application groups or some category that indicate commonness (mostly technology-centric) of respective applications that they own. While this model has helped drive efficiencies to some extent, it is not reflective of how business operates. Teams have either been constructed around channels of consumption, technologies (e.g., shared services) or some sort of logical grouping based on categories.
This organizational construct can result in the building of several duplicative IT capabilities across an IT organization, and governance models have not succeeded much in establishing clear ownership of IT capabilities, services and data. Even though you could build various IT capabilities in a cloud-native model (as a set of integrated services), it does not help achieve the objective of composeability due to the IT layers and teams involved and associated data ownership challenges. Therefore, more are looking to reorganize the IT organization along the lines of business domains, which is a logical way of grouping IT capabilities and establishing data ownership.
An essential step of building a composable IT ecosystem is to ensure the IT organization is aligned with the business domains and that you are following a systematic domain-driven approach to identify products offered and structure the teams/squads around products. This also helps establish a clear, end-to-end ownership of products, including the degree of freedom to build and manage the IT capabilities and services, including data. This also helps prevent the building of redundant capabilities and promotes better capabilities/component re-use across the enterprise. Overall, this helps drive agility, speed and time-to-market, while reducing IT costs through better reuse and avoidance of redundant capabilities.
Domain scoping and ownership
Discovering and establishing a set of business process is one of the first set of activities to undertake when developing a composable IT ecosystem. Most enterprises have a decent view of the business processes, but depth might vary with regard to how it has been managed. It’s important to conduct multiple workshops and discussions to establish the scope of each of the domains. This set of business processes form the basis for building the domain alignment and scope. When a set of processes are aligned with certain domain, it also indirectly helps align the data (bounded context) that the domains necessarily own and manage.
Identifying products and services by domains
While business processes are refined further based on learnings from various working sessions and workshops, you can also capture levels of granularity. In most situations, you can capture at least three levels of business processes. Establishing products might be much easier if you establish business processes, and often products align to business process Level 2 or Level 3 based on the complexity and granularity. Typically, a domain competency center or some similar construct works towards establishing the domain strategy, business processes, domain scoping, etc. Domain COE lays out a set of guidance for teams to identify products and scope them appropriately.
Skilling transformation
Building a composable IT ecosystem in a scalable way is about empowering various IT teams/squads to be able to work in a product-centric model. There are a few essential skills that the teams/squads need to learn to gain expertise. Skilling various IT teams will need a two-pronged strategy:
- Embed various teams with an adequate number of domain-driven design (DDD) experts and cloud native SMEs and leverage a co-creation model to transform the teams/squads.
- Establish a learning framework that includes a combination of classroom, hands-on labs and on-the-job learning managed through a learning platform.
In most cases, organizations falter in this area when embarking on such complex modernization programs. In most cases, it will be wiser to partner with an experienced IT services provider who can bring multiple capabilities to support different workstreams that include the skilling transformation.
Conclusion
The evolution of cloud has opened a plethora of possibilities for various enterprises to take advantage of, and this makes the composable IT ecosystem a reality. The emergence of various proven practices like domain-driven design, DevOps and site reliability engineering has also made full-stack squads a reality. This enables the development of independent product teams that can build end-to-end capabilities and services without layers of IT getting involved, as we have seen in traditional IT ecosystems.
Enterprises embarking on modernization initiatives to transform their IT ecosystem into a composable model need to recognize the quantum of change and operating model transformation across the enterprise and think through this more pragmatically. They also need to recognize the fact that clarity on domains and processes will evolve with time and there needs to be room for changes. Enterprises need to adopt a multi-step approach get to the model considering the above challenges.
Initial steps should focus on identifying smaller subset of products (or domains) to pilot and demonstrate success. Learnings from these pilots should be fed back to refine the roadmap, plans and operating model. Moving to a composable IT ecosystem is a long journey and measuring success at every intermediate change is key. Too much framework or too little framework could pose significant challenges, ranging from analysis paralysis to chaos. Therefore, the first-pass framework needs to be in place quickly while focused pilot/MVP initiatives should be run to test and refine the framework. The framework will and should evolve with time and only based on real execution experiences (e.g., process overlaps learned from decomposing applications, domain model refinements based on gaps, etc.).
Make sure you read Part 2 of this blog series: “Domain-Driven Modernization of Enterprises to a Composable IT Ecosystem: Part 2 – Modernizing applications and services to a composable IT ecosystem.”
Check out the following links to learn more:
Was this article helpful?
YesNo