The obsession with architecture in software development is straining credibility to the extent of absurdity. There are serious problems with the notion of architecture as used in the software development community.
1. The Architecture Layer is Arbitrary.
The software design is the totality of design choices that have been made, where a design choice assigns a specific property to the design artifact. We can separate these choices into levels of abstraction to promote cognitive economy. When we chose to call one of these levels the architecture layer, we divide design decisions on an arbitrary, undefinable line, labeling some “high-level” and others “low-level.” Creating this false dichotomy can blind us to the true nature of the task and our solution, and hide the fact that…
2. All Design Levels are Interconnected
Whatever way you divide your design decisions into levels, these levels are all still interconnected. Decisions at one level can affect decisions at other levels. Therefore, if you ignore “low-level” considerations while designing at the Architecture level, your design may be horribly flawed.
For more on this point, see Steve Reeves’ essay, Code as Design.
3. Architecture Diagrams Are NOT the Spec
For reasons I do not understand, software developers talk about architecture diagrams as if they are the system specification. Drawing an analogy to engineering, they argue that their diagrams are the blueprints, and programmers are the construction workers who build the product from the blueprints.
Programmers = construction workers is a false analogy.
Construction workers don’t make design decisions. Programmers do. If the spec were so complete that it were machine executable, we wouldn’t need programmers at all. But it’s not, so we do. Programmers are designers. The code is the spec. The compiler is the construction worker. Architecture diagrams are just analytical models to assist the programmers.
4. Top-down Design is Idealistic
While not all architecture is derived from a top-down process, architecture is central to top-down design. In my own experience (obviously I can’t generalize, but take this as you will) the people who most advocate architecture are the same people who advocate top-down design, and the two ideas are closely linked for them.
Top down design can’t work, not even in principle, if you don’t fully understand the problem you’re trying to solve.
If you simultaneously understand the problem at hand, and the forces and variables you have to manipulate to solve that problem, and the relationship between the problem and those forces and variables, then you can derive a solution systematically from the top down. Unfortunately, this never really happens outside toy problems and math class. In the real world, we have to figure things out as we go, and this need for discovery undermines the validity of a top-down strategy.
In summary, the concept of software architecture is not wrong as much as divorced from the reality of development. At its core, architecture is an arbitrary, false dichotomy that obscures a multilayer design into two fuzzy, aggregate layers, obfuscating the complex network of interdependencies and encouraging a doomed top-down strategy, while masquerading as specification – a role for which it is manifestly inadequate.
Related articles: Service Oriented Architecture is your Ticket to Hell
Note: If you are a tech-savvy writer with a nose for B.S. and you’re interested in writing a column for The War on Bullshit, please leave a comment and we’ll get back to you.