By Dr.Thomas J Mowbray Chairman - iCMG

If you have a focus for your career, gaining the knowledge you need to advance can be relatively easy. For software professionals, simply doing more to build your expertise is all that is needed in most corporate environments. For example, we often ask software people what books they have read. In the west, most professionals are familiar with Design Patterns. And many have purchased the book by Erich Gamma and co-authors that established the field of design patterns. [Gamma 95] Some have even read it. However, it always surprises us how few people have read anything further on this important topic.

For software architect books, the situation is even worse. Possibly because there are fewer popular books. But more likely because people are not really focused on software architecture as a career goal. In this book series, we are eliminating the first obstacle to establishing a software architecture profession, by publishing a common body of knowledge about software architecture theory and practice. However, making this information available does not automatically change people's reading habits.

So, if the average software professional only reads about one book per year, just think what you could do in comparison. If you read 3 books on design patterns, you would have access to more knowledge than the vast majority of developers on that important topic. In our own professional development, we try even harder. At least a book each month, and if possible, a book every week.

Some books take longer than a week. For example, the 1000 page book on the Catalysis Method. [D'Souza 98]. In our opinion, it contains breakthroughs on component-oriented thinking, but so few people are likely to read it thoroughly (except software architects), that it becomes a valuable intellectual tool for making you (the reader) a thought leader, as the entire industry moves through the difficult transition to component-based development.

Getting ahead on book reading is a clear-cut way to differentiate yourself from the software masses. Converting your book learning to real-world success is also straightforward. You can apply your knowledge on your current projects. You can covert your knowledge into briefings and tutorials that put you in visible leadership and teaching roles. You can share you knowledge at conferences and professional groups. And you can write.

The key transition that leads to success starts with sharing your knowledge one to one (e.g. inefficiently), and proceeding to knowledge sharing with many at a time. In our own careers, when we began to share knowledge in one to many situations, the appearance of success came with it. Since, for most people, appearance is reality, success is easy to attain. The much more difficult challenge is maintaining success, once you've achieved it.

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 your skills is usually even harder. Here are some of the key reasons why the architecture career is difficult:

Nascent Body of Knowledge
Confusion and Gurus Professional Jealousy
The Management Trap
The Software Crisis
We discuss each of these in the following subsections.

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. There is not much software architecture taught in schools. Academics have not yet sorted out many fundamentals. In fact, 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 admit. Hopefully, you will gain this understanding too, after reading further. In the absence of widespread agreement about software architecture theory, you have to be your own expert. To be a software architect, you have to acquire your own set of knowledge and strong set of beliefs about how to do software right. No one book or software method will give you everything that you need to be an effective software architect.

Confusion And Gurus

There are many published software approaches, which claim to provide the benefits of software architecture, but can't deliver on their promises, in most instances. In fact, the software industry has created many technology fads and trends, which are based on incomplete principles. When these approaches are applied in practice, software projects fail. And guess what? The overwhelming majority of corporate development projects do fail, by being cancelled or overspending for under-delivery.

The software products industry has not suffered based upon this almost universal failure of corporate development. In contrast, it has thrived. 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.

As a software architect, you have to be an evangelist and leader for your software team. You need to sort out what works and what does not work from the myriad of conflicting software approaches and products. This is not easy because there is a tremendous onslaught of marketing information generated by vendors and industry experts that tend to contradict your architectural messages. It is your fate to have your architectural decisions frequently contradicted and obsoleted by the commercial software industry. One of your key skills as a architect, is to make sound decisions that can survive the ravages of time and commercial innovation.

Professional Jealousy

The more successful that you become, the more some people will resent your success. Many software professionals are genuinely nice people. But there are many people in our profession who have large egos. We all have egos that can be abrasive, but whether you intend to compete on the basis of ego or not, professional competition can create serious problems in software organizations and in your career, unless you are careful.

As a software architect, professional jealousy is a factor that you will have to watch for vigilantly. You must learn to conduct yourself with a certain degree of humility, and be prepared to defend yourself when necessary. Learn to never take any comment personally; it's always a mistake. Consider that someone you just met who appears to be acting quite rudely, might be acting in their usual manner, in the eyes of people who already know them and disregard their behavior.

The Management Trap

As you become more successful in your software career, it's more likely than not, that you will be joining the ranks of management, since most companies organize around a single management ladder. If you are good at what you do, it is natural for management to want you to mentor and supervise other people doing it too. The company can try to get the productivity of several good performers based upon your experience.

As your administrative responsibilities increase, your time to perform technical work can decrease dramatically. Because there is less time on technical tasks and less time for maintaining your technical skills, you can lose your technical edge. If you chose a software career because you enjoyed technical work, you can lose one of your most important motivations for your work. Being a software architect is quite different than 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.

A software architect can avoid becoming a manager if he establish a personal professional policy. If you don't want management duties, you must learn how to say so. For many of us, one of the most difficult transitions is learning how to say "No." For example, you have to avoid lateral promotions that lead to management and administrative roles. In some organizations you will become trapped in a management role, because the company does not have a technical ladder.

At a certain level of seniority (typical of software architects), you may be surprised, one day, to find yourself assigned responsibilities on the management organization chart. One this is decided, it is very hard to reverse. The best approach is to declare your expectations (e.g. for technical assignments) when you first take the job. And repeat your policy often.

Defining Software Architecture

An increasing number of software professionals are claiming the title: software architect. In our opinion, very few of these people know what software architecture is, beyond an informal understanding. Have you ever been involved in a discussion of the question: "What is architecture?" The term "architecture" is one of the most abused words in software technology. Later, we will describe one of the common miss-uses of architecture; then, we answer the question "What is architecture?" with a conceptual standard that is in widespread use today.

Architecture Misuse

Too often, architectures are used as sales tools rather than technical blueprints. In a typical scenario, a fast-talking technical manager (the "architect") presents a few high-level view-graphs to convince you of the greatness of his product or system. This is a presentation of a marketing architecture. Most marketing architectures are directed externally at customers and not at software developers. Marketing architectures are fine for advertising the features of commercial products, but they only provide limited technical information for developers.

The problem with marketing architectures is that they are decoupled from the development process. The so-called architect is a manager who delegates most technical details to individual developers. Unless the architect manages the computational model (including sub-system interfaces), the architecture is unlikely to deliver any real technical benefits. Architectural benefits that are easily compromised include: system adaptability (for new business needs) and system extensibility (for exploitation of new technologies).

Even though there are many competing definitions of software architecture, experts emphasize the importance of architecture, especially for component-based applications. As component reuse and software complexity increase, architecture is growing dramatically in importance. We shall soon discuss several architecture-centered approaches, which support business change, technology innovation, and design reuse. Reuse of architectural designs benefits component reuse, because design reuse is often much more effective than software reuse alone.

This article is an edited excerpt from the forthcoming book by Raphael Malveau and Thomas J. Mowbray called Software Architecture: A Field Manual, to be published by Prentice Hall in early 2000.