Appendix C: The Software Architect s Role

Because this book is about Web services architecture using Java, it is appropriate to include a section on what, exactly, the software architect's role is in developing software and within the organization. The term software architecture is only a couple of decades old, and the role of a software architect has only been a distinct role in the past decade or so. The role of the software architect started when software became too complex to be managed by a small team. This led to specializations within software development areas.

The Architect Manages Stakeholder Expectations

The software architect's primary role is to provide a vision for the development of software products. He or she is involved from the start of a project interacting with all of the stakeholders of the system. Some of the stakeholders are:

• System customers

• Development organizations

• Operations organizations

• Marketing personnel

• End users

The system's customers want the system to be high quality, on budget, and on time. The development organization is looking for the products, frameworks, libraries, and tools from which they can create the system. The operations organization wants the system to be maintainable, configurable, and easily recoverable when something goes wrong. The marketing personnel are interested in how much functionality can be built into the system so they can sell the benefits to their customers. End-users want the system to be easy to use and perform well.

Every stakeholder has their own perspective on the system and it is up to the architect to mediate all of these individual concerns. Tradeoffs have to be made between these concerns. Sometimes, a concern can be easily addressed without affecting anyone else's concern. These are the decisions that the architect must make within the constraints that the project manager places on time and money.

Each concern can be described by the set of quality attributes that a system supports. A system's quality attributes describe the extent to which a system is maintainable, usable, available, portable, interoperable, testable, reliable, functional, and fast (L. Bass, P. Clements, R. Kazman, Software Architecture in Practice, Addison-Wesley 1998). The decisions that the architect makes to enhance one quality attribute often detract from another quality attribute. For instance, to improve maintainability, a configuration file could be used, but that sometimes means that the system will be slower because it has to read from the file.

These decisions are often at odds, and they change throughout the development of the system. Because things change so often, the architect has to be comfortable with ambiguity. Especially at the start of a project, the requirements will be fluid and some design decisions have to wait. But the architect should continue to drive to a solution by continually adding detail to the design. The architect should also be comfortable with changing direction or pulling the plug when it is clear that the current path is a dead end.

As the project moves forward and the details become clearer, the architect advocates the architecture to all of the stakeholders. To successfully advocate and promote the architecture, he or she has to effectively communicate the architecture to each stakeholder based on the stakeholder's perspective. For instance, an architecture presentation to a group of developers will be much different than an architecture presentation to end-users. However, both presentations are dimensions of the same software architecture.