First and foremost, a software architect must be an excellent designer of software systems. He must be able to recognize, reuse, or invent effective design solutions and apply them appropriately. He must be familiar with the key architectural styles and patterns that underlie the discipline of software architecture. An architect may even have some patterns and/or styles that are part of his private arsenal of design tools, amassed over time, possibly as a result of work within a specific domain or application family. Conversely, an architect must also be able to recognize ineffective or suboptimal designs, inappropriate styles and/or patterns, and design decisions "with strings attached."

In an ideal world, a good architect would always be able to provide rationale for all his decisions. However, we should also recognize that truly great architects—software or otherwise—often leave their mark when they depart from the conventional wisdom, for example, when they are faced with an unprecedented problem, or when they realize that an existing problem can be solved in a better way. Their inspiration in such cases may be difficult to rationalize.

To be a great designer of software systems, a software architect must be a skilled software or systems engineer, with years of experience that is both rich and varied, good communication skills, and a keen sense of aesthetics. A software architect must be an engineer because ultimately he is solving engineering problems. More specifically, he must have training as a software engineer because software systems exhibit many properties not shared by other types of engineered systems.

A good architect must have extensive experience because he must strive for the most effective balance of method, theft, and intuition for the problem at hand. For example, if he is dealing with an unprecedented system, he might need to rely on intuition honed by working on many different types of problem over the years and apply generic methods, such as object-orientation. On the other hand, if he is dealing with a variation on a known problem, he will be able to leverage directly his experience, and apply both specific methods and reuse solutions from prior systems.

The architect must also be a good communicator since he must convince many other people of his vision for the system. This includes, for example, other engineers who actually will build the system, but may also include the managers, external project collaborators, project customers and users, venture capitalists, and perhaps even the company's board of directors.

Finally, the architect must have a good appreciation for aesthetics. Those who cultivate such appreciation of design in the real world do a better job of designing in the software world. This point is only briefly stressed here, but has been discussed throughout the book (for example, see Chapters 1, 4, and 11). Elegant designs promote excitement about a project among its stakeholders, including the developers. They are remembered, studied, and emulated. In contrast, boring designs are not.

Many software development organizations produce multiple systems within the same application domain. For example, Microsoft works primarily within the domain of desktop applications; Google's primary domain of interest is information dissemination and use over the Internet; companies such Boeing and Lockheed Martin have an extensive focus on embedded systems; NASA produces ground-, Earth orbit-, and space-based systems.

In some cases, the domain of focus will be accompanied by one or more domain-specific software architectures (DSSAs) (recall Chapter 15) that codify the characteristics of the problem being tackled as well as the solution developed in response. The burden of intimate familiarity with the application domain and the greatest risks of inappropriate and ineffective solutions are removed from the architects in such systems; they need only familiarize themselves with and stick to the prescription contained in the DSSA.

However, the systems being developed in some companies will be related only loosely, such that they cannot be consolidated into a DSSA. In those cases, each system creates its own challenges. The software architects working on such systems will need to have an intimate understanding of each application domain, its major properties, and its idiosyncrasies. Otherwise, regardless of their skills as designers, architects are likely to produce designs that do not work well for the type of task at hand. They may have problems communicating with other stakeholders, including other engineers. And they may not be able to use the properties of the domain to their advantage when facing a problem with their architecture.

A software architect must know that his solutions actually will work once fully developed. Just like a building architect needs to ensure that his designs can be constructed, so a software architect needs to ensure that the software technology exists to support his ideas. A beautiful design is useless if it cannot be implemented.

An architect's primary role, and likely even his main strength, is not as a programmer. Indeed, experience has shown that outstanding programmers do not necessarily make outstanding architects. At the same time, the architect cannot divorce himself completely from programming. The reasons behind this are analogous to the arguments made throughout this book for why it is unrealistic to isolate completely a system's architecture from its implementation. Architects must progressively elaborate design concepts into concrete elements. To do so, they may need to prototype specific elements of their solutions to ensure that those elements will behave in practice as envisioned. They may need to test out ideas on the exact execution platform on which the system will run. The architects may also need to convince either managers or developers that a particularly controversial idea is worth pursuing, by showcasing its benefits in practice.

