SOFTWARE ENGINEERING INSTITUTE | 17
9 Why the Data Model Is an Architectural View and What
Type of View It Is
The software architecture of a system comprises the structures of the system, each one containing
elements and relations. These structures are documented as architectural views. Different systems
contain different structures and the architecting effort will focus on different aspects of the design
and produce different architectural views. For example, architectural design of information sys-
tems emphasizes data modeling, and architecture design of telecommunication software empha-
sizes continuous operation, live upgrade, and interoperability [Hofmeister 2007].
The data modeling activity starts in the problem space, where its main purpose is to elicit and de-
scribe the domain objects that are manipulated by the system. However, data modeling crosses the
boundary between problem and solution space because the data model ultimately describes the
structure of the database. For example, a relational database with data tables, foreign keys, data-
base views, indexes, and other elements may be an essential component of the software system
solution.
Section 4 describes how the data model embeds architecturally significant design decisions that
affect modifiability and performance. That whole section serves as the argument for considering
the data model an architectural view. But one may argue that software architecture documentation
should focus exclusively on software elements. Architectural views that fall into the category of
module views, also known as code views, show the structure of code units (e.g., classes, pro-
grams, packages) and undoubtedly describe software elements of a system. Views in the compo-
nent and connector (C&C) category, also known as runtime views, describe the structure of com-
ponents (e.g., DLLs, EJBs, data stores, threads, and processes) and their runtime connections.
C&C views certainly show a perspective of the software system as well. Nevertheless, there is a
third category of architectural views whose focus is not software elements. These show primarily
non-software resources in the environment that are required or affected by the software system.
Examples of these views include
• a view that shows primarily the hardware infrastructure with server machines, database serv-
ers, client machines, network channels, firewalls, and other computing or communication
nodes, along with indication of what files are deployed to each machine
• a view that shows the tree structure of folders, subfolders, and files used in the development
environment, production environment, or deployment artifacts
• a view that describes the human resources available or assigned to implement, test, deploy,
and maintain the software system
In the context of the software architecture, these views showing environmental resources become
relevant as long as there is a relation between the non-software resources they show and the soft-
ware elements that live in module or C&C views. For that reason, these views have been called
allocation views because they should show the allocation of software elements to environment
resources [Clements 2002].