The Mission of an Architect

A software architect leads and coordinates technical activities and artifacts throughout the project. A software architect coordinates some of the key design decisions in terms of technologies, structure, and organization of the software system. In contrast to the other roles defined in the RUP approach, the software architect's view is one of breadth, as opposed to one of depth.

A Jack-of-All-Trades

How do we characterize the ideal architect? Around 25 B.C. , the Roman architect Vitruvius wrote, "The ideal architect should be a person of letters , a mathematician , familiar with historical studies, a diligent student of philosophy, acquainted with music, not ignorant of medicine, learned in the responses of jurisconsults, familiar with astronomy and astronomical calculations." This is quite a challenge!

In a similar fashion, a software architect must be well rounded and possess maturity, vision, and a depth of experience that allows for grasping issues quickly and making educated , critical judgments in the absence of complete information. More specifically , the software architect, or the members of the architecture team, must combine these attributes:

  • Experience in both the problem domain (through a thorough understanding of the requirements) and the software engineering domain. If there is a team, these qualities can be spread across the team members, but at least one software architect must provide the global vision for the project. The software architect must understand the key technologies available or be able to quickly bring in the appropriate competencies.

  • Leadership in order to drive the technical effort across the various teams and to make critical decisions under pressure and make those decisions stick. To be effective, the software architect and the project manager must work closely together, with the software architect leading the technical issues and the project manager leading the business and administrative issues.

  • Communication to earn trust, to persuade, to motivate, and to mentor. The software architect cannot lead by decree, only by the consent of the rest of the project team. In order to be effective, the software architect must earn the respect of the project team, the project manager, the customer, and the user community, as well as the management team.

  • Goal-oriented and proactive with a relentless focus on results. The software architect is the technical driving force behind the project, not a visionary or dreamer. The life of a successful software architect is a long series of suboptimal decisions often made in the dark and under pressure. A perfectionist who spends a lot of time on issues would not be appropriate for the job.

A Person or a Team?

If the project is large enough, then several people, grouped in a software architecture team, will play this role. A project with more than 30 people all together may want to create an architecture team. If this is your case, the goal in assembling such a team is to have a good mix of talents, covering a wide spectrum of experience and sharing a common understanding of the software engineering process. The architecture team should not be a mere committee of representatives from various teams, domains, or contractors. Software architecture is a full-time function, with staff permanently dedicated to it. We often write "the software architect does...." Understand that we mean collectively the persons playing that role at a given point in time.

A Vertex of Communication

The architect is not a lone designer, operating from a technological ivory tower, but rather plays a major communication role in the development organization.

Communication Between Project Management and Development

In the movie industry, the director is responsible for the artistic content of the movie ”the direction of actors. It is very rare that the director will also play the role of the executive producer, the latter being more focused on planning, finance, budget, crews, supplies , set construction, and so on. But at the same time, these two roles need to be very closely coordinated. They need to speak to each other constantly, especially in a moving and ever-changing environment. Similarly, in a software project, the architect and the project manager will need to be in constant communication (although careful not to do each other's job). We will see later that the architect will play a major role in planning the contents of an iteration, in identifying and addressing technical risks, and in helping the project manager with strategic and tactical changes.

Communication Between Internal Parties and External Stakeholders

The architect will also interface the outside world with the rest of the team ”architecture team and project team “ “on the technical matters. The Vision Document and the requirements developed by the analysts provide the major input to the architect's work, from which the architect will extract the architecturally significant requirements that will contribute to shape the system. When multiple external parties ”customers, contractors, and so on ”are involved, this aspect of the job may become quite time-consuming .

Communication Between Various Development Teams

Especially in a large organization, the architects will also play a role of communication and coordination, on the technical front, between various development teams. They will make sure that interfaces are defined and respected; they will scout for the potential for reuse; and they will participate in reviews, striving to ensure a consistent style for the development of the system, to preserve what Frederick Brooks called its "architectural integrity." Also, this role is often continuous and informal; when things get tough, the architect plays an arbiter role between teams and takes part in the decision of a Change Control Board [1] if a CCB is instituted.

[1] A Change Control Board is a small group of people who review and approve proposed changes to baselined artifacts.



The Rational Unified Process Made Easy(c) A Practitioner's Guide to Rational Unified Process
Programming Microsoft Visual C++
ISBN: N/A
EAN: 2147483647
Year: 2005
Pages: 173

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net