Quoderat

The Zachman Framework (link to a full Wikipedia article) has been around for almost two decades now. It is an approach to enterprise system architecture that involves asking a series of questions (who, what, when, where, why, and how) for stage/aspect of a project. Because the framework is usually displayed as a table with the questions along the top and the stages/aspects down the left side, the Zachman-heads generally refer to the project stages/aspects as rows:

1. scope;
2. business model;
3. system model;
4. technology model;
5. components; and
6. working system.

An enterprise system architect will toss around the phrase “that’s a row-four question” just as easily as a network specialist will toss around the phrase “that’s a layer-four protocol”. The framework requires asking 6 questions 6 times to 5 stakeholder groups, for a total of 180 questions.

Not very agile, and maybe anglo-centric

This mountain of paperwork is pretty-much the antithesis of the agile software design that many of us are now practicing with great success — as the current version of the Wikipedia article linked at the top of this posting wrying notes, Zachman “is popular within IT architecture departments but has little hold of either the developer or user communities.” In other words, we tend not to use the stuff even if someone shoves it in our faces. I’m not going to bother rehashing the standard agile arguments against this kind of heavily formalized design, because most of you already know them (and those who do not can follow the link to the Wikipedia article at the start of this paragraph).

Today, I stumbled upon a different kind of criticism of Zachman: Graeme Simsion, writing from inside the system architecture community, notes that language bias has likely severely restricted the framework’s usefulness. He points out that, while who, what, when, where, why, and how are the six common single-word interrogative English pronouns, a French speaker would almost certainly have added “combien”. There are two common translations of combien — “how much?” and “how many?”. Obviously, these are critical questions to ask about any project. “How much will it cost?” “How many users will it support?” “How much bandwidth will it need?” “How many services will it offer?” Why are these questions missing from Zachman? Simsion suggests that Zachman left them out because they require two words in English, making them seem less natural, and because they’re missing from Kipling’s little poem:

I keep six honest serving-men
  (They taught me all I knew)
Their names are What and Why and When
  And How and Where and Who

He goes on to write, half tongue-in-cheek, that if Zachman had been Zachhomme, the framework would have had eight columns rather than six. Nice catch!

I’ve decided it’s time to figure out if aspect-oriented programming is worth, well, figuring out.

So far, nearly everything Google can find for me about AOP is positive — glowing, even — and that makes me nervous. Real change is supposed to be painful: even today, when object-oriented programming has become dominant, it is easy to find critics; XML had, and still has, many detractors; and any self-proclaimed guru standing in a Starbucks line can tell you what’s wrong with HTML and the web before the barista has time to finish making a cappuccino.

Does the lack of criticism mean that AOP is practically perfect in every way, or simply that people don’t care enough to pick it apart? After reading some online introductions and studying the AspectJ syntax and tutorials (with their seemingly endless trace and log examples), I can see how the approach might have some benefits, but I’m not convinced that the benefits outweigh the potential code obfuscation.

In fact, one of the few critical pieces I did find, a two-page University of Passau paper entitled AOP considered harmful (the paper later spawned a $250 business research paper), compares AOP with the notorious GOTO statement from early procedural programming languages, attacked by Dijkstra in his classic 1968 letter Go To Statement Considered Harmful. In addition to GOTO, AOP also reminds me a bit of C macros, another cause of confusing, hard-to-maintain code.

I’d be interested in comments from people using AOP (AspectJ or otherwise), as well as pointers to other sources that are not simply hyping the movement. Does AOP work for you? I’m skeptical, but I’m not willing to dismiss it yet.