In 2013 a small cross HP team created version 5 of the HP Cloud Functional Reference Architecture. Unfortunately the original blog describing this architecture is no longer online, so I re-published it for your reference here. This work actually led some of us to further describe how a service should be managed across its lifecycle. This resulted in the IT4IT reference architecture that was then contributed to the OpenGroup. The Open Group defines the IT4IT Reference Architecture standard consisting of a reference architecture and a value chain-based operating model for managing the business of IT.  It provides prescriptive guidance on how to design, procure and implement the functionality needed to run IT. The end-to-end, ‘how to’ emphasis of the IT Value Chain and IT4IT Reference Architecture also enables the state of services that IT delivers to be systematically tracked across the service lifecycle.

So, the objective of IT4IT is to prescribe the processes required along the IT value chain. It seemed natural for us to describe a Functional Reference Architecture that would support IT4IT. And this is precisely what we have spent the last several months doing with a small cross HPE team comprising some of the original team members, Lars Rossen, one of the IT4IT fathers and new members focused on hybrid IT and brokering. Today we are glad to share this new architecture with all of you.


Let’s review this architecture in some more details. What remains and what has changed. We have not changed the three layers, and still define them as we did several years ago:

  • The Demand Layer has all the components that is used in the interaction with the consumers of IT.
  • The Delivery Layer contain all the components that do the detailed technical management of planning, delivery, consumption and running of the services. Typically the consumers of IT do not directly interact with components in this layer.
  • The Supply Layer contain the component needed to manage and interact with supplier as well as being the mediation layer for internal resources managed by IT

At the bottom you find the resources which are the types of environments the system will interact with. As we recognize larger enterprises typically need a variety of environments to run their applications on we have called this reference architecture “Hybrid Management Functional Reference Architecture”, rather than using the term cloud which sounded limited to us.

The previous architecture inspired itself from the ITOM model and included vertical columns around service provisioning, usage and assurance. This time we started from the IT4IT falue streams. From left to right we go from the service planning through its design and development, fulfillment, usage and assurance. From that perspective, the current architecture expands the old one in the planning, design and development space while re-using some of the concepts in provisioning, usage and assurance. Here is how we implemented the four value streams:

  • The Strategy to Portfolio (S2P) Value Stream provides IT organizations with the optimal framework for interconnecting the different functions involved in managing the portfolio of services delivered to the enterprise. Activities such as capturing demand for IT services, prioritizing and forecasting investments, Service Portfolio Management, and Project Management require data consistency and transparency in order to maintain alignment between the business strategy and the IT portfolio. In this column you find the functionality supporting the IT4IT processes.
  • The Requirement to Deploy (R2D) Value Stream provides the framework for creating/sourcing new services or modifying those that already exist. We realized there were two different facets of developing a service. So we devided this area in two pieces. First we looked at what we call the service capability, the actual development of the functionality that will deliver the service or a portion of the service. You will find here development environments as well as full DevOps capabilities including source control and build/test tools, all very much associated with continuous integration. The second sub column looks at designing how the service will actually be fulfilled. It includes the development of the offer that goes into the service catalog, how the service is consumed, the posibility to compose a service from multiple services developed in the previous part or sourced from external (brokering). Here you will also find the continuous deployment tools and templates. This is often done by different organizations and have a different lifecycle (Logical Design LifeCycle versus a Release and Offer Lifecycle)
  • The Request to Fulfill (R2F) Value Stream is a framework connecting the various consumers (business users, IT practitioners, or end customers) with goods and services that are used to satisfy productivity and innovation needs. We have devided this value stream in two parts for similar reasons as R2D. In the fulfilment there are two aspects. The first aspect consists in requesting access to the service, what is known in cloud terms as service provisioning. You will find all the elements needed to create an environment in which users can provision services. The second aspect consists in consuming the actual service, in other words using it. Here we find the metering, the show or charge back mechanisms etc.
  • The Detect to Correct (D2C) Value Stream provides a framework for integrating the monitoring, management, remediation, and other operational aspects associated with realized services and/or those under construction. The service assurance provided here focuses on the identifying and remediating issues as well as managing the quality of service and experience. As with IT4IT, the D2C value stream links back to the R2D one and in particular to the service capability design.

Most of the data artifacts we use in the hybrid management functional reference architecture are the same as the ones you will find in IT4IT. However we had to add some additional ones to ensure all relevant data was available to operate this architecture.

You will also see that we perform specific functionalities in specific parts of the architecture. Intermediation is performed at the subscription management and request rationalization level while aggregation is done in the service instance lifecycle management for example. This allows us to integrate key components of the NIST cloud architecture and make sure they are properly positioned and represented in the HM FRA.

Feel free to provide us feedback. We’re actually looking at engaging with interested parties to continue building this architecture out.