![]()
The basic structure of a system is, by definition, its architecture. In this book, we describe a procedure for architecting a system. This procedure can be applied rapidly, is definitive, unambiguous, and critical to the process of preliminary system design.
For purposes of this treatise, there are two types of architects and two corresponding types of architecting processes. The first is the relatively widespread field pertaining to the architecting of buildings of various types. In this field we will see the prominent names and creations of the likes of Frank Lloyd Wright, Frank Gehry, I. M. Pei, and Mies van der Rohe. This type of architecting is distinctly not what this book is about.
The subject of this book is the other type of architecting, that which pertains to building systems. A short list of types of these systems includes:
ā¢ Defense systems
ā¢ Health systems
ā¢ Information systems
ā¢ Transportation systems
ā¢ Security systems
ā¢ Communication systems
ā¢ Human resource systems, and
ā¢ Space systems.
The body of knowledge that relates to the design, construction, and operation of such systems is generally recognized as systems engineering. This field has some 30 elements [1 ā Chapter 7], one of which is system architecting. Some practitioners equate system architecting with preliminary design, and we accept this notion as the focus of this book which answers the question ā what is the specific and recommended process by which one architects a system?
The Department of Defense (DoD)
Since the DoD is āin the businessā of building many of the types of systems cited above, it makes sense to take a look at what the DoD has done by way of developing methods and procedures whereby one architects these systems. Surely there is a single system architecting approach, established by the DoD, that would apply to all types of systems.
Back in the 1990s, the DoD started to work on this issue, within the C3ISR (command, control, communication, intelligence, surveillance and reconnaissance) community [2]. The evolved approach became the DoDAF, the DoD Architectural Framework. The centerpiece of this approach was the notion that there are three critical views of systems that must be considered, i.e.,
ā¢ The operational view
ā¢ The systems view, and
ā¢ The technical view.
These views were defined (approximately) as:
ā¢ The operational view addressed how the system would perform in an operational setting and environment.
ā¢ The systems view considered systems and interconnections to support warfighting functions.
ā¢ The technical view dealt with sets of rules with respect to the arrangement and interactions between system elements.
As the structure of DoDAF expanded with time, the DoD basically required those working on systems architecting to consider many more essential views such as those articulated below.1
AV ā 1: Overview and Summary Information
AV ā 2: Integrated Dictionary
OV ā 1: High-Level Operational Graphic Concept
OV ā 2: Operational Node Connectivity Description
OV ā 3: Operational Information Exchange Matrix
SV ā 1: System Interface Description
TV ā 1: Technical Architecture Profile
This made a lot of sense, in principle, and was in consonance with our tendency to ādrill down,ā once we have found a top-level structure that we find satisfactory to our needs. Since the three basic views remained mostly unchallenged in their contribution to an architectural framework, the more one defines and drills down from there, the better. Or so it seems.
There are several unanswered questions and areas of concern with respect to the DoDAF approach. These are addressed mostly in Chapter 9 which is devoted to a more-in-depth consideration of DoDAF. For now, we will consider it a very important building block in the system architecting process, as formulated by the DoD.
Eberhardt Rechtin
A prominent position in the field of system architecting was established by the master engineer, Eberhardt Rechtin. Indeed, he wrote what this author would consider to be the seminal work in the field [3]. Here are some of the important points he made in his book:
ā¢ There are basically four approaches to the process of architecting, namely normative, rational, argumentative, and heuristic.
ā¢ Heuristics are very important in terms of designing and building new systems. One of the most important is the KISS (keep it simple, stupid) approach, and Rechtin includes a whole Appendix on his list of heuristics.
ā¢ ā[T]he greatest architectures are the product of a single mind.ā
ā¢ It is important, also, to focus especially on boundaries and interfaces.
ā¢ Itās also necessary to place extreme requirements under constant challenge.
ā¢ āThe essence of architecting is structuring, simplification, compromise and balance.ā
ā¢ Prototyping plays an important role in designing and building the best possible system.
Beyond Rechtinās work cited above, he later teamed with Mark Maier [4] to continue ground-breaking explorations of the field of architecting and related matters. Here are three noteworthy quotes from that book:
āarchitecting is creating and building structuresā
āthe foundations of systems architecting are a systems approach, a purpose orientation, a modeling methodology, ultraquality, certification, and insightā
āone insight is worth a thousand analysesā
Author Information
Going back into the 1970s, this author worked on several large-scale systems in the fields of defense, space, and transportation. Preliminary design, equated here approximately with system architecting, was a topic of great interest. Indeed, moving some 40 years down the road to todayās world, interest has increased as we try to build cost-effective systems within changing, and often confusing, system acquisition environments and procedures.
The essence of a recommended system architecting process has evolved over the years and has been described, in some detail, in this authorās book in 2008 [1]. This process has been tested hundreds of times through the efforts of this authorās graduate students in systems engineering. Later chapters in this book provide further rationale and additional detail that is appropriate to a definitive system architecting process.
Three Special Experiences
Nimbus
One of the systems worked on by the author, going back to the 1960s, was the Nimbus meteorological satellite. This was a follow-on to the TIROS system, and was managed by the Goddard Space Flight Center of NASA. Unlike TIROS, which was a āspinner,ā Nimbus was a three-axis stabilized system that ālookedā down at the Earth from about 450 nautical miles in space. Although there were many lessons learned from participating in this program, it was first noted that Nimbus had a variety of subsystems, such as stabilization and control, structure, thermal control, communications and data handling, and various measurement instruments that constituted the payload. It was noted also that these subsystems approximately corresponded to the āfunctionsā to be carried out by the satellite system.
Mallard
Also in the 1960s, this author had a role on a communications system known as Mallard. This was a tactical communications system that was managed by an Army facility at Fort Monmouth, New Jersey. Mallard was a quite sophisticated battlefield communications system and this author was a sub-contractor on the GT & E/IBM team. GT&E was the prime contractor and took the lead in all systems engineering and architecting activities. Special attention was paid to the architecting approach. First and foremost, the architecting team set forth a detailed āfunctional decompositionā of the Mallard system. They then proceeded to design each of ...
