Friday, October 08, 2010

Defining Enterprise Architecture

#entarch Another big discussion on Twitter yesterday about the correct definition (yawn) of Enterprise Architecture (EA). This one was whether EA should be defined as "Architecture of Enterprise" or "Architecture of Enterprise Technology". I mostly saw Tweets voting for the former, so it looked to me like a pretty one-sided discussion but maybe that's just because of the selection of people I follow on Twitter.

Clearly the difference between these two definitions is in the word "Technology". I wonder how many people who contributed to this discussion thought much about this word.

A narrow definition of "technology" from an IT perspective might limit the term to computer hardware and software; a broader definition might include everything from production technologies (e.g. Kanban) to accounting technologies (e.g. double-entry book-keeping), covering the strategic choices made in everything from transportation (oil tanker versus pipeline) to warfare (air bombardment versus ground forces). Followers of Lewis Mumford might define technology even more broadly (see for example his "Myth of the Machine") while followers of Bruno Latour would have a more subtle take on the whole subject. For my part, I have no wish to produce a single definition of technology; I merely wish to point out that the boundaries of "technology" may be as debatable as the boundaries of "enterprise architecture". The game of definition has no end.

But in any case, I wonder about the purpose and usefulness of this kind of definition. People often put an extraordinary amount of energy into definitions as if they thought that the simple act of defining something made it true. There are different forms of authority underpinning such definitions - for example the reputation of a well-known writer or organization, the emerging consensus of a group or community, or the negotiated standards of some industry body - and we may sometimes be able to achieve some kind of convergence as to what some term is supposed to mean.

But even if we could achieve a universal definition of what the term "enterprise architecture" is supposed to mean, that would be a pretty empty victory if the definition failed to reflect reality - either what enterprise architects actually do, or what they are capable of doing.

The reason I think this kind of definition can never satisfactorily reflect reality is that it is monothetic - in other words, it defines a concept in terms of specific features it must or mustn't have. Inspired by Wittgenstein, the anthropologist Rodney Needham introduced the concept of polythetic definition - defining a concept in terms of characteristic features it might have. Thus instead of debating endlessly whether enterprise architecture should be either A or B, and whether to adopt a narrow or broad definition of technology, we can start to make useful (and hopefully less dogmatic) statements about enterprise architecture and technology in the real world and the relationship between them.



Rodney Needham's paper Polythetic Classification - Convergence and Consequences. is now available on Scribd. In my book Information Modelling - Practical Guidance (Prentice-Hall 1992, pp 99-100) I outlined the relevance of this notion in business modelling.

10 comments:

Chris Detzel said...

In my opinion, it depends on the culture of the organization andthe history of EA within the organization. I think it's funny that the world is still trying to figure out what EA is and what the value of EA is. Although I think senior management see value in it, EA is always trying to show and deliver the value....

svtveld said...

The problem is not so much in the definition of the term EA, it is in what is done under the flag of EA. EA, if you would want to use such an architecture, ought to be about the enterprise. Available methods/techniques/tools limit the scope of EA to IT and its use.

So it is in fact not really the definition that is discussed, it is the different meaning all kind of people use for it. This way EA has become a very complex homonym, and this is very difficult because one never knows who uses what meaning. And for this reason most under EA has become nearly unusable.

With the concluding observation that current EA-methods, techniques and tools are developed and agressively marketed by IT-vendors and are mainly based on and directed towards the technology we call IT.

Steven

Stefan Dreverman said...

I agree with Chris: the definition of EA depends on the context in which it is being used. While there might be one broad definition, but when putting it into a specific context, the meaning and use of EA changes. If we can agree that this happens and we accept eachothers views on EA, we can put this discussion to rest.

svtveld said...

@Stefan

Suppose we agree with what you propose. Then we will have a lot of homonyms for the term #entarch. Available methods will choose a certain meaning, but they will be different. It is also difficult to communicate about EA because we know everybody can have a different definition. It is also difficult to get to education in this field, because education may, will differ from one definition to the other.

Does this really solve the problem? It leads to what we have already: confusion.

