A few years ago, Joel Spolsky wrote an article on Architecture Astronauts. Essentially, it concerns the problem with abstraction: that at some point, the level of abstraction is so far removed from the actual work as to be meaningless. This article gets cited in blogs, posted on bulletin boards, hangs from walls, etc.
The article points out the foibles, but Joel's examples such as Java, XML, etc., have proven by 2004 to be good things. Architecture is a good thing. Needless abstraction isn't, but then, if XML and Java were too abstract and yet proved to be very good conceptually and in practice, even sharp guys can fail to recognize when an abstraction is needless versus when their own understanding is not yet matured to the point of appreciating the abstraction.
1. Without an architecture, development is ad hoc and duplicative.
2. Without an architecture, policies for procurement can't be created or enforced.
The reasons for abstraction should be more closely examined particularly if the implementation has to survive platforms. Abstraction if applicable often enables the designer to correctly predict where a system will need to be extensible. Abstraction enables concepts to be grouped dynamically and to share implementations. Abstraction reduces work and cost.
Knowing when an architecture is too abstract or too mundane, or in the sweet spot of reapplicable concepts is the trick. Where procurement and implementation meet, there must be specific knowledge of the task to be achieved. All true, but without the architecture, money is wasted and the project is seldom complete or mission-proficient. Without abstraction, one builds one-offs.
Code can come from anyone who learns coding. Architecture comes from those who learn to abstract. Invention comes of abstractions that scale and unify systems. Then it is time to code. Otherwise, it becomes 'cowboy coding' and in today's market, no one can afford it.
1 comment:
It's another case of the alpha-geeks who need some kind of endorphin rush protesting the obvious. What is dangerous is that this becomes part of the zeitgeist of implementor thinking, and then we have more code and less architecture. Architecture is valuable in design and in procurement but there is no one-size-fits-all requirement.
We see both ends of the exaggeration from the RFP that has a complete architecture-based design, and we hate these because they go too far into design and we don't build to each customer's architectural wants. On the other end is the RFP that has only high level descriptions of modules and we love these because they are easy to respond to and the real sale occurs in the demo. In the middle is the Gartner-style RFP that is heavily boilerplated and has a requirements matrix down to the field-level. These are OK even if tedious. Their problem is using boilerplate without actually analyzing the precise customer requirements. The end result is a proposal for modules the customer does not use and a higher price as a result.
So the question is, what part of a software lifecycle does the architecture inform? Depending on where one places that value, the level of abstraction and the utility of abstraction varies.
Post a Comment