Contained in that site are the following subject areas.

The links lists are extensive and include many presentations and white pages.

As I was sitting waiting in the doctor's office the other day, I picked up one of the magazines, it was a Time issue from March 22, 1999 (shows how up-to-date the office reading was), so in a effort to force new reading material, I stole it! In that magazine was an article from Bill Gates titled "Bill Gates' New Rules". As I read the article, it struck me how much of it applied to the Enterprise Architecture (EA) area, especially the development and adoption of the EA.

Gates' rules and how I feel they should be applied to the EA process are:

• The architecture should be developed by an author developing a example of the architecture, and requiring all reviews, additions and changes of it to be emailed to the review group. People tend to be more positive in writing that in face-to-face meetings.
• I once had a manager that said he couldn't hear very well, but could read extremely well. His point being if you cared about your complaint or suggestion enough to put it in writing then it was worth his time. I agree.
• Respond to each e-mail received, with copies to the entire work-group allowing every one to be on the same level when it is time to have a meeting.

• We are selling the biggest change in the history of IT, it is necessary to understand that the adoption of the architecture is a sales job. Public records of acceptance of an architecture should be made available to the Architecture project and it's sponsors. Examples of some of the information that can easily be made available are:

• If you have your architecture online you can review who and how many times specific areas of the architecture is accessed.
• Purchasing records show the acceptance of a configuration standard and that information should be made public.
• Desktop software inventories should be automated, studied and trends developed.
• Exception requests, who requested them, and if they were granted.

• Use the architecture process to shift the thought processes of the general staff, by encouraging the participation of that staff, and if possible requiring it.
• Respond to every comment both negative and positive.
• Show the relationships, graphically, of the knowledge workers efforts to the business case.

• Develop the architecture using virtual teams, each team member responds to the architecture and all team members receive the response.
• Shut the teams down as segments of the architecture is developed, resurrect them for periodic reviews, adding and deleting expertise as that expertise is required.
• Establish web presences for each of the teams, with discussion boards and chat rooms.

• Eliminate any paper that requires multiple individuals receiving it. Different versions, lost copies and markup copies are all distracting from the process.
• When conducting a meeting, use a LCD projector to review any document.
• The only papers used in meetings would be a "parking lot", and that would be converted to e-mail with assignments immediately upon the end of the meeting.

• When designing the architecture and it's implementation plan, think about how a person's responsibilities can be expanded into new areas, examples are:
• The procurement specialist can also become the valuator for the purchase order if he has configurations to work with. He could even be eliminated by establish e-commerce with the vendor.
• A technical support person's efforts can be eliminated by negotiating pre-configured machines as a infrastructure standard.
• Training support staff specializing in the development tools could redefine their jobs by limiting the number of tools.
• Clerical functions such as interfiling revisions in the architecture can be eliminated if the architecture is online.

• The architecture is never final, changes will always be required as the industry changes, what better way of getting information about those changes than from the subjects the architecture in a feedback loop.
• Vendors that have access to the architecture can give early warning to the development team of changes coming down-line via feed back

• Your customers are the IT staff and management, both centralized and decentralized, how better to isolate trouble in the architecture than a complaint system that is designed for feedback and response. Canned responses such as "We have received your complaint and it has been placed in queue" should not be used.

• With electronic publication, it is possible for each of your vendors to have the latest copy of the architecture. It is easier to address the vendor's concern early than after they have sold a product to one of the executive staff.
• The architecture can be included in all contracts by reference, eliminating new and divergent technologies and techniques from being installed around the architecture.
• E-commerce with the vendor should be built into any configuration standard as a requirement of that standard.

• Why have an inventory that will get out of date, when the competition between vendors, requires the vendor to provide new and innovative services. Why not make that service just-in-time, for instance the delivery of a desktop configuration as defined by the architecture the day before a new employee comes "on-board".
• Purchase training for the limited sets of development tools using "tickets" allowing staff to receive the training at the next class just by presenting a ticket.

• Deal directly with the manufacturer, if your shop has an architecture that specifies what should or should not be installed, your site can be licensed for the product, and copies on site can be used.
• Hardware vendors will provide e-commerce sites tailored to your specifications eliminating the need to custom configure many of the purchases.

• Your architecture should be resident on a well structured site, that has search capabilities.
• Complaints received should be documented and become a permanent part of the site.
• Tools on the site that allow the user to pick and choose from the possible architecture configurations.
• Budgeting tools that allow the user to project the costs of renewing the technical resources should be available.

So what is your feeling on these 12 rules? Can you add to my thoughts or disagree with them? In any case, if you will e-mail me (rule 1), we can get a discussion group going (rules 4 and 7) and perhaps solve some of our community problems (rule 9 and 12).

I have added some new presentations that have not generally been available on the web. These were developed at the Employment Development Department of the State of California. The subjects of those presentations are:

I have taken last week's notes to you and created a EA Communities page that has those and additional pointers to e-communities that support the EA effort. If you are aware of other e-communities, please let me know (rule 1) e-mail.

I have made some progress on the development of the new Internet pointer set to EA resources. There are still about 4000 pointers to be classified. The EWITA EA Presentations page is a result of one of those classifications.