The simplest way to explain the purpose of EA is to paraphrase John Zachman:
“We should try to understand the Enterprise first, before we go and build infrastructure to support it. Infrastructure is expensive, and takes time to implement or migrate to, but most importantly it is hard to change once in production. Therefore the best thing to do is understand what you are going to do with it before you take the time and sink the money into creating it.” [1]
Part of being a VCDX is having the ability to step back and design a solution that best supports what the customer (or tenant, or whatever) is trying to actually accomplish with this infrastructure from a business perspective. A CEO won’t spend half a million bucks on servers, storage, network, licensing, structured cabling, etc just because its cool. Down in the IT trenches, though, its easy to get caught up in the how and lose track of the why. Sometimes they refuse to tell us, but all too often we don’t even ask.
Enterprise Architecture as a verb means “using some kind of rational methodology to make sure the decisions we make on this project are the ones that best meet the needs of the actual consumers of this service”. There isn’t one perfect process out there that all enterprise architects use. The important thing is that you’re following some kind of system that prevents your own (unavoidable) biases, laziness, and preconceptions from delivering a design that achieves the wrong goals.
Formal EA process must be done for the same reasons that medical researchers have to do double-blind studies before declaring a drug safe/effective – its not that doctors are dumb or corrupt, its just you must have controls in place to prevent human fallibility from corrupting the end result.
From my own experience, most of the first environments I designed worked from the bottom up – I immediately leapt to we’ll use these blades, and this FC storage, and these cool ESX features, etc. Then contort what I had already designed to fit whatever workloads they threw at me in retrospect. I did this because I didn’t think I could dare ask to do things differently than my company had always done them. But that same company was looking to me as the “VMware expert” to tell them that their current approach wasn’t really going to meet the end goals the consumers wanted – and to do it in business terms that they could understand. Once I figured this out, I was able to make major changes happen in the datacenter simply by going through the exercise of a formal EA process.
Most EA approaches (Zachman, TOGAF, Fed, Gartner) tend to start with gaining an understanding of the business processes that need to be supported by the infrastructure. In practical terms this at minimum means understanding the applications that run on top of the VMs in a given design.
For instance, how you would design a vSphere based infrastructure to support a service provider’s public facing IAAS platform is going to be very different from how you would design a similar sized environment that runs General Motors’ ERP. A qualified architect can look at those two scenarios and immediately think of a dozen significant differences in how they would approach building a supporting infrastructure.
Given that it is rare to see vSphere infrastructures that only host one thing, its usually more complex than that. But this is the true challenge of EA – figuring out all of that top level stuff before you worry about blades or 10Gb or iSCSI or LBT or whatever.
BTW, the EA methodology that the VCDX is structured around is a modified version of the Zachman Framework. If you read up on Zachman, then read through “VCDX Boot Camp: Preparing for the VCDX Panel Defense“, you’ll see what I mean. I would also recommend at least familiarizing yourself with one other EA methodology (personally I like TOGAF). It will approach things a bit differently and give you more perspective on the purpose of things like Conceptual->Logical->Physical.
References
[1] http://www.zachman.com/resources/zblog/item/enterprise-physics-101
