The Value of Architecture

Nowadays a lot of people see the added value of architecture. Numerous examples exists showing that without architecture systems don’t function in the way expected. Trying to change such systems delivers a real headache. However, architecture can have different formats. Just a pile of paper without any structure doesn’t really help you. Architecture can be defined as a set of principles restricting the design freedom for a system design. These principles can be formalized using a structured format. In this way architecture can deliver real value in creating or changing a system, but how to convince your manager? Or, formulated in another way, what is the economic value of an architecture?

Architecture principles

As already said, I mainly see architecture in a prescriptive way. So an architecture consists of a set of principles. These principles can roughly be separated into two sets: functional and constructional principles. This separation is based on the two different notions on systems. Functional principles restrict and guide the functional (behavioral) part of a system, they say something about the black box view of a system. Constructional principles restrict and guide the constructional part of a system, they say something about the white box view of a system.

An example of a functional principle can be: The system should expose its functionality through web services. This principle influences the functionality of the system (of all systems build using this architectural principle). This principle also identifies (a part of) the project which should create or change the actual system.

An example of a constructional principle can be: The system should consist of modular, reusable parts. This principles influences the quality attributes of a system. It also identifies the project which should create or change the actual system. Constructional principles address topics as availability, usability, security, stability, maintainability, etc.


Architecture benefits

The problem now is, how can we determine the value of these architectural principles? I recently read a very nice article on this topic in [1]. In this article Ton Tijdink presents an analytical model for valuing IT systems. His model is based on sources [2][3][4] about the Architecture Tradeoff Analysis Method (ATAM) and the Cost Benefit Analysis Method (CBAM).

The value, or the benefits, from architectural principles also can be divided into a functional and a constructional (called technical in the model) part. Functional benefits come from business activities enabled by the functionality of the system. New functionality is introduced, so new business activities are enabled. Technical benefits, on the other hand, come from the way new and current business activities are supported by a system. Quality attributes satisfying more strict requirements improve the efficiency, security, flexibility (etc.) of business processes. Ton Tijdink [1] uses the example of replacing manual activities by automated activities. This process delivers you technical benefits. So, functional benefits are direct, technical benefits are indirect.


An analytical model

All these terms (principles, benefits, etc.) can be put in one model to give an overview of them and to show how they are connected. In Figure 1 this model is presented. Benefits, costs and the lifecycle are subject to risks. This means there are uncertainties about the level and the duration of them in the future. Risks are taken by the shareholder (or owner). Furthermore three stream (from left to right) can be identified.

Simple analytical model for IT value creation

Figure 1 – Simple analytical model for IT value creation (based on [1], changed to the usage of architectural principles)

The middle one is about the delivery of a system and has a cost structure and lifecycle. A system is created by some project and serves the needs of the stakeholders.

The top layer visualizes the responsibility of an information architect. Functional principles are devised, which influence the functionality of the system. The functionality defines how the system will be, it defines the behavior of the system (the black box view). Functionality also creates functional benefits (as explained in the previous part). These functional benefits accrue to the stakeholders.

The IT architect’s responsibility is visualized in the bottom layer. He devises the constructional principles, which influence the quality attributes. The quality attributes condition the actual system. They also create technical benefits (as explained in the previous part). These benefits also accrue to the stakeholders.


Conclusion

The model presented shows how information and IT architects influence systems (new systems, changes in systems, and so on) and how they create benefits for the stakeholders. Ton Tijdink [1] goes even further in his article. Based on ATAM / CBAM he presents a way to determine the value (the perceived value by the stakeholders) of individual quality attributes. For an in-depth explanation (with a mathematical example) I refer to his article [1].


[1] Ton Tijdink. IT-architectuur en waardecreatie. Informatie, Oktober 2007.

[2] Kazman, R., M. Klein & P. Clements. ATAM: Method for Architecture Evaluation. Software Engineering Institute, Carnegie Mellon University, 2000.

[3] Kazman, R., J. Asundi & M. Klein. Making Architecture Design Decisions: An Economic Approach. Software Engineering Institute, Carnegie Mellon University, 2002.

[4] Nord, R.L. e.a. Integrating the Architecture Tradeoff Analysis Method (ATAM) with the Cost Benefit Analysis Method (CBAM). Software Engineering Institute, Carnegie Mellon University, 2003.

Be the first to comment!

Leave a Reply