11.3 Making A NAME

"No one can make you feel inferior without your consent."

-Eleanor Roosevelt

Architects should attempt to do more than merely protect themselves. They should try to help others to grow professionally and personally. One of the goals of a software architect is to affect lives and change for the better the way that people build software. Mentoring individuals one by one, software architects can have some limited impact, perhaps helping a few dozen people over a lifetime. The scope can, however, be much more ambitious, possibly affecting thousands of lives directly.

By applying Psychological Akido as a front-end process, knowledge can be gathered from positive and negative experiences. Then positive experiences can be transformed into patterns, in the "software patterns" sense. Software architects want to find practices that repeatedly work so that they can be shared with many others. Initially, architects must prove to themselves that the patterns work by applying them in their own work. Then they need to mentor other professionals to do the same. In so doing, the ins and outs of the new technique become clearer.

When they are satisfied that the quality of this knowledge is worth sharing on a wider scale, the software architects shift knowledge-sharing strategies. They transition from one-to-one sharing (e.g., mentoring) into one-to-many sharing. This transition is essential if the practices of large groups of developers are to be affected. An enterprise architect or a Chief Information Officer, for example, would have to execute educational and administrative strategies that change behaviors on a mass scale. One-to-one mentoring simply wouldn't work.

Software architects must document and share knowledge. A useful first step is a set of tutorial briefing charts. With these charts, they can project their message to groups ranging from a half dozen to several hundred people. Because architects are adept at teaching and answering questions, they can focus their knowledge of the solution and how it is to be executed. In a sense, they are providing many shortcuts for their audience's Psychological Akido process. They are explicitly telling their audiences where the action levers are and what to avoid in terms of destruct buttons.

In many cases, some 5% or more will listen carefully, learn the new patterns of knowledge, and apply them to their own work. According to the Nolan Curve, a classic learning theory, if 5% of the skill base can successfully apply much more effective practices, the other 95% will eventually migrate. Within a single organization, a tutorial may be sufficient to effect the required change. Ideally the tutorial will include an even balance of lecture, experience, and feedback (e.g., discussing their experiences). From a training perspective, if the students perform successfully in class, they can be expected to do the same in real life. Experience, such as programming laboratories, is vital to effective knowledge acquisition.

To affect a large group of developers, software architects need to go further in disseminating their knowledge. A magazine article is a wonderful way to communicate to very large groups because it's a relatively short-term commitment. Additionally, the rewards of professional recognition are superb-almost as good as writing a book. Magazines are continually seeking talent, and if someone has something that really works in this chaotic software industry, the knowledge is probably well worth sharing. Posting the same information on the Internet is useful, but it is not nearly as persuasive as the magazine format.

Everything that has been done so far in this process affects many lives. But the impacts are transient, at best. The tutorial helps the individual focus his or her ideas and develop the verbal articulation of the ideas necessary to communicate the message. If permanent knowledge is to be created, however, books and standards are essential. A standard is a documented technical agreement. It has great moral hegemony. Most standards focus on detailed technical solutions that are intended for vendor implementation. This is a reasonable mechanism to pursue, given its shortcomings-primarily compromises and long delays. The authors do not discourage standardization because they have pursued this approach on a number of occasions.

A book defines intellectual standards. It yields substantial credibility, as well as professional recognition. For example, many more people have read the authors' books on CORBA than will ever read their standard. As architects involved in the CORBA standardization process, the authors have used this authority to articulate the technology in a way that is more effective than the standards alone. There is a great gap between what can be readily assimilated (and what is useful in practical applications) and what appears in a typical standards document. A standards-oriented book resolves this gap and makes the technology usable to much greater numbers of developers.