Author’s note: Central ownership is not the same as central procurement although they are often confused. There are many good reasons for central purchasing, standards, etc… These are all foundational to central ownership and are presumed to already be in place for the purposes of discussing central ownership.
In most large organizations, the assets which constitute the IT infrastructure are considered owned by the various business units, markets, regions, or other subdivisions rather than by IT. Since the business units either purchased the assets directly or IT did so and charged back the cost, it is quite natural for these groups to feel like they own the assets in question. This produces a number of problems and cripples the ability of IT to manage the infrastructure efficiently. Centralizing the ownership of these assets within IT drastically simplifies a number of otherwise complex or even unsolvable problems, particularly with regards to eliminating idle infrastructure. It is also is the only way to effectively support a shift to a service-oriented IT model.
So if central ownership of IT assets is the answer… what are the questions?
Reducing Idle Infrastructure
IT Asset Managers wear many hats, but I believe one of our core roles should be as stewards of the investment our organizations have made in their IT infrastructure. In that capacity, few things could be more significant than addressing portions of it which are unintentionally idle. There is a whole set of infrastructures, such as that used for high availability or disaster recovery, which could be considered idle as well, but it would at least be intentionally idle. What we are after are the items which were deployed with an expectation of use and are not fulfilling that expectation.
In just about every organization, there is a significant portion of the IT Infrastructure which is unintentionally idle. This level of idle infrastructure is far higher than would be found in areas outside IT, such as manufacturing. As part of the general effort to lower costs and increase efficiency, many organizations are already engaged with this issue to some degree, but it is one with a number of problems which plague attempts to find a solution. One of the biggest of these is the notion of “ownership.” Generally, the business unit or group which purchased and/or paid for an asset feels, somewhat rightfully, that they “own” it.
This notion of distributed ownership is at the core of the problem and what must change to effectively address not only the issue of idle infrastructure, but also a host of other related issues. The only way I know of to do this is to turn the whole situation inside out and centralize the ownership of all IT infrastructure assets. This allows the ITAM group to effectively manage the utilization of IT assets across the entire organization. If a piece of equipment is idle in one designated use, it can be redeployed where needed rather than purchasing another one.
Unfortunately, we cannot just centralize ownership without also changing how our business users acquire access to the IT infrastructure they need. For centralized ownership to work, it must be accompanied by a capacity/usage based model for access to IT resources. Fortunately, this is actually how most of our business users would rather function. For example, they do not really want a server. What they want is access to the computing power which that hardware provides. This means IT needs to get into the “capacity” game. A business unit no longer buys IT assets; instead they pay for access to the IT capacity they actually wanted. By “access to IT capacity,” what I really mean is what is far more often described as an IT service. For centralized ownership to really work IT must convert to a service-oriented model or there is no practical way for business users to access to what they need. The good news is doing so tends to already be a “top 10” initiative.
Unfortunately, the phrase “service-oriented IT” has been overused recently, even more than “utility computing” was a few years ago. Worse, many attempts to convert IT to a service-oriented model have stumbled and stalled, often ending up delivering nothing more than a new requesting system for “IT services” which really are no different than what was being purchased before. I believe the primary reason for this is the failure to recognize that the transformation to being a provider of true IT services requires the ownership of IT assets be centralized.
The reason for this can be seen in the very definition of what a service is. Two definitions:
From the “Universal Service Management Body of Knowledge (USMBOK™)”:
A service is an act or performance that one person can offer to another that is essentially intangible and does not result in any transfer of ownership. The value of the service to the customer is through the results achieved through its use – the outcome. The importance of the service to the provider is through the satisfaction and value it provides the customer, the revenue it generates for the provider, vs. the cost of production. Its distribution and use may be tied to a physical product. (1)
From the “Information Technology Infrastructure Library (ITIL®)”:
A means of delivering value to customers by facilitating outcomes customers want to achieve without the ownership of specific costs and risks. (2)
Both of these definitions address ownership and the concept that subscribing to a service does not involve ownership of the means by which the service is fulfilled. A key aspect of any type of service which both definitions hold implicitly but do not call out explicitly is that a service starts and ends.
Despite the frequent failures which have plagued attempts to transform into a service-oriented IT model, there is still a strong push to do so. The explosion of cloud services has exposed business users to what they want their experience with IT to be like. So how do we do it? And why is centralized ownership of the IT Infrastructure crucial to successfully doing so?
Core to a service-oriented model of any type, not just IT, are two different kinds of “Service Catalog” and to avoid stepping on specific meanings from various frameworks, I will use what I believe to be my own terms. Outward facing to the consumer is the “service provisioning catalog” which defines all of the services and allowable options/variations which can be ordered or subscribed to. It is much like the menu at a restaurant. In fact, for a restaurant, the menu is its service provisioning catalog. (Or at least one of them, since there may be additional catalogs for catering services, etc…). Inward facing to the provider is the service fulfillment catalog which defines how to go about delivering the services which are requested. Continuing the restaurant analogy, every item on the menu has a defined way in which the kitchen is going to go about producing it. At least, for any successful restaurant there is. This is what allows them to deliver consistently on the services which they offer to provide. The key here is that the person requesting the service generally wants to know as little as possible about how the service is actually provided so long as it delivers on what it promises to be. The service provided satisfies the consumers’ needs without exposing them to the complexity behind the curtain.
So how does this all relate to IT services? There is an old adage in sales about selling the hole, not the drill. IT is notorious for providing drills to business users who ask for holes. In almost every case, what business users need is a set of certain capabilities which they really would rather not have to know the details about. It is a near perfect scenario for a service-oriented model, but that does not mean it is easy. Defining what will be in the two catalogs and how it will be priced is no simple task. Without a centrally owned infrastructure doing so goes from difficult to impossible.
Is Central Ownership really necessary?
Efficient use of IT assets and a service-oriented approach truly fit together hand in glove. Initiatives to reduce idle infrastructure may be somewhat successful without a central ownership model, but it typically requires a crippling level of management. I have not seen an organization successfully achieve a service-oriented approach for anything other than specific operational services without IT owning the assets used to fulfill the services they provide.
The true synergy between the two lies in the fact that a service can be stopped. If a business unit owns a server or a license, they tend to hold onto it “just in case,” even if they are not using it at the moment. If they are paying for a service which gives them access to it, they are incentivized to unsubscribe from it as soon as it is no longer needed. The hardest part of solving the idle infrastructure problem essentially solves itself. Instead of chasing after it alone your business users will be on the hunt for it too. And when they find it there will not be any arguments about your taking it back like there are today.
Another advantage of moving to a model based on provisioning/fulfillment of IT services based on a centrally owned and managed infrastructure is it applies cleanly across the IT infrastructure. It works for software, desktop hardware, server hardware, virtual environments, storage, networking, telephony, etc… in one cohesive model without having to treat each segment in special ways. This further simplifies the infrastructure management effort and allows for far cleaner comparisons to third party service providers.
Problems and Pitfalls
There are many other positive effects from centralizing ownership and moving to a service based IT model, but what are the downsides? There have to be some… and there are. Not really problems with the model once in place, but things which can cause trouble in making the transformation.
Concerns about service delivery: When the specific capacity needed is purchased directly, the consumer generally has exclusive access to it. As a service, the capacity is generally going to be provided off of shared infrastructure. It can be dedicated of course, but doing so prevents much of the desired efficiency gains. Since it is shared there is a natural concern about whether there is sufficient infrastructure to meet capacity demands.
Compensating existing owners: When you centralize ownership of infrastructure owned by various business units they will need to compensated for it in some way or they will be understandably resistant to it. Providing the corresponding service at no cost for a period of time for the capacity which the transferred equipment was providing is generally the cleanest. This time frame can be fixed or based on the remaining useful life of the assets.
IT finance rules and funding: The costs of subscribing to an IT service will be almost always classed as an expense. If the capacity provided by the service would have been capitalized if purchased (such as a server), this may require some adjustment to how funding is allocated.
Creating the service catalog: It takes a great deal of effort for IT to capture the comprehensive list of services that needs to be provided. Even more analysis is needed to understand the costs associated with doing so well enough to price those services appropriately. However, rather than looking at the cost and effort required to do this, consider the value gained from it. In no other aspect of the business would we get away without already knowing this information. If we are going to even get close to “running IT like a business,” then this type of activity is a core requirement.