Lately I have been involved in discussions on the role of models in enterprise architecture. Some people seem to think that an enterprise architecture describes detailed models of current and future situations. Typically these models are stored in an enterprise repository, that could also be filled partially by other sources such as the configuration management database or sourcecode files. Let's step back a little bit to look at the role of models in architecture in general.

In general, there are two views on architecture: the prescriptive and the descriptive view. In the prescriptive view architecture provides direction in change. Key arfefacts in the prescriptive view on architecture are principles, guidelines and architectural decisions. Models are typically not seen as artefacts that are needed in this view on architecture. The descriptive view on architecture sees architecture as the description of the fundamental structure of a system, partly inspired by the IEEE/ANSI 1471 standard. Key artefacts in the descriptive view on architecture are models.

I personally strongly believe in the prescriptive view on architecture. The main reason is that I think an architect should provide direction, and that models hide the motivations behind their structure. This in contrast to principles, guidelines and architectural decisions where motivation and implications are made explicit. I do not think that designers are inclined to adopt structures, for which they do not understand the motivation. Also, models tend to age fairly quickly. At an architectural level the world seems simple. This simplicity stops when you dive into the details. Suddenly the model that the architect perceived seems way too simplistic.

This is not to say that I think models are not valuable. To the contrary; models play an important role in enterprise architecture. Their main application however is the identification of model elements, such that they can be referred to in principles, guidelines and architectural decisions. Their basically form the language that is needed to give these statements meaning, and prevent confusion on their interpretation. Also, models enable scoping and detecting dependencies between model elements. They provide an overview and show interrelationships, which is important from an enterprise perspective. They are indispensible when projects and their scopes need to be defined.

So my main message is: models are important in enterprise architecture, but only for identification. So make models at a high level, and prevent going into the details of the elements you identify. Provide enough detail to enable drawing borders between elements. Make sure that you get commitment on the model, so that it becomes stable and that it becomes a foundation that others can build upon.

Be the first to write a comment

Only registered users can write comments.
Please login or register.

Share / deel