Now that would be a good short-term business case for Cloud - or would it.
Triggered by Dennis Howlett's question regarding Cloud and the role of EA
@dhinchcliffe - but if I can move chunks of this 'stuff' to the cloud then why do I need an EA? Sounds like a silly qu but is it?and Dion Hinchcliffe's answer
It's a good question @dahowlett, the cloud disrupts all sorts of EA activity. Nevertheless, architects are still relevant, more as curators., I tried to give a concise answer but failed - a tweet definitely is too short for that
@dahowlett Dennis I'm going to take your good Cloud-EA question and blog post on it as a tweet (apparently) doesn't suffice CC @dhinchcliffeAlthough I can be concise: moving chunks of your stuff to the Cloud is much like a divorce: separation will solve some issues and problems, but create new ones as well. That's 140 characters right there exactly
Cloud's not going to make IT as a whole less complex. However, it probably will push down the lowest layer firmly into the ground so it becomes even more static, and might simply more or less become Utility, like the disks, cables, racks and U's already are
I think Cloud will greatly drive standardisation like I've said before. Us being all out here on Twitter and Facebook and all, shows that the different forms of English that can be spoken seamlessly merge into that one, unspoken, undocumented, Global form of English that everyone understands. British idiom, Aussie slang or Bostonian are simply not used widely because there's no ROI for that. We all want to understand eachother, so we mingle, merge, and become One. That's what Cloud will do to IT...
So, Cloud will diminish the amounts to choose from, thus limiting the choices to be made.
But that's very different from limiting the decisions to be made. In order for that to happen, IT as a whole would have to become more simple. Will it? No. Heck no:
There are various types of Cloud, as there are various types of enterprise architects
- Infrastructure Architects will have to make less choices about which particular SAN or database cluster to make or buy, but they'll now have to make decisions about how to align their legacy SAN or DB cluster with the Cloud's one. That's pretty much going to be an operation in space: only one extremely expensive chance to get it right
- Information System Architects will have to decide about this entirely different architecture that's come to them, and integrate that into their legacy IT-landscape applications. Client-server was a fun one, where the fat-client graphically rich legacy had to be pushed back towards the server again whilst still performing, but this will certainly pose challenges: it's a given that the mountain's not going to come to Moses this time. 'Fixing' performance issues by hauling in iron might just not work anymore. It's back to size zero on the drawing board
- Business Architects will have a tough issue as well: there are now two markets to monitor what the competition is doing. Business Architects especially will have a very hard time delivering the much-promised business services that seem to automagically sprout out of the Cloud, if I may believe the average vendor *cough*
- Security Architects will have the time of their life - they'll finally be taken seriously. And there will be a tyranny of some kind for a short while, I think. These unsung heroes will have to come out and play, and it will be a while before we all get used to their role in the play. Most of the time they'll just be very, very right...
- Governance Architects will, of course, encounter the biggest issues. Database tweaking, log-purgeing, it can't be done by looking someone in the eye anymore. Rock-solid, well-documented, repeatable, rehearsable, foolproof maintenance documents, operation and installation guidelines will be indispensible. Loadbalancing? Clustering? Failover? Monitoring? Logging? I'm predicting that the term "planned disruption" will get a widely known, popular meaning in this increasingly complex chain of interdependencies
As it works with groups and individuals, having a mutual enemy (or just focuspoint) could make our old-fashioned (IT-)organisation more intimate.
One thing I know for sure though: flirting with the Cloud will cause a formal divorce, without much, if any, room for bartering. Intimacy will be lost to a great extent, and we'll need coolblooded architects in order to arbitrate ahead of any potential conflict
There will still be EA's in their role, but their function(s) will change dramatically
6 reacties:
Martin I enjoyed your post. Here are few more builds:
1)) Infrastructure: Apart from technical strategy mentioned in your post, infrastructure architect will have to act more as an intelligent buyer of the service (ie moving up the stack from physical to to a logical architecture). He/she will need to understand and address not only technical aspects related to non-functional requirements but also characteristics of the service wrapper provided by different cloud vendors.
2) IS: Most of the current cloud solutions are effectively 'best of breed'. From that perspective, cloud is not reducing the complexity but increasing it! That means that integration will need to be not only legacy to cloud, but also cloud-to-cloud.
3) Governance will experience a major change, bigger than the above. Operations does not only involve technical support processes mentioned in your point, but also service management/support model (You can think of it as business architecture for the support. In practice, this aspect of the architecture stitches up various processes including SLAs, service desk, incident & problem, change management into a single service. In outsourcing, which is currently the most complex model, you control these by having a full control of the whole system. Cloud architectures are going to be much more complex (best of breed, delivered by multiple vendors, one cloud service dependent on another) and unpicking the whole area of support-oriented non-functional requirements will be much much harder.
Whereas the areas above are only tweaks on status quo, far biggest challenge may come from the change in the mindset in of the business customers and in how they deal with IT. If business can go and buy cloud solutions on their corporate credit card and get it provisioned in two weeks time, rather than waiting for months/years for their IT department, or engaging in a lengthy procurement process with an external SI, why would they want any architects at all?
Me and you know that this can lead to a big trouble later on, but that may not necessarily change customer minds, because they would see it as IT adding layers of unneeded complexity.
Just for the record, this is my right web address
Thank you Jiri!
I agree we'll have to move up from the physical, although I'm not too sure we ever really grasped that level as EA - we should stay in touch to it!
Cloud-to-cloud integration will be fun, although it will indeed make the SCEM and 3PL issues even less controllable. It'll pretty much be like climbing a mountain: you can't see the next peak until you've reached the current one in view...
I agree that the governance package is bigger than just the tech docs, but that level will have to be fully reached in order to Cloud Governance.
The only option we have in the Cloud, is to fully Industrialise: nuts-and-bolts the part of IT we want to Cloud
While complexity surelly will decrease in some areas when using Cloud solutions it will increase in others. The first comming to mind is integration where the maturity seems to be very polarised. Some Cloud vendors build on state of the art integration practises where others simply didn't learn anything since 1975. A year ago I was presenting Cloud Computing on a Swedish seminar and when asked for its services' integration capabilities the CEO of one of the major, global SaaS players answere "Oh, we have excellent capabilities when it comes to integration, it's very easy to export an CSV-file from our software".
What needs to happen in the EA space when it comes to integration is a massive maturity increase when it comes to sector specific information architecture standards. We'll need SID siblings, from overall conceptual architecture down to physical interchange formats, otherwise we'll still be fidling with both the broad ideas and the nitty gritty details when plugging in yet another service, things that in reality don't add business value, only adding time, cost and risk.
Joakim Lindbom
Thanks Joakim, intgeration will indeed be one of the most challenging areas. Your CSV-example makes me sad, that's not really a level of "standardisation" I am hoping for
The information is most important indeed, we need business interoperability so we can truly understand eachother, not just exchange files via the same protocol. The lack of standardisation and maturity around SOAP and WSDL on that level worries me, there's a LOT to be done. But we must focus on the business service information!
Hi Martijn
You'll know my opinions on this one :-) - to me the question is somewhat inane, because it assumes that EA is only about IT, which it isn't.
If your 'EA' is essentially about IT-architecture, then yes, shifting many of your IT-services onto cloud will all but force you to rip up the architecture and start again.
But if you've done your EA properly - starting from a whole-of-organisation view rather than solely the small subset represented by IT - then it should be clear you'll need _more_ EA, not less, in order to make Cloud work in the organisational context, because it'll be the only way you'll be able to identify and model the real impacts across the whole of the organisational space.
SOAP and WSDL and the rest are just minor details that we can leave the IT-architects to deal with. :-)
Post a Comment
Thank you for sharing your thoughts! Copy your comment before signing in...