I took the course “Systems Architecture” from professor Edward Crawley at MIT back in 2001. Feeling, like most students, secretly unworthy of such an enormous academic setting, I prepared to pay strict attention and take copious neatly-formatted notes.
An intriguing story circulated about Dr. Crawley… a kind of urban legend whispered among students, referencing the rumored opinions of elite professors who we didn’t know and therefore couldn’t interrogate. Crawley was the department head of MIT’s Aeronautic and Astronautic Engineering Department. He was a world-class aerodynamicist and had published many widely read technical papers in the field. Research grants flowed into his department from all manner of government and private sources. The best students in the world wanted to study there. Professor Crawley was a leading light of knowledge in his area of expertise, as you might expect of a person placed in such a regal academic position.
But as the legend went: Professor Crawley was quietly coming off the rails. Questions of aeronautics no longer held any interest for him. His peers would describe some complex aerodynamic problem or solution, and Crawley would reply with something like “… it really doesn’t matter, does it?” His colleagues were concerned… they thought maybe he was losing his grip. As other professors dug deeper into the aeronautical mysteries of turbulence, hypersonic flight control, the outer layers of earth’s atmosphere and so forth, Crawley had “checked out” as a fellow student once told me. It was as if he just didn’t care anymore. “He’s cooked. He’s done.” That’s what they were saying.
Professor Crawley wasn’t done. But he was thinking differently. And in particular he was asking very different questions. Questions that had nothing to do directly with aerodynamics. Questions that were almost non-technical in their nature. Questions like:
- How can human beings work together across widely distributed teams of hundreds or thousands of individual persons?
- Who defines the processes to be performed by these massive teams, and how should we draw the divisions between them?
- Which pieces of the total thing should be gathered in one system and which should be gathered unto another system?
- How can we even truly define a “system”?
And so forth.
Sitting in the Systems Architecture course, listening to Professor Crawley’s lectures and taking notes, our cohort of students had a slow-motion realization. It was true: Professor Crawley had a new direction… and we were right in the middle of it. This very course in which we were sitting was a part of his new direction; a forum into which he carried these big questions for discussion and debate.
The lectures were messy, wandering, and fun. My neatly-formatted notes never materialized. I understood some of the course content but not all of it. And some of it I “understood” in an academic sense… and then re-learned a decade or two later on the job in a real-world practical sense. But no matter. I learned some good stuff. Really, really good stuff. Systems stuff, stuff that mattered, stuff I never forgot. Stuff worth repeating and re-using even now 20+ years later.
So: what was that “good stuff” exactly? I can remember five points in particular from that class, listed below and with future substack articles coming to expand on each one.
1. Systems engineering is ultimately a human exercise. The fundamental nature of systems is complexity which extends beyond the understanding of any single person. Therefore to build good systems, the communication and collaboration of multiple persons is required.
2. Engineers are educated to solve problems by digging deeper into technical details, which engineers are trained to understand. But systems thinking relies on thinking in the opposite direction: not diving into deeper detail, but abstracting information to an appropriate degree at a higher level. And that is a skill that engineers aren’t often taught. (For more on this idea see the Map of New York City Problem).
3. We assign names to abstractions; and that assignment of a name makes the abstractions real. The act of naming is a seminal act; an act weighted with great power but also fraught with difficulty. (For more on this idea, see the Osep Sensor problem <coming soon!>).
4. To design and implement complex systems, such systems must be “decomposed” or broken down into smaller pieces, simply so that manageable teams of people can work on them. The act of decomposing a system is a task of system architects and system engineers; it’s a conscious task to be performed purposefully. And there is tremendous hidden power in those decisions of how to decompose… power to enable great systems engineering, and power to screw it up in ways it can never be repaired. (For more on this idea see System Decomposition of the Chicken <coming soon!>).
5. Problems occur at the interfaces between systems or sub-systems. Often times these problems have the feeling of a “dropped fly ball”… each person just assumed the other person had it covered. Every interface is a chance for new problems. (For more on this idea, see Panel Gaps <coming soon!>).
***
Great systems thinking is comprised of much more than these five points. But these are a good starting point. Additional articles in this substack will deal with at least these five points of good systems engineering; and hopefully more over time.