Software architecture is an emerging discipline and an exciting career path for software professionals. It is relatively new. You may have noticed that most software books today do not say much about software architecture. It is not taught in educational institutions.
It is confused with software engineering (typically by people who have remote relationships to software architecture per se in their hard attempts to find out what is the software architecture is).

We choose the pseudo-military style, because it embodies an essential attitude. As a software architect, you need many survival skills - some technical, some political, some personal. While neither of us has military experience, we have seen software architecture become battleground in many ways. It is a battleground of ideas, as developers compete to forward their own concepts. It is a battleground for control of key design decisions that may be overruled by managers or developers, perhaps covertly. It is a battleground with many risks, since architects are responsible for a much wider range of technical and process risks than most managers or individual developers.

We have lived through the experience of graduating from "member of technical staff" developers to becoming practicing software architects at the most senior levels of respective companies. We are technical people, not managers, and we enjoy the technical nature of our work.
We enjoy parity of salary and benefits with the senior managers at respective firms. In other words, we are none-the-worse-for-wear as a consequence of choosing a software architecture career.

Software Architecture is everything - from design patterns to prototyping, business case development to leadership. We want to share profound insights and practical solutions for all the key challenges of architectures using objects, components, and distributed Internet computing, showing how to avoid time-consuming pitfalls and costly errors. A software architect must master methods for:

• Identifying the best architectural model for any project
• Executing heavyweight or lightweight approaches to software architecture
• Addressing scalability and long-term business flexibility
• Making the most of abstraction,refactoring, and architectural prototyping
• Leveraging superior design patterns to improve your implementations

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 key reasons why the architecture career is difficult:

• Misuse of the Term "Architecture"
• Nascent Body of Knowledge
• Confusion and Gurus
• Professional Jealousy
• The Management Trap
• The Software Crisis

An increasing number of software professionals are claiming the title: software architect. In our opinion, very few of these people understand what software architecture is. Have you ever been involved in a discussion of the question: "What is architecture?" The term "architecture" is one of those most often misused. Below we describe one of the common misuses; then we answer the question "What is architecture?" with a conceptual standard that is in widespread use today.

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 provide only 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). Despite the many competing definitions, experts emphasize the importance of architecture, especially for component-based applications. As component reuse and software complexity increase, architecture is growing dramatically in importance. Architecture-centered approaches 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.


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 admit. Hopefully, you will gain this understanding, too. In the absence of widespread agreement about software architecture theory, you have to be your own expert. You have to acquire your own set of knowledge and a 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.


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 - by being cancelled, from over-spending, or for under-delivery.
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. Consequently, despite all the failures, the software products industry has thrived.
As a software architect, you have to be an evangelist and leader for your software team. From the myriad conflicting software approaches and products you 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 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 an architect is to make sound decisions that can survive the ravages of time and commercial innovation.


The more successful you become, the more some people will resent your success. Many software professionals are genuinely nice people. But many people in our profession 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. Rechtin said: Challenge the process and solution, for surely someone else will."
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. Never take any comment personally; it's always a mistake. Consider a situation where you are meeting someone for the first time and they appear to be acting quite rudely. In the eyes of people who have known them for an extended period of time, they may very well be acting in their usual manner.


As you become more successful in your software career, you may 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 you spend less time on technical tasks and on 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 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 you advance as a manager, eventually a superior will tell you to stop touching the keyboard (i.e., programming).
You as a software architect can avoid becoming a manager if you 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.
Once 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.


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. 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. Modification and extension of systems are the most expensive cost drivers and very likely to create new defects. Overall, virtually all application software projects produce stovepipe systems, brittle software architectures that underperform 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. Three key factors are exacerbating the software crisis:

• requirements change
• commercial innovation
• 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, in both 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. Owing to predominance of the Internet and geographically diverse enterprises, distributed computing is an essential feature of many new applications.
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.

---

• Run Away Back to Mama
• Basic Level
• Drill Sergeant
• Navy SEAL
• Special Advisor
• Commander-in-Chief
• Secret Agent
• I Spy

---