Exploring an objective-driven approach to modernizing IT and the various tenets of such an endeavor.

Many organizations today are joining the move-to-cloud bandwagon, primarily to reduce technical debt and cost and to meet CapEx-to-OpEx objectives. The work involved includes lift-and-shift, replatforming, remediations and more. As various practices like DevOps, cloud-native, serverless and site reliability engineering (SRE) are maturing, the focus is shifting toward a significant level of automation, speed, agility and business alignment, with IT helping IT organizations transform to engineering organizations.

CIOs/CTOs are realizing that the real power of all this lies in modernizing their applications and services to a product-centric model, which is core to achieving an engineering-centric IT organization. This blog post talks about an objective-driven approach to modernizing IT and the various tenets of such an endeavor.

Why modernize?

Enterprises today have many reasons for transforming their workloads to cloud, including time to market, cost reduction, increased agility, improved resiliency and more. The diagram below depicts these objectives in a way (with the purple chevrons) that we could link them to specific actions enterprises should take (explained further in a later part of this blog):

As these cloud transformation initiatives evolve, many enterprises are realizing that the move to cloud is not giving them the desired value or agility/speed beyond basic platform-level automation. The real problem lies in how the IT is organized, which reflects in how their current applications/services are built and managed (see Conway’s law). This, in turn, leads to the following challenges:

• Duplicative or overlapping capabilities offered by multiple IT systems/components create sticky dependencies and proliferations that impact productivity and speed to market.
• Duplicative capabilities across applications and channels give rise to duplicative IT resources (e.g., skills and infrastructure)
• Duplicative capabilities (including data) give rise to inconsistent customer experience.
• A lack of product thinking impacts the evolution of business capabilities in alignment with business and market needs. In addition, enterprises end up building several band-aids and architectural layers to support new business initiatives and innovations.

Modernizing applications and services (including data) to a set of domain-aligned products and capabilities while restructuring application teams to product teams helps address many of the above challenges. The best way to realize this model is to leverage cloud-native technologies (microservices, serverless and event-driven architectural styles) that help transform applications from traditional monolith model to domain-aligned capability components (as-a-service based) and an end-state, zero- to low-touch operational model.

In this target state model, full stack squads build each of the application capabilities and services in a DevOps-driven way, with end-to-end automation that includes observability and operational automation. This eventually helps build an engineering-centric IT organization wherein the teams have complete ownership and accountability, and they have the highest degree of freedom to evolve their components with business.

Key benefits

Programs and initiatives with the objectives laid out above will help achieve certain benefits:

• Improve productivity and speed to market with independent product teams that have minimal dependencies (outside service contracts).
• Optimize IT resources (people and infra) by removing duplicative capabilities across applications and channels.
• Remove dependencies on several shared services as product teams have full stack squads (so they have less dependencies).
• Avoid customer satisfaction issues through functional data consistency.
• Evolve business capabilities in alignment with business and market needs through product thinking. This also helps establish a foundational IT platform for driving business innovation.

Tenets of modernization: The big picture

Throughout this article, we examine each of these objectives with an IT modernization lens that focuses on agility, speed and productivity. Before we proceed, we are going to look at a holistic view of various actions that need to be performed to realize the objectives mentioned above. Then we will dissect various pieces of the puzzle. Here are a few pointers on how to read this big picture.

Read the legend and the colors—they describe the category of actions that need to be performed on or around the application or system to achieve the end state. Then follow the color legend across the flow from left to right as per the following points:

• Objectives (purple): Lays out the objectives we have discussed above into areas that can best describe how an enterprise IT is modernized and transformed to a product-centric model based on cloud-native principles.
• Application decomposition and modernization workstream (pink): Decomposes the application into components.
• Target operating model—org change/transformation (red): Focuses on target operating model activities (squad structure, process, etc.)
• Talent and skilling (blue): Focuses on enabling the full-stack squads on ways of working, technology, tooling etc.
• SRE/DevSecOps practices (green): Focuses on building necessary operational aspects into the IT capability components to ensure zero-touch operations.

Sections below describe each of the objectives and how are they achieved across the journey from legacy application and team model to an end state.

Increasing agility and speed to market

Moving from monolith legacy applications supported by a layered/multi-team ecosystem impacts agility and speed. Modernization of the legacy applications to domain-aligned capabilities and services supported by empowered full-stack squads helps drive the necessary agility and speed. It helps remove redundant shared services via an automation-first approach:

Product-centric model

The product-centric model is about decomposing and rewriting existing monolith/legacy applications and services (including data) to a set of domain-aligned products that are supported by product teams (consisting of full-stack squads). Typically, industry-standard domain models (e.g., BIAN, IATA , TMForum, etc.) are customized to suit the enterprise. Domain models form the reference point for identifying products and decomposing application capabilities, and they also help restructure the IT organization to a product-oriented organization. Product-engineering practices are incorporated in various aspects of the lifecycle, from concept to the deployment and operation of IT capabilities.

