Recently, at TechEd Africa 2009, I spoke to a rather large audience about a topic I entitled ‘The Good, the Bad and the Ugly of Architecture’.
It was essentially a redelivery of material created by Miha Kralj (upon whom much credit is graciously bestowed), but with a local spin and additional material and examples relevant to our local geography.
I find the concept of patterns (predictable, recurring events) in architecture quite intriguing, but also one the most difficult elements of architecture to sustain when we add external pressures that I spoke about in terms of ‘anti-patterns’ in my presentation.
It’s quite ridiculous really. Architecture is usually developed by Architects who all have different backgrounds, are intuitive and forward thinking in nature, and whose roles, to which the title refers, are different depending on the IT organization within which they find themselves.
Abstract thinking and architectural vision is not usually valued as highly in organizations as technical detail skills may be. The reason is usually because technical detail people usually create something tangible, and often this is perceived to be from nothing. While they may pull the proverbial rabbit from the hat, we often forget who defined the hat… and the rabbit.
In essence, an Architect is what an Architect does!
Architects often come in two extremes, and from these two extremes anti-patterns are allowed to surface. These are:
Between those two extremes there are, naturally, many good and bad examples of architects. It’s hard to identify them, but we can start looking at processes and results to help identify them in retrospect. The bad process stuff and the bad output stuff can be considered anti-patterns, and as I step through them it will become clear to you if you’re seeing them within yourself or your organization. The idea is to walk the fine line between the extremes and present something useful.
The three basic roles of an architect can be summarized as follows:
In this post I will provide some anti-pattern extremes for each of the above, in the hope you can identify and avoid these in your organization
Anti-pattern: Cognitive Dissonance
The typical "we know it all, we know what they want, it’s just a cookie cutter re-delivery kind of approach”. Maybe even, “I don’t use it, so why would they need it”
I’ve encountered so many architects in my many years of consulting that love quoting the old mantra, “we only use 10% of the functionality in Office”. Who is this we to which they refer?
The answer for Office specifically lies in SQM (pronounced “squim”) data. Software Quality Metrics allow Microsoft to understand what features are made use of in a product. It’s interesting to see what we lose if we cut back to 10% of the features. The most commonly used features on Office are cut, followed by paste, but if we cut out 90% of the lesser used features we lose Word Art. Do you know anyone in your company that uses Word Art? Would it be important to them? How about pivot tables?
Architectural cognitive dissonance such as the above can lead to circumstances where technology decisions may lead to inappropriate tools for the staff that need them most.
I must add, before I proceed, that there may be instances where the types of technologies below apply, but they’re not one size fits all.
The “10% of the features” thinking often leads to acquisition of the cheapest tools offering a “similar” (but often substantially reduced) feature set. For example as an architect we should know that before generating an architecture for Office Productivity that bases the business on a web-based platform that things like browser limitations exist, that not even HTML5 can address. Do we adequately understand the three ways to work within a browser, namely:
All three have limitations that need to be factored in when choosing to go from the extreme of full suite that is installed locally to being 100% browser dependent.
Perhaps as an architect a range of solutions would be better to establish.
This is one, super simple example to illustrate the point. Imagine how many complex examples there are. Understanding the actual requirements rather than assuming what they are or basing them on your own experiences of the work day are critical in determining an appropriate solution.
For every anti-pattern, there is an opposite anti-pattern. In this case it’s the Obedient Butler.
Opposite Anti-pattern – The Obedient Butler
This is the, “yes sir, yes sir, three bags full sir,” anti-pattern. Basically if they ask for it we can do it.
“You want to check your home alarm status from Notepad with a simple click of the File Menu”
“You want the cappuccino machine to make kosher, pork sausages”
When we agree to everything, we forget that we’re gathering requirements and that those requirements need analysis before we agree. Being an obedient butler means you’re a little light on the analysis in your eagerness to please.
I’ve seen IT companies do that constantly. A typical example. Company X wishes to migrate their aging, *nix based email system to Microsoft Exchange. Everything looks okay… “I mean how hard can *nix mail be right?”
So the IT company says they can do it without any problems. Then they find it’s Xenix Mail running on a file system they don’t understand and cannot connect to, running a protocol that isn’t POP or IMAP and using a directory service they don’t understand.
NO PROBLEM. “We’ll do it” while thinking quietly that there must be freeware tool on the web or that we can just write a script.
Never mind the kosher, pork sausages.
Next anti-pattern please….
Anti-pattern: Napkin Doodle
This one has really developed…
That is, from the smoky, restaurant table written on the white side of the shiny tin foil found in old cigarette boxes to the clinical environment of the smokeless restaurant napkin. How times have changed! At least architecture no longer involves getting my long blonde hair full of smoke!
Basically it goes like this
Dude, “I need to put together a collaboration platform for our company.”
Architect, “What do you want to do?”
Dude, “Email obviously, oh… and document sharing, and IM”
Architect, “Do you have a WAN”
Architect, “Uh oh, but we can solve it, here’s what you need to do”
The problem is obvious. Requirements gathering may be detailed, or may be minimal (my guess, given the setting is that they are minimal in this instance), but the analysis is terrible! Architecture is a skill. Architects form the analysis bridge between business requirements and business analysts and the engineering side of the business. MOSS doesn’t mean much to an engineer, so they might just end up doing a standard deployment rather than engineering it to meet useful criteria for the organization. Ensuring the requirements are adequately listed and captured is a requirement of any architectural analysis.
The next phase after gathering of requirements is analysis. Without adequate gathering of requirements and an adequate understanding of what is needed, analysis will fail and any further outputs and dependencies will just be exponentially worse.
Assuming the requirements are light without actually testing them to any degree is a big mistake. It also does a huge disservice to the role and perceptions of architects in general and demonstrates an arrogance that should be the sole preserve of fresh out of college developers!
Opposite Anti-pattern: Documentation Overkill
Creating architecture can be complex, but that doesn’t usually mean taking every letter in the phone book, sorting them in alphabetical order and then attempting to recreate the complete works of Shakespeare. Tomes are best left to people who are excited by writing and reading them.
My 'favourite architectures' are those that look at things from every conceivable angle; whether it necessary or useful or not! They are not often created on the basis of adequate requirements gathering, but rather on the underpinnings of analyst reports, magazine opinions and whatever every product which might fit into the relevant category might offer.
This is why in my time as an Architect at Microsoft I will often respond to RFP’s for solutions that will ask questions such as those below. This would represent a minute subset of an RFP that had nearly 60 pages of questions just like these:
These exact questions came to me from a customer who utilizes the following directories:
I have to assume that before a customer releases a complex and detail technical RFP they must at least have had some architecture in place… and they did. It was enormous. It didn’t take into account what was actually in place in the organization, or what might be. It just included every single thing that could possibly every need to exist in an identity management system.
Can you imagine the 18 months of trade shows, conferences and information gathering that went on to finally produce an RFP. Surely gathering the requirements correctly and then creating an architecture accordingly is more time efficient and practical. Ultimately the idea is to get to a tangible result, rather than creating a huge additional workload for all those downstream and an indeterminate result.
A good architect might have created something more specific. So let’s revise the questions to what they could have been if the architecture had been correct (again a limited subset, and assuming AD is the primary authentication and authorization engine).
That’s all for now. In my next post I will cover some of the anti-patterns found in the analysis stage.
All images in this post are Copyright ©2009 Sarah Chana Mocke
*Top Secret is a registered trademark of CA Inc. All other products are registered trademarks of their owners.