Let me start by briefly explaining what Enterprise Architecture (EA) is, its purpose and benefits, why an organization needs EA and who should practice it. I use the noun 'practice', in a hope that it is apparent that EA is incremental and iterative. I will also be using more nouns alongside EA.

Though I admire Gartner's definition for its vocabulary, in my opinion, it gives the readers an impression that it is a very complex process (need not be) and is a herculean task (not really) to accomplish it.

As this article's intention is to keep things simple, I'd like to quote the simplest definition of EA I've come across till date, as given by Dustin Hudson (EA, Seaboard Foods) in a recent Kansas City Developer Conference. In his words, "EA is about Strategic technical direction". That sums it all.

EA is a field that essentially (and formally) started in 1987 with a journal from John A. Zachman. For a field that's almost three decades old, the adoption has only increased in the last decade, a period that coincides with the peak of Information Revolution.

Even with a handful of methodologies and frameworks, the understanding and expectations for EA are quite different. Each organization is unique and so EA has to be tailored. There is no one size fits all. There are pitfalls in all the existing approaches. Common pitfalls among the organizations that had adopted EA, before and after, aren't few. It makes one wonder, "Well 'wait' pitfalls 'after' adopting EA? Doesn't feel right?" Yes, that's indeed the case. The reasons as stated by Gartner are very obvious and make a lot of sense. It is a must to avoid these prior to starting on the EA journey.