8 years, 7 months ago

What is Enterprise Architecture (not again)?

Link: http://feedproxy.google.com/~r/Soapbox/~3/5PP_PZKkdCw/what-is-enterprise-architecture-not.html

Prelude

Let’s start with the tweets.

@RSessions: Enterprise Architecture is a tool, not a solution. 
@Cybersal: I agree EA is not a solution; however I prefer to characterise it as a discipline or a practice. A tool seems too mechanistic. 
@leodesousa: I agree it is a discipline/practice that should be embedded into existing processes like proj mgmt, chg mgmt, stratplan
@richardveryard: If we understand #entarch as a means-to-an-end, then the word “instrument” is better than the word “tool”. 
@ironick: How about EA is a process? That’s how #GartnerEA defines it. 
@RSessions: A process is reproducible. I know very few (only one, actually) EA methodologies that strive for reproducibility. 
@enectoux: EA is a complete discipline and mindset. It has many frameworkS, processeS, methodS, practiceS, toolS… 
@RSessions: Tool” is really a metaphor. The point is that effective use of EA requires training. Just buying “EA” doesn’t buy you anything.
@leodesousa: is not something you buy rather something that is invested in as an ongoing practice

    I’m sorry if I missed anyone, but this kind of debate could go on for ever …


    Fugue

    So here’s my take. There are (at least) five perspectives of what enterprise architecture is.

    1. EA as instrument. It’s something that is used as a means-to-an-end. (Like a tool, but more general and perhaps less mechanistic than a tool.) It is wielded with such-and-such intentions to produce or maintain such-and-such outcomes. If you don’t have these intentions, or you don’t believe EA can produce these outcomes, then you shouldn’t be doing EA at all.

    2. EA as discourse. It is a language (way of talking) that expresses (and focuses attention upon) a particular set of concerns and issues. This is what establishes a certain agenda for EA, and helps to differentiate EA from various other practices (such as programme management or requirements engineering or risk management) which might appear to address much of the same problem space.

    3. EA as community (of practice). There is a large number of individuals and organizations that identify themselves as part of this community, including several groups and organizations that claim to represent this community and its interests. In practice, EA can be regarded as the totality of what the EA community does in the name of EA.

    4. EA as body of knowledge. Among other things, EA bodies of knowledge include various prescribed processes, but it is important to distinguish between the espoused processes (what the book says you should do) and the processes-in-use (what the community actually practises).

    5. EA as trade or profession. Enterprise architecture provides a set of paid-for services to the enterprise, or to senior business managers, or to some other individual and collective stakeholders. (Payment can be in the form of salary or consultancy contract.) The commercial viability of EA and the careers of EA specialists depend on a sustainable demand for these services.

    There are significant issues for EA from each of these perspectives, which I talk about in my next post What’s Wrong with Enterprise Architecture?