The Architecture provides a single, common, and cohesive vision that directs the design, construction, purchase, deployment, and management of information systems (I/S) and information technology (I/T) across state government.
This is a complete architecture for a large enterprise, probably one of the best (and earliest) on the web. The Architecture addresses a federated large legacy based enterprise in 12 domains,

The North Carolina Architecture is an example of Meta's EAS (see below), and is used as examples in the DCI and Meta Group classes and seminars. The Chief Architect spends a lot of time on the road explaining the development of this architecture. It is probably one of the most copied architectures in the world.

"A mask to conceal some design; a person put forward to mislead; a sham. Fowlers used to conceal themselves behind horses, and went on stalking step by step till they got within shot of the game. "

"The author attacks an argument which is different from, and usually weaker than, the opposition's best argument."

When I was first assigned to an architecture team, I spent a massive amount of time on the Internet, trying to understand just what was meant by architecture. This research resulted in the link lists on my site, it was a little cluttered and perhaps contained non-architecture information, but it was (at the time) pretty comprehensive.

There were some real gems of information out there, including process, procedures and real examples (see the site spotlight). One of the gems, was the North Carolina architecture and it pertained to the organization I was working in (Legacy systems transitioning to Internet). Alright, so I downloaded it, and did some MS Word magic on it and delivered a 200 page architecture in a matter of days (so, I'm not proud!). And, as with all 200 page documents, it got copied, and filed (never read or understood). The CIO ignored it for months, finally taking it on a trip from California to Florida to read it. She was seated next to a consultant from a LARGE consulting firm (let's call them Grand Gargoyles consulting) , who after watching her suffer though some part of it, indicated that their firm was able to produce a architecture in 90 days.

Now, we all know that airline air or food cause mental lapses of judgment. So when she returned, we had the assignment of producing a totally unique consensus architecture for her organization in 90 days.

It is my premise that nothing gets done in meetings or as a large consensus group! I maintain that ALL major documents written are written by one person, even the Declaration of Independence! Consensus is achieved by modifying that single author document and getting participants to agree. Such a document is a "strawdog" (see definitions). So I needed a way of creating these strawdogs for use in consensus meetings.

While the 200 page document described previously did not meet the CIO's requirements, it did meet the need for the strawdogs for the consensus meetings.

The architecture team spent time designing and documenting the domains of the architecture (this along with the results of interviews driving out business requirements, a summary of trends, and best practices represented a conceptual architecture).

We then divided the 200 page document into domains and as a result we had the necessary "strawdogs" for the consensus effort.

We found that those team members who chose not to use strawdogs ended up in a morass of discussion and re-discussion of what the document should contain. The resolution was to adopt the idea of creating a example document and modify it (yes a strawdog). Those domains that used the concept of strawdogs finished their part of the architecture on or before schedule, and that was a good thing because we had to help in the other domains.

• KISS - Keep it shot and simple, find out what your sponsor's attention span is and use it!
• NIH (Not Invented Here) - is a invalid concept.
• Re-use - Utilize existing work if possible.
• Know a answer- Have a written solution in hand before meeting with the technical staff to drive out consensus.
• Be willing to change - Make the fact known, and encourage that the document is to be modified to meet the needs of the group.
• Encourage change - Do not exercise pride of authorship, encourage comment, questions and change.

I have decided to do a series of Enterprise Architecture articles for this (face it) newsletter. The articles will be in almost a conversational tone. They will give in a similar format to the above, definitions, background, assumptions (premise), a solution and the points learned (moral). I will attempt to do one of these a week, keeping it short and light, an easy read of about 750 words. They will not be in chronological or project order. They will be like conversations, may not be grammatically correct, but they work in the case of the architectures I have worked on.

A note about the title: "Hammering away in the garage" - my home office is in the garage, where I do most of the work on this newsletter and the community. The office is equipped with computers, and an extensive hardcopy reference library (boy, do those books get out of date fast).

At the conference, I will be chairing one of the "Birds of a Feather Tables at Breakfast" on Thursday, October 26th from 8:00-8:45am, the table topic will be "Internet as a development tool for architectures". Plan on joining me and swapping "war stories".