The System Stakeholders

Many people believe that the software architecture is meant only for developers to use as an overall guide for system design and construction. While this may be the software architecture's primary purpose, other system stakeholders can use the architecture as a basis to guide their activities as well. The following are some of the system stakeholders:

• Developers

• Managers

• Software architects

• Data administrators

• System customers

• Operations

• Marketing

• Finance

• End-users

• General management

• Subcontractors

• Testing and quality assurance

• UI designers

• Infrastructure administrators

• Process administrators

• Documentation specialists

• Enterprise architects

• Data administrators

The software architect must elicit input from all the system stakeholders to fully understand the requirements for the architecture. This is important because the requirements are built from the perspective of what the system should do. However, the architecture must reflect how the system will perform those functions.

The system's customers want the system to be of high quality. They want the system to be delivered in a timely manner. And they want it to be developed as inexpensively as possible.

The development organization is looking for a vision for the system it is going to design and develop. It wants to know that the architecture is easy to implement. It has hard deadlines that it must meet, so reusability is important. The developers are going to be looking for technologies in the architecture that they currently understand. They want the architecture to match their desired platforms, development tools, libraries, and frameworks. They need to meet dates, so the architecture should ease their development effort. Most of all, they want an architecture that they have participated in developing and evolving throughout the lifetime of the product.

The operations group wants a product that is supportable and maintainable. The product must not fail. It has to meet service level agreements that it can only meet if the product is reliable. If the system goes down, this group is on the front lines trying to get it back up. When it does fail, the operators need to find out why so that the problems can be fixed. Therefore, the system should provide some traceability for system transactions so that what went wrong can be tracked down. The operations group also has the responsibility for installing new machines and upgrading software platforms on a schedule. It needs the software to be flexible and portable so that moving it to a new machine or onto a new version of the operating system is fast and easy.

The marketing people are looking for an architecture that can deliver the greatest number of features in the shortest amount of time. An architecture that is flexible and can integrate off-the-shelf packages will win their hearts. In addition, if the product is a commercial product, the architecture may be a key selling point. Savvy customers of commercial products will recognize a good architecture from a bad one.

End-users need great performance from the system. It must help them get their jobs done more quickly and easily. The system must be usable. The interfaces must be designed with end-user tasks in mind and, ideally, the system should be customizable so that end-users can choose how they wish to use it.

Every stakeholder has his or her perspective on what is important for the system to do. It is up to the architect to mediate among these individual concerns. Not all stakeholders can get everything they want all the time. Sometimes, a requirement can be easily met without detracting from another requirement. Sometimes trade-offs have to be made among the various requirements. These are the decisions that the architect must facilitate within the constraints that the project sponsor places on time and money.