Good Architecture?

What is it? Well, since you asked....

It's not code, coding style or convention, patterns, blah blah blah . NOT. Architecture precedes code.

TDD
Some argue in favour of TDD (test driven development). TDD will not cause the organic emergence of a good architecture. It will, however, delay development as you create and debug test cases, then refactor them as the application evolves. For an application of reasonable size and scope, and good test coverage, this becomes a significant burden. The only team which can benefit from TDD is one with a serious lack of highly experienced and talented people. Good architecture requires a fundamental understanding and broad experience within the problem domain (software, infrastructure, business, data, etc). It takes that rare individual with the right experience, knowledge, skills to develop a good architecture. To defer architecture to TDD is the implicit statement that your team has not a single person who can make a good design up-front.

Easy to explain
Is a good architecture one which is easy to explain to a colleague? If you said yes you were likely wrong. A pattern is easily explained, as is a simple algorithm, and all such smaller things. Architecture is no such beast. For a trivial app, one could argue the architecture is more easily explained, but then trivial apps don't really need "architecture" per-se. To explain an architecture, and in particular, a good one, is not going to be easy. However, it really depends on the skills, knowledge and experience of the person you are explaining it to. It also depends on the manner in which you explain. For example, complex architectures can be explained to high level business people by using the right abstractions, leaving out technical details, and focusing on key concepts at a high level. Furthermore, by explaining the benefits in a non-technical way, a non-technical audience can grasp your concepts and the reasoning behind the design. In this way, you have communicated how the business benefits from the core concepts which underpin the architecture; everybody wins.

On the other hand, a good architecture could be impossible to explain to developers. With such an audience, the tendency will be towards greater detail in the presentation. And developers tend to ask a lot of detail oriented questions, as well as motivational ones ("Why did you...?"). The problems here occur all too frequently because of developers who are either inexperienced, lacking knowledge, or otherwise unable to grasp higher order concepts for whatever reason. Often, inexperience leads to questioning the motivation for design concepts, arguing the futility thereof, etc. Also, a lack of broad industry experience will have developers focused less on reusable design concepts and more on direct scripting of requirements. A lack of knowledge of higher level platform options, design concepts and their usefulness, business needs, etc, will also be cause for developers to question, debate, and not see the benefits of a good architecture. Thus, a good architecture is not necessarily easy to explain; when it is, it is because it was done properly, and to the right audience.

Flexibility and Abstractions
A good architecture includes a software design that understands that requirements will change tomorrow and provides proper abstractions to permit various components to be updated/replaced ad-hoc. "Loose coupling" is one way to achieve this, but loose-coupling is not Architecture; it is one small tool in the tool-chest. It is also important to know how and when to inject abstractions. I have seen, for example, developers layer abstraction over abstraction, only to question why late in the project. This is perhaps a lack of experience, or an eagerness to pile in as many patterns as can be made to fit. A good architect, and thus a good architecture, recognizes the right time and place to apply abstractions, use meta-data, extract commonalities, and so forth. One imperative of good architecture is to remain somewhat distant from requirements while leveraging experience and the broader understanding, environment, etc. Finding the line between abstraction, flexibility, performance and achieving the business directives in an optimal way (time, effort, resources) is a key ingredient for the architect. A good architect can achieve both highest quality of architecture and minimal effort. This last statement tends not be believed, except by those rare few who've actually seen it happen.

The concept of "Minimal Assertion"
A good architecture is many things; among them, a good architecture is the minimal assertion which supports the business. This means that you understand requirements will change, you understand the load (user/cpu/disk/network/db) required, the infrastructure, interdependencies, the business need vs. want, the data model, etc. This is ultimately a long list. The minimal assertion architecture is one which supports all of these things properly. It's acceptable to have a piece of poorly written code, as long as it is properly encapsulated. For example, a small routine which implements some well defined interface may be sloppily written. It can either be cleaned up later, or replaced entirely with no impact to the project (beyond the time to do this task). The minimal assertion does not introduce concepts, patterns, interfaces, layers, optimizations, services.... that are not immediately required. It most certainly should be inspired by future needs and ensure they are easily integrated, or at least provide the path whereby this can happen easily enough. With enough experience, the architect can provide for current needs and the flexibility to change as requirements change while not introducing unnecessary elements into the design.

The limits of Architecture

