Up in the clouds

More cross-posts from the LinkedIn enterprise-architecture lists, this time about cloud-computing and enterprise architecture.

(This one’s long, so I’ll put a ‘More’ link in here.)

The start-point was a post by Carval Swaby at Chrysler, evidently “fascinated by the prospects of Could Computing”, but with a lot more sense than many cloud-‘evangelists’:

While cloud computing is no silver bullet, if strategically leveraged, this new computing model could significantly disrupt the Enterprise Architecture (EA) ecosystem. In addition, if companies begin to orient their businesses around a cloud computing paradigm, this may lead to major shift in the various aspects of traditional IT solution delivery and operational activities.
…But how can large businesses make the transformational shift to operate in the cloud, especially after spending many years executing tried-and-true practices of the past? What segments of EA will be most affected as a result of running the enterprise in the cloud? Will this force the enterprise architect to realign the EA around a more business-oriented paradigm?

As you’ve probably discovered, my own feelings are that most current approaches to cloud focus only on the technology or the opportunities, and flatly avoid looking at the end-to-end business risk. So it’s good to see that Carval here does at least recognise the importance of a more business-centred approach to EA. My first response picked up from a comment of his in relation to a post by Tom Nolle of ExperiaSphere:


Carval – “a business can exist and function without computer technology” – in some business-continuity / disaster-recovery contexts a business will cease to exist unless it can function without computer technology.

The biggest problem with cloud is not the technology but the business-risk. The technology will sort itself out over the next few years; however, much if not most of the business-risk will remain – yet most of the cloud-evangelists still seem to be ‘solving’ those problems by loudly pretending they don’t exist, which is not helpful…

Business-risk barely appears in many people’s ‘EA’ because that haven’t yet moved out beyond the technology. Cloud is just another technology, in an endless stream of ‘new’ technologies: we should be doing trade-off analysis with it in exactly the same way as we do with any other technology. If – as I think Tom Nolle is suggesting – you start your EA from themes such as the business-need / business-opportunity / business-risk factors, and use a service-oriented approach at that level as ‘business services’, then cloud et al become just another available option at what should be an almost implementation-agnostic integration layer.

Right now that implementation-agnostic approach requires a seriously sophisticated EA, with the full backing of the enterprise behind it; but quite a few large orgs are getting close to that level by now. The existing cloud apps and infrastructure fit well with the SME / startup mindset because the enterprise is small: the complexity is much lower, and there’s usually a much more cavalier attitude to risk – why is why they’re startups, of course. It also works well with ‘startup’-like experiments in a large org, for exactly the same reasons. But don’t even think of trying that with business-critical processes and data in a large global org: the complexities and risk-issues are bad enough as it is without throwing near-religious obsessions about cloud into the mix.

Cloud is just a technology – nothing more than that. It’s just another trade-off in the age-old balancing-act between centralisation and decentralisation, but beyond that there’s very little that’s new beyond some seriously-nasty risk-issues that few people seem to be willing to address. Don’t get hung up on the technology: concentrate your EA on the business-issues and risk-issues first, and only then look for technologies and processes that can support them.


Perhaps unsurprisingly, Carval said that he preferred to “differ a bit”: “IMHO the cloud computing model is more of an orchestration of capabilities offered by several existing technologies — like virtualization, grid computing, utility computing — with the goal of delivering business and IT capabilities via the ubiquitous Internet”, and then suggested that “The question therefore is whether this shift in the EA dynamics will effect a renewed approach to the EA strategy implementation.” So my next post was as follows:


Carval – agreed that cloud is an orchestration rather than a single technology, but that too is still just a technology – a ‘technology of technologies’, in the same sense that Defence talk about ‘systems of systems’. It’s the ‘enabling thing’, not the ‘thing’ itself – the ‘thing’ being the purpose of the business.

The most subtle risk, and perhaps greatest risk, in cloud is that the end-to-end link is not in anyone’s control. From the provider’s perspective, they may well be able to give very solid SLAs about uptime and scalability and audit and the rest; the end-user’s IT department can give solid guarantees about maintenance of the ‘last mile’ connections; but the whole point of the net is that no-one controls it – and therefore, in effect, no-one is responsible for it. We know exactly what happens at each end; but we have no idea what happens in the middle. Latency-times can vary from milliseconds to minutes or more – which means it’s all but unusable for most business-transactions, let alone real-time systems. No-one knows what route any packet will take; it could be intercepted anywhere, lost anywhere, substituted anywhere. And that’s before we start talking about any of the commercial risks…

If the EA has been done properly, starting from a whole-of-enterprise perspective,with solid mapping of ‘pervasives’ such as risk and quality and security and the like, cloud will barely make a dent: it’s just another technology with strategic-level impacts that need to be evaluated and assessed in the normal way. (Yes, cloud would require detailed review, and would/should impact in the technology / applications / process space, but it should not require any fundamental change to the EA as a whole.)

If the EA has been done in the usual technology-centric TOGAF/FEAF way, yes, you’re probably going to have to rip it up and start again. But that’s only because the EA was done the wrong way round in the first place. If you had done it right, there would have been minimal difference: that’s why I keep hammering on about the dangers of ‘enterprise IT-architecture’ masquerading as ‘enterprise architecture’.

One useful thing about cloud is that it might at last force IT-fanatics to think about risk. Exactly as with security and service-orientation, you cannot make a usable EA for cloud that is based on technology alone: to make it work, you must start from the enterprise – not the IT – and build outward from there.

Would be good if the cloud-evangelists finally got that point, and started seriously thinking about more than just the IT. I won’t hold my breath waiting for that to happen, though. <wrygrin>


One more post from me in that thread was in response to a comment from Tom Nolle, who possibly thought that I was ignoring technology entirely: “I also think that EA can’t and shouldn’t escape some technology focus”.


I agree entirely: any EA has to be of practical use, which “a totally abstract approach” isn’t – it’s literally ungrounded. An EA has to cover everything, at the appropriate level of detail – though most good EA aims to provide the overview that allows the domain-architects to dive down into the implementation-detail but still link everything together in an integrated way.

(My concerns about the term ‘human resources’ and its huge dangers for EA are off-topic for here: we’ll come back to them some other day! 🙂 )

My objection to the current over-hyping of cloud, from an EA perspective, is that it starts from the technology, and then goes looking for uses for that technology, in order to justify the technology. Otherwise known as ‘cart before the horse’… But if we start from an IT-centric approach to EA, we won’t even be able to see that it’s cart-before-the-horse, because the EA is centred on the IT rather than on the business of the enterprise.

Cloud is in no way unique in this: we’ve seen it before with BPR, and we’re also seeing it right now with the struggles to make service-orientation work. The only way to make the EA work is to start from the business – actually one layer above, at the level of the ‘shared enterprise’ in which the business operates – and expand outward from there in a holographic, everywhere-and-nowhere-as-centre approach. If we settle on any one place as ‘the centre’ – including, for that matter, business as ‘the centre of everything’ – our EA is toast: it has to cover everything, all of the time, at the appropriate level of detail for the task in hand.

In that sense, cloud is just one more detail amongst many, many, many others. Yes, it’s interesting and relevant – but so should be everything else, surely? Yes, it has EA impacts – but doesn’t everything else? And yes, it’s ‘hype-du-jour’, but so what? – something else will be along in a year or two’s time. In a real EA, we’re in for the long haul, not the hype-cycle: if you keep a sense of perspective, a sense of realism, you will have some chance of getting it right. Otherwise? – well, that’s what the hype-cycle is for, isn’t it? <wrygrin>

Leave a Reply

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