Dissecting Cloud Functional Reference Architecture – Overview

This blog entry was originally published on the “CloudSource” blog in 2014.

I was asked a couple of years ago to develop a Functional Reference Architecture to provide a common framework to discuss cloud and the HP offerings. I have to admit I scratched my head. How would I be able to build such thing? How was it going to look?

Fortunately, I could count on some work that had already been done, and I managed to assemble a top notch team to help me build it. And frankly, we learned a lot along the way. The only advice I can give you is to either develop your own or carefully study an existing one. It forces you to think through many of the aspects that make cloud what it is.

The concept of a cloud platform

The first decision we made is that we would not start from what I have seen too often: a diagram with IaaS (Infrastructure as a Service) at the bottom, PaaS (Platform as a Service) in the middle and SaaS (Software as a Service) at the top. That gives the impression that to deliver SaaS services you also need to deliver PaaS and IaaS services. We know that’s not the case. Many companies just deliver SaaS services. So, there must be something else.

We ended up creating a concept we called “cloud platform” by asking ourselves what were the common functionality required to deliver any type of service. Frankly, I’m not really happy with the term “cloud platform” because it is too close to PaaS in my mind, but haven’t found any other term that correctly describes this base functionality. If you have a suggestion, don’t hesitate to let me know.

Now, the concept of cloud platform has to interact with the existing environment; within the converged cloud vision. There also has to be some functions that address both the traditional and the cloud world. We did not want to have different tools in each world, so we identified a number of key functionalities that cover both spaces. Building on our experience with ITIL and SIAM (Service Integration and Management), we came up with four classes:

  1. Governance related functionalities, focused on risk management, compliance, the management of the enterprise policies and standards and architectures. Again, you do not want to have different risk management approaches for your cloud and traditional environments. Enterprises are looking at assessing and managing their overall risk regardless of the service delivery approach taken.
  2. Business Management addressing the strategy, demand, financials, invoicing, procurement and client relationships. IT typically has one budget to manage all service delivery, regardless of the business model chosen. In case of shared services, the customer/user wants one bill.
  3. Management of the integrated environment, allowing the management of the complete IT environment from one pane of glass. You do not want two operations teams using two different sets of tools to manage the traditional and the cloud environment. They often are so tangled into each other they require an integrated management.
  4. Security including identity management, application, information and infrastructure security. You want to log on only once, while ensuring end-to-end security across all environments.

The nature of a service

We all talk about cloud services, but this term encompasses so many different options. Mostly people jump from discussing a cloud service to provisioning a virtual machine. That’s the easy bit. As an end-user, I want services that address my needs. Let’s re-visit an example I used earlier.

I’m an R&D project leader and have been assigned the development of one of our companies’ next-generation products. I’ve been told we will build on open innovation during the development process, resulting in me working with three universities around the globe. I should also closely work with a couple suppliers delivering key components as well as with our contract manufacturer. And last but not least I should coordinate five geographically distributed development teams. With all this in mind, I’ll need collaboration tools.

I want to be able to go to the service catalog and provision a “project collaboration service.” Don’t make it difficult. I want to provision this in one click. Now, the service I’m looking for will probably consist of a number of elementary services combined together to give me all the functionality I require. For example, I can imagine that the project collaboration service consists in:

  • A project mail address forwarded to my address
  • A SharePoint environment where our IP is captured
  • A Wiki to develop the documentation
  • A forum to allow interaction between the team members
  • An ideation platform to make suggestions and choose the most appropriate ones
  • A virtual room environment (such as MyRoom) allowing real-time collaboration and document sharing

Each of the elements of the service can be offered individually in the catalog. But from the point of view of the project collaboration service, they are service elements. Each service element will consume a series of resources to deliver its functionality. And to make it even a little more complex, my project mail may be delivered through dedicated servers, the SharePoint kept behind the firewall, the Wiki hosted on a managed cloud, the forum on a public cloud and the ideation platform  and  virtual room may be aggregated SaaS services.

Welcome to the converged cloud. As an end-user I do not want to have to bother about the intricacies of all these delivery environments. I just want to consume the service advertised in the service catalog.

Three layers of functionality

To deliver this service in a comprehensive way, we have built the cloud platform around three layers, each focusing on a specific functionality. I’ll describe those layers in more detail in future blog entries, but here is a glimpse:

  • The Demand layer—interacts with the user, shows him the services he can provision as well as the ones he already provisioned, allows him to choose a service and manages the approval cycle associated with this request. The demand layer is focused on the advertised service.
  • The Delivery layer—will decompose the service in all its service elements and ensure the appropriate resources are available to deliver each service element, hence the final service. Once that is done, the delivery layer will trigger and manage the provisioning process.
  • The Supply layer—will work closely with the delivery layer to provide all the resources required in the delivery of each service element. This includes servers, storage, networking, but also license keys, IP addresses, network elements etc.

IT from a service provider point of view

IT is really becoming a service provider. For this reason we decided to use elements of the eTOM model and you’ll find three key concepts have returned:

  • Provisioning/de-provisioning, the process of obtaining or releasing an instance of the service
  • Usage, gaining access to the service instance
  • Assurance, addressing the service level agreements and metering aspects related to the consumption of the service.


There is one more aspect I need to discuss before I go into the details of the cloud platform layers, and that is service portfolio management. I’ll do that in the next blog entry, because it’s important to gain a complete picture of the HP Cloud Functional Reference Architecture. So, stay tuned.

Do you recognize your needs in what I described up till now? How would such approach benefit your organization? What did we miss? Feel free to start the debate.


Tell me what is going through your mind.

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s