Domain-driven-design-led modernization

Enterprises need a domain model that’s closer to how the business operates. Typically, it is established through a core set of domain SMEs (Domain Center of Excellence/Competence) that are aligned to the future-state vision (also referred to as Target Operating Model). This core COE/COE team builds the enterprise domain model (based on industry domain models) and helps with structuring the IT organization in a domain-centric approach where product teams own business capabilities within a domain.

The core team subsequently scales up domain-drive design (DDD) experts to help various project teams align to the domain models, DDD principles and practices. Architects and full-stack squads in each of the domain-led organizations should have skills to decompose applications to capabilities and subsequently map them to respective domain teams so that they can own and manage the capabilities in a cloud-native/NoOps-based model.

When moving towards product-centric IT, many clients under or overestimate the organizational change needed to achieve these objectives. Such initiatives may fail if you underestimate 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.

We have defined a framework that outlines a systematic, disciplined way of applying DDD principles across the enterprise to simplify the complexity. An executable, step-by-step plan needs to be established to address these challenges, and this three-part blog series dives deeper into this topic.

Rapidly move applications to cloud

Enterprises will have a spectrum of applications with different criticality levels and business value. Typically, modernization journeys are applied to high-value/high-criticality applications. An automation-first approach (inclusive of tooling) is a must to gain the necessary acceleration to modernize these applications to cloud.

Such tooling typically supports discovery, analysis, design and execution through a patterns-based approach that helps rapidly move (e.g., migrate or containerize) these applications to cloud. IBM’s cloud engineering—in partnership with many of our ecosystem patterns—provides multiple proven tools and assets that help during each lifecycle phase. Once in the cloud, these apps are expected to continually align and evolve with the overall product-centric model and be supported end-to-end by product teams who continue to modernize them on the cloud:

Continuous business alignment

A domain-centric approach to decomposing and rebuilding applications ensures that the capabilities that are being built align well with the business. Identifying products based on domain-centric principles ensures the necessary independence and ownership to the product teams. This, in turn, goes a long way in ensuring the continual evolution of the product capabilities and services aligned with business needs. 

Product teams own IT capabilities/services as part of the product scope (which also includes infrastructure services, applications and data). This is key to drive agility and speed while different products teams collaborate through service contracts that include SLAs, etc.

Value-stream mapping exercises help establish various value streams and associated business capabilities offered; this becomes a key input for performing an efficient DDD. A structured DDD approach ensures each of the capabilities are built or customized (in the case of third-party products) in a loosely coupled manner with clear data ownership.  

Transforming current state applications into a business value-stream based products and services model needs a systematic approach:

• A top-down approach of establishing value streams and business capabilities mapped to each of the value streams.
• A bottom-up approach of decomposing and mapping current applications to business capabilities and subsequently a set of domain-driven products and services.

Our initial experiences indicate that a mix of top-down and bottom-up approaches is the best as there is a significant amount of domain knowledge to be harvested from the current-state applications and the functionalities they offer:

Improve resiliency with low-touch/no-touch

Hybrid cloud platform foundations

Product teams with full-stack squads require infrastructure and platform autonomy to succeed. This necessitates certain foundational platform capabilities (e.g., on-prem, cloud, etc.). These platform capabilities could be classified into core foundational services—landing zone, control tower, security capabilities, DevOps capabilities, multicloud capabilities, etc.—all aligned with a cloud target operating model (CTOM).

The entire foundational platform needs to consider the fact that during transformation, applications and services need a hybrid platform (where part of the components would be on-prem while the rest of them are being incrementally modernized to cloud). The platform also should consider the fact that the application or product teams should be able to consume all the services in an “as-a-service” model with extreme degree of automation via Infrastructure as Code, DevOps pipelines, etc.

Enterprise DevOps and SRE automation

Continuing with the autonomy theme, along with platform capabilities, DevOps is also essential to this endeavor, but can sometimes be plagued through legacy centralization models. Within a centralized model, a shared services team provides/manages all DevOps capabilities (e.g., tooling, pipeline, software supply chain KPIs, etc.). Such a centralized model has distinct advantages but often limits autonomy, flexibility and speed. Therefore, the foundation platform should offer the necessary tooling and services that full-stack squads can leverage to build, deploy, observe and manage their workloads.

It is critical to have Pipelines as Code and reference pipelines that not only provide just enough capabilities for teams to get started but also the flexibility to customize the pipelines based on specific workload needs. The key is to ensure that the right metrics and measures against enterprise KPIs are gathered and gated as part of pipeline execution to determine the overall product health and engineering rigor expected from product teams.

