“He who does not understand history…

By Stuart Boardman, Getronics

….is doomed to repeat it.” (Misquote from Burke – so sue me.)

What exactly is our industry’s problem with history? Why are we so good at dredging it up and so bad at learning from it? Every new development that comes along is treated by some people as a silver bullet that will magically solve all the problems we had before, whilst there are always others keen to assure us there’s nothing new and we were doing it all years ago, so what’s all the fuss about? Neither of these factions seems the least interested in the question of what we were doing wrong before or why, if we already knew how to do it, we so often didn’t get it right.

Right now the big hype and centre of discussion is Cloud but let’s take a look at some history – seen through the filter of my own experience.

My first exposure to a “paradigm shift” was Object Orientation. OO was going to supply us the means to prevent us from making all the errors we made in the past. (One could go back to Structured Programming for the same lessons but that’s before my time). With encapsulation, information hiding, polymorphism and all that great stuff, it would no longer be possible to produce highly coupled application modules with little cohesion. Uh huh. A couple of smart guys called Sharble and Cohen back in 1993 wrote a study called The Object Oriented Brewery (never mind why) in which they demonstrated exactly how easy it was to produce highly coupled, low cohesion code in an OO language. And why was it so easy? Because avoiding these errors requires understanding how they happen – not just technically but the kind of circumstances and thinking that produce them – and there are lots of different ways of getting it wrong! If this is news to you, you could do worse than check this Wikipedia page.

So then the next big thing was SOA. Here again we had the silver bullet merchants (mostly selling ESBs and the like) on the one hand and on the other the “this is just EAI on steroids” bunch, who could all tell you how they’d been doing this for 10 years already. Which of course begs the question: “so why is it such a mess?” It’s not as if we didn’t have good methodologies. I have seen EAI methodologies that really were pretty much SOA. But still it went wrong. We just took those N2-1 interfaces that EAI was supposed to eliminate and stuffed them inside a black box. So clearly the high priests of SOA needed to be asking themselves why this happened. At least they did, if they didn’t want it to happen again. And hey, look – most of them didn’t ask and we did indeed finish up with the same old mess (except now we call it JBOWS). The folks who should have known better (the old hacks) just let it happen. There’ll be a reason for that too.

So what about Cloud? It’s easy to argue that it’s nothing new. I’ve even seen someone argue it all started in 1960! We certainly used to have “time sharing” services, which offered a limited form of what we would now call PaaS over a dial-up connection. More than 20 years ago I was working on an IBM VM system, which one could reasonably describe as fully PaaS (including a usage based charging capability). I also recall an (unsuccessful) IBM initiative to deliver software over the internet direct to user PCs – somewhat along the lines of what app stores do now. And then of course we’ve had outsourcing and managed services in shared data centres, which has also rendered mixed results.

Don’t get me wrong, I don’t want to argue that Cloud is just old wine in new bottles. It represents an aggregation of a variety of capabilities, which at its best has a coherence one couldn’t claim was available in earlier manifestations. It’s to a considerable extent platform independent. (I didn’t say interoperable, OK?)

But there’s nothing inherent to Cloud that will stop us making the same old mistakes. Speaking for myself I have no expectation on Cloud providers to do it for us. I’m happy if they just don’t make it harder for us to do it right. It’s down to us (IT folks and Enterprise Architects) to learn from history, to use methodologies intelligently, find ways to minimize the risk and get business buy-in. The Cloud business model is a good stimulus for that buy-in. Separation of interface and implementation may sound like techno-babble but it’s exactly what both providers and consumers need, if they’re to get business value from the Cloud.

The Open Group has an important role to play here. Sitting at the junction of business and IT, we’re ideally placed to address these problems in a way that is meaningful to the business and technically effective. We cover most applicable areas with the work of the Jericho and Security Forums and of the SOA and Cloud Computing Work Groups. We have TOGAF® and we have our own collective experience. And we’re seeing more and more joint efforts across Forums and Work Groups. If we use all that to make an honest assessment of what went right and wrong in the past (and why), we will do something really useful for all parties in the Cloud.

Stuart Boardman is a Senior Business Consultant with Getronics Consulting where he co-leads the Enterprise Architecture practice as well as the Cloud Computing solutions group. He is co-lead of The Open Group Cloud Computing Work Group’s Security for the Cloud and SOA project and a founding member of both The Open Group Cloud Computing Work Group and The Open Group SOA Work Group. Stuart is the author of publications by the Information Security Platform (PvIB) in The Netherlands and of his previous employer, CGI. He is a frequent speaker at conferences on the topics of Cloud, SOA, and Identity.

1 Comment

Filed under Cloud, Enterprise Architecture

One response to ““He who does not understand history…

  1. As Outsourcing before it, what is very likely is that ill informed managers will make ill informed decisions which will waste mllions of pounds and (more importantly) vaste amounts of time and then blame IT for when the preveerbial hits the fan ;-)