Architecture, a definition

Architecture, Architecting and Architect, terms heard a lot nowadays. A couple of years ago we called someone programming software applications a programmer, now such a person is called a Solution Architect. Much more examples can be given according to the number of job descriptions containing the word ‘Architect'. Yes, I have to admit, my contract also states that I am an Architect. However, if the work an Architect does is architecting and the result of that work is an architecture, most job descriptions seems to be a little bit inaccurate in my opinion. To make that more clear, I will define what the architecture of a system is.

Designing and engineering

Before defining architecture, the terms ‘designing' and ‘engineering' must be made clear. The clarification of the term ‘designing' is needed for making a distinction between the design and the architecture of a system. All these terms refer to how systems are constructed. According to [1] two different system notions exist: the teleological and the ontological system notion. The teleological system notion is about the function and the (external) behavior of a system. This notion can be visualized with a black-box model. The teleological system notion is adequate for the purpose of using or controlling a system. The ontological system notion, on the other side, can be used for building or changing a system. It is about the construction and operation of a system and can be modeled with a white-box model.

Both the teleological and the ontological system notion are relevant for designing a system [1]. In other words: both the functional and the constructional perspective of a system are relevant. In software, the terms functional design and technical design are often used to refer to these perspectives. How to make these designs is described in a so-called software development process. Such a process also shows the connection between the different models. A lot of such software development processes exist in literature. All of them have their own advantages and disadvantages. However, commonalities exist in these processes. These are described in the generic system design process in Figure 1. As the name already states this process is not only suitable for software development but it holds for each system you want to design.

Figure 1 – The system design process [1].

The starting point in designing a system is the using system (US). From the construction (white-box model) of the US we can determine the requirements for the object system (OS). These requirements are, by nature, about the function and behavior of the OS, thus in terms of the black-box model of the OS [1]. Once the black-box model of a system is determined, the specifications for the construction of the OS can be defined. So the designing of a system essentially consist of two things:
– Determining the (functional) requirements
– Devising the (constructional) specifications

When the design of a system is completed, the system can be engineered. If the design processed by the system design process is specified as an ontology, the process of engineering a system is like the one shown in Figure 2. An ontology model of a system is fully independent of the implementation, it only shows the essential features. Good examples of such ontology's are the SMART model for system development [2] and the DEMO (Design & Engineering Methodology for Organizations) approach to enterprise ontology (considering enterprises also as a system)[3].

Figure 2 – The process of engineering a system [1].

The ‘lowest' model of a system, called the implementation model, can straightforwardly be implemented on the available technological platform [1]. In software development this model often is the source code in a programming language like Java. The engineering of a system now can be defined as: the translation of an implementation independent (ontological) model of a system into an implementation model of that system.

Defining architecture

Now the terms ‘designing' and ‘engineering' are made clear, a closer look at existing definitions of the term ‘architecture' can be taken.

One of the definitions of architecture which has had a huge influence is the one provided by Zachman [4]:
Architecture is that set of design artifacts, or descriptive representations, that are relevant for describing an object, such that it can be produced to requirements as well as maintained over the period of its useful life.

Another definition which looks like the previous one reads like:
An architecture is the set of significant decisions about the organization of a software system, the selection of the structural elements and their interfaces by which the system is composed, together with their behavior as specified in the collaborations among those elements, the composition of these structural and behavioral elements into progressively larger subsystems, and the architectural style that guides this organization—these elements and their interfaces, their collaborations, and their composition.[5]

And to conclude a more recent definition:
The software architecture of a program or computing system is the structure or structures of the system, which comprise software elements, the externally visible properties of those elements, and the relationships among them.[6]

Many other definitions can be found saying the same in other words. As in all three of the given definitions architecture is defined as the description of a system. These definitions of architecture look like what is called ontology in the previous part of this article. When adopting this definition the difference between design (expressed in an ontology model) and architecture does no longer exist. So, why introducing the term architecture if the term design already is known? According to [7] the given definitions can be referred to as the descriptive notion of architecture.

Compared to these descriptive definitions the IEEE 1471 standard adds something more to the definition of architecture. IEEE 1471 states that architecture is:
The fundamental organization of a system embodied by its components, their relationships to each other and the environment, and the principles guiding its design and evolution.[8]

According to The Open Group [9] architecture has two meanings depending upon its contextual usage:
1. A formal description of a system, or a detailed plan of the system at component level to guide its implementation.
2. The structure of components, their interrelationships, and the principles and guidelines governing their design and evolution over time.

The first definition of The Open Group can be categorized as descriptive according to what is described above. The second definition and the IEEE 1471 standard are much the same. Following [1] these definitions are equivocal in the sense that they contain two different definitions in one sentence. The first part is again descriptive, the second part is much more interesting. It states that (architecture is defined as) the principle and guidelines governing their (components) design and evolution over time. This notion of architecture is called prescriptive [7].

