EA's are often the champion of large change initiatives that span multiple business units. If they're not on board - we've got problems.
Here's why I ask the question:
1. It's my perception (perhaps incorrect) that the EA leadership typically doesn't come from a background in infrastructure architecture. It's been my observation that the EA's who tend to get promoted usually have a background in business or application architecture. These people are often hesitant to enter deep discussions on CPU power consumption, DNS propagation, VLAN decisions, storage protocols, hypervisor trade-offs, etc.
2. Most people have agreed that the cloud can be viewed as a series of layers. You can attack it from top (SaaS) or bottom (IaaS). Quite frankly, there isn't *that much* architecture in SaaS (other than the secure connection and integration). That leaves IaaS as the starting point - which takes me back to point #1 - IaaS intimidates the EA team - - meaning that they're relying on the I.T. data center operations team (and localized infrastructure architects) to define the foundational IaaS layers which will serve PaaS, Dev/Test, disaster recovery, hadoop clusters, etc.
Any truth here? Leave a comment (moderated) or send me an email either way: jschneider AT MomentumSI DOT com
1 comment:
I am not sure that intimidated would be the best descriptive word. I think Enterprise Architects are cautious when it comes to the cloud for a lot of reasons. While I agree with your first premise that most EA leadership has a strong understanding of business domain knowledge and application architecture, most also have at least a fundamental understanding of hardware architectures as well. In every EA career, we have been presented with a scalability question, DR scenarios, virtualization questions, etc. If you do not have at least a fundamental grasp of hardware architecture, then you open yourself up to a lot of nasty surprises.
I think the reason that EA leadership is cautious when it comes to the cloud is that they have to look at a lot of aspects including many that you mention in your original post. However, there are also a lot of non-technical aspects that have to be taken into account. If the site goes down for any reason, what is the legal implications to all parties. How much control does the company retain over emergency hardware updates like OS service patches. What are the limitations of supported software and releases. Most Cloud sites are virtualized servers which also have implications on architecture and production service level agreements. If someone hacks into the database and downloads personal information or corrupts data, what are the legal implications there. If it is an internal cloud owned an operated by the company itself, what are the cost justifications. Unfortunately, I do not think EA Leadership is intimidated by the cloud technologically, I think it is the business and legal ramifications of cloud computing that they are still trying to work out in a lot of cases.
Post a Comment