- 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.
May 18, 2009
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: