1 Introduction

This document describes a model of activities to produce IT-architecture descriptions in

a stakeholder oriented way. The model also covers the use of the IT-architecture
descriptions by the stakeholders. The model does not tackle all the activities in
producing IT-architecture description, it focuses activities geared at improving
stakeholder orientation and so achieving better usability of the documentation for the
stakeholders.
The model described in this document will be tried in practice in an action research
project on the communication of IT-architectures in the period 2003 2004. The goal of
this research is to find ways to improve the readability of IT-architecture documents.
This document is a draft to solicit comments and it is part of a set of documents. The
other document are
@@@ which contains the research activities that are undertaken to test and improve
this model.
@@@ which contains the research questions and tools
@@@ which contains a planning spreadsheet
This research works within the framework of the IEEE Std 1471 @@@[IEEE, 2000]. It
adds to IEEE 1471 the explicit desire to optimize the application of the standard to
receive a high readability of the resulting architecture descriptions. Where in this
document stakeholder orientation is mentioned, it is, in accordance with IEEE to be
understood as orientation on the concerns of the stakeholders.
Chapter 2 give a short intro of IEEE 1471 and some remarks relating to it. Chapter 3
contains the hypothesis that forms the basis of this model. Chapter 4 describes the
various activities that make up the model.

2 IEEE 1471
Mission

Environment

Concern

System

Architecture

Stakeholder

Architecture
Description

Viewpoint

View

Library
Viewpoint

Rationale

Model

IEEE 1471 proposes that an AD consist of views and that views are constructed
according to viewpoints.
In the IEEE 1471 conceptual model a stakeholder is represented by his concerns.
Wherever in this document we mention stakeholder orientation we mean
orientation on the concerns of that stakeholder.
IEEE 1471 defines a view as A representation of a whole system from the perspective
of a related set of concerns (id, p.9), and a viewpoint as A specication of the
conventions for constructing and using a view. A pattern or template from which to
develop individual views by establishing the purposes and audience for a view and the
techniques for its creation and analysis. (id. p. 10).
This research focuses on the definition of viewpoints as the leverage point to improve
the quality of the architecture description, and more particular on improving the
insight in the relation of the architecture design to the concerns of the stakeholders,
before deciding on the viewpoints to use.
Viewpoints delineate the architectural information that is presented to the
stakeholder. @@@???For us this means paying explicit attention to the selection of
architectural information from the conceptual model of the architecture that will be
part of the view.
Viewpoints contains prescriptions for models to be use in the views. From our interest
in communication we intend to give additional guidelines on the use of text and the use
of diagrams in these viewpoints.

3 Hypothesis
The model described in this document is based upon the following hypothesis:

3.1 IT-architecture documents in general

an IT-architecture lays the foundation for a development project for (parts of) one
of more IT-systems. I creates the frames for others to work in.

an IT-architecture is a limited set of (architectural) statements building on a

limited set of clearly defined (architectural) concepts.

Current IT-architecture documents provide much to much information for the

various stakeholder; serious doubts exist whether all the stakeholder can find the
information that is relevant to them [Koning, 2003].

Describing architecture requires a situational approach. Although many attempts

have been made to standardize architecture descriptions, the current practice is
that architects for good reasons make their own choices for each project.

Though the situational approach is practice, it is not per se desirable. Where there
repeatedly can be made use of the same viewpoints, IEEE 1471 offers the possibility
of storing and reusing viewpoints as library viewpoints. This method can be used to
construct those library viewpoints or evaluate existing library viewpoints for
possible use in a given situation.

3.2 Stakeholder aspects related to IT-architecture documents

An architecture description that is composed in a stakeholder oriented way is

better readable for the stakeholder. Better readable means: the stakeholder can
find more quickly the information that is relevant for him, and he can process that
particular information more easily.

Stakeholder orientation is determined by three aspects: the structure of the

document (IEEE 1471 views; general structuring guidelines), the use of text, the use
of diagrams. These three aspects are worked out in the next three paragraphs.

The smaller the number of views a stakeholder must consult to see how his
concerns are addressed, the better it is. The smaller the amount of unnecessary
information a view contains for a stakeholder, the better it is. Information that is
only for internal use by the architecture team should not be communicated to the
stakeholders.

3.3 Structuring IT-architecture documents

IEEE 1471 prescribes that an IT-architecture document consists of views.

Views contain the information that is needed to address a set of closely related
concerns of the stakeholders. Views form the top level structuring of the
architecture description. The division in views must be clear, which means that a
stakeholder must be able to easily determine which views are relevant to him/her.
Views are constructed after prescriptions thereof in corresponding viewpoints.

A viewpoint must prescribe a clear structure for the entailing view, which means
that a stakeholder can easily determine what kind of information the various parts
of the view contain and how this information relates to the concerns to be
addressed.

A clear structure also means a composition of layers of abstraction. For each layer
the information is complete, which means that the stakeholders can, remaining on
the same abstraction level, infer fully the meaning of this information. It is the
responsibility of the writer of the architecture description to construe these layers
of abstraction and to not leave the reader up to doing this himself. The architect
must be to himself clear about the priorities in the architectural decisions taken,
which are essential, which are of less importance. The hierarchy of meaning must
be clear.

To clarify the structure of a document to the reader, a docscan-table linking the

content to the concerns of the stakeholders [Koning 2003] will be experimentally
provided in the documents.

3.4 The role of Diagrams in IT-architecture documents

Diagrams play an important role in the communication of IT-architecture. Diagrams

contribute mainly by giving overview of components and relations and by giving
support in making inferences. @@@[Gyselinck 1999]. Diagrams speed up the
processing of the information and they aid in remembering the information.

The use of diagrams must be tuned to the frame of reference of the stakeholders.
The stakeholder must be able to easily perceive his place in the world of the
diagrams. The use of symbolic forms and of icons and colors must correspond to
what he is used or be easily recognizable by him. All the mean architectural

statements must be depicted graphically in the diagrams. The way the contents of
the diagrams mutually relates must be clearly discernable (for instance by similarity
in place and form of corresponding items). The diagrams must be consistent in the
use of visual attributes. The architectural concepts must be clearly recognizable in
the diagrams. See the guidelines for readability @@@[Koning 2001].

To clarify the content of a document to the reader, a concept map relating the
architectural concepts to each other will be experimentally provided in the
documents.

3.5 The Use of Text in IT-architecture documents

The use of text must be tuned to the frame of reference of the stakeholders. In
headings and body text the concerns should be recognizable. The language of the
body text should make use of terminology of the stakeholder, or terminology that is
familiar to the stakeholder.

There are three categories of concepts to discern: the concepts with which the
stakeholder daily operates, the concepts on which the architecture is based, and
the shared concepts of the environment in which the stakeholder and the ITarchitect work. These categories can be further differentiated into more levels of
familiarity and/or commonality. An accessible document leads from the known to
the unknown. If necessary the IT-architect must add translations of the ITarchitecture concepts to the concepts and concerns of the stakeholders.

Understanding an IT-architecture is basically a process of translating the ITarchitecture concepts to the own concepts of the stakeholder, and making
inferences about possible situations or results that may occur by introducing the ITarchitecture.

4 Model
This is the tentative model that shall be tested and corrected by means of the research
activities. The model is described in the following paragraphs.
The model contains the result of the collaborative learning that is part of the action
research activities. For a starting point the model has a hypothetical nature, it
expresses the common understanding, that will be tested by the research activities.

4.1 Activities in the model

IT-architect

Stakeholder

Detailed design of
diagrams
Produce
architecture
descriptoin

Overall design of
viewpoints

Read

Detailed design of
textual description

The model consists of three design activities that proceed the actual production of the
architecture description. The fourth activity is the use of the architecture description
by the stakeholder. In the following sections each of these activities is described.
Documenting the architecture is an activity that takes place in all stages an
architecture design project. For internal discussion of for intermediate discussion with
stakeholders parts of the design under consideration are described, altered, and
described again. These pieces of description may have a varying degree of formality. In
the final stages of the project a roundup takes places of all available pieces of
description and an effort is made to check for completeness and to see to it that
documentation standards are met.
An extra effort may be made to produce clear documentation to serve the larger
audience that will be reached at the end of the project. This model presumes that a
conscious and substantial effort is made to produce stakeholder oriented
documentation that is very readable. It is up to the architect to decide when and where
he will perform these activities as long as in the end the proposed deliverables are
there.

4.2 Overall Design of Viewpoints and their architectural

information
Overall design of viewpoints

Summarize
internal design
documentation

Compile
stakeholder
profiles

Relate summary
of internal design
documentation to
concerns of
stakeholders

Define viewpoints

This is a very essential activity. Basically it consists of tinkering around for a prolonged
period of time with the relation between the messages in the architecture design and
the concerns of the stakeholders. Various tools are provided for the stakeholder to
express and amend his thoughts, find omissions, seek words to express the perceived
relation, etc.
Since experienced architects probably are trained and molded in some general
applicable it-oriented documentation standard, it is important to take enough time for
this activity and allow yourself to grow into specific stakeholder perspectives.
There is some logical relation between the sub-activities, as shown in the figure from
left to right, but as with any design process, each part influences the others and while
progressing it may be necessary to come back and review previous results.
Probably this activity could (should?) be done in cooperation with stakeholders. That is
not worked out here, but is certainly not excluded and in fact probably a very valuable
thing to do.

4.2.1 Activities

4.2.1.1Summarize internal design documentation

The goal is to produce a listing of the architectural information that makes it possible
to reason about the relation of this information to the concerns of the stakeholders.
The listing should name parts of the information that can be allocated to views. The
listing should describe the parts the IT-architecture sufficiently clear to aid memory
and to be able to reason about them.
This listing can be adjusted and further developed when used in the next activities.
The summary is a good starting point for a first draft of a concept map of the
architecture description. This concept map shows the main descriptive concepts. It can

be any type of information that has played a role in the design process somehow.
Examples are: concerns, design principles, goals, components, products, deadlines,
money, etc. Each concept can have subtypes depending on specific characteristics of
the architecture design.
Deliverables:

Summary of internal design documentation (see 5.1)

Concept map of architecture description (see 5.3)

4.2.1.2Compile stakeholder profiles

The goal of this activity is to make the stakeholder position explicit and to be able to
reason about his information needs. The profile description should be independent of
the architecture design to make it a stable point of reference, but not so far off to
make it meaningless. The profile expresses how the architect sees the stakeholder. The
profile should be understandable and verifiable by the stakeholder.
For even better understanding and better communication two profiles can be made for
each stakeholder. One general profile, independent of the architecture being designed,
expressing the position of the stakeholder in the organization, and one profile giving
more details of how the stakeholder is positioned towards the system of which an
architecture is designed.
When working on architectures of collections of systems the problem of which
stakeholder concerns to include or reject becomes important. When you are building a
single system this is easier. At the family level many stakeholder concerns need to be
rejected because they are resolved at the level of a particular system, not the family.
But, this is hard to recognize and many peoples practices do not understand it.
IEEE 1471 prescribes these concerns as a minimum to take into account (id, p. 15):
The purpose or missions of the system
The appropriateness of the system for use in fulllling its missions
The feasibility of constructing the system
The risks of system development and operation to users, acquirers, and developers of
the system
Maintainability, employability, and evolvability of the system
Other common concerns are: costs, resources, planning issues, migration issues.
Deliverables:

Stakeholder Profile Tables (see 5.2), one or two for each stakeholder

4.2.1.3Relate summary of internal design documentation to

concerns of stakeholders
The goal of this activity is to make explicit the relation between the content of the
architecture design and the concerns and concepts of the stakeholders. This relation is
expressed in textual form and in graphical form. The texts reflect not only the fact that
there is a relation, but also the essential reasoning that shows how the architectural
statements address the concerns of the stakeholders.
The result of this activity is the basis of the design of the viewpoints. This goal will
determine for this activity the proper level of detail (which may not be easy to find
right away).

The text and graphics produced in this activity are not the final documentation, but
they will be of help in producing the final documentation and make that more smooth.
The effort put in producing this intermediate material will have a return on
investment later on.
Deliverables:

See 5.5 for another example of a concept map. (see 5.3)

Concept Map with Concerns (see 5.5)

4-column map (stakeholders, concerns, architecture statements, concepts)(SCAC)

(see 5.6)

4.2.1.4Define viewpoints
Now this is what it is all about.
The viewpoints indicate what information will be presented to which stakeholders and
which concerns are addressed by this information. It also contains directions for
modeling techniques to be used and for how to assemble or verify the information.
This activity takes from the previous activities a well-founded insight into the relation
of the architectural design to the concerns of the stakeholders. A goal of designing
viewpoints is to present to each stakeholder exactly the information he needs regarding
his concerns. When he is presented more information, It should be easy for a
stakeholder to find the 25% - 50% of the total information in which he (on average) is
interested. This information should not be scattered.
Defining the viewpoints is a design activity in itself. It is a balancing act between the
interests of the stakeholders and the interests (and limitations) of the architect. On the
stakeholder side the goal is to give each stakeholder exactly the information he needs
in a way that suits him/her well. On the architects side there is the limited time
available and the practicalities of the distribution of the final documentation.
One of the viewpoints may concern mr. everybody as stakeholder and give a general
overview and any information not related to specific concerns that is common to all
stakeholders.
It seems only natural to capture the reasons for the choices made in this activity as
part of the rationale.
Deliverables:

Viewpoint definition (see 5.7), for each viewpoint

Rationale (see 5.8), part of.

4.3 Detailed design of the diagrams in a stakeholder oriented

way
The design of diagrams is a separate activity for various reasons:

Communication by means of diagrams has proven to be very effective in ITarchitecture and in IT-designing in general. By making it a separate activity the
architect is encouraged to reserve due time and energy for it and take is very
seriously. The image of the project is often carried by the diagrams, of the one
main diagram.

The use of colors, graphics and other visual aspects in diagramming offers very
good opportunities to connect to the situation of the stakeholder, and make the
information his information.

The use of visual attributes should be designed for all documentation at the start.
The visual representation of the main architectural concepts and messages should
be chosen with care and used consistently.

The representations proposed in documenting software architectures @@@[Clements,

2002] can be taken as a (rather technical) starting point, and augmented with or
replaced by representation specific for this architecture description and organizational
context.
The design of a representation is primarily driven by the information it must provide
and the reasoning that a stakeholder is presumed to be doing with that information.
See @@@Guidelines for readability [Koning, 2001] for many other practical guidelines.
The designed overall use of visual attributes should leave room for use of special colors
or graphics in the stakeholder oriented views. The use of visual attributes should all
work together to convey for each stakeholder the main architectural statements and
highlight where the architecture touches on his/her concerns. Stakeholder oriented
diagrams should be clearly related to general diagrams (intended for all stakeholders).
This can mean in practice:

Use colors, graphics from the stakeholder environment, and that are meaningful to
him.
Produce extra diagrams with only the relevant information for the stakeholder.
Produce extra diagrams that equal general diagrams, but with added icons to show
stakeholder aspects.
Take a look at diagrams the stakeholder is used to, and where possible, follow
suite.

There is one specific thing the practitioners are asked to do and that is to offer the
stakeholders a concept map of the architecture description somewhere in the
introductory parts of the documentation.
Deliverables:

@@@

4.4 Detailed design of text in a stakeholder oriented way

As well as with the diagrams, it may be a good thing to think for a moment about the
use of text in an architectural description. What will be the structure of the text within
a chosen view? Can the outline be made more understandable? What terms will be used
often and are these understandable for the stakeholders? Can terms from the
stakeholder be used, or can the architectural information be translated to his/her
terms?
Here are some guidelines for creating textual description in a stakeholder oriented way.

Provide in beginning of AD a docscan table linking content to concerns

(practitioners are kindly urged to do so, because testing this out is one of the
subgoals of this research)

Making sure that relevant information is delineated by structure elements (dont let
the stakeholder search for relevant information in unstructured text).

Use where possible the concepts of the stakeholders, or provide translations to

them.

Repeat the concepts of the stakeholders in the titles of (sub)sections

Explicitly referring to concerns in the text

Enriching the text with recognizable tags @@@???

Produce summaries targeted at specific concerns of stakeholders (comparable to

the management summary)

(combi with diagrams) design a set of icons related to the main architectural
messages and recognizable / meaningful to the stakeholders; add these icons to
the text or the page border

Deliverables:

@@@

4.5 Reading architecture documents by stakeholders

This activity is added to the model to have a place for collecting stakeholder responses.
It is not up to the IT-architects to tell the stakeholder how to read a document, but it
important to have a idea of how the stakeholder does this, in order to provide the best
document.
In the next paragraphs an attempt is made to breakdown this activity.

4.5.1 Process steps

These process steps are derived from guidelines for reading research papers [Walliman,
2001].

4.5.1.1Read outline of content and summary

4.5.1.2Study Content to Concern table and Concept map
4.5.1.3Skim report
4.5.1.4Follow Content to Concern table and read appropriate
sections in detail
4.5.1.5Process the information
This may require rereading parts of the information. Essential parts (diagrams?) may be
consulted again on later occasions.

5 Deliverables
5.1 Summary of internal design documentation
The summary of internal design documentation is a simple list of all the main
architectural statements. It is a listing, it is not the full description of the architectural
statements.
For an existing (classical) architecture description a detailed outline of content can be
used.

5.2 Stakeholder Profile Tables

The stakeholder profile table is a condensed rsum of the position of a stakeholder
concerning the problem domain.
Attribute

Meaning

Title

Short recognizable descriptions of role/function

Goals

The goal or goals of the role/function. A goal is a

condition that must be reached or maintained.

Tasks

Logical grouping of all the activities that must be

performed for the role/function.

Concepts

Objects that are relevant for the stakeholder and that

make up his view of the world.

Concerns

Concrete interests or worries that guide the activities

in the role/function and that determine which services
are requested of other roles/functions.

Example:
Attribute

Content

Title

Manager User Department

Goals

Keep the performance, composition and working conditions of

the department between agreed boundaries.

Tasks

Take decisions about people, money, resources

Take responsibility for work of employees
Represent department
Report to corporate management

Concepts

Employees, management, capabilities, work processes,

products, services, money, office-facilities, IT-systems,
applications, workload, meetings, appointments, contacts,
customers, decisions, company strategy

Concerns

How to stay within budget and meet all set targets?

How to keep the operations going? What disruptions can be
expected?
How to implement changes?
How to keep my employees in good shape?

5.3 Concept map of architecture description

A concept map is an UML diagram of the main architectural concepts, the concepts that
carry the story. It is not easy to make a concept map. It may take some time to make
a good one. In the end, all the main architectural statements should be easily linked to
one of more of the specified concepts.

This is a small example of a concept map of a new data-architecture that was designed
for a company. The concepts are in black, the main architectural statements are in
gray.
FD and
applications
maintained in
coordination

Functional
design

Application

All applications
which access
data are known
Functional datacomponent

Design principles
guide the
mapping of
functional
component to
data access
functions

Data Access
Function
There is a limited
number of
sufficiently
functional data
access functons

Data Entity

Relation

The technical
structure is better
maintainable in
coordination with
the data access
functions

See 5.5 for another example of a concept map.

5.4 Content 2 Concerns Table

The goal of the content 2 concerns table is to show which architectural information is
relevant for which stakeholder (via the concerns).
The content to concerns table has as headers the concerns of the stakeholders with
regard to the architecture. Each row starts with an element of the summary of the
architecture. The cells contain the information concerning a combination of a concern
and a summary element. Not all the cells need to be filled.
A filled cell has two pieces of text: first, a short description of what the concern means
for this element of the architecture, and, second, what is the related architectural
information.
As an example here the first some columns and rows of an experimental C2C-table:

Summary of
GTP
Architecture
Report

Acquirer

Process designer

Domain Architect

How to
prepare the
organisatio
n for the
new
solution?

What is the impact of

this process
architecture on my
business domain?

.
.
.

How can I
Can I design a clear
administer the new process wit hit?
regulations
efficiently?

Information
Manager

.
.
.

Which regulations
Which regulations
can be administered have clear process
more efficiently?
steps?
3.2
Considered
regulations

A more efficient
A selection has been
administration is
done on the basis of
realisable when
the number of
regulations have a process steps and
strong resemblance the clearness and
and need no extra needed authority of
contacts with clients. decisions.

3.3.1 Scope
in business
process
model

Which departments
and/or workprocesses
are touched by the
changes and how?
The impact is indicated
in an organisation
description dd ....; a
distinction is made
between small changes
(process continues)
and big changes
(temporary measures
will be needed)

5.5 Concept Map with Concerns

The goal of the Concept Map with concerns is similar to the Content to Concerns Table,
but it operates on a more abstract (meta-)level and is more visually.
The Concept Map with Concerns is a diagram with as a basis a UML (meta-)model of the
architecture. The model is enriched with boxes that denote the stakeholders and their
concerns. Extra lines show from which concepts in the (meta-)model information is
needed to show that the concerns are addressed.

@@@try concerns in the map, close to one or more concepts they are related to,
instead of on the side, and dont connect to stakeholder (use colors to indicate
stakeholders, or make a diagram for each stakeholder)@@@
As an example:

