May 16, 2022 By Balakrishnan Sreenivasan 8 min read

Modernizing applications and services to a composable IT ecosystem.

In Part 1 of this blog series, we saw various aspects of establishing an enterprise-level framework for domain-drive design (DDD)-based modernization into a composable IT ecosystem. Once the base framework is established, teams can focus on modernizing their application in alignment with the framework.

Typically, teams undertake a two-pronged approach to modernize applications and services. The first step is to enumerate and scope the processes (mentioned in Part 1) and use this to conduct DDD-based event-storming sessions to identify various capability components (i.e., microservices). The second step is to decompose the applications and align them with appropriate products (within domains) and map each of the capabilities to respective capability components that help realize the capability. An iterative execution roadmap is built based on dependencies (capabilities and services) and execution starts typically with a minimum viable product (MVP). This blog post — Part 2 of the series — details the above-mentioned approach for modernizing applications to the composable model. Part 3 of the series will look at facing challenges and prepping for organizational readiness.

Decomposing applications and services to capabilities: Overview

So far, the discussion has been about laying the groundwork to composable IT capabilities, which essentially includes organization structure alignment, process scoping by domains and a broad set of products. Next is to focus on modernizing current applications and data into composable IT ecosystem capabilities.  

The following diagram illustrates how different layers of the system are supported by different IT teams in the traditional model versus how the capabilities are built and managed in a composable model. Essentially, a monolith application is decomposed into a set of capabilities and appropriately built and managed by squads based on domain alignment:

While this model is challenging to implement, the value achieved outweighs the challenges:

  • The model provides the best alignment with business domains and the most flexible and agile IT model, driving a high degree of time-to-market improvement.
  • Product-centric model drives clarity of ownership and independency to squads, helping drive an engineering culture across the IT organization.
  • Domain alignment promotes a high degree of reuse of capabilities, reducing enterprise-wide duplication of capabilities (both application and data).
  • This model helps build deeper domain and functional skills in squads and promotes end-to-end ownership and a continuous improvement culture, which, in turn, accelerates adoption of SRE practices.

The following diagram depicts the two major areas addressed in this blog: a domain-driven design (DDD)-based application and services decomposition and the building and deployment of capabilities details:

Domain-driven decomposition of applications and services

Most enterprises have several applications and a set of application services (legacy SOAP services/APIs, integration/messaging services, etc.). These applications have evolved over a period to become monoliths, whereas services have also evolved in a different way to meet demands of consumers. The problem most enterprises are trying to solve is to contain scope of transformation to the capabilities offered via existing applications and services and not end up driving a blue-sky approach.

The following are key steps involved in decomposing applications and services in each domain.

Step 0: Map applications and services to domains per the context and usage scenario

When there are existing applications and services in enterprises, it is important to ensure there are owners for the applications and services. Based on my experience, it is a good idea to look at personas using the applications versus a primary domain that would be looked upon to offer the application or service to consumers. Once the primary domain associated with an application or service is identified, later, the end-to-end consumer ownership of the same lies with the organization that owns the domain.

Step 1: Bottom-up analysis of applications to identify and map capabilities to business process level 3 or deeper (as appropriate)

Once applications and services are mapped to primary (owning) domains, they are then decomposed into capabilities. In general, capabilities are expressed in business terms, and they mostly map to level 3 or slightly deeper:

Applications offer a set of capabilities; and in turn, capabilities could be from different domains based on the business process and bounded context alignment. As applications are decomposed to capabilities, they are also mapped to respective domains to identify who builds and manages (owns) them. While mapping capabilities to domains, it is also important to understand which of the existing services and data that the capability maps to. This is going to be critical to establish input scope (process and boundaries) guidance for event-storming workshops and identification of services.

Step 2: Event-storming and identification of capabilities (services) from business process

There are excellent articles and technique papers for domain-driven design and event storming (e.g., “Event-driven solution implementation methodology” and “DDD approach” by Jerome Boyer and team), and I suggest going through them to get a good understanding of how event-storming is done, the taxonomy followed and so on. The idea here is to ensure that the processes and capabilities that are enabled via the applications in Step 1 drive the scope for event storming. The following are key activities performed in this step:

  • Establish a set of domain events and the actors (persona or system) triggering them and identify relationships between the events (as appropriate) into flows.
  • Review and align (or discard, if appropriate) events to the input scope of the event storming (from the application and service decomposition step).
  • Elaborate the event(s) as a combination of policy, data (business entity, value objects, etc.), command, business rules, actor (or persona), external systems, etc. into one or more flows.
  • Establish aggregate boundaries by analyzing the entities and values in terms of how they establish their context and identify potential services. While the aggregates are typically microservices, the data associated with them forms the bounded context.
  • One could establish user stories based on interactions between elements of each of the flows (it is important to identify user stories to completely implement the flows).
  • Iterate through the above to elaborate/refine each of the flows to such an extent that one can identify the initial set of services to build and likely capabilities to realize.

Step 3: Map application capabilities to services

On one side, we have a set of capabilities identified via decomposing the applications; on the other side, we have a set of microservices elaborated via event storming. It is important to ensure each of the capabilities are mapped to their respective services (or aggregates) to ensure the capabilities (or requirements) can be realized. The detailed operations that include data needed (including Swagger definitions) is defined after this mapping based on the consumption needs of each of the services:

Step 4: Iteration planning

It is also important to establish capability dependencies (with regard to data and services needed to realize them) in such a way that one can figure out how to sequence the build-out of the capabilities to build on top of one another. In most cases, the dependencies are much more complex, but this helps design the necessary coexistence solution to build and deploy capabilities:

