In one of my recent training classes I was asked to define what the term “architecture” means in the practice of system engineering. While I think I solve the immediate concern of the class, I did not give a very precise answer. This week I did a bit of research from my library to craft a better answer to this question. The primary resources for my search were: “The Art of Systems Architecting,” 3rd Edition, by Mark W. Maier and Eberhardt Rechtin and, “Systems Engineering Principles and Practice,” 2nd Edition, by Kossiakoff, Sweet, Seymour and Biemer. Most of us know these textbooks as formative publications referenced by many system engineering practitioners.
“Systems Engineering Principles and Practice” discusses Architecting in Section 8.8. The main point that stands out to me in this chapter is the distinction between system architecting and design engineering. The authors make a point of stating that system architecting is based on inductive processes to refine system operational and functional models and drive the system fundamentals to a specific purpose. Heuristics play heavily into the architecting process and influence the architecture.
The authors go on to compare system architecting to design engineering by stating that design engineering is based on deductive processes. The design engineer focuses on the physical understanding of the detailed system and with quantitative measurement, as opposed to qualitative principals handled by the system architect. To this end, the design engineer deals more with analytical tools to conduct analysis of systems performance which confirms or corrects/improves the architect’s design.
The architect and the design engineer activities are closely coupled and doing either without the feedback and information from the other’s activities will likely not result in an optimum system design.
The idea that heuristics plays a prominent role in the architect’s efforts has always bothered me a bit because this seems to not be well defined. However, in reviewing “The Art of Systems Architecting,” my attention was drawn to Chapter 2, which is titled as “Heuristics as Tools.” Among many things in this chapter the authors detail a select set of heuristics from a University of Southern California graduate course in System Architecting. The top four heuristics from the list, paraphrased by me, are:
1. Don’t Assume the original problem to be the best, or even the right one.
2. Wherever possible, when partitioning a system, choose elements so that they are independent, with as low an external complexity as possible. (Which allows the complexity to be contained with a partition to be dealt with much easier at the next lower level.)
3. The eye is a good architect – so believe the drawing or model; if it doesn’t see or feel right, then it most likely needs to be simplified.
4. Don’t eliminate options too early. If the system is complex, you will sooner or later, need to exercise an option in the design.
These four heuristics lead me back to good system thinking practices and reinforce basic principles of our STRATA™ methodology. Namely, to approach the design from a systems perspective and complete the design in a layer by layer approach. Applying these heuristics in each layer will help us to design better systems, and something I will apply in my future classes.
I also re-learned a valuable lesson, that I need to take time every now and then to do some research and reading on system engineering. I don’t learn everything I should from the first reading, and each time I re-visit something in textbooks, I take away something new.