Architects also must have a grasp of the generic capabilities software developers will have at their disposal when implementing the architecture. In the previous chapters we have covered many such technologies and shown that they can have a direct bearing on a system's architecture. This may include the details of the operating systems and programming languages on which the eventual application will run. It may also require the architect to familiarize himself with the latest advances in software libraries, frameworks, middleware platforms, networking solutions, and so forth. The architect's job is not only to ensure that his ideas can be implemented; it is to ensure that they can be implemented effectively and that the process of creating that implementation is efficient.

Additionally, the architect may need to play the technologist card because of perceptions. Due to the nature of the job, the architect must project authority with different stakeholders. Since an architect often is not a manager on whom authority is explicitly bestowed, that authority must be earned. This is especially the case in the architect's interactions with engineers who have no competence in software development, yet who may be the architect's most important clients. Engineers are typically highly educated and skilled themselves, very protective of their work, and may believe that they are capable of solving a particular problem just as well as the architect—regardless of their lack of any genuine qualifications in software. Being able on occasion to demonstrate technical prowess will help the architect remind the engineers that he is one of them, of the reasons he holds the job, and that he does not live in the proverbial ivory tower.

Many government, legal, and technical bodies produce standards to which a development organization must adhere. Some of those standards are mandated externally and are the precondition for bidding on contracts. For example, many projects funded by the U.S. Department of Defense must adhere to the C4ISR architectural framework. Other standards may be required by the company's management. For example, a company may decide to use UML 2 as an architecture documentation tool.

In either case, a software architect must be intimately familiar with the relevant standards. They must be able to accurately assess and communicate the value of specific standards, or the lack of appropriate standards. They must understand a given standard's expected impact on the architecture and on the eventual product—both positive and negative—and be able to explain that impact to other stakeholders. Finally, they must be able to demonstrate that their architectural solutions adhere to any chosen standards, for example, in the case of a project audit.

The architect should also follow newly initiated standards efforts. A standards body may produce a technology that will significantly simplify development of future products, improve modeling and analysis capabilities for existing architectures, or ensure easy interoperability with important third-party software. For example, the emerging Architectural Analysis and Design Language (AADL), which was discussed in Chapter 6, may provide modeling capabilities that UML does not possess; a given extension to the CORBA standard may ease system implementation; and so on. Additionally, actual participation in standardization efforts may help prevent ill-conceived and resource-wasting standards from being imposed on future projects and software architects.

A great software designer is not necessarily a great software architect. His designs may indeed be superior when looked at in isolation, but in the context of a particular organization or project, those designs may be unrealistic, too expensive, technologically too ambitious, in violation of certain technological agreements or legal codes, or too risky for a multitude of other reasons. In other words, an architect must be more than just a (great) designer. An effective architect must produce an architecture that effectively addresses the problem at hand while simultaneously respecting the constraints placed on the project. If it fails on either count, that architecture will very likely result in a failed project.

One of the frequent constraints in real-world projects is money. Some companies competitively bid for contracts whose size constrains what can be done in the course of the project. Examples of such companies are large enterprises that work on government-funded projects in the United States and Europe: Lockheed Martin, Boeing, BAE Systems, and so on. Other companies get a finite, frequently quite small amount of venture capital to produce a successful system. Examples include many dot.com start-ups. Yet other companies go to their own coffers to fund a project that is expected eventually to turn a profit. Such companies include large commercial software outfits, such as Microsoft, Yahoo, and Google.

In each case, when producing an architecture for a system under development, the architect must not only be aware of the monetary constraint, but must also be able to determine whether his solution can be implemented effectively within the project's budget. This means that the architect must have some, at least basic, understanding of the economics of software development, and must accompany his design decisions with, possibly quick and crude "back of the envelope" calculations of how much their implementation is likely to cost. Budgetary considerations may also lead the architect to opt for adopting or adapting existing architectures and for going with off-the-shelf functionality. Being able to provide appropriate economic justification for all such decisions is an integral part of the architect's job. Ultimately, the architect must be constantly aware that the solution he produces may very well be technically suboptimal.

