Systems Architecture

[Systems] [Architecture] is the [art] and [science] of creating a [blueprint] for a [computer] systems implementation. It is a way to bring [coherence] and [organization] to complex systems [projects]. Systems architecture, while analagous to the [construction] industry, is rooted in the [aerospace] & [defence] industries where the huge technical advances in [aircraft] and [weapons] in the [1950's] and ['60s] led to greatly increased complexity in the [design] and construction [process]. The original systems architects were responsible for overseeing development of these complex [products] and were the "big picture" guys who kept track of all the major subcomponents and their [interfaces]. The computer [hardware] industry [adopted] and [adapted] this role for their needs and by the early 1990's the software industry recognized the need for such a role.

Systems architecture is usually described by referring to the [construction] [industry] and comparing the role of a systems [architect] to that of the traditional architect. The systems architect generates the [vision] for the system(s), specifies the major [components]and how these components are connected and passes the finished blueprints to the [systems engineer] for implementation. Similarly the traditional architect grasps hisher client's need and creates models and blueprints that a [civil engineer] can implement. For an amusing commentry on how the architecting process can go awfully wrong see the "Architecture Sketch" by [Monty Python].

The art of systems architecture is the understanding of the [business] [problem] and the selection and application of the appropriate [technologies] to that problem. As such the system architect must be conversant in the business of his or her client. The [science] of architecture is the specification of the [physical componentry] of the system and the [capacity planning] and [performance engineering] associated with that.

Systems architecture is commonly performed in two steps. The first step is usually referred to as the [conceptual] or [logical] architecture. Most [practitioners] accept a that this is a [service] based [model] that defines the architecture as a set of [components] commonly grouped into [layers] that deliver specified services. Some practitioners seperate conceptual and logical into two steps, but this is inefficient given the speed to delivery times in today's [market]. The second step is [physical] architecture where the components and services are [translated] into actual [hardware] and [software] that is properly sized and configured for its purpose. There is not necessarily a one to one relationship between logical components and services and the physical products.

Systems Architecture is made up of several [domains], how many is based usually on the personal preference or experience of the architect. The domain concept is simply a way of breaking down a complex problem into more manageable pieces. But the goal of the architect is to maintain an [integrated] and coordinated view across all the domains. My preference is for 6 domains:

[Application]
[Integration]
[Data or Information]
[Infrastructure]
[Security]
[Management] and [Administration]

In addition the architect must have sufficient knowledge of the business problem to ensure the various technologies making up the solution are correctly applied.

The architect must be [politically] aware in order to be able to sell the solution to various groups of [stakeholders].

The systems architecture should be measurable, despite the fact that it is a "paper" deliverable. There are several methods of ensuring measurability:

Principles based design: state the [principles] and [assumptions] on which the architecture is based and review the final architecture against these.
Quantify requirements: technical and business requirements should, in most cases be quantifiable.
Prioritize competing factors: force your client to choose between competing factors.
Test the architecture: although it is a paper deliverable an architecture can be tested by using high-level [use cases] or [scenarios].

One problem with the systems architecture discipline is the [devaluation] of the term systems architect. As the popularity of systems architecture grew in the software industry more and more people described themselves as architects. I have read resumes where [programmers] with less than 5 years experience describe themselves as systems architects. A true architect has a multi-disciplinary background covering several of the key domains of architecture, is at least knowledgeable about domains where he or she has no personal experience, and has appropriate business knowledge, plus the personal skills necessary to speak at board-level meetings. Such skills are not acquired without considerable experience.

There is a lot more to this topic but this is as far as I want to go with an opening [writeup].

Recommended Reading:

"The Art of Systems Architecting"
Eberhardt Rechtin, Mark Maier
CRC Press, 1997

Systems Architecture (idea)