Architecture, Digital Strategy, and Portfolio

Description

The aggregate digital investments of any large enterprise are massive. Whether capital or expense, whether internally hosted or externally sourced, the IT portfolio consumes tremendous amounts of time, money, and expertise. In this chapter, we have discussed architecture in terms of catalogs, diagrams, and matrices, sometimes stored in architecture repositories. But architecture repositories are in general not analytic tools. Nor is architecture an analytic discipline (it is not usually strongly quantitative). Architecture too often relies heavily on interviews and expert opinions, approaches that are sometimes critiqued as relying on the “HiPPO”. Portfolio management can be a means to bring in a more quantitative approach.

We first discussed portfolio management in Portfolio Management. How do we define portfolio? Charles T. Betz defines it as: “things of consequence managed over a long time horizon” [Betz2011]. The concept of the TOGAF catalog is a good place to start. Frequently, portfolio management starts at the application level; the application portfolio can be seen as a sort of alternate “chart of accounts” by which digital investments can be grouped.

Portfolios are intended to provide a consistent basis for comparison and understanding. Items in the portfolio should be comparable. They may rely on both objective and subjective data points:

  • Objective data

    • Business revenue/value

    • Cost

    • Risks

    • Staffing

    • Service levels, changes, incidents

    • Product obsolescence (quantifiable technical debt)

  • Subjective data

    • Usability

    • Customer satisfaction (net promoter score)

    • Engineering assessments (subjective perceptions of technical debt)

Digital investments and costs typically include some or all of the following:

  • Hardware investment, depreciation or leasing

  • Software licensing (typically 15%-20% annually of initial acquisition, required for vendor support)

  • Floor space; i.e., real estate charges

  • Facilities infrastructure: power, High Volume Air Conditioning (HVAC), raised floor, racks, etc.

  • Network connectivity and related infrastructure (e.g., directory services software, security perimeters, and the like)

  • Operational software infrastructure: monitoring systems, batch schedulers, backup systems, and so on, all with their own associated costs

  • Operations and support staff; staffing typically can come in various flavors:

    • Data center operations monitors

    • Help desk operators

    • Application specialists

    • Senior engineers

    • Senior IT executives and customer relationship managers

    • Business-side lead users and process and information specialists

    • Vendor relationship owners and contract managers

Application Value Analysis

APM may concern itself with any or all of the following:

  • Business or financial value of applications in terms of what they support/enable

  • Application functions (examined for redundancy)

  • Application total cost of ownership

  • Application complexity

  • Fitness and currency of underlying technical products

  • Application service performance

  • Application customer feedback

A four-box is often used for application value analysis, as shown in Standard IT Portfolio “Four-Box”.

Table 1. Standard IT Portfolio “Four-Box”
Low Technical Fitness High Technical Fitness

High Business Value

Re-engineer or replatform

Consider outsourcing carefully

Invest as needed to exploit value

Low Business Value

Retire if possible or outsource

Improve understanding of customer requirements

Retire service if no longer serving a purpose but reclaim/reuse platform, capabilities, and assets

Application Rationalization

What does it mean to rationalize"? There are three steps:

  • Take an inventory of the items to be rationalized

  • Categorize them to identify redundancy

  • Consolidate redundancy

This implies some basis for classification so that the investments can be compared. This is where industry taxonomies, such as found in industry reference architectures, may help. You may call your application “Peoplesoft HR”, “Workday”, or even an internal brand like “HR2020”, but a reference taxonomy categorizes it as simply a “Human Resources Management System”.

Data integrations may also be a way to identify redundancy. When two systems start exchanging more and more data, a useful question is whether there is still a need for both or if a more economical, integrated solution is possible. Just beware of the risk of overly ambitious consolidation efforts.

Through analysis and understanding of redundancy and business and technical value, applications (and related concepts such as services and capabilities) can be managed as a coherent investment strategy.

Evidence of Notability

Architecture is often called on to rationalize complex assemblies of systems; for example, in the case of an organizational merger. This is some of the most challenging and high-value work in the digital/IT industry.

Limitations

A fully rational, planned approach to portfolio rationalization is extremely difficult, as complex portfolios are dynamic sociotechnical systems and radical interventions frequently give rise to unexpected, emergent responses.

Related Topics