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.