Category: Software Architect

As an architect we want to know how good the software is that we are developing. Its quality has an obvious external aspect, the software should be of value to its users, but there is also a more elusive internal aspect to quality, to do with the clarity of the design, the ease with which we can understand, maintain, and extend the software. When pressed for a definition, this is where we usually end up saying “I know it when I see it.” But how can we see quality?

In an architecture diagram little boxes represent entire systems and lines between them can mean anything: a dependency, the flow of data, or a shared resource such as a bus. These diagrams are a 30.000ft view, like a landscape seen from a plane. Typically the only other view available is the source code, which is comparable to a ground level view. Both views fail to convey much information about the quality of the software, one is too high level and the other provides so much information that we cannot see structure. Clearly, what is missing is a view in between, a 1000ft view.

This 1000ft view would provide information at the right level. It aggregates large amounts of data and multiple metrics, such as method count, class fan out, or cyclomatic complexity. The actual view very much depends on a specific aspect of quality. It can be a visual representation of a dependency graph, a bar chart that shows metrics at a class level, or a sophisticated polymetric view that correlates multiple input values.

Manually creating such views and keeping them in sync with the software is a hopeless endeavor. We need tools that create these views from the only true source, the source code. For some views, a design structure matrix for example, commercial tools exists but it is also surprisingly easy to create specialized views by combining small tools that extract data and metrics with generic visualization packages. A simple example would be to load the output from checkstyle, which is essentially a set of metrics on the class and method level, into a spreadsheet to render charts. The same metrics could also be shown as a tree-map using the InfoViz toolkit. A great tool to render complex dependency graphs is GraphViz.

Once a suitable view is available software quality becomes a little less subjective. It is possible to compare the software under development with a handful of similar systems. Comparing different revisions of the same system will give an indication of trends while comparing views of different subsystems can highlight outliers. Even with just a single diagram we can rely on our ability to spot patterns and perceive aesthetics. A well-balanced tree probably represents a successful class hierarchy, a harmonious set of boxes might show code that is organized into appropriately sized classes. Most of the time a very simple relationship holds: If it looks good it probably is good.

97 Things Every Software Architect Should Know – 27/97

I know, there really is an ‘i’ in architecture. But it‘s not a capital ‘I’, calling attention to itself, dominating discussion. The lower-case character fits neatly within the word. Its there only because it fulfills requirements for proper spelling and pronunciation.

How does that relate to us as software architects? Our egos can be our own worst enemy. Who hasn‘t experienced architects who:

• Think they understand the requirements better than the customers.
• View developers as resources hired to implement their ideas.
• Get defensive when their ideas are challenged or ignore the ideas of others.

I suspect any experienced architect has fallen into at least one of these traps at some point. I‘ve fallen into all of them and learned painful lessons from my mistakes.

Why does this happen?

• We‘ve had success – Success and experience build self-confidence and allow us to become architects. Success leads to bigger projects. There is a fine line between self-confidence and arrogance. At some point the project is bigger than our personal ability. Arrogance sneaks in when we cross that line but don‘t know it yet.
• People respect us – Tough design questions provide a critical safety net. Our own defensiveness, arrogance, or emphasis on our experience can result in missed design questions.
• We‘re human – Architects pour themselves into each design. Criticism of your creation feels like criticism of you. Defensiveness is easy. Learning to stop it is hard. Pride in our accomplishments is easy. Recognizing our limitations without conscious effort is hard.

How do we avoid it?

• Requirements don‘t lie – With correct, complete requirements, any architecture that meets them is a good one. Work closely with the customer to make sure you both understand the business value each requirement provides. You don‘t drive the architecture, the requirements do. You do your best to serve their needs.
• Focus on the team –These are not just resources; they are your design collaborators and your safety net. People who feel unappreciated usually make a poor safety net. It‘s the teams‘ architecture, not yours alone. You provide guidance but everyone does the heavy lifting together. You need their help as much or more than they need yours.
• Check your work – The model is not the architecture. It is only your understanding of how the architecture should work. Work with your team to identify tests that demonstrate how the project‘s architecture supports each requirement.
• Watch yourself – Most of us fight our natural tendencies to defend our work, focus on our selfish interests, and see ourselves as the smartest person in the room. Pressure pushes these tendencies to the surface. Consider your interactions for a few minutes every day. Did you give everyone‘s ideas the respect and acknowledgement they deserved? Did you react negatively to well meaning input? Do you really understand why someone disagreed with your approach?

Removing the ‘I’ from architecture doesn‘t guarantee success. It just removes a common source of failure that‘s entirely your fault.