It should come as no surprise that the first pillar of the SPAMMED Architecture Framework (SAF) are the stakeholders – after all at least some of these are the people/organizations that are the cornerstone of the software project itself.
What exactly is a stakeholder – EIA 632 , a standard for System Engineering, defines a stakeholder as “An enterprise, organization, or individual having an interest or a stake in the outcome of the engineering of a system”.
Sounds good enough to me :) – but before we delve into more details on how to identify these stakeholder, what do we do with that information, we first have to understand why it is important to us as architects. The short answer was already mentioned stakeholders (most obvious examples are Customer, Project Manager) are what makes the project tick. That, however is just the beginning of it. One of the primary responsibilities of the software architect (much like the project manager by the way) is to balance the stakeholders interest to ensure the success of the project. In the SAF sense the stakeholder are important for several reasons:
- The solution is developed to serve their needs or goals (at least some of them i.e. customer, end users, management)
- They serve as the source for constraints (and sometime principles)
- Their concerns can help elevate needed quality attributes
- Stakeholders can (and should) help evaluate the architecture
- The documentation of the software architecture is targets at stakeholders
Several stakeholders are pretty common to any project . The following list shows them along with samples for some of the concerns (or vested interest) they have regarding the project:
- Customer – Functionality, price
- End-User – Ease of use, performance
- Project Manager – On time delivery, development costs
- Management – Price, reuse
- Developers – structure and dependency between components, interesting technology
- Maintainers – ease of debugging, modifiability
- Testers – Testability, Traceability
- Security Analysts – security
- Project New comers – structure and dependency between components, traceability
- Customer’s IT group – ease of installation, stability
This list is a nice starting point but it is just that – a starting point. There are still a few things we may want to do
- Identify additional stakeholder – sometimes there are less common or obvious stakeholders (e.g. System engineers, shareholders, safety analysts, the general public etc.)
- Map stakeholders relevance – Jaap Schekkerman from suggest prioritizing stakeholders by power vs. interest. I believe the privatization should also include the (stakeholders) concern importance:
- Lastly you may want to document your stakeholders so as not to forget what they are interested in. This documentation can include the constraints they place their concerns (translated into quality attributes) and a list of viewpoint that are needed to satisfy them (i.e. explain the architecture to them). A template for documenting stakeholders is availablefrom the SAF page.
