and it was a nice article, but I politely disagree with Zman that "architecture is not arbitrary".
Lock 10 architects in 10 separate rooms; provide them all an identical copy of the same business, technical, process, and system requirements; have them design an architecture under the same rules and perspectives; and I guarantee your result will be 10 different architectures of varying degrees. Maybe my opinion is biased because I come from a Software background, but I often think Enterprise Architecture is an Art that is trying to apply a Science. No 2 architectures are identical. No 2 interpretations of how an Architecture should look like are identical. No 2 Architects think alike. Often times, Architecture is the art of compromise because rarely will you get to 2 architects to agree on the final architecture. Compromise is really hard for us, because we are traditionally very stubborn people! I've met many an architect whose ego is bigger than the Internet, and thinks he could teach a thing or 2 to Socrates. We don't like to be told we are wrong, especially when we develop a "work of art".
Maybe a better statement can be "architecture tries to make the design non arbitrary". With good architecture principles, patterns, frameworks, rules, constraints, standards, policies, procedures, and approach, the design becomes a simplistic exercise with little left to judgement, error, and becomes more a commoditized task. This is what I think architecture truly strives for-- making everything downstream trivial. Architecture lays the foundation for the remaining pieces to snap in very easily without much variance. Success is when the blueprint is followed according to plan!
The article continues to articulate how industry standards have played a role in making architecture non-arbitrary. This makes sense in certain vertical industries cited in the article such as airplane manufacturing, nuclear power plants, developing the Space Shuttle. However, it doesn't make sense in many commercial corporations whose architecture is centered and largely dependent on enterprise software .
Think about it-- Building an airplanes for Boeing or a nuclear reactor has very strict standards, specifications, and processes with little to no variance. However, building software has tons of variance and therefore industry standards are rarely adopted religiously in software implementation (unless you are in some thees industries mentioned above). There are some very simple reasons for this dynamic:
- Qualifications for building software are low. Low barrier to entry, commoditized work force, easy to learn software programming skills.
- QA requirements are much lower. Often times, it's "just enough QA" and many corners are cut and sacrificed so not to slow down the market plan.
- Time to Market patience is low. Software is expected to get deployed before its truly ready (and bugs are well known). Rapid is the name of the game, especially in today's economy.