So you want to become a software architect? Or perhaps you are already a software architect, and you want to expand your knowledge of the discipline? This is a book about achieving and maintaining success in your software career. It is also a book about an important new software discipline and technology, software architecture. This is not a book about getting rich in the software business; our advice helps you to achieve professional fulfillment. Although the monetary rewards of this career are substantial, often, what motivates many people in software architecture is being a continuous technical contributor throughout their career. In other words, most software architects want to do technically interesting work, no matter how successful and experienced they become. So the goal of this book is to help you achieve career success as a software architect and then maintain your success.

In this book, we cover both heavyweight and lightweight approaches to software architecture. The role of Software Architect has many varied aspects, an architect is: part politician, part technologist, part author, part evangelist, part mentor, part psychologist, and wears many more hats. At the epitome of the software profession, the Software Architect must understand the viewpoints and techniques of many players in the IT business. We describe the discipline and process of writing specifications, what most people would consider the bulk of software architecture, but we also cover those human aspects of the practice which are most challenging to architects, both new and experienced.

1.0 Advice for Software Architects

"Success is easy; maintaining success is difficult." - J.B.

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 (See Section 1.3). 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 1 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.

"Particularly for social systems, it's the perceptions, not the fact, that count." [Rechtin 97]

Getting ahead on book reading is a clearcut 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 pratice 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.

"Technical problems become political problems." [Rechtin 97]

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 obsolesced 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.

Challenge the process and solution, for surely someone else will." [Rechtin 97]

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.

LESSON LEARNED

As you advance as a manager, eventually a superior will tell you to stop touching the keyboard. (i.e. programming). LESSON END A software architect can avoid becoming a manager if they 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. Below, we describe one of the common mis-uses of architecture; then, we answer the question "What is architecture?" with a conceptual standard that is in widespread use today (see Section 1.2).

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 viewgraphs 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 subsystem 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. In the following sections, we 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.

Before Architecture

High quality, flexible software is one goal of architecture-centered development. In recent years, popular development approaches assumed that bad software is better. In other words, getting software delivered quickly, is better than delivering quality software which supports change and reuse. Well-known process models and vendor regimes are founded on the bad is better principle.

Architecture-centered approaches accommodate reuse and change more effectively than bad is better approaches, because there is a planned system organization, specifically designed for these purposes, i.e. the system architecture. In our opinion, the practice of software architecture is essential for component-based development. Bad is better was the thesis; software architecture is the antithesis.

Of course, we do not want to lose the inherent benefit of bad is better, i.e. rapid delivery. Architecture-centered approaches utilize several techniques including pragmatism, architecture planning, and architecture reuse, which jointly support increased productivity, reduced risk, and rapid time-to-market.

The Software Crisis

Many of us have serious misconceptions about the capabilities of current software approaches. Based upon surveys of corporate software projects in the United States, the realities of software development are as follows. [Brown 98] About one third of all software projects are cancelled. Average projects expend twice as much budget and schedule as initially planned. After delivery, the majority of systems are considered unsuccessful because they have far fewer capabilities than expected. Modifying and extending systems are the most expensive cost drivers and very likely to create new defects. Overall, the outcome of virtually all application software projects are stovepipe systems, brittle software architectures that under-perform on requirements.

The software crisis in corporate development became apparent decades ago, when procedural software technologies were popular. Subsequent, object-oriented approaches (such as the Object Modeling Technique) have been equally unsuccessful for corporate developers. These outcomes have been repeatedly confirmed by research. [Brown 98]

Three key factors are exacerbating the software crisis:

• requirements change,
• commercial innovation, and
• distributed computing.

A significant part of the problem is rising user expectations. User requirements for systems have increased much faster than corporate developers' capability to deliver. Requirements changes are more frequent as businesses maneuver for competitive advantage with strategic corporate software.

Another confounding factor is the destabilizing force of accelerating technology innovation, both in commercial software and hardware platforms. Corporate developers have difficulty finding compatible configurations of software products, and are forced to upgrade configurations frequently as new products are released. Software maintenance due to technology upgrades is a significant corporate cost driver.

Distributed computing is an essential feature of many new applications due to predominance of the Internet and geographically diverse enterprises. Traditionally, software designers assumed homogeneous configurations, centralized systems, local communications, and infrequent failures. Today's highly distributed enterprises require heterogeneous hardware/software, decentralized legacy configurations, and complex communications infrastructure. The resulting computing environments have frequent partial system failures. Distributed computing reverses many key assumptions that are the basis for procedural and object-oriented software development.

The software industry has established object-orientation (OO) as the mainstream technology. OO is the technology adopted by new corporate development projects because OO is universally supported by software tool vendors. Masses of legacy programmers are training for object-oriented development (e.g. C++ and Java) as corporations create new strategic systems. Unfortunately, these developers and corporations are likely to become the next generation of disillusioned participants in the software crisis. However, the organizations that survive and thrive with this technology, must use it in sophisticated new ways, represented by componentware.