There are also certain tendencies an architect must avoid. Some obvious bad habits are discussed here; the reader may be able to identify others as well.

Perfectionism The constraints inherent in the architect's job often will make it impossible to produce the perfect architecture for the given problem. Among the many reasons discussed throughout this text, at any given time the architect is likely to possess only partial information. That information may change over time such that, as the architect discovers new details about the system he is working on, previously held beliefs become invalid. Striving for perfection in such a fluid environment is impractical. In fact, one's ability to acknowledge, respond to, and even embrace change will be a mark of one's success as a software architect. This leads to the second bad habit.

Inflexibility An architect should avoid insisting on a single correct or best way of constructing a system. A basic, positive, tendency of a designer should be to produce a clean and simple design. When constructing a building, bridge, or dam, this may mean clearing the building site so that the site fully reflects the architects' and engineers' vision. Unfortunately, it does not always work that way with software. Very few large systems are built from scratch, using a single architectural style, one's favorite set of patterns, standard middleware, programming language, operating system, and hardware platform. Instead, a software architect is much more likely to have to mix and even invent styles and patterns, look for new middleware platforms that solve the new problem more effectively, address multilingual development on multiple platforms, and so on. The reasons for this may be legitimate technical considerations. The reasons may also be the many conflicting and changing requirements levied on the architecture and the architect by the other system stakeholders. In many ways, a big element of a software architect's job is deciding which stakeholders to disappoint.

Micromanagement Another bad habit for a software architect is the impulse to micromanage. An architect produces designs that may result in huge systems developed by many teams, possibly from many organizations, over a significant time period. Making sure that everything goes perfectly and that everyone adheres to the architect's vision at all points in time is simply not possible. It is also not the architect's job. A good architect will recognize that he is surrounded by highly skilled engineers and that many, or even most, of them will be able to do their own jobs much better than he will. Furthermore, trying to meddle in their jobs may create resentment and undermine the architect's goal of leading by example.

Isolationism Finally, the architect should not isolate himself. Even though the architect may feel that the weight of a project is on his shoulders and that, at least early on in the project, he bears the greatest burden, the architect must remember that he is part of a much larger team, and that an integral part of his job is to ask, watch, listen, and communicate. The architect may get solutions to his specific problems in the process. He will also get the early buy-in from the stakeholders, a sense of joint ownership of the architecture, and the chance to set the stage for the architecture's eventual implementation. Shutting oneself in a room because one is "the architect" will likely achieve the exact opposite effect.

Another aspect of isolating oneself is insisting on always devising and using one's own solutions. Even though at times there may be a legitimate need for an architect to invent new design techniques, notations, patterns, or styles, the accompanying danger is doing this even when it is not necessary. This is often referred to as the "Not invented here" syndrome: Architects and, more broadly, organizations are sometimes unaware of, or even deliberately ignore, known effective solutions and insist on developing their own instead. Closely related to this is the "We have always done it this way" syndrome, where suboptimal or even ineffective solutions are applied repeatedly because they may have been demonstrated to work nominally in the past (possibly in very different contexts and on very different problems). Both of these situations are risky, expensive, and frequently result in duplicating the work someone else has already done or, worse, producing inferior solutions.

A talented software designer will most often be able to produce an excellent technical solution for the problem at hand. That solution, however, may not be the best one for the project or the organization solving the problem. A talented software architect will have to recognize the distinction between the two, and make sure always to address the latter. The architect's primary job is to help develop a comprehensive strategy for the project. That strategy, if appropriately implemented, not only will result in a system that is a good technical solution, but also one that becomes a valuable product for the organization.

This requires understanding the economic context of the project and the organization, the competition in the marketplace, and any standards and regulations by which the organization must abide. Perhaps most importantly, the architect must be intimately familiar with the human as well as technical resources at the project's disposal. An otherwise outstanding design will have a high likelihood of failure if it requires purchasing a lot of expensive new technology, retraining the existing engineers, or hiring many new staff.

A central part of overall project strategy is design of the system's architecture. Once an architect is aware of the relevant constraints being faced, he is ready to proceed with solving the problem. This is likely to be the most enjoyable part of architect's job; paradoxically, it may also be the most stressful.

