Enable JavaScript.

The Proper Role of Software Architects

A commonly held view is that software architects are generalists, capable of dealing with all aspects of software development; everything from high-level conceptualization to coding. In a panel discussion on software architecture, Matthew Eberz said:

An architect is more than a technical engineer, he is an accountant, a salesman, a marketer, a teacher, and a communicator all in one. Without those skills, the architect will not be successful at the enterprise level.

Jeffery Redding added:

An architect has all the skills of a programmer, an analyst, and a senior software engineer as well as skills most often associated with project managers, business managers, finance managers and mediators. In addition, an architect has a vision that is often the difference between success and failure. The architect that blends all these skills into a cohesive, coherent, whole, creates a successful architecture that satisfies the needs of the enterprise.

I object! No one can be an expert in that many fields, especially not in a field as complex as software development. Instead, we should view software architects as specialists who team up with other specialists to develop software. It may appear that an architect must be expert in all of their roles, but to act in all of those roles is to guarantee that none will be performed adequately (at least not in large projects). What always suffers is the documentation of the architecture. Everything else always seems to be more urgent, even if it is less important to the overall success of the project.

Architects need not be experts in requirements gathering and analysis; this is the responsibility of business analysts. Nor need architects be experts in database schema design; this is the responsibility of database designers. And similarly, architects need not be experts in the selection of programming tools; this the responsibility of the programming team. But the architect does determine the objectives to be achieved by these specialists. For example, if the architect specifies fast response to changes, the programmers may well select an Interactive Development Environment (IDE), such as Smalltalk, as opposed to a batch-oriented C++ tool set.

Software architecture is the specialty practiced by people called software architects. Their prime functions are:

  1. The high-level conceptualization of the structure and behavior of the software to be produced — roughly 20% of the architect's total effort. This part of the job has to be done really well, based on training and experience in software design, which are not the same as training and experience in programming.
  2. The communication of the vision to all of the other specialists of the project through blueprints — roughly 40%. This is the paperwork part of the job that so often gets short-changed.
  3. Interpretation of the blueprints and problem solving during software development — roughly 40%. This is the consulting part of the job that too often expands to 110% of the architect's time.

Activities outside of these functions should be severely constrained. The creation and communication of high-quality architectural blueprints requires focused effort by people who specialize in their production — software architects.

Contrary to the prevailing view, it is not desirable for a project to be under the rigid, hierarchical control of a super-generalist, who must be involved in all decisions. This approach results in a bottleneck and in a general failure to adequately communicate decisions. It is better to distribute decision making to the specialists best able to make them. The result is a development team that emerges from the interactions of its specialists. Architecture blueprints have a central role in this process; many other forms of documentation are available for other purposes and between other specialties.

There are many subspecialities of software architecture, by industry and technology. We can talk about manufacturing, retailing, or insurance industry software architects, and we can talk about user interface, embedded system, or database software architects. Each subspeciality of software architecture has its own concerns, its own knowledge base, and its own terminology. What they share is the delivery of blueprints to communicate a vision. Often, an architecture team will include subspecialists for a variety of areas, all contributing to a common set of blueprints.

Software architecture is a discipline that is slowly emerging from computer programming. Most practitioners have self-promoted themselves from the ranks of programmers. They are usually people with strong abilities to envision the structure and behavior of a software system. Too often, however, they allow themselves to become distracted by non-architectural issues. To often, they retain the typical programmer's disdain for documenting their work. By focusing on blueprints, this paper identifies what distinguishes software architecture from other software disciplines.

Le rôle approprié des architectes de logiciels


Désolé, pas encore traduit.