There's been a lot of interesting banter - some expected, some not so much - around the Sample EA Capability Map that we posted last week. One of the more interesting insights centers around the appropriate use of Enterprise Architecture. Here's an interesting exchange between me and @JohnPolgreen on Twitter:

JohnPolgreen

RT @chrisdpotts Just reading phrase "business-driven EA" and its apparent tautology. Any "not-business-driven EA" (in a business) not EA.

JohnPolgreen

RT @RealLouwWe have to solve the problem of confusion Enterprise IT Architecture with EA bit.ly»

aleksb6

Re: @JohnPolgreen ... is that really a problem?

JohnPolgreen

Re: @aleksb6 There is a place for IT Arch, but, IMHO it must be predicated on knowledge of BA, and usually in direct response to bus imperative.

JohnPolgreen

Re: @aleksb6 ...example - large scale server consolidation - seems an IT arch exclusive problem. Needs at bare min anal of impact on bus

JohnPolgreen

Re: @aleksb6 ...EA PROJECTS may often go light on BA, the EA PRACTICE must focus on business value.

aleksb6

Re: @JohnPolgreen ... there is such a thing as business of IT. If predicated=aligned, I agree w you. If predicated=dependent, not so much

aleksb6

Re: @JohnPolgreen re: business value - agreed... convincing #CIO #COO #CEO of this is quite difficult

aleksb6

Re: @JohnPolgreen ... however, #EA is constrained by Biz Operating and Tech Operating models; in some cases only ETA is most appropriate

JohnPolgreen

Re: @aleksb6 but you agree that the overall practice should be EA, therefore bus focused, even if an ETA approach is used for specific projects?

JohnPolgreen

Re: @aleksb6 difficulty convincing Cxx of value of #EA is one reason #TOGAF recs going after low hanging fruit to gain trust - use ETA for this

aleksb6

Re: @JohnPolgreen ... my point is that in some operating models, only ETA is appropriate, not full #EA - it must be a conscious decision by biz

aleksb6

Re: @JohnPolgreen ... just as w other tools/investments, there is such a thing as appropriate use with #EA, whether #TOGAF gets that or not

aleksb6

Re: @JohnPolgreen re: #TOGAF recommendation: doesn't that approach further ossify #EA as #ETA in minds of biz stakeholders?

JohnPolgreen

Re: @aleksb6 ...but build up your #BA knowledge as you do the #ETA projects - "#EA by stealth". In the lng run ul hv EA & show its value to Cxx

aleksb6

Re: @JohnPolgreen ... malheuresement, in that long of a horizon, #EA is usually susceptible to Shutdown/Restart #eapitfall

About half-way through the exchange, I realized that there is nothing in #TOGAF or #Zachman (or other frameworks) around the concept of appropriate use for EA itself. They throw the entire classification framework and in TOGAF's case ADM as the way to do Enterprise Architecture ("Framework is THE answer #eapitfall"). Hence, it becomes fodder for practitioners to argue about what "real" EA is, relegating perfectly legitimate subset approaches to pariah status.

In response, following our standard SenseAgility Bulls-Eye model, Enterprise Architecture as a function (or as Capability Portfolio in our view) is constrained by the Goals, and further b y Operating Models of each perspective. So if a subset of EA is appropriate for a particular Operating Model, then there is nothing wrong with only doing that part of EA! For instance, if an organization is based on Diversified Business Operating Model, the only impetus for EA to offer Business Architecture-based services as part of Business Reference Architecture Capability is if that organization wants to change it's Business Operating Model. If not, that information is not consummable by anyone outside of EA, so why would you invest into that capability?

In summary, EA is like quicksilver running where the lowest common denominator allows it to run. It will look different for every business and even within each business as it matures. This is where frameworks can lead practitioners astray. They have an end-state that is uncooperative with the demand.