An architect will likely enjoy designing systems because he will get the opportunity to design, use his imagination and creativity, put his stamp on the future systems, and perhaps even to think outside of the proverbial box. However, the architect will still need to be in frequent contact with other stakeholders, gather information from them, and respond to their possibly conflicting requests. He will have to deal with the likelihood that he may not have the complete picture at his disposal and that the picture constantly changes. It has been said that the job of a software architect is a succession of suboptimal decisions made in semidarkness. The architect will also have to avoid letting personal goals, such as producing a clean design in record time, override the other stakeholders' concerns.

Throughout the process of developing the project strategy and producing the architectural design, the architect will be in frequent contact with the system's various stakeholders, which may include developers, testers, technical leads, managers at all levels, customers, and users. One of the main factors in the project's success is whether the architect can project and ensure a continued, coherent vision for the resulting system. In that sense, his job has something in common with that of a salesperson, with the added twist that he is negotiating with and "selling" the project to many different types of customers in many different ways. The architect may need to interact with the various stakeholders repeatedly, especially in a long-lived project, where the overall vision may be temporarily lost in the details. In such situations, the architect may also need to assume the role of the project's cheerleader, maintaining the morale of the different stakeholders. He may also need to show significant awareness and political savvy regarding the competing interests of the various stakeholders in order to carry out this task effectively.

While the architect may use different languages to communicate with different stakeholders and may focus on different aspects of the project depending on the situation, throughout this process he must ensure the architectural integrity of the project. The compromises the architect must inevitably make cannot be allowed to undermine the overall objective or to clash with earlier decisions made for equally valid reasons. Architectural degradation must be avoided throughout this task.

An architect makes many decisions that are crucial to the project's success and has to convince a broad audience—a part of which that may be skeptical—that those decisions are correct. Some decisions may be unpopular, yet the architect needs to get the buy-in from all the major stakeholders, and must do so continuously throughout the project's life span. In some situations, just getting buy-in may not be good enough; the architect may need to elicit excitement for the project. He will frequently have to assume this responsibility without any explicit authority over the stakeholders.

To do this, the architect must be a leader. While it may be difficult to teach, leadership is a skill that can be nourished and refined. To be an effective leader, an architect must:

At all times, the architect must put the interests of the project before his own, and lead by example. Developing a complex software-intensive system may require sacrifices from engineers, including long hours, working weekends and holidays, and time away from families. An architect who is a true leader will always be prepared to make his share of the sacrifices. He must also know when making such sacrifices is in appropriate, and should ensure that project personnel are treated with respect and consideration.

The software architecture team must be composed from people whose strengths are complementary and cover the range of skills discussed above. It is unlikely that a single person will be an outstanding designer, domain expert, technologist, communicator, and leader. More likely, each architect's primary strengths will be in a small number—perhaps only one—of these areas.

Composing the architecture team from people with similar skill sets thus is not helpful. For one, if certain project needs, such as design, are overstaffed, there is a danger that the architects will get in each other's way, while other aspects of the architecture, such as domain expertise, may suffer. At the other extreme, staffing the team with architects whose skills do not sufficiently overlap carries the danger that the information gathered and architectural decisions made will neither be properly understood by different team members nor integrated into a coherent whole.

The architecture team carries a great deal of responsibility for and exerts dominant influence on a project. Thus, it must be staffed with qualified people. A long-time software architecture practioner and researcher, Phillippe Kruchten makes the interesting observation that the architecture team should not become a "retirement home" for aging software engineers (Kruchten 1999). This may seem to be an unnecessary admonition. However, it is not uncommon for engineers with outdated technical skills in large organizations to be "promoted" to software architects. This may be seen as the easiest way of minimizing the negative impact of such engineers' deteriorated abilities, but can be very dangerous and, simply put, it is patently stupid.

The software architecture team should be an integral part of the project, and should be associated with the project throughout its life cycle. Both the architecture team and the other stakeholders must understand that the architecture team is invested in the success of the project. To the architects, this is important because of the architecture team's need to exert influence over all principal design decisions whenever required. To the programmers, it is important because they must feel that the software architects are "one of us." To the managers and customers, it is important because they can clearly see accountability for the architectural decisions made.

