NIST Cloud Computing Reference Architecture

I see NIST have now published their Cloud Computing Reference Architecture as a recommendation. Little has changed conceptually since earlier drafts, but the document is now more detailed and complete.

In earlier commentary on Cloud Computing Reference Architectures, Models and Frameworks I described how there is little concensus on what form a reference "thing" should take or what its content should be, and that most are a mish mash of concepts that have their own structure, but not a consistent structure that enables them to be easily combined or compared for example.   The NIST Cloud Computing Reference Architecture is no different in that respect.

However, it is still a worthy document, and as with earlier NIST output that laid out definitions for core cloud computing concepts such as SaaS/IaaS/PaaS, the reference architecture is bound to be widely referenced as a "standard".

Service Boundaries

Richard Veryard asks in his blog on Service Boundaries  "where did all the boundaries go?"

CBDI Forum was one of the organizations back in those early days that Richard refers to that promoted the concept of service boundaries, but unfortunately not much of our work on that principle is freely available. So, I thought I would rectify that.

The Service Oriented Cloud

Cloud Computing is intrinsically service-based. But this is not just in the highly generalized sense of the term ‘service’, but also in the more specific Service Oriented Architecture (SOA) use of the term, where capabilities are provided via published service interfaces. When Amazon CTO Werner Vogels describes the Cloud as "a collection of services", in AWS terms the capabilities provided are SOA-style software services, complete with published Web Service interfaces.

As well as the PaaS and IaaS capabilities provided by AWS or Microsoft's Azure for example, there are also SaaS capabilities provided by the likes of salesforce.com that can be consumed as software services.

Hence the concept of the Service Oriented Cloud (SOC)  illustrated below.

Cloud Computing Reference Architectures, Models and Frameworks

There are a plethora of different reference architectures, models and frameworks for Cloud Computing (CC). As well as several vendors such as IBM or CISCO, it seems every standards or industry body has to have their own reference "thing" too. Hence there are architectures from DMTF, CSA, SNIA and the Open Group (which has been submitted by IBM) as well as several seemingly competing federal initiatives.  NIST, who have established the de facto definitions of CC and the service and deployment models also have a draft CC Reference Architecture.

So which one should an organization adopt? Of course there’s no straightforward answer to that question and so I have published a research note on Everware-CBDI to provide guidance on how to organize some of the best ideas that are emerging in a practical structure that should stand the test of time.

UML Profiles in Visual Studio 2010

UML Profiles are supported in Visual Studio 2010 (VS2010). Here I examine how they work and whether our CBDI-SAE UML Profile for SOA (SAE Profile) can be used in VS2010

Trialing Microsoft Office 365 Beta

Currently trialing the Microsoft Office 365 Beta. It seems tailored made for small businesses like us. Like many small businesses, we already rely on several disparate hosted services such as email, a SharePoint for collaboration, Skype, Webex, plus some use of Google Docs, and so on, all of which are supplied by different providers, resulting in incompatibilities, lack of integration, multiple signons, etc.
Bringing together all these capabilities under one roof seems attractive. It will also help to ensure everyone is using Office 2010 (no more need to save as 2003!).
Will update as we use it more.

Everware-CBDI plays key role in developing ACT-IAC white paper on Enterprise Architecture and Cloud Computing

Under the auspices of ACT-IAC’s Enterprise Architecture SIG, my colleague Dave Mayo, the President of Everware-CBDI, has led a team in the development of a white paper explaining the role of EA in Cloud Computing.  The paper explores architectural issues, management issues and tools for decision making regarding cloud deployments.  The fundamental finding is that the prerequisite to success with cloud computing is the establishment of a Service Oriented Architecture that identifies the services deployed to the cloud and how they may be accessed.

Click to access the White Paper on the ACT-IAC website. (Word)
or view as HTML on the Semantic Community

Windows Azure - Making Migration to the Cloud Seamless?

