Admittedly, when I was heads-down in code earlier in my career, I did not pay much attention to reference architectures. We had our own internal architectures that served as ‘the way and the truth', and reference architectures for our product or solution domain were simply out of scope. Anyway, reference architectures are, by design, not detailed enough to steer someone implementing one out of hundreds of components that will fall under said architectures. So, for the most part I ignored them, even though I could hear rumblings coming from rooms full of folks arguing over revision 25 of the reference architecture for some problem domain or another.
Fast forward a few years to a change of professional venue, and my outlook on reference architectures is a good deal different. If I were still developing, I'm sure my outlook would be much the same. However, talking with users on a frequent basis has made me aware that such architectures and solution domain overviews can be of great value to both buyers and providers. For buyers, reference architectures can help to orient them in a particular domain, and they can guide implementation and buying strategies. For providers, reference architectures serve to clearly communicate their outlook on a particular domain to both the buyers and broader market. Put simply, reference architectures serve both sides of the coin.
Now that's not to say that reference architectures come without their detractors. There are always those that stand ready to point out holes and biases in a particular provider's reference architecture. In fact, some seem to completely write off reference architectures as an instrument of marketing. In my opinion, some of these complaints are without merit and a bit overly cynical. Other complaints rise above typical inter-vendor sniping and actually point out valid holes, oversights, and biases with a particular provider's architecture. Open discourse and communication is good. In that light, I was glad to see IBM publish the second version of its cloud computing reference architecture to the Open Group earlier this week.
The document, which you can download here, explains the reference architecture in detail, but I want to look at the major highlights. To start, let's consider the high-level diagram for the architecture:
As you can see, the architecture orients itself around user roles for cloud computing. On either end, you have the cloud service creator and cloud service consumer. As its name implies, the cloud service creator role includes any type of cloud service creation tools. These tools include software development environments, virtual image development tools, process choreographing solutions, and anything else a developer may use to create services for the cloud.
On the other side of the architecture, the cloud service consumer comes into focus. As you well know, in a cloud environment there are many potential service consumers. The architecture above accounts for in-house IT as well as cloud service integration tools as consumers. There are countless more, but just with these you can begin to appreciate the challenge of effectively enabling the ‘consumer.' This requires self-service portals, service catalogs, automation capability, federated security, federated connectivity, and more. It is certainly no small task.
Finally, in the middle of the diagram, we have perhaps the most complex role, the cloud service provider. This section builds on top of a shared, usually virtualized infrastructure to address two basic facets for providers: services and service management. From a services perspective, we see the trinity of the cloud (IaaS, PaaS, SaaS), with an added wrinkle, Business Process as a Service. As the diagram acknowledges, existing services and partner services will nearly always augment these services, thereby implying the need for tools that provide both functional and non-functional integration capabilities.
Opposite the services, we see the common management framework that divides into two major categories: Operational Support Services (OSS) and Business Support Services (BSS). Naturally, the OSS accounts for those capabilities that a provider needs to effectively operate a cloud environment. This includes provisioning, monitoring, license management, service lifecycle management, and a slew of other considerations. BSS outlines the capabilities providers need to support the business requirements of cloud, and this includes pricing, metering, billing, order management, order fulfillment, and more.
Of course, there are non-functional requirements that span all three roles including security, performance, resiliency, consumability, and governance. Thus, these wrap the three major roles in the reference architecture shown above.
I know there will be some that disagree with certain elements of this reference architecture, but that is good and healthy. For those that have strong opinions on this subject (one way or another), I encourage you to get involved. That is the benefit of this being in the Open Group. You can download the reference architecture, review it at your leisure, and then discuss and influence change via the mailing list discussion. In other words, speak up!
Subscribe to WebSphere Journal Email News Alerts
Subscribe via RSS