An alternative to this view is to treat the software architecture team as a consulting entity that jumps in depending on the needs of different projects. This can be dangerous for several reasons. If a project experiences difficulties, an "us versus them" division may result. Furthermore, the implicit lack of accountability and oversight by management in that case makes it less likely to get buy-in from the stakeholders. For example, if developers believe that it is their responsibility alone to build a successful system and that the architecture team is a marginally interested third party, they will be less likely to take and implement the architecture team's advice, thus possibly violating critical architectural decisions. Most importantly, it is highly unlikely that a part-time software architecture team can simply show up whenever needed, understand all the nuances of the system, make appropriate decisions, and move on.

We should recognize the tension that inevitably will appear between the need of the project to have a readily available software architecture team and the need of the organization to leverage the most experienced, talented, and effective architects across multiple projects that may be undertaken simultaneously. There is no easy solution to this problem, and different organizations may try to address it in different ways. For example, more experienced, senior architects may move to another project once a given system's architecture is reasonably stable, while the junior architects would remain with the project, assume additional responsibilities, and further hone their skills.

Google the phrase "software architect," and a number of Web sites belonging to consulting firms will appear. These firms specialize in providing software architecture "services" to other software development firms. Their mode of operation is to come into an organization, familiarize themselves with the project and possibly the problem domain, and help develop the appropriate architecture for the system under development. At first blush, this may seem like the part-time software architecture team pitfall mentioned above. However, these teams may be hired to staff the project throughout its duration, alleviating that particular concern.

The real question in this case becomes whether it is preferable to employ a permanent software architecture team that will be part of, and thus fully accountable to, the software development organization, or to outsource this important, but possibly scarce and expensive, capability. The conventional wisdom would suggest that having a native software architecture team is preferable, a stance that probably is influenced by the traditional view of software development in which an organization owns a project and develops it completely in-house. Such organizations and projects still exist in some cases, an obvious example being Microsoft, and this view may be appropriate for them.

The answer to the question of whether to employ or hire a software architecture team becomes more complex in the case of many other development organizations. The reasons are two-fold. First, a typical software project will use a number of off-the-shelf technologies and even application-level components. In such situations, the question becomes, who actually owns and controls the software architecture? It has been shown that such technologies directly impact a system's architecture (Di Nitto and Rosenblum 1999). Therefore, by importing an off-the-shelf capability, an organization, at least in part, imports an architecture as well, and the perception may be that there is less of a need for an in-house architecture team. This may indeed be the case in certain situations. But beware: The danger is that by letting a chosen third-party's technology control the architecture, the organization is, in fact, relinquishing a critical piece of control over the project. And that control is given to people who:

In effect, doing this is akin to letting the tail wag the dog.

The second consideration in deciding whether to maintain an internal architecture team has to do with the software development model that has gained increased popularity: outsourcing. Usually a development organization will find it economically advantageous to hire outside developers, often in a foreign country, to implement parts of a system. It might be argued that, by extension, the architecture of the system can be outsourced as well. On the surface, this is similar to hiring an external architecture team. However, relying on an external architecture team assumes that the team would still need to understand the details of the project and its requirements, work in close collaboration with the other system stakeholders, get their buy-in, and oversee the architecture's implementation and evolution. Simply purchasing a putative architecture for a project from a third party usually is not feasible, unless the organization is branching out into a new business area having a well-established existing architecture.

One potentially positive aspect of hiring an external software architecture team or the outright outsourcing of the architecture is that it might be an effective way of avoiding both the "Not invented here," and the "We have always done it this way issues." Even here, however, this risk can never be completely eliminated: The "here" and the "we" may just be shifted to the external team.

