Stakeholders

 

Stakeholders 

Traditional software development has been driven by the need of the delivered software to meet the requirements of users. Although the definition of the term user varies, all software development methods are based around this principle in one way or another. However, the people affected by a software system are not limited to those who use it. Software systems are not just used: They have to be built and tested, they have to be operated, they may have to be repaired, they are usually enhanced, and of course they have to be paid for. Each of these activities involves a number—possibly a significant number—of people in addition to the users. Each of these groups of people has its own requirements, interests, and needs to be met by the software system. We refer collectively to these people as stakeholders. Understanding the role of the stakeholder is fundamental to understanding the role of the architect in the development of a software product or system. We define a stakeholder as follows.

First of all, consider the phrase “individual, team, or organization.” As we shall see in this book, those with an interest in the architecture of a system stretch far more widely than just its developers, or even its developers and users. A much broader community than this is affected by the realization of the architecture as a system, such as those who have to support it, deploy it, or pay for it. Specifying the architecture is a key opportunity for the stakeholders to direct its shape and direction. You will find, however, that some stakeholders are more interested in their roles than others, for a variety of reasons that have little to do with architecture. Part of your role, therefore, is to engage and galvanize, to persuade people of the importance of their involvement, and to obtain their commitment to the task. As the definition notes, a stakeholder often represents a class of individual, such as user or developer, rather than a specific person. This presents some problems because it may not be possible to capture and reconcile the needs of all members of the class (all users, all developers) in the time available. Furthermore, you may not have the stakeholders at hand (e.g., when developing a new product). In either case, you need to select some representative stakeholders who will speak for the group.

Interests and Concerns

 Now consider the phrase “having an interest in the realization of the system.” This criterion is— deliberately—a broad one, and its interpretation is entirely specific to individual projects. As you will see when you start to develop your architecture, you are engaged in a process of discovery as much as one of capture—in other words, this early in the system development lifecycle, your stakeholders may not yet know precisely what their requirements are. Another way that we sometimes express this idea is to say that we are interested in stakeholders who have concerns about the system. We find the term concern particularly appropriate because of the broad range of possible types of stakeholder involvement with a system.

Many concerns will be common among stakeholders, but some concerns will be distinct and may even conflict. Resolving such conflicts in a way that leaves stakeholders satisfied can be a significant challenge.

The Importance of Stakeholders 

Stakeholders (explicitly or implicitly) drive the whole shape and direction of the architecture, which is developed solely to create a system for their benefit and to serve their needs. Stakeholders ultimately make or direct the fundamental decisions about scope, functionality, operational characteristics, and structure of the eventual product or system—under the guidance of the architect, of course. Without stakeholders, there would be no point in developing the architecture because there would be no need for the system it will turn into, nor would there be anyone to build it, deploy it, run it, or pay for it.

It follows that if a system does not adequately meet the needs of its stakeholders, it cannot be considered a success—no matter how well it conforms to good architectural practice. In other words, architectures must be evaluated with respect to stakeholder needs as well as abstract architectural and software engineering principles. As we’ve seen, it is not uncommon for the needs of different stakeholders to be in conflict with one another. There is no easy answer to such a dilemma, and it often falls to the architect to strike an effective balance in such cases (for example, by accepting higher maintenance costs in a performance-critical system, caused by the level of optimization and integration of system elements required in order to reduce request processing latency)