Here’s a repost of something I wrote about 4 years ago. I think it still applies.

 

This is my first take at some thoughts on Architecture that have been swirling in my head for many years. Much of this comes from my experiences and the vast knowledge and wisdom of my many architecture friends & colleagues.

The ten deadly sins below summarize many of the common mistakes I’ve seen (and made) in system/software/application architecture over the past 20 years. These traps can be just as fatal as the typical software project management mistakes. The 10 are (by title):

1. Pursuing “Holy Grail” Architectures
2. Set in stone: Fixed Architecture
3. Materials-Free architecture
4. Architecture as first-order goal
5. Architecture by Edict
6. Spray-on architecture
7. “MIT Layer Syndrome”
8. One-size fits all
9. Instant Architecture
10. Pattern Madness

I’ll summarize each of these below and (if I get to it) try to post a more detailed essay on each. Actually, I’d love if others could chime in with their own experiences to support these sins, debunk them, or add new ones. Note that these sins are related to architecture, not just technology or software development.

1. Pursuing “Holy Grail” Architecture

I’ve seen many projects where the architect or designer is targeting a perfect architecture, an ideal state of design. Often this takes the form of a specific architectural target, such as Unlimited scalability, a perfectly abstract object design, a perfectly normalized database, or complete platform independence. Another form of this sin is complete focus on a single architectural design concept, such as Service-Oriented Architecture, or Thin-Client. (“If we implement SOA, we’ll have complete flexibility!”)

2. Set in Stone: Fixed Architecture

This one really annoys me: designing/implementing an architecture with the assumption that it will never change or need to change once deployed. Even worse are architects who assume their architecture design will not change (nor need to) throughout its implementation and deployment. Good Architecture must assume some aspects of change (if not accommodate change). Heck, even a building’s architecture changes over time. One of the best architects I’ve ever worked with describes system architecture more akin to landscaping (rather than building design), as the architects role is to design an evolving, living system.

3. Materials-Free architecture

Software architects love the abstract. Often this love is at the expense of reality. It’s easier to come up with a great architecture if you don’t have to consider the realities of the materials used to implement it. By not considering the building materials, you end up with conceptual great architectures that can still fail because of the materials, like the Titanic’s brittle hull plates. Architecture designs are only hypotheses until they are tested through actual systems.

Don’t, however, think that I’m proposing the opposite: that architecture is entirely driven by materials. Quite the contrary. Materials by themselves make for lousy (or accidental) architectures. It is good architecture design that enables the best use of the materials and build around their limitations. Moreover, architectural practices enable us to change the materials over time. Just don’t expect the architecture to overcome all limitations of the materials.

4. Architecture as first-order goal

Why does the system architecture exist? Unless you’re working with Grant money, it shouldn’t be the architecture itself. Too often architects make the architectural design the goal of the project, relegating the true goal to a secondary, if not lost, priority. Architecture is only a means to the goal – a working system for a shared purpose (usually involving making more money.) (e.g. SOA is not the goal.) If you don’t get this point, read (or listen) to the book The Goal.

5. Architecture by Edict

Pre-designed or pre-fabricated IT/App architectures (e.g. ERP, CRM products) aren’t necessarily a bad thing – if the trade-offs are thoroughly understood. However, too often architectural decisions are made and implemented by edict, rather than reasoning. (This sometime goes together with sin #4). Most of us know of CIOs that have said “we’re going to use ____ to solve our problem”, and then leave the architect or IT staff to perform superhuman acts to actually make it work (and – unfortunately – often do make it work, leading the CIO to think she/he has made the right decision.) With basic technology platform choices, such as J2EE vs. .NET, it may be fine (both can work.) However, simply deciding on an architecture, or worse, core software product, before understanding the business and architecture requirements usually leads to disaster.

6. Spray-on architecture

One of many gems of architecture wisdom it learned from Lynne Whitehorn-Umphres is that you can’t just add architecture after the fact, which she referred to taking “Spray-on” approach (Refactoring can help, but can’t solve fundamental architectural problems.) Scalability, Security, and many core architectural design stances must be addressed early rather than later.

7. “MIT Layer Syndrome”

Over 15 years ago, Bachman Information Systems developers (actually one from MIT) had to design a graphic UI/Window system from scratch in LISP (running in MS-DOS). Too achieve maximum flexibility, it was designed with a large number of abstraction layers (e.g. bitblt, rendering, drawing, shapes, window, canvas, feltboard, etc.) A well designed system with abysmal runtime performance. Abstraction layers are important architectural constructs. There’s a danger, however, of the seductive nature of these layers – they make architecture look/sound better than they actually turn out to be. Joel Splosky has a good writeup on this issue. (Note: As David Krieger once pointed out, all software is based on abstraction. The only real things are valent electrons flowing through silicon – everything else (OS, Apps, architecture) is a set of structured illusions that make systems ‘work’).

8. One-size fits all

Thin Client. Yeah, right. ’nuff said.

9. Instant Architecture

EAI, XML, BPM, SOA, etc. – All you need is one architecture. Or better yet, how about one platform or product? Anyone remember Broadvision? How about your investment in CORBA? Simply buying an ‘architecture’ is not enough, sometimes downright wrong. If you do by a set of architectural practices and implementations, know what you’re getting into. Here’s the basic trade-off: get a basic architecture platform (e.g. J2EE, .NET) and you’ll have to build on top of it. Or, get a pre-build ‘instant’ architecture (e.g. ERP, BPM pure-play) and live with the architectural choices of the vendor (or the death of the vendor).

10. Pattern Madness

I’m still trying to work this one out. Patterns have been around for a long time, but there’s been more interest in patterns recently (read: last 5 years). What I’ve seen in some cases is that some architects equate architecture with patterns. Simply apply a generous amount of Sun Blueprints and, voila!, they expect to have an architecture. Good architectural designs use patterns, but patterns do not themselves make an architecture.