Transformation of IT to Product Centric Models
Co-Author: Shankar Kalyana (IBM Fellow)
Digital transformation initiatives were supposed to bring IT closer to business and help deliver higher value, at higher speed and optimal costs. Most digital initiatives start with a bang focusing on high value areas and as they are get implemented, the drag starts — and the real problem emerges; IT organisations are so layered that they can’t deliver value at the desired speed and since in most cases, IT systems reflect IT organisation structure (Conway’s law) which also impacts speed and productivity. It is very challenging to translate business priorities into specific IT systems due to this complex ecosystem.
Let’s understand the problem a bit more… Due to the way in which IT organisations have evolved, teams must depend on multiple other teams as well as shared services (DevSecOps tooling, testing etc.) to deliver certain functionality. Typically channel applications tend to re-build significant level of business processes, policies, and rules into their front-end layers and over a period they end up being consumed by other IT systems citing inflexibility of legacy applications, services that offer similar functionality. This ends up diluting functional and data ownerships and creates a spaghetti of application functionality and data with significant overlaps as well as fragmented ownership. Imagine one needs to implement a new customer journey or functionality, then the spaghetti needs to be untangled through multiple team discussions and this is what impacts overall speed and productivity.
Given the above context, Introducing the notion of products will help establish full clarity of what product teams can own & manage (application and data) and has clear contract on what the team delivers that includes functional and non-functional aspects. Product based ecosystem visualizes entire IT as a set of products that collaborate between themselves as per need — e.g. one product relies on another product for data & functionality and vice-versa. While the transformation to products is a long journey, incrementally moving specific journeys, functionality and data helps move an enterprise towards the product centric model.
Product centricity and business-IT alignment
The notion of product in the context of an IT organisation slightly differs from the broader definition of product. A product needs to have a well-defined functional scope via a set of business capabilities that it offers that’s inclusive of associated non-functional requirements. Products need to be owned, developed, deployed, and managed by a set of squads (aka product team) that can work independently but with clearly defined interface contracts with upstream products and downstream consumers. Collectively consumers (downstream products) define the requirements as well as SLAs as expected from the product. In this context enterprise IT would be viewed as a set of Products that work together to deliver desired value to their respective consumers. Product teams are essentially comprised of full-stack squads that has skills ranging from product managers, business SMEs, functional coding, Infrastructure-as-code, DevSecOps, Secure coding, testing, as well as ongoing operational skills.
Looking at IT systems as a set of products centered around business domains and re-organizing the teams around these products essentially helps IT organizations embrace product centricity. This model of re-imagining IT as a set of products jointly created by business and IT helps establish a much tighter level of business-IT alignment that has eluded IT organisations for so long. Product centric approaches provides enough traceability from business or market changes to drive rapid and continuous prioritisation of work. Organisations are embracing product centric approaches and per Gartner survey about 85% of organisations are either adopted or plan to adopt product centric models. We have seen enterprises starting to transform their application ecosystems to embrace product centricity. This article focuses on how to go about transform your IT applications & services to embrace product centric model.
Product centricity: Enterprise IT perspective
Products in the context of enterprise IT is different from how software vendors, and other product companies look at products that are sold & consumed by their customers. In the context of enterprise IT, a product is something that mirrors what business offers to their customers and could be defined as a set of IT capabilities that can be developed independently with clear ownership of functionality and data whereas the interface boundaries are well defined from consumers of the products as well as producers of services / capabilities that product consumes.
Let’s examine this through an example; a retailer typically have multiple business domains (inventory management, shopping, purchasing, logistics etc.) working cohesively to address customer needs. Each of the domains would offer a set of business capabilities and the diagram in his section depicts shopping domain and its core set of products and business capabilities offered. Shopping offers products that are Catalog, Order Mgmt. and Pricing and in turn each of these products offer set of business capabilities (e.g Order entry product offers Shopping cart, Checkout and Order capabilities and so on). Product teams are formed around these products whereas they develop, manage, and evolve a set of capability components (IT component / code) that enable the business capabilities. This way, the boundaries and scope for each of the products are clear, yet the product teams must collaborate through these clearly defined interfaces.
When we elevate this perspective to the broader enterprise, we will see a set of product teams collaborating with each other through clearly defined interfaces (consumption and producer) that gives rise to a product centric Enterprise IT organisation. Traditionally enterprises have always dealt with applications and services (as well as databases). This notion changes w.r.to product centricity whereas the applications become “experience layers” that surfaces the business capabilities that are through a set of IT components (Capability components within the products scope). In almost all cases applications aka experience layers surface business capabilities from more than one product. If we take channel types of applications, they bring together a suite of capabilities from different domains & products based on user journey needs. From data perspective, every product teams owns and manages its set of data depending on the collective bounded context it’s capability components deals with.
Product centricity: Application platform & Platform foundations
In the above example, product teams work independently but collaborate amongst each other via defined interface contracts that not only includes functional, but also non-functional requirements (driven by SLAs). Diagram below depicts the context of application (product) teams versus platform squads.
Product teams fully automate the mechanics of build, deploy, and manage of the component via Infrastructure-as-code, DevOps pipelines, security tooling through consuming cloud native services. Platform engineering squads ensure the suite of services (including tooling service) are guard-railed to ensure its enterprise grade and incorporates all of enterprises policies (including security & compliance requirements. Cloud acceleration center kind of constructs help optimise the learning curve & accelerate standardised adoption aspects while leveraging the platform services.
Transformation to product centric IT model
Moving to product centric IT delivery model is transformational since it involves multiple work-streams coming together with Domain models & products being the pivot around which the work-streams operate. Following diagram depicts various work-streams and how they need to work together to realize the product centric IT model.
- Domain models & products help structure the IT organisation
- Transformation of IT organisation from traditional to product centric model
- Re-alignment / modernisation of applications, services, and data to offer product centric business capabilities
- Building a platform foundation and application platform that empowers product teams to operate independently with significant automation
- A mechanism to accelerate cloud centric development (through cloud competency center) that helps build reference architectures, patterns-as-code for product teams to quickly adopt
- Re-skilling / enablement of IT teams to embrace product engineering models, agile execution skills as well as technology skills (cloud native etc.)
Following sections briefly describe each of the work-streams. Our intent is to publish a white-paper series on each of the work-streams and the execution nuances.
Work-stream 1: Application modernisation
Decomposing applications & services into domain aligned products & capabilities based on domain model as reference is a key first step. Subsequently each of the product teams rebuild these capabilities into experience layers and IT capability components through applying domain driven design practices. This approach drives the necessary data discipline across products w.r.to ownership of data versus consumption of data from other domains or products. Through this method legacy applications are transformed into experience layers that consumes set of services from multiple products. Diagram below depicts how a monolith application is decomposed and modernised to a set of IT components that includes experience layers and products that realize business capabilities:
A key question that comes to mind is — do i need to re-write all applications and the answer is not necessarily. The decision to rewrite or re-platform or migrate is largely based on the value and criticality of the application in the enterprise. In the case of re-platform or migrate, applications are not broken down to components but they are mapped to the predominant domain or products.
Work-stream 2: Target Operating model Change
This work-stream lays the organisational and process foundation for the transformation to happen. Key components of this work-stream are as below:
Domain model
Domain models describe the business taxonomy of various business domains operate and the capabilities they offer. Best way to establish a domain model for the enterprise is to customise an industry standard domain model along the lines of how business operates. There are several models e.g., TMForum, BIAN, IATA Value Chain etc.
Products in the context of an IT Organization
We looked at domains and products in the initial sections and example products in shopping domain. Domain model acts as the reference to define Products and enough analysis is done through joint discussions with business and IT SMEs to ensure clarity of product scope, business capabilities it offers, data contextually owned, other domain / product dependencies, as well as the ability of the team to operate independently.
IT Organization Structure
As applications are decomposed to product aligned capabilities, there is a need to re-organise IT organisation along the lines of product associated squads which lays the framework for product centric IT organisation. There are various ways of grouping product teams; either they are grouped by domain boundaries OR by value streams. Product teams are comprised of full-stack squads with product engineering skills. Platform squads comprises of platform oriented products squads that build, deploy and operate various services.
Talent and Skilling
In continuation, as squad types and compositions are defined, there is a need to elaborate the skills needed by each of the squad members as well as learning paths that helps employee’s skill themselves. Skilling various IT teams will need a two-pronged strategy.
a) Core of skilling strategy is to embed various teams with adequate number of domain driven design experts, cloud native SMEs and leverage co-creation model to transform the teams / squads.
b) Establish learning framework that includes a combination of classroom, hands-on-labs, and on-the-job learning managed through a learning platform.
Transformation of key processes
There are several processes that need re-alignment to suit the needs of full-stack, empowered product teams. Following are key processes and brief descriptions of those:
Enterprise Software Development Lifecycle / Path to operations based on DevOps principles
As each of the capabilities are being taken through concept to design to development to production, in traditional models, the teams need to go through several organisational touch-points (e.g. security and compliance reviews, Architecture review board, change management and so on). It is key to bring all these processes under one roof to realise enterprise software development lifecycle — ESDLC. First part of transformation is really to establish a single pane of glass w.r.to ESDLC which will further give rise to several automation possibilities and that’s where one would start seeing the maturity of ESDLC evolving. Hence ESDLC will also help establish dashboards and program trackers to visualize the journeys of the capabilities, where they are and measure efficiencies, velocity from end-to-end perspective and so on. DevOps is central to ESDLC as It leverages cloud native models to automate everything as-code.
Domain Drive Design & Enterprise Intake Processes
While Domain Driven Design (DDD) is a well-known methodology to apply domain thinking into designing software systems, it is slightly different when it comes to translating legacy applications into DDD centric designs. Here DDD principles are applied to identify products, scope them appropriately and subsequently create technical designs, to ensure product squads are empowered and enabled to work as true product teams in terms of independency & ownership. Point to note is that products are composed of capability components (IT components) and associated bounded context. There are two things that help enable this model:
Enterprise DDD: A structured process to systematically establish products across the enterprise, scope and ownership, and eventually executable designs of capability components (IT components) including bounded context etc. As part of this process, legacy applications and services are decomposed into capabilities (via DDD / event-storming models), designed per reference architectures and are ready for further design & development. Thus Enterprise DDD lays the guard rails for structured design and development of IT components based on the adopted domain model.
Enterprise Intake process that helps prioritise golden threads, application capabilities to be modernised and taking product teams through enterprise DDD process to establish backlog for not only the product teams but also consumers and upstream products.
Security & compliance processes
Security and compliance (S&C) requirements typically are expressed via set of controls and policies and implementation guides. Many of these exist in documents that aren’t codified. As an organisation is moving to cloud, it’s important to decompose the security & compliance requirements into a codified set of requirements that could be automated over a period of time (e.g. encryption of all storage, authorisation and so on). S&C should be able to offer a suite of services to the product teams / squads that are integrate-able to their pipelines that provides the level of digital transparency needed to automate security and compliance requirements.
Change management processes
While change management is about establishing the “change” that the capability has gone through w.r.to development and its impact on dependent consumers and other systems. With this intent, the focus should be to codify various features / stories that are being included in a certain deployment which then corresponds to impact points on dependent consumers & systems. Enterprises should embrace automation through the change management guard-rails that includes checks and balances to identify impact of deployment of components.
Work-stream 3: Platform Foundations & application platform
Hyperscalers and technology partners offer variety of cloud services but in most situations, they aren’t fully enterprise ready. Enterprise readiness includes the security and compliance guard rails and any other enterprise requirements such as Authentication and authorisation etc. While platform squads build, configure various cloud services, landing zone and various networking aspects, they also work closely with security and compliance to build variety of policies and guard-rails on the platform services which helps shift-left security and compliance to the development squads. Hence platform foundations ensure all necessary cloud services including the tooling needs are offered as a service fully automate-able via Infra-as-code by the product teams / squads. Platform squads necessarily build the foundation platform that helps product teams work in true full-stack / product centric model.
Work-stream 4: Cloud Acceleration Center
Given the evolution of cloud services and multitude of services available for each solution, it is important to lay out a set of reference architectures, patterns, guidance and decision matrix and make it available to various product teams / squads. Cloud Acceleration center lays out enterprise level guard-rails for design and development of IT products via reference architectures, code-patterns (re-usable) that addresses key architectural constructs and subsequently work with various product teams to evolve and institutionalise leverage of the same across lifecycle (design-dev-ops). In summary, cloud acceleration center offers a set of products that helps build IT components in cloud native way (DevSecOps pipeline accelerators, API gateway generators, IAM accelerators etc.).
Cloud acceleration center works with different parts of the organisation (business continuity, security and compliance, change management etc.) to incorporate their requirements into their products. This incentivises product teams to embrace Cloud acceleration center artefacts. This enables product teams to make their own design decisions in alignment with the guard-rails laid by Cloud acceleration center. Also this helps address cloud skilling challenges due to ready-usable code-patterns that are easily consumable by product teams and they learn the depth over a period of time.
Conclusion
Overall, we have seen that transformation to product centric IT model requires a delivery model that addresses various dimensions of the transformation — people, process, and technology. A successful transformation program needs to deliver across all the work-stream so as to meet the end objective of product centricity. While this article summarises each of the dimensions we are planning to elaborate various dimensions in detail in subsequent articles.
Finally this is an attempt to layout an enterprise centric approach to embrace product centricity. We are extremely happy to hear any thoughts / feedback from anyone with their experiences that helps improve.
References
Special thanks to Charro Gruver (Senior IT Architect @ Red Hat and an SME in the DDD space) for his willingness in sharing the Shopping domain & products example referenced in this article. LinkedIn: https://www.linkedin.com/in/charro-gruver/
- Conway’s Law — https://en.wikipedia.org/wiki/Conway%27s_law
- Project to Product — https://techbeacon.com/app-dev-testing/projects-products-what-it-means-why-it-matters
- Product Centric IT — https://www.ibm.com/blogs/services/2021/06/30/8-ways-to-modernize-your-it-management-for-a-product-centric-organization/