Where software architecture gets sketchy (and I dare anyone to say they haven't had this debate with management!) is that at some point, it stops. It is the leading of the proverbial horse to water. There is a hand-off to developers. If the architecture documentation were detailed enough, developers would have little wiggle room to screw it up. To get to that point, the architecture would be as close to code as you could get and the design would get lost in the details. This is not a desirable situation for many reasons, and therefore, there is a gap. Between architecture and implementation we need to guide progress.

The same situation occurs when putting up large structures - the architect has to work closely with the builders and compromises are made to ensure a stable structure, the plumbing/electrical/hvac all works, building codes adhered to, etc. The guy swinging the hammer may not understand the architectural vision, but that's ok. The architect works with the team to ensure everything goes ok.

I would further assert that the architect then becomes the lead developer. This person did not become a good architect by reading books, it was instead through years of fighting in the trenches, learning from mistakes, building a large base of experience in all sorts of situations, by trial and error (or success), by pushing boundaries, reaching out, and always looking to make things better. There is no school of architecture, and that's where the construction analogy ends. If the architect can't speak the language of the developers, the project is at risk. And, as we've seen, the communication of the architecture may be challenging at times. Who best to actually create the more complex parts of the design than the architect himself? And for the less experienced architect, this is something that will lead to more experience; good or bad. There is no better way to know the outcome of certain decisions than by being at code level through the project and seeing directly the benefits, issues, and failures.

In this regard, management needs to be managed. All too often I've seen managers question how a lack of quality or other development issue is possible in light of a good architecture. They fail to understand that there is a gap, there must be a gap, and that gap needs to be bridged by the architect being a lead developer. Sometimes the issues arise out of a lack of skill on the developers' part. This is not a flaw in the architecture. Good architectures often elevate the productivity and quality of lesser dev's. However, the architecture alone will not prevent bugs, poor performance, mistakes in business logic or other problems. Once a developer is tasked with work, he alone must be held responsible for proper delivery. The architect is there to help; the architecture should be his guide (along with whatever else is available, such as use-cases). But when the developer fails, he does so alone. That is a strong statement, and I go back to the title of this rant "Good Architecture". When the architecture itself is flawed, the developer should not take the fall, but we're talking about Good architecture.

Metrics anyone?
Can we measure the quality of the architecture through the use of some metrics? My answer is no, but not a firm negation. The measurement must be made later in the project - after the architecture has been implemented. Can we do it before? Well, we can sit around and debate how we might do things differently, but it is all subjective at that point - I cannot imagine a pre-implementation metric. The problem with post-implementation metrics is narrowing the measurement in a way that excludes all other variables (this is the "scientific" approach). If management interferes (as they all too often do), or developers do not deliver according to expectation, or funding is insufficient, or the user load exceeds all expectation leading to capacity issues, or any of a million other variables affects the final outcome, then what metric can we use to judge the architecture alone? I usually consider the time to develop in association with scope. If we have developed rapidly the full scope of the project, I like to take credit for having a good architecture. However, this only happens when management is benevolent (or hands-off), there is sufficient talent in the pool of developers, and other reasonable conditions are met. Another metric I've heard is "does it meet business requirements?". This fails on so many fronts. Initial requirements are generally not what needs to be delivered, and therefore, nothing should be judged against them. We could measure against a finalized requirement, but if constraints such as time and/or budget force a de-scoping exercise, the business will not be happy with the result. This is not the failure of architecture, though in some cases it certainly could be. The uncertainty here makes this metric unreliable. Can we measure how easy it is to modify or maintain? Again, the quality of people and other environmental factors can affect this is very significant ways. There are many other examples I could give, but I'm trying to keep this short. The end result is that there are simply no metrics by which you can safely judge the quality of an architecture.

So....what is "Good Architecture"?
This has been one of my longer rants, and I've barely covered the topic. It would take perhaps an entire book to fully hash out what a Good Architecture is, and how to ensure you are driving towards one. There are many subtleties, as well as many obvious points to make. The topic spans not just software design but the full gamut of influences. Good Architecture must not be over-engineered or under-engineered. It should be quick and easy to develop (by the right people). It should be influenced by requirements, not created solely to meet them. And sometimes, just sometimes, a Good Architecture is not the right answer for a project.

Good Architect, Good Architecture
There is no simpler summary I can give here. To have a successful project, you need a critical mass of good people. For a good architecture, you need a good architect. This is a rare breed, rarely seen in the wild. Good luck!