The Cloud is in the cloud

This one’s another follow-up from the model-development session with Stuart Boardman last Friday, and relates to a different way to understand the often over-hyped Cloud.

[I hasten to add that most of what follows is just a minor elaboration on an original idea of Stuart’s, which formed part of his presentation to the Cloud track in the Open Group conference in Cannes back in April this year. The real credit for the ‘cloud within the cloud’ concept is Stuart’s.]

It’s probably unlikely now that any business-folk or IT-folk – let alone any enterprise-architects – have failed to hear all the hype and buzzwords around the concept of ‘the Cloud’ – as in the many assorted variants of what’s commonly described as ‘cloud-computing’.

There’s so much hype about Cloud that it’s often quite hard to see that in many ways it’s nothing new. As Gartner’s Andrea di Malo complained the other day, ‘Why do people keep treating Cloud as something special?‘ – because in reality it’s little more than a long-established design-pattern, going right back to 1950s leased-line ‘electronic data-processing’ and the like. Sure, it’s a different kind of scalability, and offers a much broader range of access-methods, but otherwise that’s about it.

The real giveaway clue, though is in the terms that are used for the various different modes or forms: information-as-a-service, software-as-a-service, platform-as-a-service, and so on. They’re all services.

And the crucial point is that in a service-oriented view of the enterprise – such as I use in modelling with Enterprise Canvaseverything is or represents a service. In that sense, Cloud is, well, just another kind of service, really. It has its own specific quirks, just like every other type of service – but in essence it’s just another service.

Gosh.

So why all the hype?

No reason at all really – other than that it makes a good sales-pitch that sells stuff, I guess?

Humph.

But if we drop the jaded cynicism of the long-experienced industry-watcher, what we see is this:

  • if everything is a service, then our organisation is part of, and exists within, an almost infinite cloud of services, of many, many different kinds
  • as an organisation, we can choose to keep some of the services we use within our boundary-of-control – the effective boundary of our organisation – or we can outsource some to ‘external’ services beyond that boundary-of-control
  • the services classically described as ‘the IT-department’ are usually inside the organisation’s boundary-of-control
  • the services that make up the so-called ‘Cloud’ are just another part of that service-cloud, but usually outside of or beyond the organisation’s boundary-of-control

In other words, Cloud is just one more cluster of services within the overall cloud, conceptually little different from other services that the organisation might access through outsourcing-relationships – such as electricity, cleaning-services, legal-services and catering-services. They’re all just different kinds of services – preferably interoperable, and preferably interchangeable if need be, too.

[Kind of ironic that the small subset of the services-cloud that is the IT-based Cloud is the part that gets aggrandised with the capital ‘C’, whereas the real overall services-cloud doesn’t – but that’s the IT-industry’s infamously-myopic self-importance we’re dealing with here, after all…]

In that sense, the much-vaunted Cloud is just another cloud within the cloud – the real cloud of shared or shareable services, or, as Stuart puts it, the overall business ecosystem of which our own organisation is itself just one small part. Or, to put it in more visual form:

But there’s one more point we can see from that bullet-list above, which is really important from an enterprise-architecture perspective. And that’s that, like any other outsourcing arrangement, Cloud usually sits outside of the organisation’s boundary-of-control. Which is not the case with the classic internal ‘IT department’: that’s definitely inside the organisation’s boundary-of-control.

Which means that the moment we port anything onto the Cloud, it literally moves beyond our control. Sure, we can give ourselves the illusion of control, through contracts and the like: but we may soon find that those contracts aren’t worth the paper they’re (not) written on – especially when we hit up against the nightmare tangles of national jurisdictions and the rest…

As with any other outsourcing-arrangement for provision of services, the nearest we’ll get to ‘control’ with Cloud is some reasonable form of influence with the service-provider, in which trust – so often noticeable only by its absence – becomes the only thing that’ll hold it all together. Tricky, that…

Which means, in turn, that before we go anywhere near Cloud, we need to have some very clear ideas about governance – about who really holds accountability and responsibility, both within the organisation and beyond, and how all those responsibilities will be maintained within the messy realities of real-world practice.

And the only way that’s going to work is if there’s a really solid enterprise-architecture in place, complete with a really solid information-architecture that explains which items of information can be safely outsourced, and which items can’t, for all manner of strategic and other concerns.

In short, the Cloud within the cloud is no perfect panacea: it’s just another class of services, with everything that that implies. Everything – including governance, architecture and the rest. We forget that fact at our peril…

3 Comments on “The Cloud is in the cloud

  1. The service view is really useful in this hyped context. Some enterprises have been very slow to understand the concept and I suspect have still some way to go in reaching the class of service offered by EC2-style self-service computing power. You are absolutely right Tom: it’s just another class of service. But I would not underplay the ability to fire-up a server to implement a service in a matter of minutes including billing. Surely this requires addressing a plethora of underlying services including security, payment, infrastructure, persistence, etc. but in my experience corporate IT services get stuck at that level and fail to deliver any service at all. For example obfuscating the payment of the instance behind forms amounts to masquerading ASP-grade services behind the word Cloud.
    This view of service is really important and useful here. In particular to those IT reps who miss the business value of providing computing capabilities to an autonomous business unit. This value and its underlying requirements hidden to the business departments definitely requires governance and architecture.

    • @Jean-Paul: “I would not underplay the ability to fire-up a server to implement a service in a matter of minutes including billing” – yes, agreed, though in a way that ease of use is itself a very real part of the danger. 🙂

      One of the points I’ve been trying to make is that when we use ‘external’ services – especially outsourced-services like cloud that are, in effect, within the organisation’s boundary of identity – we need to crosslink them fully not just at the transactional level (which can be very easy indeed, exactly as you say), but also all the way up to the level of vision and values (which is a lot harder). Getting the balance right here can be absolutely business-critical, especially in the longer term – and it’s one area where a proper whole-of-context enterprise-architecture will prove absolutely essential.

      More on that in other posts to come, I think.

      [Apologies for the late reply, by the way: I’ve had to do a full migration of several of my websites, and it’s taken a lot longer than I’d hoped or intended…]

  2. Perfect! Only last week at a vendor cloud fest did I use the word we stuck our cloud into a cloud, it was then i realized then hyperbole of it all, and the fact that cloud doesn’t exist. From a customer/service consumer POV drop the word cloud and just call it service ….

Leave a Reply

Your email address will not be published. Required fields are marked *

*