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.

Service Provisioning Contracts - New SOA Training

SOA is fundamentally a contract-based approach. The concept of ‘loose coupling’ works because the dependency between implementations is replaced by a dependency on contracts. As long as the contract between provider and consumer is met, then the dependency on a specific implementation is removed. However, the devil is always as ever in the detail. What contracts are actually required? How are they documented? How should the level of precision required be conveyed?

To answer these questions, I recently completed work on building, and subsequently delivering, a new SOA training workshop based on our concepts of Service Provisioning Contracts.

This workshop considers the following three prime contracts used in the provisioning of a Service, and the relationships between the,

• Service Level Agreement: The quality of service contract between service provider and consumer for the operational delivery of the service at run-time.
• Service Specification: The implementation independent behavioral contract between the service provider and consumer, and also the service provider and service implementer, that specifies what a service does but not how it does it.
• Automation Unit Specification: The requirements contract between the service provider and service implementer for the Automation Unit that provides the implementation of one or more service specifications.

Several CBDI Journal Reports Now Freely Available for Download

As well as making the CBDI Journal free from September onwards, we have also published several reports from past journals available for free download. Registration is required (but at no costs)

See the CBDI Journal index

Hope you find these useful.

How Long is a Piece of String? The 'Dark Arts' of SOA Project Management

We are often asked "how long is a piece of string?" Well that's not entirely true, more likely the question would be something more SOA related such as "can you tell us how long it will take to define a service architecture?" However, without some greater precision of what is actually involved it is equally hard to answer either question.

Portfolio Management and SOA

In the current economic climate, most IT organizations are faced with extremely tight budgets. Yet at the same time, the business is likely to be exploring new opportunities for growth or improvements in efficiency that in turn often increase the demand on IT. Application Modernization for example is not just a simple case of switching old systems off to immediately save money, but more often requires investment in order to improve efficiency of those systems and in the business processes they support in the long term.

You sense that for a long time it has been easier for organizations to take the easy option of giving projects the budget and freedom to do what they want, without regard to the needs of other projects or even the organization as a whole, as long as the project promises success.

However, enterprises of all types, especially the public sector, cannot simply dispense money like this anymore, and now must face up to making difficult decisions to reject project proposals that take such a ‘laissez-faire’ approach, and instead focus on more efficient utilization of the organization’s resources and to “do more with less’ by reducing waste and duplication, whilst increasing sharing and reuse

Consequently, more attention needs to be paid to the portfolio as a whole, rather than the projects in isolation

Service Portfolio Planning

CBDI Forum has long advocated a Portfolio Management approach to SOA, with Service Portfolio Planning (SPP) being a cornerstone of CBDI-SAE. So in a new report, as well as considering the specific case of SPP, I set out to consider other portfolio types and how to extend conventional portfolio management activities.