5.6 4-column map (stakeholders, concerns, architecture

statements, concepts)(SCAC)
The SCAC map serves again the goal of making explicit the relations between the
concerns of the stakeholders and the architectural information. The stakeholder,
concerns and concepts are the same as with the Concept Map with Concerns. What is
adds is the 3d column which summarizes the architectural information that addresses
the connected concerns (column 2) and that is based on architectural concepts (column
4). The concept map with concerns becomes cluttered very easy and this diagram tries
to amend that (while sacrificing the 2-dimensional layout of the concepts). This
diagram is also intended to support the traceability requirement.
As a small, and still a bit void, example:

5.7 Viewpoint definition

This section offers some help in defining viewpoints.
IEEE 1471 (section 5.3) prescribes that a viewpoint contains:
a)
b)
c)
d)

A viewpoint name
The stakeholders to be addressed by the viewpoint
The concerns to be addressed by the viewpoint
The language, modeling techniques, or analytical methods to be used in
constructing a view based upon the viewpoint
e) The source, for a library viewpoint (the source could include author, date, or
reference to other documents, as determined by the using organization)
See IEEE 1471 sections 5.3 and 5.4 (on views) for the complete prescription for
viewpoints.
Different modeling techniques can be combined in one view to represent all the
information needed to address the concerns. See [Clements, 2003] for a thorough
description of proven modeling techniques. Paragraph 5.7.1 offers a short introduction
to this book.
Some additional guidelines:

Network based systems need layered representations (layer==view, at least

sometimes). This works fine for physical and application layers, where we know
what to represent. It works less well for intermediate layers because there are no
standard notations and people do not understand. However, frequently some of the
most important information is captured in the intermediate layers.

5.7.1 Book Documenting Software Architectures (DSA)

The book Documenting Software Architectures [Clements, 2003] contains a description
of software architecture modeling techniques (called styles in this book), grouped in
three categories (called view types). For each style the constructing elements are
described, a notation is proposed, its possible uses are discussed and relation to other
styles is indicated. Table 1 contains a short overview to give you an idea.
Table 1 Viewtypes and styles in Documenting Software Architectures
View Type
Module

Style
Decomposition

Uses
Generalization
Layers

Usage (essentials, HK)

- overview of system functionality
- impact analysis
- basis for other views
- projecting maintenance
- debug & test
- OO design
- specify commonalities and differences
- represent modifiability and/or portability
- managing complexity

Component-andConnector

Allocation

Pipe-and-Filter

Shared-Data
Publish-Subscribe

Client-Server

Peer-to-Peer

CommunicatingProcesses
Deployment

Implementation
Work-Assignment

show/analyze sequential data transformation

steps
show characteristics of (related) data store(s)
show construction with independent senders and
receivers
show characteristics of functionality split between
hardware platforms or system environments
show characteristics of independent (distributed)
collaborating units of functionality
show (constraints for) allocation of components to
runtime units
show allocation of software to hardware
analyze performance, reliability, costs
development and build configuration
show development chunks and planning

There is no complete freedom to choose a certain Component-and-Connector style at

documentation time, it may be closely linked to whether the corresponding pattern is
chosen as a design pattern for the architecture earlier on.
Different DSA styles can be combined in composing an IEEE 1471 viewpoint, as
demanded by the concerns that are addressed in the to-be-made IEEE 1471 view.
In separate chapters the book treats additional modeling techniques, like context
diagrams, behaviour diagrams, etc. For this we refer to the book. These additional
techniques can also be very useful in composing IEEE 1471 viewpoints.
All the DSA styles can probably be transformed to higher abstraction levels, to arrive at
for instance Application-and-connector styles, to show how various kinds of functional
relations exist at more abstract levels.
[Clements, 2003] (p 317) also proposes a template for architectural views that consists
of: the primary presentation, the element catalog, a context diagram, a variability
guide, architecture background, other information, related view packets.

5.8 Rationale
IEEE 1471 (section 5.6) prescribes for the Rationale:
An AD shall include the rationale for the architectural concepts selected. An AD should
provide evidence of the consideration of alternative architectural concepts and the
rationale for the choices made. When the AD describes a system that pre-exists the
development of the AD, the rationale for the legacy system architecture shall be
presented, if known.

5.9 Detail design of diagrams

6 References
[Clements, 2003] Clements et. al., Documenting Software Architectures: Views and
Beyond, 2003, Addison-Wesley, ISBN 0-201-70372-6
[Gyselinck 1999].@@@
[Koning, 2001] @@@ guidelines readability @@@