Red Flag - The Architect and Agile Methodology

Today, I want to focus on technical architects and how they document and present their vision to 'C-Level' executives and business experts and some warning signs that should cause you great alarm.

Let me paint the setting before we launch into the 'Red Flag'. You have a technical architect on staff working on a complex major project for you. You are using Agile project management methodology. That means different things to different people, but you are at least doing daily scrums, have someone that sort of resembles a scrummaster, have your staff in a common work area where 'high-bandwidth' communication is the order of the day, are focused on sprints and doing and not on reams and reams of documentation, etc. If you have done Agile before this is familiar.

Red Flag - An architect who uses Agile methodology's focus on less documentation as an excuse not to do their professional due diligence. This particular architect feels that since Agile methodology means very simple and light documentation he does not need to document his vision and explain it to people, or for that matter, think through the issues. When pressed, the excuse is always "we are using Agile methodology. We don't need to do that." After all, the focus is on doing the core 80% and then refactoring to fill out the gaps in the final 20%. Sounds good.

• Except when your architect has not thought through all the parts and pieces and is doing UML diagrams and flow charts of key pieces after the fact.
• Except when he is cursing the developers for being slow and dense because they are not doing what he wants -- because no one knows what he wants.
• Except when he asks a developer to make multiple major course changes in architecture – within the timespan of an hour.
• Except when the technical writers, QA team and user training team need an overview so they can do their jobs -- but nothing exists.
• Except when key components like security are ignored -- then hastily plugged with hacks at the end.

Any of this sound familiar? When you sit down with your business experts, technical staff and decision makers, the architect should be able to articulate the system and how it will work. This does not mean that he needs UML class diagrams of every single part of the system. In fact, when using Agile that is something I always leave at the discretion of the developers. However, the architect should articulate what technologies he is using and what is going to be used to do what.

Your architect should show that he has done the level of due diligence that is appropriate for your business and the legal and regulatory requirements it faces. He needs to demonstrate that he has thought through the issues you face and has a realistic strategy of how to solve them – especially technically. This does not mean a chart with a couple of boxes on it where he explains 'magic happens here'. Use common sense.

If you are the main stakeholder and your architect cannot do this, be worried. How are you going to plan this thing out? How are the developers going to know what to do? Are they going to meet the use cases? How are you going to budget? Don’t wait until the financial department raises the hue and cry when they realize that the project is hemorrhaging money. Agile methodology is not an excuse for technical incompetence, laziness, or arrogance.

I usually play the role of data architect or technical architect in most of my projects, sometimes both. The purpose of a technical architect is to put together a data or technical vision for the system being created. But a good architect is an evangelist; he must see the vision AND be able to articulate it. One of the first things I do after having gone through the requirements phase, gotten my use cases, activity diagrams, etc. is to draw out a basic diagram with all the moving parts of the system: what they are, where they live, who owns what, what they do and how it all fits together. For the last of these I use a Zachman-like approach where I have different layers representing everything from hardware, to ETL packages, to web front ends and reports. I have seen something similar done in David Hays work, Data Model Patterns A Metadata Map.

This diagram is an excellent tool for communicating with executive and business experts. I usually print it out on a plotter and make a wall chart then go through it with all my stakeholders. No matter what level the stakeholder is at, i.e. a subject matter expert, system administrator, etc. they can focus on their view of the world and see how it fits into the bigger picture of where we are going.