Architecture Modernization : Strategic IT portfolio

• Architecture should be treated as a portfolio, with a level of investment and operating model tailored to the specifics of each area.
• A well-designed technology architecture may just be gold plating that wastes effort that could have been better invested in more strategic areas.
• Martin Fowler’s utility versus strategic IT dichotomy classifies IT applications as utility or strategic according to their contribution to business differentiation. Software that helps organizations to differentiate is considered strategic, while software that is considered just to be a cost of doing business with little or no differentiation is considered to be utility.
• Classifying IT as utility or strategic is not to serve an academic or theoretical purpose; it should have specific impacts on many aspects of the operating model, including team size, team composition, product discovery, prioritization, domain modeling, architecture, code health, and build versus buy versus partner.
• Candidates for strategic IT are likely to be found on a Wardley Map between late genesis and mid-product. This is not a hard and fast rule, and not all components within these areas are guaranteed to be strategic IT.
• The act of collaboratively defining a product strategy based on research and data will make clear which parts of IT are strategic.
• Business domains are a great model for enabling architecture to be treated as a portfolio with investments aligned to business outcomes. Each business domain and subdomain can have tailored investment and operating model characteristics.
• Core Domain Charts is a technique from the domain-driven design community that helps to identify and make decisions about strategic IT and the approach to be taken in each subdomain.
• A collaborative approach involving business, product, technology, and other stakeholders is ideal when defining Core Domain Charts.
• In DDD, each subdomain is considered to be core, supporting, or generic based on a combination of business differentiation and model complexity.Core domains (which are subdomains) are high in differentiation and complexity, so they should nearly always be built in-house. They align with Fowler’s definition of strategic IT.Supporting subdomains are less complex and differentiating but require industry- and company-specific domain logic, so they are typically built in-house.Generic subdomains have little or no differentiation potential, and where possible, off-the-shelf solutions usually make sense. They align with Fowler’s definition of utility IT.
• The classification of a subdomain can change over time. What is core at one point in time will most likely drift left into supporting at some point in the future. Arrows can be used on a Core Domain Chart to show this evolution.
• Model complexity is a composite measure of complexity that represents the effort required to discover user needs, build and evolve a domain model, implement it in software, and support it in production.
• Operational complexity is usually not considered to be part of model complexity but often plays an important role in strategic discussions, so it can be highlighted on Core Domain Charts using annotations.
• There is some overlap between Core Domain Charts and Wardley Mapping; however, Wardley Mapping is a much more advanced technique that takes an industry-wide perspective and can be applied to all scopes. Core Domain Charts are used more specifically to visualize strategic IT choices according to differentiation and complexity.
• There are a variety of patterns that can be observed on a Core Domain Chart, like decisive core, indefensible core, suspect supporting, and table stakes supporting. Each pattern has implications on how the subdomain should be treated.
• A decisive core typically necessitates a big investment in talented people, collaborative practices like EventStorming, and more advanced architectural patterns.
• A table stakes support requires a much smaller investment to achieve a good enough solution, providing that there is no negative effect in core domains.
• While fine-grained investments can be made on a per-subdomain/per-team basis, it’s important to look at the investments in the portfolio as a whole because there are dependencies between subdomains, and decisions taken in one may affect others.

#Architecture #Modernization #Strategic #IT #portfolio

Credits - Manning