Software Architect

Stable problems get high quality solutions

Book: 97 Things Every Software Architect Should Know
Publisher: O’Reilly Media
Author: Richard Monson-Haefel
97 Things Every Software Architect Should Know – 77/97

'Coz sharing is caring

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.

'Coz sharing is caring

By Swatantra Kumar

Swatantra is an engineering leader with a successful record in building, nurturing, managing, and leading a multi-disciplinary, diverse, and distributed team of engineers and managers developing and delivering solutions. Professionally, he oversees solution design-development-delivery, cloud transition, IT strategies, technical and organizational leadership, TOM, IT governance, digital transformation, Innovation, stakeholder management, management consulting, and technology vision & strategy. When he's not working, he enjoys reading about and working with new technologies, and trying to get his friends to make the move to new web trends. He has written, co-written, and published many articles in international journals, on various domains/topics including Open Source, Networks, Low-Code, Mobile Technologies, and Business Intelligence. He made a proposal for an information management system at the University level during his graduation days.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.