The interacting lifecycles: Service, Asset, and Technology Products

We have previously discussed the Asset lifecycle and its architecture. However, Asset is only one of four IT lifecycles:

• Application services
• Infrastructure services
• Assets
• Technology products

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 (IT): a user example could include a bank customer looking up her account balance, or an Accounts Receivable systems operator checking payment status, while a Service example by contrast would include IT-centric functions such as an Online Banking system or a Payroll system.

An Infrastructure Service is, by contrast, a digital or IT service primarily of interest to other digital or IT services/products. Its lifecycle is like that of the application service, except that the user is some other IT service. An example would be a private cloud, or 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 is also tracked here.

The Service Lifecycle is the end-to-end existence of either application or infrastructure service systems, from idea to retirement. Services imply ongoing support; they are live and operational.

An Asset is a valuable, tangible investment of organizational resources that is tracked against loss or misuse and optimized for value over time, which 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, but given the licensing implications of virtual servers, treating them as assets is not uncommon.

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. Or, a particular class of server (e.g. HPE ProLiant DL380) is another kind of technology product. Technology products are not services; an organization can acquire technology products by buying assets and not running them, in which case they are not services. Or a service may use multiple technology products (e.g. a private cloud service based on VMWare, Cisco, and DELL hardware and software assets).

Technology products can be complicated to explain, and many people who are starting out on their CMDB (Configuration Management Database) journey simply don’t understand why you need all these concepts. But trying to reduce technology products to services or assets always leads to confusion. Services are composed of assets, which are instances of technology products, is the correct way to think of it. Services are supported – someone is “on call” – while technology products are passive and only made available through asset instances that support operational services.

The lifecycles drive much activity because they often don’t line up. Services use multiple kinds of technology products, represented by assets.

One of the reasons that IT management can be so painful is the time and effort spent “lining up the lifecycles.” As an example, assume a database is no longer supported for version 9, and so a decision to start deployment of version 10 is taken, but version 10 only runs on 64-bit architectures, so it’s not just a matter of upgrading the database license. The entire server strategy needs to be considered, and there will also be ripple effects up into the infrastructure services (e.g. internal cloud) and ultimately the application layer. Before you know it you’re in a discussion about building out a whole new water-cooled, DC-powered wing of the data center, all because the database version went off support.

Another example might be an application vendor  requiring a patch, but again, that patch has only been released for versions of the application that are certified on more modern infrastructure and so the entire technical stack gets driven into change from the top-down.

One thing is clear, having solid IT asset data is essential to navigating these commonplace complexities. If you have a complete inventory of your assets, you can understand the interacting lifecycles and make appropriate plans by combining your asset data with lifecycle data; you can comfortably build long-horizon forecasts and strategic technical plans. But this planning all starts with having data that is complete, accurate and clean, which is why CMDBs are so critical to a smoothly operating IT ecosystem.