The sequenced capabilities are bucketed into a set of iterations and are continuously refined with every iteration. While establishing an iteration plan for the entire system results in waterfall thinking and heavy analysis effort upfront, a high-level roadmap is always prepared based on a group of capabilities, high-level dependencies and approximate t-shirt sizes. As iterations progress, the number of squads and capabilities developed is realigned (or accelerated) based on velocity achieved versus desired velocity.

When building an iterative incremental roadmap, one must think through coexistence because it is a foundational ingredient for success. It implies the ability for the legacy and modernized capabilities to coexist, with a 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 co-existence model would allow for uni- or bi-directional data synchronization and/or cross-leverage of functionality not yet modernized through wrapper APIs to achieve such an objective, which needs careful architecture considerations for both functional and non-functional aspects.

Build and deploy capabilities, services and day-2 operations

Modernizing applications and services into a product-aligned, capability-based model is about building capabilities by respective squads per the product alignment. The capabilities built by multiple product squads are composed at the experience layer (originally applications) to ensure consistency for the users.

Squads follow a typical cloud-native development model (based on DevOps and SRE practices) to build and deploy capabilities for consumption. As capabilities and services are developed, their consumption needs are validated and improved continuously (mostly with iterations).

While domain-driven design (DDD) helps identify capabilities that are common across apps, building co-existence code while incrementally modernizing capabilities results in stickiness of the modernized capability to the legacy application and data until the entire capability (including services and data) is modernized. Therefore, the premise of reusability of capabilities and capability components (microservices) needs to be caliberated and governed until the desired level of reusability is achieved. This also contributes to the complexity of day-2 operations (where one will have the monolith legacy application, services and data on one side and distributed/product-led squads supporting modernized capabilities on the other side).

It is important to understand that the day-2 operations model shifts considerably from the traditional monolith-based support model. Product teams collaborate to align the build-out of capabilities that need to be integrated to compose the target application. This means that their iteration plan must be continuously aligned. A day-2 support model for composable applications is different because the capabilities are supported by their respective squads. Incident management and ITSM processes must be restructured to suit a products and services squad model.

Also, the tendency of teams to monitor and manage dependent capabilities (that existed in old monolith model) must be managed through clearly articulated boundaries for capabilities and capability components. One also must skill the teams so that they embrace the cloud-native models. This is a fundamental change in the day-2 support model and it takes a significant amount of organizational readiness to move to this model.

Program management of such programs needs a multi-pronged approach to minimize cross-domain chatter, prioritization challenges and complex dependency challenges. SAFe (Scaled Agile Framework) is probably one of the best models to execute such programs. While one aspect of program management is to keep a razor focus on applications and services being modernized and measure “how much of it is modernized” on a continuous basis, another perspective is to identify complex reusable capabilities and build them via vertically integrated (across products) to accelerate progress. Keeping a critical mass of squads in an application-centric way that builds out the capabilities (even if they are owned by other domains) is critical to ensure knowledge of current application and data is leveraged to the fullest and what is being modernized has functional parity with what exists today while meeting desired SLA levels.


While domain-driven design (DDD) helps establish a disciplined approach to decompose applications and services and establish an overall design that’s well aligned with business domains and processes, it is also important to ensure purity does not get in the way of progress. “Iterate-iterate-iterate” is the mantra, and success depend on how soon teams can quickly build, learn and refine on a continuous basis. Success also depends on the business and SME participation in the above design exercises, without which there will be a tendency to reproduce existing capabilities with minimal transformation.

If you haven’t already, make sure you read Part 1 of this blog series: “Domain-Driven Modernization of Enterprises to a Composable IT Ecosystem: Part 1 – Establishing a framework for a composable IT ecosystem.”

Check out the following links to learn more:

Was this article helpful?

More from Cloud

Announcing Dizzion Desktop as a Service for IBM Virtual Private Cloud (VPC)

2 min read - For more than four years, Dizzion and IBM Cloud® have strategically partnered to deliver incredible digital workspace experiences to our clients. We are excited to announce that Dizzion has expanded their Desktop as a Service (DaaS) offering to now support IBM Cloud Virtual Private Cloud (VPC). Powered by Frame, Dizzion’s cloud-native DaaS platform, clients can now deploy their Windows and Linux® virtual desktops and applications on IBM Cloud VPC and enjoy fast, dynamic, infrastructure provisioning and a true consumption-based model.…

Microcontrollers vs. microprocessors: What’s the difference?

6 min read - Microcontroller units (MCUs) and microprocessor units (MPUs) are two kinds of integrated circuits that, while similar in certain ways, are very different in many others. Replacing antiquated multi-component central processing units (CPUs) with separate logic units, these single-chip processors are both extremely valuable in the continued development of computing technology. However, microcontrollers and microprocessors differ significantly in component structure, chip architecture, performance capabilities and application. The key difference between these two units is that microcontrollers combine all the necessary elements…

Seven top central processing unit (CPU) use cases

7 min read - The central processing unit (CPU) is the computer’s brain, assigning and processing tasks and managing essential operational functions. Computers have been so seamlessly integrated with modern life that sometimes we’re not even aware of how many CPUs are in use around the world. It’s a staggering amount—so many CPUs that a conclusive figure can only be approximated. How many CPUs are now in use? It’s been estimated that there may be as many as 200 billion CPU cores (or more)…

IBM Newsletters

Get our newsletters and topic updates that deliver the latest thought leadership and insights on emerging trends.
Subscribe now More newsletters