So, concluding, two basic notions of architecture exist: a descriptive notion and a prescriptive notion. The descriptive notion says that architecture is about the structure of a system. The prescriptive notion says that architecture is about principles and guidelines. The descriptive notion is very important, but is already referred to as design and is very well covered on an abstract level by the notion of ontology. This leaves a definition of architecture which is prescriptive. By adopting this notion of architecture we follow Dietz and Hoogervorst [1] [8]. Dietz [1] defines architecture as:

Theoretically, architecture is the normative restriction of design freedom.
Practically, architecture is a consistent and coherent set of design principles.

Combining this definition of architecture with the given definitions of design and engineering, architecture can be visualized as shown in Figure 3.

Figure 3 – The Generic System Development Process [1]

In line with the different system notions presented before a distinction is made between functional principles or function architecture and constructional principles or constructional architecture [1].

Architecture Frameworks

With a clear definition of architecture in mind another important issue pops up: how are architectures created? Which things should be taken into account when devising a list of design principles? It is smart to have a structured checklist of issues when doing this. Such a structured checklist is called an Architecture Framework [10]. The term Architecture framework is used very widely, sometimes it refers to a ‘real' framework as just defined, but it also refers a lot of times to some kind of design methodologies. Giving an overview of different definitions of the term ‘architecture framework' is not helpful, because most of them are based on another notion of architecture.

Formally, an architecture framework can be defined as a tuple [10] where:
– S is a set of system types.
– D is a set of design domains.
– A is a set of areas of concern.

A system type defines a class of systems for which an Architecture Framework is meant. An example of such a system type could be an information system, but also an enterprise is a system type. In principal each system type is allowed as long as it satisfies the definition of a system [1]:
Something is a system if and only if it has the following properties:
– Composition: a set of elements of some category (physical, biological, social, chemical etc.).
– Environment: a set of elements of the same category. The composition and the environment are disjoint.
– Production: the elements in the composition produce things (products or services) that are delivered to the elements in the environment.
– Structure: a set of interaction bonds among the elements in the composition and between these and the elements in the environment.

Domains are distinctions that are inherent to the system type(s) [10]. Examples of domains are function and construction. Many existing architecture frameworks have domains like What, Where, When, How, Why and Who or a subset of them. These domains can of course be chosen and the resulting framework will satisfy the given definition of an architecture framework. However, it appears to be that no scientific foundation exists for using these domains. Unless this is a very interesting discussion we leave it for now because the choice of domains for a particular architecture is beyond the scope of this article.

Areas of concern are the general requirements put in by the stakeholders [10]. Examples are: security, user-friendliness, maintainability, etc.

A formal definition of architecture

Based on the definition of an Architecture Framework a more formal definition of Architecture can be given. According to [10] an architecture is a set P of design principles, conforming to some Architecture Framework. Every p Î P
– concerns one system type s Î S.
– is a restriction of design freedom in one domain d Î D.
– accommodates one or more areas a Î A.

Conclusion

The following terms are now distinguished and clearly defined: architecture framework, architecting, architecture, designing, design, ontology, engineering, implementation model, implementing and system. An overview of all these terms is given in Figure 4. This figure is based on Figure 3.3 in [11].

Figure 4 – Main activities in realizing a system

References

[1] Dietz, J.L.G., Hoogervorst, J.A.P.: Enterprise Ontology and Enterprise Architecture – how to let them evolve into effective complementary notions, GEAO Journal of Enterprise Architecture, vol.2 nr.1, March 2007

[2] Dietz, J.L.G., System Ontology and its role in Software Development, Proceedings of the Open Interop Workshop on Enterprise Modelling and Ontologies for Interoperability, vol.160, June 2005.

[3] Dietz, J.L.G., Enterprise Ontology – theory and methodology, Springer-Verlag Heidelberg, Berlin, New York 2006.

[4] Zachman, J.A., Enterprise Architecture: the Issue of the Century, Zachman International, 1996; http://mega.ist.utl.pt/~ic-atsi/TheIssueOfTheCentury.pdf

[5] Booch, Rumbaugh, and Jacobson: The Unified Modeling Language User Guide, Addison-Wesley, 1999.

[6] Bass, L., Clements, P., and Kazman, R. Software Architecture in Practice. Second Edition, Addison Wesley, 2003.

[7] Hoogervorst, J.A.P., Enterprise Architecture: Enabling Integration, Agility and Change, Published in: International Journal of Cooperative Information Systems, Vol. 13, No. 3, 2004, pp. 213-233.

[8] Maier, M.W. Emery, D. Hilliard, R., Software Architecture: Introducing IEEE Standard 1471, IEEE Computer, April 2001, Vol. 34-4, pp 107-109.

[9] The Open Group Architecture Framework (TOGAF), version 8.1.1. Enterprise Edition, 2007. http://www.opengroup.org/

[10] Dietz, J.L.G., Extensible Architecture Framework (xAF), Extended Summary v2.1, april 2007.

[11] Hoogervorst, J.A.P., Enterprise Governance & Architectuur, Corporate, IT en enterprise governance in samenhangend perspectief. Academic Service, 2007.