The software architecture team does not disband and/or disassociate itself with the project after the architectural design activity is over. There might be an impulse to do so as the team's task is considered to have been completed and other projects may need architectural help. However, moving the team to other projects will have a similar effect to that of treating the team as a consulting entity. More importantly, we have stressed several times throughout this book that it is inappropriate to think of software architecture as a "phase" that is completed early on in a project. While most of the major architectural decisions may be undertaken during the project's early stages, the architecture remains an active, almost organic underpinning for the project that constantly changes and evolves. Cutting off the architecture team from the project can result in many critical architectural decisions being made haphazardly, understood partially at best, and documented poorly, if at all.

Instead, the architecture team must be closely involved with the project throughout the project's life cycle. Once the architecture becomes reasonably stable, it may in fact be possible, and even advisable, to reassign some members of the architecture team to other projects. However, at least a part of the architecture team should remain on the project. In certain cases, members of the architecture team may be assigned as liaisons to the development teams; in other cases, they may become leads of different development teams. This allows the architecture team to have direct oversight of the project's progress, any difficulties encountered, and adherence to the architecture and any needed changes to it. It also helps reinforce the fact that the architecture team's primary allegiance is to the project, thus helping to improve the morale.

Software architecture teams can be structured in different ways, depending on the size of the software development organization, the number and types of projects on which the organization is working concurrently, and the organization's own management structure. We briefly discuss three primary ways of structuring an architecture team. Variations on these models are possible.

A large project typically will have a number of engineering teams working on it. Different teams may be charged with different facets of the system, and may include specialists in specific software engineering subdisciplines such as requirements, quality assurance, implementation, and cross-application middleware.

The architect must have a close, well-functioning relationship with all engineers. In the case of some, such as requirements engineers, the relationship may be more natural and objectives more mutually aligned than in the case of others, such as software testers. In either case, however, the guiding concern must be the overall success of the project.

Perhaps the most important constituency within the organization to the architect is the programmers. Programmers will realize and refine the architect's vision. They also serve as validators of the architecture: If an architectural design decision has unforeseen consequences, a programmer likely will be the first one to notice. In such cases especially, a close, cooperative relationship between architects and programmers is critical; if it is lacking, architectural degradation will quickly occur.

In many companies, architects also must work closely with systems engineers and, in some projects such as embedded systems projects, hardware engineers. An architect's relationship with these engineers will likely be different from that with software engineers. One reason is that a software architect creates the overall vision and design for the software portion of the given system, but does not have analogous control over the remainder of the system. Another reason is that, because systems and hardware engineers lack training in software engineering, they may not have appropriate appreciation for the nuances of the system's software architectural design. They may fall victim to the misconception that, because software is infinitely malleable in principle, it should always change to accommodate the needs of other system components. By now it should be clear that frequent changes to a system, especially if undertaken hastily, tend to invalidate the key architectural design decisions, and result in architectural degradation.

A related, and even bigger, issue that may occur in the relationship between a software architect and nonsoftware engineers is the lack of respect for the architect's importance to the project. This can, of course, happen with software engineers as well. All engineers working on a given project may be highly capable and may qualify as experts in their own focus areas, whether systems, hardware, or some particular specialty. They may thus feel that they understand the nuances of their task much better than the software architect does. Furthermore, they may not see the direct benefit of strictly adhering to the architecture: They frequently are more interested in achieving local optima due to their limited vision of the entire project. In some development organizations software architecture—and software architects —still are not held in very high regard. Coupled with a dislike of being told what to do, this can result in significant resistance to the software architect and contribute to a failed project. Avoiding, or identifying and remedying such situations, is one of the main challenges and primary duties of a software architect.

At times, an architect must achieve his objectives in the face of skeptical and even uncooperative engineers, and often must do so without any formal authority over those engineers. The architect may have to resort to winning them over with personal competence and leadership. Clearly, things are likely to go more smoothly if he also has the support of the organization's management.

Software development organizations are increasingly beginning to understand the importance of software architectures and software architects. Management must work to ensure a project's success and, in an ideal world, that would mean ensuring that the system's architecture, that is, the architects' vision, is realized fully and effectively. In turn, this requires architects and managers to interact frequently and to closely align their goals. This may mean that the managers must adjust their expectations of a project based on the architects' technical considerations, and it may also require architects to adjust their expectations, and the architecture itself, based on the organization's realities. Schedule and budget constraints, marketplace considerations, personnel turnover, and other such issues must be considered.

