Managing Digital: Concepts and Practices

We’ve discussed products and the various ways digital organizations deliver them, from simple work management to more sophisticated project and process management approaches. Now, we need to refine our understanding of the products themselves and how they are managed.

We previously discussed the relationship between feature versus component teams in chapter 4. In chapter 9, we touched on the idea of shared services teams. Both of these ideas are now expanded into what is called the "four lifecycle model.”

The four lifecycle model was first documented in [24]. The four lifecycles are:

Each of these lifecycles reflects the existence of a significant concept, that is managed over time, as a portfolio. (More on IT portfolio management practices in Chapter 10).

First, bear in mind that services are kinds of products. Digital value is usually delivered as a service, and shares standard service characteristics from an academic perspective, including the idea that services are produced and consumed simultaneously (e.g.,an account lookup) and are perishable (a computer’s idle time cannot be recovered if it goes unused).

The first two concepts (application and infrastructure service) below reflect these characteristics; the second two (asset and technology product) do not.

An application service is a business or market-facing product, consumed by people whose primary activities are not defined by an interest in information technology: for example, a bank customer looking up her account balance, or an Accounts Payable systems operator. In terms of “feature versus component,” the concept of Application is more aligned to “feature.” An example would include an Online Banking system or a Payroll system.

The application service lifecycle is the end-to-end existence of such a system, from idea to retirement. In general, the realization such a system is needed originates externally to the IT capability (regardless of its degree of centralization). Software as a Service usage is also tracked here.

An infrastructure service is, by contrast, and as previously discussed, a digital or IT service primarily of interest to other digital or IT services/products. Its lifecycle is similar to that of the application service, except that the user is some other IT service. An example would be a storage area network system managed as a service or the integrated networking system required for connectivity in a data center. Platform and infrastructure as a service are also tracked here.

Note that in terms of our service definition discussion, the above lifecycle concepts are service systems. The lifecycle of service offerings is a business lifecycle having more to do with the go-to-market strategy on the part of the firm. We covered this to some extent in Chapter 4 and will revisit it in Chapter 12.

An asset is a valuable, tangible investment of organizational resources that is tracked against loss or misuse, and optimized for value over time. It can sit unused and still have some value. Examples would include a physical server or other device, or a commercial software license. Whether assets can be virtual is a subject of debate and specific to the organization’s management objectives (Given the licensing implications of virtual servers, treating them as assets is not uncommon).

The asset lifecycle is distinct from the service lifecycles, following a rough order including standard supply chain activities:

A contract reserving cloud capacity is also an Asset.

Finally, a technology product is a class of Assets, the “type” to the Asset “instance.” For example, the enterprise might select the Oracle relational database as a standard Technology Product. It might then purchase 10 licenses, which are Assets.

The technology product lifecycle is also distinct from both the Service and Asset lifecycles:

Cloud services need to be managed in terms of what version they are and what the interoperability concerns are.

The challenge in digital management is “lining up the lifecycles” so that transactional value flows across them (see Multiple lifecycle model footnote:[similar to [24]).

This can be very difficult, as each lifecycle has a logic of its own, and there may be multiple interdependencies. A technology product may come to the end of its market life and drive expensive changes up the stack. Conversely, new application requirements may expose deficiencies in the underlying stack, again requiring expensive remediation. Technology product vulnerabilities can prove disruptive, and the asset lifecycle (representing either physical depreciation and refresh cycles, or time-bound licensing) is a significant cost driver.

These lifecycles are essential to all of the next 3 chapters.