“Big EA” and “Little ea”
Much has been published in the last five or so years about Enterprise Architecture. While Zachman and Spewek have been attempting to promote the idea for much longer, the recent frenzy around EA has been a great thing for maturing the profession and the promoting and expanding discipline of IT architecture beyond its technical realms. Many proponents have even carried this idea of “architecting the enterprise” into non-IT parts of the organization, claiming that EA is much more about strategic planning than specifically an IT process. I would agree with that. I also agree whole heartedly that EA is just as important, if not more so, to the organization’s strategic planners as to the IT program or project planners. Therefore to distinguish EA from other senses of the moniker and to partner with Zachman’s use of all capitalized letters for ENTERPRISE ARCHITECTURE, I have begun referring to this super-architecture; i.e. the process of architecting the enterprise as an independent system needing a planning process of its own; as Big EA. It’s in this sense that analysts at Gartner and Forrester to authors Bernard and Ross to Zachman to the writers of TOGAF, FEA, FSAM, etc. are referring to Enterprise Architecture. They are referring to Big EA.
There is, however, a less specific meaning to the distinction Enterprise Architecture. In organizations where there is little to no formal IT architecture process at all; where there is no formal architect, design, build progression; before Big EA can take place, there must be enterprise architecture or little ea. Little ea is the enterprise process for doing architecture, such that all people engaged in building are required to participate in a repeatable architecture process. Big EA can certainly happen before little ea, but without little ea, Big EA is forced to be focused on its own architecture alone and will have a difficult time consulting or reviewing or recommending or collaborating with other non-EA driven projects, whose specifications are non-existent. Organizationally, I am finding too, that outside the context of IT, there is generally little understanding of something as seemingly non-technical as architecture. That is until business folks sees it happening within the context of projects they directly requested. What I mean is that if we ever hope for Big EA to be a part of how the organization drives strategy, then it will need to be seen as a viable and relevant business activity on operational projects. Without little ea, the business does not experience architecture until it comes from the highest parts of the organization down. That is, of course, assuming that it would even be promoted downward by executives that probably don’t understand architecture’s presence in IT or business.
Unless you have support at the highest levels of the organization for an EA capability, in the Big EA sense, and if there isn’t architecture being employed in your IT ranks to systematize planning and execution, then my take is to start there. It will allow the organization to mature in concert with the collective frames of reference we all use to assess value and leverage tools. If EA is to be useful, then it must be practical and relevant.
