11.2 Word of Caution
The software architecture career path is a difficult one for many reasons. While becoming a competent software architect can be difficult, maintaining those skills is usually even harder. Here are some key reasons why the architecture career is difficult:
Each of these is discussed in the subsections that follow.
Nascent Body of Knowledge
First of all, the body of software architecture knowledge is not well established. Software architecture is a relatively new field of computer science. Not much software architecture is taught in schools. Academics have not yet sorted out the fundamentals; there is still much discussion and disagreement on the basics.
However, many practicing software architects believe that sufficient knowledge does exist. The practice of software architecture is much more mature than many will believe. A survey of the current body of knowledge in software architecture, included within and referenced by this text, should suffice to enable the reader to share this understanding.
In the absence of widespread agreement about software architecture theory, each individual must be his or her own expert. The individual must acquire his or her own set of knowledge and a strong set of beliefs about how to do software correctly. No one book or software method will provide everything necessary to be an effective software architect.
Confusion and Gurus
Many published software approaches claim to provide the benefits of software architecture, but most of them can't deliver on their promises. In fact, the software industry has created many technology fads and trends, on the basis of incomplete principles. When these approaches are applied in practice, software projects fail. And guess what? The overwhelming majority of corporate development projects do fail-they are usually canceled because of overspending or underdelivery.
These failures are characteristic of a vast corporate software market, populated with companies that are struggling to deliver their internal software. New products and software development ideas are constantly being produced, in a never-ending attempt to meet the needs of the struggling software masses. Despite all the failures, the software products industry has thrived.
Software architects must be evangelists and leaders for their software teams. From the myriad conflicting software approaches and products, the architects need to sort out what works and what does not. This is not easy because a tremendous onslaught of marketing information generated by vendors and industry experts tends to contradict the architectural messages. The fate of software architects is to have one architectural decision after another contradicted and made obsolete by the commercial software industry. Consequently, one of the key skills that architects must have is the ability to make sound decisions that can survive the ravages of time and commercial innovation.
The Management Trap
The more successful software architects may join the ranks of management, since most companies organize around a single management ladder. For those who are good at what they do, it is natural for management to want them to mentor and supervise other people doing it, too. The company can try to get the productivity of several good performers based upon a good software architect's experience.
As administrative responsibilities increase, the time to perform technical work can decrease dramatically. Because less time is spent on technical tasks and on maintaining technical skills, management employees could lose their technical edge. For those who chose a software career because they enjoyed technical work, turning to management could destroy an important motivation.
Being a software architect is quite different from being a manager. A software architect is a direct technical contributor, whereas a manager contributes indirectly by coordinating the actions of other people. Together, managers and architects make highly effective leadership teams. In our experience, combining the two roles can work only temporarily.
As architects evolve into managers, eventually a superior will tell them to stop touching the keyboard (i.e., programming).
Software architects can avoid becoming managers by establishing a personal professional policy. Those architects who don't want management duties must learn how to say so. For many architects, one of the most difficult transitions is learning how to say "No." For example, lateral promotions that lead to management and administrative roles must be avoided.
Some organizations trap architects in a management role, because the company does not have a technical ladder. At a certain level of seniority (typical of software architects), many architects are surprised to find themselves assigned responsibilities on the management organization chart. Once this is decided, it is very hard to reverse. The best approach is for architects to declare their expectations (e.g., for technical assignments) when first hired and to repeat that policy often.
 | 
