When can we consider a given software architecture to be of high quality? Is there a unique, formalized answer that allows to build some kind of tool in the future that would just analyze an architecture description and measure its quality. One possible approach is to judge software architecture quality in terms of the requirements it meets with respect to the original goals and constraints of the software system under construction. If, for example, security was one of the original goals then a software architecture without any security-related entities would definitely not be called a good software architecture. With other words, quality of a software architecture is always relative to the problem going to be solved. But what about a problem specification that introduces contradicting, missing or vaguely specified requirements? Have you ever heard about the Garbage-In-Garbage-Out rule. A software architecture can only be as good as the problem specification it is based upon. Thus, software architecture quality can be considered as the fulfillment of a consistent and complete problem specification. One conclusion that can be drawn from this is that using metrics to measure software architecture quality does not make any sense. In addition, the precondition of a complete and consistent problem specification does not necessarily mean that you'll have to have such a specification when your project starts. Rather it implies that you should apply an agile method where the problem specification can possibly be refined anytime and the architecture must then be refined accordingly. Is that all that's important with respect to software architecture quality? What about readability and maintainability? Even if your software architecture can currently balance all existing forces, it might not be capable of addressing future requirements. Take remoting middleware as an example. Although .NET Remoting or Java RMI are excellent solutions for building business applications, they are quite unusable for the construction of embedded, real-time systems. How would you change RMI to support that kind of systems. You propably would have to completely re-engineer RMI. So, what? We are still on the right track, if we consider developmental qualities such as extensibility and maintainability as required parts of the problem specification. Unfortunately, the problem domain itself can be so complex that it is almost impossible to come up with a complete and consistent specification.
But there is even more. From my viewpoint, there some meta-qualities exist that are often ignored in requirements engineering. For example, symmetry and orthogonality. If the same problem occurs in different parts of your system your architecture should reveal the same solution in all of these parts. If different solutions are used for the same problem, understanding the architecture will be significantly more complex as you have to deal with more solution concepts. If the solutions are patterns that basically means: don't use different patterns to solve the same recurring problem except if there are very good reasons. Should we now try to increase pattern intensity for all of software systems we are going to build? I remember a guy talking to Erich Gamma and me on a conference in Vienna a few years ago. He told us that in his software system he has applied ALL patterns of the GoF book. Suppose, what our reaction was. Pattern density is not necessarily a sign for good software architectures.
Two of the most difficult issues in software architecture design are still unresolved:
- What is the right structuring of a system. What granularity should one use? How many layers of abstraction or indirection are good or bad?
- How could we systematically inject operational and developmental qualities in a software architecture?
Unfortunately, there are myriads of ways to solve the same problem. And among them are still myriads of good solutions. One reason for this is that many cross-cutting concerns appear in software design, Thus, it turns out to be impossible to decide exactly and determistically what entities we should interweave, which ones to separate, and what kind of relationships to introduce between them.
Nonetheless, there are good and bad smells. For example: Experienced programmers will recognize whether a software architecture reveals specific properties such as symmetry. They will understand whether a given structuring is good or bad.
Maybe, this illustrates that software design represents a combination of different areas: engineering, science, and art. It reveals some mathematical aspects but in the end intuition and experience are equally important. As a consequence, outsouring software architecture design is always a bad idea.
In other words, being a good software architect is what you should strive for.
No comments:
Post a Comment