Transformation to Security as Code

Security organization and process need to embrace the cloud-native model and move towards automation. Security and compliance teams are often isolated and typically bring an outside-in perspective to product lifecycle. Security and compliance teams can be fully integrated to the product lifecycle by helping integrate proactive security and compliance validations into the product lifecycle.

This can be achieved by moving to a patterns-based design/develop/build/deploy/manage approach and by empowering teams to continuously validate their overall security posture by leveraging integrated security best practices. Various security and compliance policies are integrated into platform and application (via DevOps pipelines) as code, which helps establish necessary guardrails. Application or product teams integrate a suite of security tooling and services into their DevOps pipelines to bring out necessary transparency into security and compliance adherence, and this helps shift-left security model to application or product teams.

Product lifecycle acceleration

Enterprises often retrofit cloud transformation elements within existing application supply-chain processes rather than considering new application lifecycle and delivery models that are more suited for delivering applications to cloud. Those enterprises that can reimagine the application lifecycle through an automation-first approach help bring in the necessary product lifecycle acceleration that cloud transformation promises.

This typically requires that security, compliance, change management, operations, business continuity and business come together. It’s important to have a single view of the end-to-end application lifecycle from concept to deploy/manage in cloud, where automation driven transformation points can be identified.

Examples of such transformation points could include the following:

• Codify and automate security and compliance requirements.
• Implement a pattern-based solution definition approach to accelerate security, compliance and change-management processes  (patterns with embedded security implementation).
• Re-use “patterns” as code.
• Utilize DevOps pipeline-driven activities across the lifecycle.
• Build traceability from security requirements to implementation.
• Generate a high degree of data needed for governance, risk and compliance. Perform security and operational-readiness reviews with limited or no manual intervention.

Zero-touch operations model

Automated monitoring, insights, alerting and a suite of auto-healing/remediation capabilities are key to reducing manual touchpoints and achieving a zero-touch operations model. Full-stack squads and SREs build observability and day 2 operational management aspects into the capabilities and services with ‘no-manual-intervention’ as an objective. Enterprises need to focus on stressing the importance of an operations model that is process- and automation-dependent (rather than people dependent). This requires rigor, well-defined SRE, operational-readiness practices and collaboration:

Build engineering-focused teams through skill transformation

Cloud-native development expects full-stack squads to work in the following model: “You build, you own, you manage”

These full-stack squads are autonomous and own end-to-end progress, and this needs a foundational platform that truly implements various cloud services in a Platform-as-a-Service (PaaS) way for teams to build applications and services. There needs to be a systematic learning plan and framework based on personas to drive various aspects of learning (e.g., core programming skills, cloud services certifications, DevOps/SRE practices, DDD skills, etc.):

How does it all come together?

Let’s bring back the big picture, which groups the objectives we have discussed above into areas that can best describe how an enterprise IT is modernized and transformed to a product-centric model based on cloud-native principles. Don’t forget to look at the legend as described at the beginning:

The journey from objectives to target-operating model is a continuous endeavour. The time it takes to reach the target state would depend on enterprise maturity and consider people, processes and technology dimensions. With multiple workstreams catering to different enterprise strategic objectives, adding each objective creates significant complexity within the enterprise and requires a higher degree of effort across multiple teams and portfolios to get implemented and matured.

A Cloud Center of Competency (CCC) is a great acceleration mechanism to realize these strategic objectives within the enterprises. A center of competency is about the successful deployment of a new technology at the enterprise level. As an example, a CCC could help build codified reference architectures and patterns that integrate multiple cross-cutting concerns (e.g. non-functional requirements, operations, security, reliability, FinOps, compliance) into Infrastructure as Code (IaC). The IaC can then be leveraged by full-stack squads to deploy and manage end-to-end automated product capabilities to the cloud.

Conclusion

The evolution of cloud has opened a plethora of possibilities for various enterprises to exploit, and this makes the composable IT ecosystem a reality. The emergence of various proven practices like domain-driven design, DevOps, Infrastructure as Code (IaC) and Site Reliability Engineering (SRE) have made full-stack squads a reality. This enables the realization 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 a smaller subset of products (or domains) to pilot, demonstrate successes or fail fast, and identify learnings that should be fed back to refine the journey, plans and operating model. Moving to a composable IT ecosystem is a long journey and measuring success at every intermediate change is key to long term sustainable success.

The role of the Cloud Center of Competency (CCC) is crucial. It brings the right level of interventions that accelerate the journey via building reference architectures, patterns as-code and guidance and help work across various organization teams to establish an integrated develop-deploy-operate lifecycle.

Key links

• CCOE Gartner view
• CCC IBM Cloud
• Composable IT Ecosystem Part 1, Part 2, Part 3