Managers and architects do not always work well together, however. There may be many reasons for this, but from a software architect's perspective one reason can be particularly damaging: Understanding the importance of the architect's role in a project does not ensure managerial competence. A project, and an entire organization, may be mismanaged in many ways and for many reasons. The managers also may simply lack the technical know-how to grasp the importance of the architect's design decisions. As a result, while a manager may in principle support the architect, he may unwittingly undermine the architecture.

Managers may fail to think through all of the consequences of their actions, which may negatively impact the system's architecture. They may commit to purchasing and using third-party components, frameworks, or middleware that are a poor fit for the architecture. They may decide to comply with standards that cannot be easily shoe-horned into the company's existing architectures. They also may commit to delivering too much, too quickly, too cheaply, without understanding the architectural implications of those promises. An architect must always be aware and may be forced to respond to these challenges.

Of course, an even bigger challenge faced by architects is in more traditional software development shops, in which certain techniques, tools, and processes may have ossified over time. In some parts of such organizations, architecture-centric development on the whole may be considered to be a fad, too inefficient, and unnecessary. Likewise, a particular architectural approach—for example, requiring that a developer request a formal architectural design review before he may change a component's interface—may go against the organization's culture, which in the past has relied on, and thus still encourages, a swaggering form of individual initiative. In such situations, architects simultaneously must fight two battles: arriving at an effective architecture for the system under construction while at the same time trying to overcome institutional resistance, ignorance, and hubris.

Software architects must also interact with additional stakeholders, both within and outside of their organization. Of particular importance is their relationship with the marketing department. In many organizations, innovation is frequently driven by market needs and pressures. This is, of course, understandable because a company's primary goal is to sell products. There is nothing inherently wrong or inverted in such an arrangement: The marketing department researches the current marketplace conditions and customers' needs, and reports those to the company's management or engineers; in turn, the software architects employ their skills to design systems that will best take advantage of the market conditions and satisfy customer needs. It is, therefore, not unusual for marketing to drive a product's development, and hence its architecture: It may determine the systems that need to be built, their exact features, development priorities, release dates, and so forth.

At the same time, there are certain pitfalls in this relationship. Both the architects and marketing staff may fail to properly understand the motivations, abilities, and expertise of the other. The architects may resist being told what to do, especially if they fail to appreciate that market conditions will occasionally get in the way of producing the best or preserving the originally envisaged architecture for a system. For example, an architect's task will be directly impacted if a potential competitor has been identified and it becomes imperative to release a product much earlier than originally planned. So, too, if the primary customer base for the system under construction is observed to be moving to a different computing platform, or if the envisioned customer base significantly expands or shrinks. Architects have no choice but to accommodate such nontechnical realities.

On the other hand, the marketing department may cause problems if it fails to understand that a system's architecture cannot be arbitrarily or abruptly modified to incorporate newly identified needs. Marketing may also strive for unrealistic goals and unreasonable deadlines, and may attempt to drive the engineering process without adequate understanding of technical challenges and realities. In the most extreme case, marketing may promise a product that simply cannot be built by the company's engineers at the given time.

In either case, misunderstandings and lack of proper communication between architecture and marketing teams may result in an adversarial, counterproductive relationship. Keeping this relationship healthy should be an important, regular objective.

Somewhat similar to the architect's relationship with the marketing staff will be his relationship with the system's customers and users, with whom the architect may need to interface directly. In fact, he may well be the face of the project as far as the customers and users are concerned: The architect may present the project vision to them, ensure that their requirements are properly reflected in the system's blueprint and eventually in the system itself, address their inquiries, and resolve their concerns and doubts.

If properly established and nurtured, this can be a very productive relationship, helping ensure the system's final acceptance, with all of the major issues addressed as they came up during construction. On the other hand, the customers and users may be very particular in their requests, impatient, and, in the worst case, insufficiently knowledgeable of the nature of software and the nuances of its development. Thus, in addition to providing the rationale behind the architecture to the stakeholders within the organization (developers, testers, managers), the architect may also need to tailor that rationale for the benefit of the technically less savvy customers and users.