Several months ago I posted a framework for "thinking about EA". This posting was mainly inspired by my work for the Enterprise Architecture in Practice (EAP) course that I teach for the Hogeschool Utrecht, but also based on several scientific publications that I had read back then. Last week (i.e., several months later) I was discussing this approach with Tom Graves as well as the new group of students following the EAP course and found that this framework missed a key point: there should be 4, not 3 dimensions of enterprise architecture:
This framework is mostly theoretical in nature and can well be used to "talk about EA", e.g. in a teaching setting. In my view, it may also help explaining what EA is and does to prospective clients. Here's how it works.
One of the discussions popping up frequently (not only among architects, but also with other practitioners, researchers and even customers) is the question "What is EA?". Hans Bot already pointed out in response to a blogpost by Erik Proper that we should "stop talking about it and get work done". I couldn't agree more with the possible exception of a teaching setting of course. Hans refers to the IEEE 1471-2000 definition of architecture of software intensive systems which is, indeed, the mother of all definitions. Inpsired by the way xAF distinguishes between a theoretical and practical definition of EA, I observed that "what EA is" seems to depend on which of the other three dimensions is dominant:
- Studied in its own right: the IEEE definition indeed captures the essense of what (the) architecture (of a system) is.
- When taking the documentation / communication perspective, architecture can be seen as a collection of models, principles etcetera. The Open Group Archimate 1.0 standard is important in this respect.
- When taking the process / way of working perspective, architecture can be seen as a way of working to achieve organizational goals. The TOGAF ADM is relevant in this respect.
- When taking the goals / use perspective, architecture can be seen as a consitent way of working (process), documentation and communication to achieve business goals (stated in terms of e.g. efficiency, effectiveness, redesign of processes, business functions etcetera). In this perspective, OMG's BMM is a relevant standard.
2 comments:
Hi Bas
Looks good - especially the recursive views implied by your bullet-points.
Only critique is that was at first confused by 'Definition' and 'Communication' seeming to be the same ('What is Enterprise Architecture?'); but from your previous post the first seems to be about generic idea of architecture itself, and the second about the specific 'architectures' in use in the enterprise. Might be helpful to clarify this difference on the diagram?
Another suggestion is that it's useful to distinguish between organisation and enterprise. For example, the goal of a commercial organisation may be to make a profit, but the goals of the enterprise - "the satisfaction of a need", in ITIL terms - are often more prosaic and practical: get the house clean, for example. The organisation's enterprise-architecture needs to show how those two sets of goals intermesh.
Tom,
thanks for your remarks. You're right, I should probably be careful with the distinction between enterprise and organization. More accurately, I should figure out which term I want to use and stick to it. I'm also working on updates of the diagram but haven't figured out how to proceed yet... there's a certain elegance to keeping it conceptually simple.
Post a Comment