Service Portfolio Enablement Through the Cloud

Many are extolling the virtues of moving to the Cloud-enabled environment. From increased reliability to elastic applications and even predictable infrastructure costing, the benefits are indeed great. However, there has not been adequate conversation around how the Cloud allows the automation of Service Portfolio Management. Prior to the cloud, it was simply impossible to dynamically allocate infrastructure costs to the various services in the Portfolio. By using the allocation tools embedded in a public or private cloud, it is now possible to properly allocate these costs in a true consumption-based model. This allows us to automatically align the asset cost data with the labor cost to create the end-to-end cost structure of the service. Only through the automated calculation of this cost can fluid ROI calculations be generated, which facilitate the many benefits of Service Portfolio Management.

The Service Costing Challenge

The biggest challenge in enabling Service Chargeback in most environments is accounting the foundational elements that are shared dependencies across all Services. For example, there is a huge cost associated with establishing core-networking functionality in an organization -- from the network equipment and accessories, to the labor, to install, to configure, and to maintain this equipment, and even the upstream service cost from the Telco providers used for WAN connectivity. It is necessary to make this cost digestible by the business as an enablement service and apportion it to the various dependent business services the organization is able and willing to pay for.

There are many strategies to address this, but most leave much to be desired. In the best cases, the cost ends up being represented as a sunk cost equally distributed across all departments. The challenge in this methodology is the inequity of forcing all departments to bear the burden of costly services used by only a few. Imagine the situation in which one department requires a dedicated OC3 connection to support their activities where others could easily operate with a fraction of a single T1 line. While all departments will benefit from the increased capacity, the benefit to one department will clearly be higher. Does it make sense to charge all departments equally? How do they account for capital expenditures, or support costs and labor where one department uses a disproportionate percentage of a given service?

While unfair, the equal distribution method is still vastly superior to the more often leveraged methodology in which the costs are owned entirely by IT, which then becomes a black boxed cost center rather than a partner in the business. In these instances, the demands for faster, better, more expensive service tend to grow unchecked because the costs are not transparent to those consuming the service. The business simply demands more, faster, better, while simultaneously demanding that IT find a way to reduce budgets. This is clearly not a model for success.

There is, however, a way to define a model that accounts for the distribution of costs across the Service Portfolio.

Enter the Cloud

Among the many benefits of the cloud, cost transparency is certainly one of the most important. This is especially true of the public cloud. Here, IT can consume resources at a predetermined rate, which enables them to expose and pass along those direct consumption based costs to the department directly benefited. It is possible to extend these same benefits to the private cloud by establishing a cloud service model in which IT becomes a service provider for the business.

The key to success in cost modeling in the private cloud is establishing a "Cloud Wall" for IT costs associated with each internal cloud environment. This wall separates the costs as they align either to the shared environment or to a department or userís specific service consumption. With this wall acting as a line, it is possible to cleanly take all above-the-Cloud Wall costs (such as user support cases, instantiation costs, or special orders) and charge them back directly to the consumer. Below-the-line costs would roll up to establish the base cost of the cloud environment that is then partitioned to all the containers utilizing the platform.

Examples of below-the-line costs that should be rolled into the platform cost include items such as:

  • Physical Infrastructure devices (Servers, Switches, Firewalls, etc)
  • Software consumed below the wall (Virtualization, databases, web servers, management software, etc)
  • Services consumed by the platform (IP connectivity, Monitoring, Power, Facilities, etc)
  • Support and Labor costs associated directly with the maintenance of the platform

With these costs correlated, there can now be an understanding of what it takes to provide the base platform on which our business cloud-containers will reside. There need only be an equitable way to apportion this cost out based on the consumption of containers operating on the platform segment. For this, Public Cloud providers offer good costing examples. Four currently popular ways to allocate costs are:

  • Instance: Cost associated with each container (typically variable based on the container type. e.g. a virtualized infrastructure container would have a fixed rate that differed from a backup storage container)
  • CPU: Measure of CPU cycles consumed by the allocated cloud-container (in many ways this method brings us full circle to the MIPS based mainframe charging of 30 years ago)
  • Bandwidth: Measure of the consumed bandwidth of a given cloud-container
  • Storage: Measure of the persistent storage requirements of a given container

Using these metrics, the costs of the IT environment can be fairly distributed to those placing the largest demand on the systems. For example, in a cloud environment serving applications to various business units, the total cost of the platform would be distributed to each department based on their containers cumulative Instance, CPU, Bandwidth, and Storage consumption. The total above-the-line costs would be added to determine the invoice total for a given department. Further, these costs could be expressed in an invoice back to the department that clearly demonstrates their consumption. This would provide the necessary transparency for the business to make appropriate business decisions regarding their efficient or inefficient use of the shared platform.

From these costs, it is also possible to extrapolate the effective Return on Investment (ROI) of every service provided. As infrastructure, support, and foundational support services are demystified, department heads can take a close, honest look at what services are adding net positive value to the organizations. It is here that the real value of Service Portfolio Management becomes possible. With benefit calculations coming from the Service Catalog, associated costs can be aligned to determine if a Service in the Portfolio should be maintained, improved, or simply retired.

About the Author

Joseph Hurley has over 15 years experience in IT. He has spent the last 10 years focused primarily on the areas of service management and asset management. A software developer by training, he has worked closely with a wide variety of companies ranging from small startups to the Fortune 500. He operates, a website devoted to expanding industry exposure to IT Best Practices. He has authored many whitepapers and articles. He has presented at itSMF events, holds certifications in ITIL and ITAM, and is currently a Sr. Principal Consultant for CA, Inc.

More by Joseph Hurley