This week I attended a Microsoft UK Tech Days (a sort of local version of TechEd) on building and deploying applications onto the Windows Azure cloud platform.  In typical TechEd style, once a few positioning slides had been quickly dispensed with it was down to business with a deep dive into the code and admin tools.  Though my day job isn't as a professional developer, as a consultant and architect I like to know enough about how these things really work.

I came away impressed with just how seamless they are making the migration of applications to the cloud.

CBDI-SAE UML Profile for SOA V3 Now Available

Thanks to the hard work of my colleague John Butler, the latest version of our CBDI-SAE UML profile for SOA is now freely available for download.  This impliments V3 of our CBDI-SAE Meta Model for SOA.

This enables the full lifecycle of SOA to be modeled in UML, enabling SOA artifacts to be associated with both business models at the begining of the lifecycle, through to deployment at the end.

John has also authored a useful introduction to using the SAE profile and walks through the process of modeling a service specification architecture. This is also available for download.

Download now at http://everware-cbdi.com/umlprofile-v3

Cloud Computing. Are Utility and Cloud Computing really analogous to traditional utilities?

The analogy is often made between utility computing and other ‘traditional’ utilities such as electricity, gas, water, and telephone. The same analogy is now being made with cloud computing. At a high level this makes sense. In the same way there is no need for each individual or company to operate their own power plant, do they really need to operate their own computers? Why invest in the capital equipment to provide a computing capability if it can be piped into the premises and purchased ‘on demand’? The opportunities for economies of scale, the centralization of expertise, increased reliability and scalability all make perfect sense.

However, as Nicholas Carr also recognizes in his book “The Big Switch”, analogies often break down once you move to another level of detail as highlighted in the table below. Here we need to understand the difference between the utility (e.g. electricity) and the application of that utility (e.g. cooking).

Making Sense of Cloud Computing

The terms virtualization, utility computing and Cloud computing are often used interchangeably which can be very confusing. A new report I have just authored aims to provide clarification - to identify the similarities and differences in those characteristics, and provide a framework in which organizations can decide which capabilities they require in specific situations – as it is unlikely that one model alone will suit all their requirements.
A visitor from outer space would be forgiven for thinking that virtualization, utility computing and Cloud computing are different capabilities. But most of us understand that many product and service offerings use the terms rather casually and the trend is to assume they are all describing the same thing, where virtualization is synonymous with utility computing which is synonymous with Cloud. Some might say these are just steps in the evolutionary process – where utility has simply evolved into Cloud.
So, are they the same or different? Can the terms be used interchangeably, or are there clear distinctions between them?

The answer is not straightforward. There are clearly some common, overlapping characteristics that allow the terms to be used interchangeably. But at the same time there are other characteristics that enable them to be distinguished from each other.

The report aims to provide clarification. To identify the similarities and differences in those characteristics, and provide a framework in which organizations can decide which capabilities they require in specific situations – as it is unlikely that one model alone will suit all their requirements.

ESB - Everyone's Silver Bullet?

Given its prominence in any discussions around SOA for several years, you might think that by now everyone has acquired an Enterprise Service Bus (ESB).  However, it is clear that there is still ongoing discussion about the need for an ESB, and questions still remain as to what exactly an ESB is.  Cloud computing seems to have renewed interest in the topic. In the same way that people asked "do I need an ESB to do SOA?", we now have "do I need an ESB to do Cloud Computing?" (at least amongst those who recognize that Cloud Computing is largely service-based).

I sometimes think a better expansion of the abbreviation might be “Everyone’s Silver Bullet”, such is the perception that all you need to buy is an ESB and all your problems are solved.

SOA in Context

SOA does not exist in isolation. Whilst it may be the centre of the universe for SOA aficionados, SOA is just part of a "bigger picture". That isn't to say that SOA can be marginalized. Far from it, as SOA is an important part of, and enabler of that bigger picture as the image below illustrates.