Steven

Carl said...

For most consumers (sufferers?) of EA they often see EA in terms of their perspective on the world - e.g. a CFO will see EA in a way that allows her to make sense of it from her perspective. Therefore, aside from the EA practitioners, a strict definition of EA is largely a waste.

However, the sum of the perspectives of the consumers of EA does not formally define EA - and may be that is the point. Perspectives are often built upon a different world view to that of the EA practitioner. Therefore a mutually agreed practitioners' definition of something as complex as EA leads to meaningless words encased in an impenetrable dialect.

So I find myself agreeing with Richard on this: a polythetic definition based on perceptions is better than a rigid definition based on self-interest.

Or is that too harsh?

svtveld said...

@Carl (and Richard)

Your points are well taken. The problem of each of us having our own EA is that we do not have a way to go about EA, or communicate with eachother about this subject. Also, education will become difficult because then EA is everything.

So we can do what you propose. The question remaining will be why we call anything EA, becasue EA is all. And therefore EA is of no use to anyone.

Steven

Richard Veryard said...

Thanks everyone for some great comments.

Just to clarify: a polythetic definition of EA doesn't mean that anything whatsoever would count as EA, merely that we are acknowledging a lack of precision around the edges. Confusion results not from polythetic definitions but from a plurality of incompatible monothetic definitions, which is what we now have.

It seems absurd to me to tell enterprise architects that what they are doing isn't real EA because it doesn't conform to some idealized notion of EA. You might as well try to tell David Beckham that football isn't a real game because it doesn't involve dice. That would be trying to impose a monothetic definition of the word "game", which Wittgenstein showed was impossible.

Normal people can cope perfectly well with polythetic definitions, so it would be strange if enterprise architects were the only people who couldn't.

Carl said...

I think what this discussion and several others is revealing is the fact that confusion rules!

As practitioners we cannot formally define what we practice and, even if we could, we would never agree. Therefore, what chance do the consumers of EA have?

By defining something by inference and also allowing different perspectives to deliver different inferences, we will at least get contextual definitions of this black art we practice. And from the folk most affected by it.

The only caveat I have to this approach is that of the over abundance of IT-centric architects who seem to think that EA is a natural emergence from that domain. I accept without reservation that there is a well-defined (sic) beast called Enterprise IT Architecture (EITA), but this is not EA. When EITA practitioners refer to a mythical beast called "Business Architecture" I get nervous as they appear to be missing the point.

But each to their own...

Doug said...

Hi Richard --

Thought I'd take advantage of your great post and this discussion to make another distinction I just realized. You have been talking about momothetic and polythetic definitions, at the same time that I have been tweeting about polysemy with respect to Enterprise architecture. Your "-thetic" terms have to do with a concept with variable features, and the "-semic" term I've been using refers to different (though related) concepts expressed by the same lexical unit.

The idea of polysemy is expressed in the form of different "senses" of the lexical unit (word or phrase) in question. This is recognized by the different definitions given in dictionaries - 1., 2.., etc. A lot of confusion can be avoided by *assuming* there is polysemy, and for parties to a conversation to clarify which sense they are are using at different points in time.

So, in the case of "enterprise architecture" I can be comfortable with talking about EA "in the sense of" an IT-driven initiative that uses a particular tool, and some business and technical concepts to make sense of a large complex IT environment of legacy and modern systems. Or I am happy to talk to you about enterprise architecture in the sense of the business models and structures put in place by the founder of the enterprise - as in your example of Ray Ozzie.

When I sat on the Business Architecture Working Group of The Open Group (BAWG of TOG) we called out three related senses of the term business architecture: 1. The intrinsic form of the business (each business) that may or may not be expressed in any type of model 2. the discipline that professional business architects use to make such architecture (present or anticipated) explicit and 3. the representations of such architectures in the form of models, repositories, reports, etc.

Seems like if we assume all concepts are likely to polysemous or polythetic or both, and we are careful about specifying the sense in use at any time, we can move forward with discussions without endless wrangling about the one correct definition.

Doug said...
This comment has been removed by the author.