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.

Comments

  1. Anonymous28/12/07 10:46

    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 (http://www.ibm.com/developerworks/wireless/library/wi-arch7/) 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.

    ReplyDelete
  2. Anonymous28/12/07 13:02

    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".

    ReplyDelete
  3. Anonymous28/12/07 13:03

    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 http://archi-works.blogspot.com/2007/07/business-innovation-framework.html) 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\")

    ReplyDelete

Post a Comment

Popular posts from this blog

Models that matter; Return on Modelling Effort

-
In the context of enterprise architecture, IT architecture, (software) system development, et cetera, we use several models. Some models have a descriptive nature (e.g. UML, ArchiMate and DEMO models) and some have a prescriptive nature (e.g. sets of business rules and architecture principles). All of these models are created for many different purposes. At the same time, the creation of these models takes time and effort. In other words, they cost money. This raises the question of how these investments can be put to good use? How to increase the return on investments put into models? In other words, how to achieve return on modelling effort (RoME)? Since a year or two, my research group at the University of Nijmegen has been using the return on modelling effort question as one of the drivers in its research activities. Below I'll venture out and explore some potential returns of modelling efforts. Knowing beforehand what the expected return of modelling effort for a given model
Read more

Enterprise architecture as organisational Zen

-
The way I have learned to understand Zen , is that it is about concentration and focus. By means of meditation , Zen teaches us to focus on the things you really want to focus on , meanwhile allowing us to obtain insight into our inner drives as well as our imprinted reflexes. Whenever we, as average beings, are put under stress, our imprinted reflexes tend take over, taking us away from the things that really matter to us. Instead, we start worrying about how good we are in our jobs, whether our boss likes us, threats to our status in society, et cetera. Zen helps us in focusing on what is important. It does so by improving our mental discipline by way of meditation . This improved discipline allows us, in our daily live, to be more aware of situations where our mind starts wondering off. Especially when we are put under stress, and the mental reflexes that are imprinted in our mind (based on past experiences and shadow beliefs ) take over. Once we have learned to observe such behavi
Read more

Architects: Execute and evaluate your methods!

-
Since architecture is a relative new field, much debate goes on about the methods and techniques to be used within the field. As one of the key competencies of an architects is to be able think conceptually, it is only natural for architects to engage in lengthy discussions about their tools, techniques, approaches and methods. A recent example of such a discussion can be found on the  Via Nova Architectura  website, where a rather opinionative posting on TOGAF 9 resulted in an involved discussion with 38 elaborate responses. In principle, there is nothing wrong with a critical attitude towards methods. Especially in developing disciplines, one needs to be critical about the efficiency and effectiveness of the methods we apply. Regretfully, however, current discussions on architecture methods tend to be based on opinions, views and impressions rather than facts derived from thorough evaluations in practice. In the earlier mentioned discussion on TOGAF 9, several participants referred
Read more