What “architecture” means to a systems engineer, and the man who helped us understand it

A few weeks ago while I was talking with a longtime colleague, we found ourselves discussing model-based-systems engineering terms. The conversation centered on exactly what needs to be defined up front in any project to avoid misunderstandings. It would be beneficial if every group beginning a project had this discussion, and then later, as the project matures, one can regroup and ensure that everyone is still on the same page, redefining terms if need be. As our discussion progressed, the one term that kept coming to the forefront was “architecture.” In today’s post, I present definitions for this term, and reflect on the legacy of one of the first system engineers, a man who coined terms that now define our profession.

My colleague and I spent an inordinate amount of time talking about the term “architecture” and coming to terms about what it really means. As an elected official in a rural community looking to see good growth and development within our locality, I get to see more than my fair share of both building plans and site plans. I know firsthand there are some really good architects and then some really bad ones, which leads me to ask sometimes in frustration, “Do we really need an architect for this? A first grader could have done a better job!”

What do we mean when we say “architecture”?
“Architect” and “architecture” certainly mean something different in the building and construction industry than what we as systems engineers mean when we use the terms. It never hurts to look back at where the nomenclature came from and follow the origins of the term. In fact, this can serve as a reminder of the evolution of our profession.

Let’s browse some dictionaries to get a feel for the variety. We’ll start with Dictionary.com. This is their definition of “architecture”:

architecture

[ahr-ki-tek-cher]

noun

1. the profession of designing buildings, open areas, communities, and other artificial constructions and environments, usually with some regard to aesthetic effect. Architecture often includes design or selection of furnishings and decorations, supervision of construction work, and the examination, restoration, or remodeling of existing buildings.
2. the character or style of building:
   the architecture of Paris; Romanesque architecture.
3. the action or process of building; construction.
4. the result or product of architectural work, as a building.
5. buildings collectively.
6. a fundamental underlying design of computer hardware, software, or both.
7. the structure of anything:
   the architecture of a novel.

And, this is how The American Heritage Dictionary of the English Language defines “architecture”:

ar·chi·tec·ture (är-kĭ-tĕk′chər)

n.

1. The art and science of designing and erecting buildings.
2. Buildings and other large structures: the low, brick-and-adobe architecture of the Southwest.
3. A style and method of design and construction: Byzantine architecture.
4. Orderly arrangement of parts; structure: the architecture of the federal bureaucracy; the architecture of a novel.
5. Computers The overall design or structure of a computer system or microprocessor, including the hardware or software required to run it.
6. Any of various disciplines concerned with the design or organization of complex systems: enterprise architecture.

This last definition is from The Free On-line Dictionary of Computing (27 SEP 03):

<architecture>

Design, the way components fit together. The term is used particularly of processors, both individual and in general. . . . It may also be used of any complex system, e.g. “software architecture,” “network architecture.”

I think we can agree that many of the first listings in the definitions above can easily be classified as relating to the physical construction of buildings.

These two pictures show a style, a design, a structure, a plan, an instantiation, and a product, and can be developed from a set of blueprints. They are a classic representation of basic building architecture.

So far, so good, but this is not exactly model-based systems engineering! We can, however, get there from here. All architecture is an art, whether building a system or working on a set of blueprints. Let’s look at how the term “architecture” became part of the systems engineering dialog.

The Father of Systems Engineering: Eberhardt Rechtin
The “Father of Systems Engineering” was a gentleman named Eberhardt Rechtin. Rechtin’s career spanned the 1950s, 1960s, and 1970s. He coined many terms, and was the first to formally introduce “systems engineering” as a discipline. He also coined the term “system(s) architecture” between 1956-1958. He was making the point that there are many ways to build a house. What distinguishes one from another is how you design the house, and this creative act of design is frequently called architecture. By analogy, when you are building a system or component; there may be many different approaches. Ultimately the head engineer must make judgment calls on how to build the system or component in question, and select a style and approach. Rechtin called the design approach a “to be” and named it a “system architecture,” acknowledging full well that there may be many alternative styles and approaches that could be chosen.

Rechtin influenced an entire generation of engineers—especially during the space race. NASA’s Apollo program was one of the most complex engineering challenges of all time, and required a particular type of thinking to manage the complexity of a massive system of systems that culminated in the Saturn V rockets. Rechtin also worked for the U.S. Navy and influenced young engineers like the now renowned Navy officer Lt. Jerry O. Tuttle. (More on him in a bit.)

U.S. Navy Influence
Prior to 1984, the U.S. Navy had a program in the Office of the Chief of Naval Operations (OPNAV) to set requirements for the Navy’s System of Systems, and an overarching acquisition organization called the Navy Materiel Command (NAVMAT). This ensured that the Navy’s System of Systems was built and fielded in a coherent and deliberate manner. In 1984, Secretary of the Navy John Lehman disestablished NAVMAT and deactivated the OPNAV offices to manage the Navy’s System of Systems. By 1985, Jerry O. Tuttle, now a Rear Admiral, created the Navy’s Warfare Systems Architecture and Engineering (WSA&E) effort, operating out of a newly created office called Space and Naval Warfare Command Code 30. Tuttle wanted the U.S. Navy’s technical and acquisition communities to apply a systems engineering approach in order to gain exceptional expertise in the systems architecture (design, style and approaches) of complex systems of systems. (Unfortunately, upon Rear Adm. Tuttle’s retirement, without strong advocacy, the WSA&E effort went into rapid decline, was re-organized by 1991, and had its funding terminated by 1993.)

Many of the same engineers working in WSA&E were instrumental in drafting the Command, Control, Communications, Computers, Intelligence, Surveillance and Reconnaissance (C4ISR) Architecture Framework in the late 1980s and early 1990s. The C4ISR Architecture Framework version 2.0 was re-written and became the DoD Architecture Framework. (See the Wikipedia article on this topic.)

This is the DoD Architecture Framework in use today. This is also the same DoD architecture instantiated in Vitech’s CORE and GENESYS software.

Since we are now in my realm of the definition of “architecture” and zeroing in on what most of the conversation between me and my colleague centered on, let’s look at the graphic below.

For those familiar with the Vitech schema, each domain has Architecture classes. The System side has classes called Components, Functions and Requirements. On the other hand, the Operational Architecture Domain is comprised of Classes such as Performer, Operational Activity and Capability. These Classes contain attributes and relationships. This structure is the basis of what I would term an architecture.

This schema chart in particular portrays architecture as having two sides, as we see the Operational side in blue and the System side in green. Note the Operational architecture side portrays what the systems should do, and the System Architecture side develops how it will be implemented as a system. This method provides a ready focus on what will be needed to implement the project.

Looking back over the course of my career, I have been handed many packages which clients were confident were the “architecture” I needed to complete a project. Due to continuing contradictions in terms and understanding, this could be anything from a data package to a collection of artifacts related to a previous creation or whatever they thought could make something happen. Many times, it was not nearly enough of what was needed. So I have come to realize that conversations about architecture can often be frustrating and circular, and that one must proceed with caution.

I have learned that it is best to clarify terms at the outset, and to check in as one goes along, to make sure everyone is still on the same page. If you do this, you will save a lot of time, you will gain the trust of your team and your stakeholders, and your project will be far less likely to be derailed on the way to its destination.