Category: Software Architect

An architect‘s job is often portrayed as an activity focused on ingenuity and problem solving. Ingenuity is a key trait of successful architects. However an equally important characterization of the activities of a successful architect is ‘diligence’. Diligence can manifest itself in many ways, but ultimately it is an exercise in perseverance and paying the right amount attention to each task and each architectural goal of the system.

Diligence goes hand in hand with the mundane. Successful architecture practices are in many ways mundane. Effective architects often follow mundane daily and weekly checklists to remind them of that which they already know academically, but fail to practice by habit. Without such mundane checklists and reminders architects can quickly fall into software time, in which no measurable progress is achieved because a lack of diligence allowed the architecture to meander and violate known academic principles. It is important to realize in these retrospectives of failed projects that in most cases it isn‘t incompetence that drove failure, but rather the lack of diligence and a sense of urgency.

Diligence also requires an architect to succeed at the deceptively simple task of making and keeping commitments. These commitments are often disparate and can encompass a wide range of constraints and expectations. Examples include:

• Embracing the budget and time constraints of the customer
• Performing all the work that makes the architect effective, not just the work the architect enjoys.
• Commitment to the process/methodology
• Accepting responsibility

Atul Gawande, in his terrific book ‘Better: A Surgeon‘s Notes on Performance‘ , speaks of diligence in the medical community:

“True success in medicine is not easy. It requires will, attention to detail, and creativity. But the lesson I took from India was that it is possible anywhere and by anyone. I can imagine few places with more difficult conditions. Yet astonishing success could be found … what I saw was: Better is possible. It does not take genius. It takes diligence. It takes moral clarity. It takes ingenuity. And above all, it takes a willingness to try.”

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.