Thursday, January 13, 2011

What is Enterprise Architecture (not again)?

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?

    4 comments:

    1. Foucault proposes four characteristics of a community of practice: it has its 'objects' - the things it deals with; its 'concepts' - its ways of reasoning about its objects; its 'ways-of-speaking' - how it recognizes who is authoritative; and its unifying 'themes' - the way it explains everything as part of unified whole.
      We should care about the characteristics of a community of practice because of the ways in which it is able to make problems tractable.
      But what are these problems? Are they to be expressed solely in terms of serving the interests of the sovereign enterprise? Can the practice of EA make claims for itself beyond the interests of its own community?
      What is its relationship to the 'beyond' of the enterprise?

      ReplyDelete
    2. I probably shouldn't have used the term "community of practice", and therefore I have adjusted this term, since the Foucault stuff is more associated with what I was calling discourse (=discourse of practice). I was using the term "community" to denote some kind of group identity - something that practitioners identify themselves as part of.

      The rhetorical purpose of my five interlinked perspectives will, I hope, become more apparent in my next post, because there is a different class of critique that applies to each.

      Your question about the interests of the "sovereign enterprise" is an important one. In a previous post on The Independence of EA, I raised an ethical concern about deriving "the best thing to do" simply from "the best interests of the enterprise". Why should we ever regard the interests of the enterprise as beyond question, and who shall speak for the interests of the enterprise?

      ReplyDelete
    3. I am reminded of the difference between two approaches to sustaining competitive advantage:
      1. Positional. Do as little as possible for the customer without jeopardizing the customer relationship.
      2. Relational. Do as much as possible for the customer without jeopardizing the sustainability of the business.
      Increasing competitive intensity around (1) pushes businesses to take up (2). But in (2) the sovereignty of the enterprise is limited by the need to meet the needs of the customer in a way that it is not in (1).
      EA practices in support of (2) present very different challenges to supporting (1), for example in creating appropriate forms of agility.
      Taking up (2) will affect the practices, affecting whose identities get supported. I shall be curious to read how the different classes of critique implicate a critique of what constitutes the 'enterprise' itself.

      ReplyDelete
    4. There are several reasons why sovereignty is an important and difficult question, and I may be jumping ahead of myself if I try to tackle this question at this stage. However, let me post a few prelimary thoughts.

      Any given model of the enterprise, for any purpose, makes some assumptions about what "belongs to" the enterprise. For example, employees have many various interactions with each other, as well as with non-employees. Some of these interactions are deemed to be of interest to the enterprise, and there are certain interactions that the enterprise may classify as inappropriate for various reasons. Meanwhile, there are some interactions that employees may regard as private, and they may regard surveillance by the enterprise (for example, monitoring emails and telephone conversations) as inappropriate.

      This is particularly relevant to the "customer relationship", since it is often unclear to what extent this relationship is with the enterprise as a whole or with individual people within the enterprise.

      Once upon a time, time and motion studies crossed an imaginary ethical line between the dignity of the workforce and the interests of the enterprise, using stopwatches to monitor and control labour productivity. Among other things, this can be regarded as a question of sovereignty. To the extent that enterprise architecture seeks to exercise some kind of architectural control, in the name of some EA discourse, it could trigger similar ethical concerns.

      ReplyDelete