Systems architecture is the art and science of conceptual decision making. What is the best possible solution under the circumstances? (The circumstances are always uncertain.) Especially when the people considering the same problem often have disparate views of “best” and “possible”.
Amidst those disparate views, we need to build a strong case for a path forward, despite uncertainty. Alas, we rush to make things concrete. Then we get stuck in it. Now, our challenges have increased. Instead, we can settle into uncertainty, articulate the differing ways of looking at the challenge. How are they different? Why are they different? We can work towards a well-reasoned case for a solution — even though we can be certain we are right. Even when we don’t all agree.
If you can’t (yet) make a case for a solution, you (probably) don’t understand the problem well enough yet.
We can’t avoid making interdependent and interrelated decisions. We hope to make logical and consistent decisions that encourage interdependence and interrelating between parts. In the people and the software system. More often, we make silos and play politics and the system suffers for it.
Fred Brooks says that conceptual integrity is “the most important consideration in system design.” The value is clear: the quality of our conceptual thinking becomes the quality of the system itself. How do they maintain conceptual integrity?
The antithesis to integrity, Brooks says, is a system with “many good but independent and uncoordinated ideas”. Isn’t that how many teams approach product development? Products that might seem, conceptually, independent but are, more and more often, a coordinated part of an emergent system.
The success of those systems depends on building bridges between business and technical strategy, architecture and implementation, product engineering teams and other product engineering teams. To do this, we stretch our thinking beyond specific technology solutions, into the world in which the problems exist. We seek first to understand the real problems (they are never what they seem in systems.) Then become very, very good at making a strong collaborative case for how to solve those problems.