Architecture

What's an architect?

Architect:

from Greek arcitektwn,
from arci chief
    (cognate with arc-ein    to begin, to take the lead)
+   tektwn    builder, craftsman

“It is the sole purpose of the specification to act as an interface between the system’s users and the system’s builders. The task of ‘making a thing satisfying our needs’ as a single responsibility is split into two parts: ‘stating the properties of a thing, by virtue of which it would satisfy our needs’ and ‘making a thing guaranteed to have the stated properties.’ Business data processing systems are sufficiently complicated to require such a separation of concerns.”

— Edsger Dijkstra, professor

“What gets measured, gets done”

— Gerhard Schulmeyer, CEO

Current best practice in information system architecture is the development of a system architecture by this process: start with a set of requirements, propose a design, evaluate it to see how well it meets the requirements, and iterate to improve the design.

That is, software architecture remains one of the useful arts, rather than a practice with a well-defined, straightforward process for producing good results.

The architecture of a system is: a high level, long term set of requirements; a specification of the parts and connectors of the system and the rules for the interactions of the parts using the connectors; and a demonstration that the specification meets the requirements.

An architecture is a specification that is made from two points of view: the use of the system and its design. Use of a system means employing it to a purpose: so that the owner profits from the practical advantage and intended effect of the system. The design of the system is evaluated to ensure that it delivers the intended effect and results in the practical advantage desired by the owner and users.

............

Terms used
Since the terms that name some of the central concepts of this document are used by different speakers and writers with many different meanings, these definitions are provided to make clear what this document means by the terms:

architect (of an information system) a master system-builder; a skilled practitioner of the art of building systems, whose job it is to prepare the design of the system, and exercise a general superintendence over the course of its construction; a craftsman who begins and takes the lead in the design of the system and oversees its construction.

architecture [in computing] "the conceptual structure and overall logical organization of a computer or computer-based system from the point of view of its use or design; a particular realization of this." An architecture contemplates both the use of the system and the design to make possible that use.

architecture (of an information system) [as used in this document] a high level, long term set of requirements for the system, a specification of the parts and connectors of the system and the rules for the interactions of the parts using the connectors, and a demonstration that the specification meets those requirements.

use noun "the act of employing a thing for any (especially a profitable) purpose."

purpose "practical advantage and intended effect."

design "a plan according to which things or parts of a thing ... are to be arranged." A design may be conceptual or detailed, overall or for a particular part.

model "an architect's set of designs…"

abstraction the result of "the process of suppressing irrelevant detail to establish a simplified model."

blueprint "a detailed plan …" a blueprint is the most detailed specification, which does not suppress detail necessary for construction.

framework "A structure which serves as an underlying support or skeleton, or of which the parts form an outline or skeleton not filled in."

architecture framework (for an information system) An (often abstract) semi-finished architecture intended to be completed. An architecture framework defines the design for a family of architectures and provides (some of) the basic parts to create them. It also defines the parts of itself that must be adapted to achieve a specific functionality.

Purpose and problems of architecture

In large scale system integration, there are many hardware and packaged software parts, and it is necessary to divide the work of developing the custom software also into parts. The purpose of architecture is to ensure that the parts of a system work together to meet the requirements. The intended effect of having the architecture of a system drive the project of building the system is that the parts will fit together better and with less problems. The practical advantage of this is that it allows earlier delivery, at lower cost, of a better system.

The architect preparing a design that will accomplish this purpose is faced with a number of problems. There is an endless space of possible designs. The architect must make design choices and then somehow evaluate those choices in light of the requirements. This means deciding what effect the choices will have on the construction and use of the system.

The whole architecture

Dijkstra tells us the "sole purpose of the specification [in our case, the architecture] is to act as an interface between the system's users and the system's builders." On one side of this interface the architect helps the owner and users to state "the properties of a thing, by virtue of which it would satisfy [their] needs;" on the other side the architect helps the developers to make "a thing guaranteed to have the stated properties."

What gets measured, gets done.

The way to get work done well is to set the goals for the work and to measure the result of the work against the goals. To do this with the architecture work, we must state the requirements the architecture is intended to meet, do the work, and then measure whether the result meets the stated requirements.

So, I define the architecture of a system to be a set of requirements for the system, a specification of the parts and connectors of the system and the rules for the interactions of the parts using the connectors, and a demonstration that the specification meets those requirements.

Note that I say "a set of requirements." This is not the entire set of all the requirements of the owner and users, stated in full detail. It is the set of requirements the architecture is designed to meet. The architecture is an abstraction of the complete system specification (the blueprint), and this set of requirements is an abstraction of the complete requirements.

In the process of refining an architecture, a refined set of requirements will sometimes be needed for next iteration. In some cases this will be a more detailed set of requirements. But, there is also a feedback from the architecture to the requirements, as the architecture sheds light on the clarity, precision, and completeness of the requirements, and on alternate approaches to fulfilling the purpose of the system. In such cases, the needed refined set of requirements will not be more detailed, but improved in other ways.

Building an architecture

Every project needs a process and tools for building the architecture of an information system.
Here 'architecture' refers to the chosen set of requirements, the high-level design decisions about the information system that remain valid in the long term (for years), and their evaluation. I use it in contrast to short-term tactical decisions (such as details of information, implementation techniques, and choices of technology).

Examples of the distinction: An architecture may provide a mechanism for variation in information details. A design may be implemented using different techniques. The information variation mechanism and the design are long term decisions. The selection of the information details and the particular implementation may be tactical decisions. As basic building blocks of information systems become commodities, technology, vendor, and product selection also become tactical decisions that may change from year to year.

............

That's all for now.

home