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.

Definition. A stakeholder in the architecture of a system is an individual, team, organization, or classes thereof, having an interest in the realization of the system.

Most system development projects include representatives from most if not all of these stakeholder groups, although their relative importance will obviously vary from project to project. However, if you do not at least consider each class, you will have problems in the future. You need to balance and prioritize the needs of the different stakeholder groups, so that when conflicts occur, you can make sound, well-reasoned decisions.

It is also worth noting that, although we don’t consider the architect’s needs explicitly, when acting in that role you are also an architectural stake- holder. (We assume that you can represent yourself adequately to ensure that your views are taken into account!)

Principle. The architect must ensure that there is adequate stakeholder representation across the board, including nontechnology stakeholders (such as acquirers and users) and technology-focused ones (such as developers, system administrators, and maintainers).

Our Stakeholder Categorization

We classify stakeholders according to their roles and concerns as in the following table.

Acquirers	Oversee the procurement of the system or product
Assessors	Oversee the system’s conformance to standards and legal regulation
Communicators	Explain the system to other stakeholders via its documentation and training materials
Developers	Construct and deploy the system from specifications (or lead the teams that do this)
Maintainers	Manage the evolution of the system once it is operational
Production Engineers	Design, deploy, and manage the hardware and software environments in which the system will be built, tested, and run
Suppliers	Build and/or supply the hardware, software, or infrastructure on which the system will run
Support Staff	Provide support to users for the product or system when it is running
System Administrators	Run the system once it has been deployed
Testers	Test the system to ensure that it is suitable for use
Users	Define the system’s functionality and ultimately make use of it