Real-world programming is not about solving the problem that someone gives to you. In the computer science classroom you must solve the binary-sort problem it‘s given to you. In the real world, the best architects don‘t solve hard problems they work around them. The skill is in drawing boundaries around diffuse and diverse software problems so that they are stable and self-contained.
An architect should be able to look at a whole mess of concepts and data and process and separate them into smaller pieces or “chunks”. The important thing about those problem chunks is that they are stable allowing them to be solved by a system chunk that is finite and stable in scope. The problem chunks should be:
- Internally cohesive: the chunk is conceptually unified, so all of the tasks, data, and features are related
- Well separated from other chunks: the chunks are conceptually normalized; there is little or no overlap between them
The person who is excessively good at doing this may not even know that they are doing it, just as a person with a good sense of direction knows where they are. It just seems to make sense to them to break up the tasks, data, and features in a way that provides a nice edge or interface to the system. I‘m not talking about the actual interfaces of an object-oriented language, but system boundaries.
For instance, a relational database management system has a very nice system boundary. It manages literally any type of data that can be serialized into a stream of bytes and it can organize, search and retrieve that data. Simple.
What is interesting is that if the problem is stable then when it is solved, it is solved permanently. In five/fifty years time you might want to slap a web/telepathic interface over it, but your core system won‘t need to change. The system is durable because the problem is durable.
Of course, the code needs to be pretty neat, but if the problem is neat the code can be neat as there are no special cases. And neat code is good because it is easy to test and easy to review, and that means that the implementation quality can be very high. As you don‘t have messy code you can concentrate on things that are outside the domain of user-visible features like using reliable messaging, distributed transactions, or driving up performance by using multithreading or even low level languages like assembly code; because the problem isn‘t changing you can concentrate on driving up the quality to the point where quality is a feature.
A stable problem allows you to create a system with a stable design; stable design allows you to concentrate on making an application that has very high quality.
