George,

I'm happy to describe what we did. We've enjoyed a measure of success--our organization now has an architecture, we have management support, and we are getting ready to align our programs--yes, our IT spending throughout the organization--with the architecture. We have the support of all the managers who have IT responsibility; in fact, they adopted our architecture.

I'd like to give an accurate portrayal of Meta's involvement. They were consultants, and we had them on site perhaps a total of two or three days during the architecture development, plus a three-day immersion course in architecture that Larry Deboever conducted at our facility. They provided advice based on their experience in working with many organizations who had been through this process. We did the work. They have a general process to follow, that we used as a starting point because it was the most practical approach we found. We didn't follow it religiously; we changed it radically in a few ways. My guess is that anyone doing architecture needs to tailor what they do to the needs of their organization, and if they use the Meta approach it's a point of departure rather than a bible to follow.

But I'd like to be clear about another point--we could not have been even reasonably successful without them. They provided an experience base and a continuing source of sound advice that I would not recommend anyone not have available for this work. But it's not expensive, we're talking something like $30K a year for the service. I would not want to undertake an architecture effort without Meta's help, particularly considering the small cost of their assistance when you look at it compared to the cost of all the labor that goes into developing an architecture.

Another key to success was teamwork. We brought together a group of people of varied disciplines, and we listened to everyone. All through the effort, different individuals made huge contributions. I can point to each of the people who was with us through the whole saga and list their multiple essential ideas that let us succeed. We faced the hardest political and technical problems I've encountered, we sometimes argued about how to proceed, but great ideas emerged somehow from this band of talented people. So teamwork is essential. I could never have had enough good ideas to lead this effort in a directive fashion and succeed.

We didn't turn out a lot of pages. I don't think running the printing presses for a long time gives you a bigger chance of success--in fact, quite the contrary. So we did a tremendous amount of work to get our reports down to a small size in very readable language with professional graphics that complemented the text.

We felt that our real job was to convince all the people who mattered in the Agency that it was in their interest to adopt a coordinated enterprise approach to IT. Who matters? The people who do the work, and the people who make the decisions about what work is to be done and how money is to be spent. So we needed to get people on board from the worker level to the most senior managers.

We assembled an Architecture Committee from all over the Agency. The committee decided early on that we knew enough about what we already had--in our ranks, we had experts in all of it--we wanted to figure out where we wanted to be, not where we were. So we didn't even do a baseline, we focused on the future.

First, we did a technology survey, wrote a report on ten key technology trends that would influence Agency computing. It was quite carefully written, backed up by solid data and good graphic design. It's about 25 pages. We have distributed many, many copies, and the survey has been very well received.

Our second document established the business case for architecture at the Agency. How the business would be better with architecture. To do this, we developed a report we called "The Business Context for an ETA". We used scenarios to portray the benefits of an ETA--how it is now, how it could be better. We used a diagram to show each scenario. The report is about 20 pages long; again, it's written with great care and attention. It got the attention of senior management at the Agency and was widely distributed.

Our architecture document is 45 pages long. We divided the architecture into 9 of what Meta (and we) now call "domains". They are all described in that document. Again, it was extremely hard to write--we boiled down hundreds of pages to get to this. But this gives the dimensions of the future, and we find that already, even before we have governance in place, Agency organizations are eagerly following the guidance in that document. Of course, not in every case!

We are able now to have significant influence on IT direction. The Agency just implemented another feature of the architecture, an enterprise-wide desktop PC buy. We will be forklifting out 1/3 of the PCs each year, and we have funded this on an Agency basis. Because of the architecture, we are buying machines with some capacity that they may still be moderately OK in three years when they are replaced. We are saving a lot of money compared with buying them 20 or 30 or even 200 at a time.

Now we are starting a baseline study and a gap analysis to identify the gaps between our architecture and what we have now. Then we will work with the organizations that spend IT money to integrate their plans with the directions to get to the future state that is envisioned by the architecture.

So there you are. Sadly, I can't show you documents two and three, because they are classified. The tech trends document is unclassified, and I can share that with you.

Now I'd like to respond to the GAO concerns "about the necessity to describe the business before spending money on technology." We used the strategic needs of the business as our starting point for architecture--but they were based on the Agency's goals for its future business state, and did not involve writing down hundreds of pages of descriptions of present business processes.

I've heard John Zachman ask how you can plan a new IT infrastructure if you don't understand the present one. We understood the present one pretty well, but we didn't write hundreds of pages about it. In fact, we focused on where we wanted to be rather than where we are now. Now that we know where we want to go, as we do our baseline study we know exactly what is important to look at and what we can ignore. We think it will take a month or two to do our baseline study and write a report on it. Our page budget for the report on the baseline and gap analysis is 50 pages, shorter if possible.

I believe that if we had tried to do a Zachman-style infrastructure description, or if we had tried to document all our business practices, instead of having an architecture that is providing important benefits now we might still be gathering information and writing reports that no one would ever use.

I hope this discussion is worthwhile in helping others move forward in their own efforts. The advice that I would give is that pages of reports are not the goal. Convincing people is the goal.

Dave Roberts

Can be reached at dave@davedoesitall.com

Extracted from