Three perspectives on enterprise architecture

This is a cross-posting (a cross-blogging?) from my blog at
Via Nova Architectura. The reason for cross posting this blog entry is that I want to keep at leas a copy of all my blog entries at a central location.

When looking at the different types of interpretations of what enterprise architecture is, I believe there are three main perspectives on what architecture is about:
  1. A regulation-oriented perspective in which architecture is regarded as a way to govern the design/evolution/transformation of an enterprise by means of regulations. In other words, in this perspective architecture is regarded as a prescriptive notion limiting the design freedom with regards to the design and evolution of a system.
  2. A design-oriented perspective in which the essential properties of a system are being designed. This perspective treats architectures as actual specifications of high level system designs focussing on `architecturally relevant' design decisions and tradeoffs.
  3. A patterns-oriented perspective which focuses on the use of design patterns. This perspective forms a bridge between the regulative and the design perspectives. To meet the regulations set out in the regulative perspective, during design activities, suitable patterns can be applied.
When looking at publications, ranging from Alexander, Gamma, IEEE, ArchiMate, to Dietz and Hoogervorst, one can see these perspectives in different shapes and form.

In my opinion, talking about architecture only makes sense when acknowledging the complementary role of each of these perspectives rather than limiting the definition of architecture to merely one of these perspectives.

It's not your definition of architecture that matters, but what you do with it.


  1. It's amazing the debate is still going on. I studied this topic five years ago, and discovered three different flavours too. I named them
    * the prescriptive vision - architecture by decree;
    * the descriptive vision - the (high-level) design is the architecture;
    * the constructive vision - the architecture is a reflection of the design principles.

    The descriptive vision is still widespread. You can hear architects in IT talk about the architecture they made, referring to either a 200 page document or a poster on the wall. Managers plan the creation of the architecture as a phase preceding the creation of the design. The implicit logic seems to be that artefacts made by an architect must be architecture. Only think of the documents they call "project-start architecture".

    However, when you refer to the origin of architecture, the building industry, you will soon find out that architecture is a concept bound to a construction. Architecture does not exist on paper, nor in decrees, nor in models. A design is a design, a rule is a rule, a pattern is a pattern, and an architecture is neither.

    Why is it, that in IT, we tend to hijack a word from another industry, and give it an altogether different meaning? What is a poorly designed architecture ( different from a poorly designed system? Why do we use the verb "to architect" if we mean "To design intentionally?" Is it just to impress? Well, for me it serves as a disqualifier.

    The IEEE working group did a very good job in defining those terms back in 2000. Architecture is a property of a system reflecting its internal cohesion; its harmony with its surroundings and its design principles. Or, officially, "The fundamental organization of a system embodied in its components, their relationships to each other, and to the environment, and the principles guiding its design and evolution." And a document simply is (part of) a view on the architecture description of the system.

    If only IT people would accept (and practice) the difference between an architecture description, a view as part of the architecture description – either made during the design of the system or afterwards – and the architecture itself, much confusion and mystification would be prevented.

    Let's end the debate, and start with the real work.

  2. A cross posted response from this blog entry on via nova is:

    Written by Marc Lankhorst on 26-12-2007 13:02

    Here here! We should indeed stop trying to define "architecture" as only one of these perspectives. Furthermore, the "design-oriented perspective" often also serves to regulate lower-level decisions, e.g. in a stepwise refinement, and thus becomes part of the "regulation-oriented perspective".

  3. A second response to the original posting on via nova:

    Written by Louis Dietvorst on 16-12-2007 20:12

    I agree with the statement \"It\'s not your definition of architecture that matters, but whay you do with it\". An architecture perspective is thus \"in the eye of the beholder\". Many perspectives seem possible, for example prescriptive and descriptive architecture as a complementary mechanism. The descriptive architecture consists of expressions of as-is and to-be in both natural language constructs and models. The prescriptive architecture is used to guide the transition from as-is to to-be.

    Another perspective on architecture is that of a set of overlapping, complementary continua with no clear demarcation points between the continua (see where an experimental framework is explained. In this architecture perspective, each continuum is supposedly supported by a more or less dedicated competence or set of competences.

    Where these continua are overlapping or complementary, competences need to collaborate leading to the question: how do we solve our competence gap? In architecture contexts, this is often done with models since not everything can be expressed clearly enough in natural languages only.

    Models thus support one way to bridge a competence gap and a new perspective on architecture is born: that of architecture as a competence gap bridge using models and transition rules as a means to add value from competence to competence (leading effectively to a \"model value chain\")


Post a Comment

Popular posts from this blog

Models that matter; Return on Modelling Effort

Fundamentally understanding IT? - Why Web 2.0 needs architects. Part II