Enterprise-architecture and the Cloud

Okay, let’s go back to something that’s perhaps a bit less controversial than the past few posts…

This one starts with a ‘rant’ (as he put it) by Anders Jensen, about the ongoing hype over (gosh!) ‘the Cloud’:

  • aojensen: As phk of FreeBSD says: #cloud is no different to the IBM mainframe. // It puzzles me why so many people put #entarch and #cloud in the same tweet. The former is a mgmt function, the latter a tech concern. // In other words, #cloud is a solution pattern and delivery mechanism. #entarch is about systemic management of all of the enterprise. // Thus, #cloud architect is nothing but a fancy word for solution architect. // Okay, rant over. #entarch
For the most part I would agree with Anders’ rant – I’ve said the same myself often enough. Yet there is a point about which we would definitely want to link enterprise-architecture (‘#entarch’) and cloud-computing (‘#cloud’) together, and that’s around strategy:
  • tetradian: @aojensen: “puzzles me why .. people put #entarch and #cloud in same tweet” – is valid if about enterprise strategy or strategy-to-tactics
  • aojensen: @tetradian true, but then it is still a delivery mechanism realising a certain strategic/emergent intent.
Perhaps the real point that’s missed by way too many cloud-adherents is this:
  • tetradian: @aojensen for viable biz-strategy, #cloud needs #entarch much more than entarch needs cloud – cloud can be biz-lethal without proper entarch
  • dougnewdick: @tetradian @aojensen couldn’t agree with Tom more – whether you are talking EITA or “proper” EA 😉

And Doug Newdick is right here, too: this isn’t just a ‘real-EA’ issue. It applies just as much to an IT-oriented or even IT-centric ‘enterprise’-architecture, because it’s about the organisation’s strategy for managing its business-critical information.

I’ve seen some people – okay, probably only the most hype-ridden and IT-obsessed, admittedly – who’ve argued that the availability of cloud-storage and cloud-based applications means there’s now no need for any enterprise-architecture. Let’s just be blunt about this: that’s dumb. Stupid – seriously stupid. Demonstrates an almost complete inability to grasp the role of enterprise-architecture – and probably of the role of cloud, for that matter. Various other irritated epithets… definitely worthy of Anders’ ‘rant’… mumble mumble grumble grrr…

Okay, back off for a moment. Cool down, Thomas. Etcetera…

For the moment, let’s just assume a ‘classic’ TOGAF-style ‘enterprise’-architecture, focussed solely on IT. (It’s perfectly adequate for this purpose, so for once I’m not going to complain about ‘IT-centrism’ etc here. 🙂 ) It has four distinct domains: IT-infrastructure, Applications, Data, and ‘Business’, which in essence is a ‘none-of-the-above’ relative to the other three IT-specific domains. Let’s assume, then, that we now believe the cloud hype, and hence that we can do everything via the cloud:

  • IT-infrastructure: don’t need any, it’s all ‘bring your own IT’
  • Applications: don’t need any, it’s all in the cloud, accessed via browsers and apps
  • Data: don’t need to define any, it’s all defined in the cloud
  • ‘Business’ (process-workflows, business-models etc): we can build it all around what’s already available in the cloud

So: get rid of the IT-department, because there’s nothing for them to do any more. And get rid of all the enterprise-architects, because they’re just part of the IT-department that we don’t need any more. Simple, right? Huge savings in costs, too.

Hmm. Right. Let’s take just a few points that are missed in those glib assertions above:

  • Who’s going to test the apps on all that range of different hardware and software and screen-resolutions and everything else?
  • Who’s going to help people when their ‘bring your own IT’ doesn’t work?
  • Who’s going to help people understand how to access those cloud-apps, to understand the security-issues, and why leaving their iPhone in a cab could be a lot more serious than just the loss of a few of today’s Tweets?
  • Who’s going to choose which apps to use? Why will they choose those apps, from which providers?
  • Who’s going to design the workflows that bridge between all the different apps? Who will be responsible for the end-to-end business processes that jump around between different apps and different cloud-providers?
  • Who’s going to identify the business-metrics that bridge across those end-to-end business-processes? How will you gather those metrics, and ensure that they make business sense?
  • Who’s going to manage the reverse-backup, where you back up your own cloud-data in local storage? Who is going to be responsible for information-security, for end-to-end business-continuity and disaster-recovery, for escrow and recovery when (not ‘if’) one of your cloud-providers goes out of business, or when (not ‘if’) one of your providers starts getting too greedy, or for deciding what to do when your cloud-provider is taken over by one of your own competitors?

That list goes on, and on, and on, and on: and you won’t be able to answer many, if any, of those questions, without a solid enterprise-architecture. You’ll probably discover that you do indeed need that IT-department, too – a lot more than you’d realised. Oops… perhaps throwing everything into the cloud isn’t such a good idea after all…

(There’s not much difference between this IT-oriented analysis and one coming from a ‘real-EA’ perspective. The latter would cover a rather wider scope that’d throw up yet more crucial issues that cloud-providers, uh, somehow seem to forget to mention, but that’s about all, really.)

The key point is this: cloud is just another outsourcing arrangement. Anders is right: in many ways it’s just a reversion to the IBM ‘data-processing’ bureaus of half a century ago – brought up to date a bit, of course, and with a few more fancy bells-and-whistles such as ‘access by anyone from just about anywhere’, but otherwise the core principles are almost exactly the same.

So if it’s ‘just another outsourcing arrangement’, we need to handle it architecturally much as for any other outsourcing arrangement. In other words:

  • Never outsource your business-vision.
  • Never outsource your strategy.
  • Never outsource your business-critical information – and especially, never outsource the ownership or control of your business-critical information.
  • Know what you’re getting into, and why.
  • Know what it will cost, in every sense – including all of the myriad hidden costs that no-one seems to notice until too late.
  • Know what rules and regulations apply, under which jurisdictions.
  • Know how to ensure alignment between your organisation’s business vision and values, and those of the outsourcing provider.
  • Know how to ensure customer ‘single-view’, end-to-end continuity and suchlike whole-enterprise requirements.
  • Know who’s responsible for what, when, where, how and why – and how to plug the inevitable gaps between boundaries of responsibility across the overall partly-outsourced business-structure.
  • Know what can go wrong, and what impact each type of ‘going wrong’ could have.
  • Know what to do when (not ‘if’) things go wrong.
  • Know how to get out of what you’re getting into.

(That’s another list that goes on and on, too… and again, that’s why enterprise-architecture exists, to help you resolve each item on that list.)

What’s scary is the number of business-folks and IT-folks who’ve never even looked at that list, for any kind of outsourcing arrangement: they seem to buy into all of the sales-hype of the latest ‘fad-du-jour‘ instead, and apparently just hope for the best… Perhaps not the wisest strategy, shall we say?

There’s no question that cloud is great for a typical start-up – because there you do usually have to outsource everything you can, to keep the initial costs right down. Yet in a more mature business, things get radically different. Sure, you can scale cloud-apps themselves, and data-storage in the cloud, and so on. But not the way in which information itself is used across a 5,000-person company: that’s a different ball-game entirely.

What we find in practice is that, yes, some parts of the business do still need to be as nimble as any start-up – and hence, at first glance, would be seem to be ideal candidates for cloud-apps and the like. But some parts of the business need to be very stable, in some cases for decades or more – as in health, for example, or retail-banking, or some aspects of pharmaceuticals, or some types of engineering. After half a century and more of IT practice in organisations large and small, we do know how to manage that kind of data, those kinds of processes – and one of the things that that tells is that those kinds of requirements are not a good fit for cloud. And it’s different for every industry, every organisation, every size of organisation – whereas the best that most cloud-providers seem to offer is a kind of vaguely-customisable one-app-fits-all which in some ways combines all of the disadvantages of the different options with almost none of the advantages, other than some surface-layer cost-savings that may well evaporate and worse once Reality Department barges its way into the real picture. Hmm… Tricky, that…

To make it even more difficult, most large organisations have organisation-specific taxonomies and schemas that do need to be enforced across all usages throughout the business – which may well not be supported in the kind of prepackaged schemas offered by many providers. As a result, we’d have to do some potentially-tangled to-and-fro translations between the internal schemas, and the providers’ schemas – all of which is doable, of course, but increases the cost and the risk-potential, and reduces the actual savings from the outsourcing arrangement.

To make sense of all of this, we need a solid understanding of backbone versus edge – of what must be maintained strictly according to standard, or what must be managed internally for strategic reasons, versus what can be much more freeform; and the transitions and translations and governance-issues between them; and how all of the respective choices are guided in turn by enterprise-strategy. Which, again, is where a solid enterprise-architecture really needs to be part of this outsourcing picture.

Which brings us back to Anders’ point with which we started: cloud is ‘just another outsourcing-arrangement’. And as with any other outsourcing arrangement, the business needs a solid strategic understanding of all the implications of that outsourcing-arrangement – its potential advantages and disadvantages, its costs and revenue-possibilities, its opportunities and risks, its impacts on business-processes, and much, much more. And almost the only way to identify whether that outsourcing arrangement does or does not make strategic sense is via a well-described enterprise-scope architecture-description, fully linked to enterprise strategy.

Outsourcing everything – or anything, actually – to the cloud could be lethal to the business: yet without a proper enterprise-architecture, there’s no way to know what is a risk, and what is not. As Anders says, cloud is just a solution-pattern: there are usually plenty of other options that can be used instead. But enterprise-architecture is a management-function, a strategic function: not wise to try to run a business without it…

So cloud isn’t actually necessary to any business: but an enterprise-architecture certainly is. In that sense, cloud needs enterprise-architecture much more than enterprise-architecture needs cloud. Might be useful for everyone if some of the current clutter of cloud hype-merchants were a bit more willing to grasp that point?

5 Comments on “Enterprise-architecture and the Cloud

  1. “without a proper enterprise-architecture, there’s no way to know what is a risk, and what is not. ”

    I don’t think that anybody want to hear what all the risks are of doing something. Maybe that is the real problem of digital architects: too much focused on obstacles and risks, and always commenting from the balcony like Statler and Waldorf (in the Muppet show)…

    (this it not against you Tom, but more a general observation, I also act like Statler and Waldorf most of the time 🙁 )

  2. Tom. I think enterprise architects need to see Cloud as an opportunity. At least those of us who are not IT Centrists and who realize the business of an enterprise extends beyond its legal boundaries and that value networks are increasingly vital to any organization (i.e. pretty much the whole readership of Tom’s blog). Surely we are not predisposed to doing everything internally via the enterprise’s IT department? We don’t have to have any predefined attitude to Cloud vs in-house at all.
    Cloud may not be necessary for business (that’s arguable but open to discussion) but it’s often the business that adopts Cloud solutions – especially SaaS. (IT is in fact far more likely to emphasize risks and complications.) And you’re right Tom, they often don’t take proper account of the risks. The perception exists that Cloud can provide significant cost savings. And sometimes it does. Money talks. Another reason SaaS solutions are chosen is because the business is fed up waiting for IT to deliver new, reliable and predictable functionality. They’ve been fed up for a long time but now they have somewhere else to go. So standing in the road with a big red stop sign is unlikely to be a successful tactic.
    I strongly agree with you that the business will actually appreciate someone who can help them to make a sensible assessment of the risks, mitigations and benefits. And they probably won’t trust IT to do that. So there’s a big opportunity for us to jump in, preferably with the benefit of an existing architecture and failing that on the basis of a bit of guerrilla EA. That in turn will make them more open to letting us complete our work and become a continuing contributor to enterprise strategy.
    So that’s why Cloud presents us an opportunity. We don’t need to be for it or against it. We just need to do our work – preferably quickly.
    Later I’ll post some pointers to where some of your (perfectly valid) concerns have already been addressed in a useful and constructive way.

  3. @Peter Bakker – Thanks, Peter.

    “I don’t think that anybody want to hear what all the risks are of doing something” – nope. 🙂 Yet since the flipside of risk is opportunity, perhaps one way to identify un-obvious opportunities is to be a bit more systematic about exploring risk?

    “this is not against you Tom” – I’m well aware that it’s not: as I’ve said in a reply to Stuart in the comments-section of the ‘One more try…’ post, I’m really grateful that you make the effort to challenge me to do it better. Thank you! 🙂

  4. @Stuart Boardman – Stuart: “I think enterprise architects need to see Cloud as an opportunity” – I do. That’s the whole point. 🙂 At the very least, cloud represents an opportunity on the scale that new technologies of ‘data processing’ were for businesses half a century ago: that was a huge breakthrough then, and there’s no reason why should not be so for businesses now.

    The flipside of opportunity is risk; the flipside of risk is opportunity; they always occur as a pair. Everything has advantages, and disadvantages; and every context has a different trade-off for those risks and opportunities, and for those advantages and disadvantages.

    Note that this wasn’t (and isn’t) an ‘anti-cloud’ piece. It’s solely about the relationship between cloud – a particular type of mainly-IT ‘solution’, a particular type of outsourcing – and enterprise-architecture. Some of the cloud-evangelists have been saying that cloud itself means the end of IT-architecture within the organisation: I don’t think so, because – as above – I believe we need a solid IT-architecture to understand the IT-specific risks and opportunities represented by a cloud outsourcing. (That’s why I kept to a TOGAF-type view of enterprise-architecture above, because we don’t need to confuse the issue with arguments about IT-centrism etc here. It’s useful to extend the scope to that of a ‘real-EA’)

    The point I’m really making is in that last main paragraph: “cloud needs enterprise-architecture much more than enterprise-architecture needs cloud”. I do believe Anders’ comment was right: cloud offers a great deal, yet in the end it’s just another type of ‘solution’, just another form of outsourcing – and instead of just leaping at the hype, or rejecting it outright, we need to understand where best to use or not-use that type of ‘solution’. The whole point of the various enterprise-architecture disciplines – whether IT-specific or not – is to give us the means to develop that understanding. That’s why cloud does not somehow ‘supersede’ enterprise-architecture: it actually makes it even more necessary than before.

    On “the business will actually appreciate someone who can help them to make a sensible assessment of the risks, mitigations and benefits. And they probably won’t trust IT to do that” – yes, there’s a significant risk for us there, and also a huge opportunity. The risk is that if EA is still labelled as ‘part of IT’, we won’t be allowed to do this kind of support-work: or rather, we can do it, but as you say, we wouldn’t be trusted, so it would be rather pointless. But the opportunity here is that this gives us a very strong means to break out of the ‘IT-only’ box: the phrasing and framing of the typical ‘cloud hype’ enables us to describe in business-oriented terms, without ‘traditional’ IT-jargon, what are actually still just IT-type functions and capabilities. That’s hugely important – especially for EA.

    That’s also one reason why I’ve been pushing the ‘backbone and edge’ metaphor – because it’s actually a means to bridge between ‘classic IT’ (i.e. the backbone) and ‘shadow-IT’ (i.e. the edge), in a way that explains the kind of IT-context that fits best with each. That metaphor also provides a consistent governance-structure across the whole spectrum, and also explains why we need each type of governance.

    That’s what I’m hoping for, in the relationship between enterprise-architecture and cloud – and yes, it’s a huge opportunity that we really should reach for with both hands.

  5. Hi Tom,

    Thanks for taking your time to synthesizing our scattered Twitter comments into this nice blog post. There is an inherent need to separate all hype and buzz from what really matters: architecting our organisations for better outcomes. Not that there is anything wrong with that — Enterprise Architecture is, itself, in a stage of hype, and that is fine. That said, there is no doubt that cloud is a highly relevant opportunity in this process in order to make certain architectural elements (processes, contracts, services, sourcing, …) more flexible and smooth. In this view, cloud is an effective delivery mechanism for materialising certain architecture plans and blueprints.

    Keep up the good writing.


Leave a Reply

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