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 componentsand 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:
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.
"The Art of Systems Architecting"
Eberhardt Rechtin, Mark Maier
CRC Press, 1997