ro"

108
PART

II THE PROCESS OF SOFTWARE ARCHITECTURE

We explained that a good way to visually represent aspects of the scope is to use a context diagram. Production of such a diagram is a good way to begin your work with the stakeholders. We explained that stakeholder concerns may be specific and measurable (in which case. we call them requirements) or may be vague and loosely stated but nonetheless still important to your stakeholders. We described how to effectively document your stakeholders' concerns. We defined an architectural principle as a fundamental statement of be lief. approach. or intent that guides the definition of an architecture. We ex plained how principles are extremely useful in creating a framework for architecture definition and showed how you can use principles to trace back your architectural decisions to business drivers and goals. Finally. we considered various types of architectural constraints. such as standards. guidelines. strategies. and policies. You must take all of these into account when designing your architecture.

9
IDENTIFYING AND ENGAGING STAKEHOLDERS

FURTHER READING
Many software architecture books discuss the process of setting the scope of the system; examples include Garland and Anthony [GARL03]. which de scribes a Context viewpoint. and Bosch [BOSCOO]. which describes how to de fine the system context at the start of the architectural design process. A number of requirements engineering books also discuss scoping sys tems. A particularly good example is Sommerville and Sawyer [SOMM97], which presents a clear set of guidelines around requirements capture. presen tation. and ratification. Each guideline is accompanied by a cost/benefit anal ysis and practical suggestions on how it can be implemented.

A those who use it. Systems are not just used: They have to be designed and built; they have to be operated; they may have to be repaired; they are
usually enhanced; and. of course, they have to be paidJor. Each of these activities involves a number-possibly a significant num ber-of people distinct from the users. Each of these groups of people has its own requirements. its own interests. and its own needs from the system. We refer collectively to these people as stakeholders. In Part 1 we defined a stake holder as follows.

s we saw in Part 1, the people affected by a system are not limited to

DEFINITION A stakeholder in a software architecture is a person. group. or entity with an interest in or concerns about the realization of the architecture.

Correctly identifying stakeholders and gaining their commitment is one of the most important (yet underrated) tasks in software development. The concept of architectural stakeholder is clearly explained in the IEEE standard Recommended Practice Jor Architectural Description. and our discussion builds on theirs.

SELECTION OF STAKEHOLDERS
It is. in our experience. a subjective choice whom you select to populate your

community of stakeholders. We have found, however, that casting your net more widely at the beginning is important in the long term (although in the

110

PART II

THE PROCESS OF SOFTWARE ARCHITECTURE

.pr
. .

~
,t
t
~

"c'

CHAPTER 9

IDENTIFYING AND ENGAGING STAKEHOLDERS

111

short term, it may make your life more difficult because you will have more po tentially conflicting requirements to reconcile). If you don't take stakeholders' concerns into consideration at the beginning of your development project, you can be sure that they will complain at the end, when making changes is much harder-and making architectural changes may be practically impossible.

TABLE

9-1

CRITERIA FOR A GOOD STAKEHOLDER (CONTINUEO)

Criterion Authorized Representative

Description Can you be sure that decisions made now by your stakeholders will not be reversed later (at potentially high cost)? If a stakeholder is a group rather than a person, have suitable representatives been selected from the group? Do those repre sentatives meet the above criteria for individual stakeholders?

[ID

The selection of stakeholders is a subjective activity; but in gen eral, the wider the stakeholder community, the better your chances of deliver ing a successful product or system.
STRATEGY

Unfortunately, there are no purely objective criteria for determining whether you have correctly identified your stakeholders. Whom you select de pends on a range of factors including the goals of the system, organizational and political considerations, availability of resources, and cost and timescale constraints. (We sometimes find, for example, that stakeholders are consulted in a spirit of openness, to demonstrate a desire to reflect a wide range of con cerns, rather than an absolute need to take account of their views. There is absolutely nothing wrong with this, as long as it contributes to the success of the architecture.) Drawing up your list of stakeholders, therefore, is a collaborative activity that sets the tone for the future direction of the project, and it is essential that you get this right. As well as ensuring that your stakeholder list is complete (we explore this issue further in the next section), there are four criteria to help make sure your list is right.

CLASSES OF STAKEHOLDERS
In Table 9-2, we classify stakeholders according to their roles and concerns. Most system development projects include representatives from most if not all of these stakeholder groups, although their relative importance will ob viously vary from project to project. However, if you do not at least consider each class, you will have problems in the future. Widening your set of stakeholders leads to a tradeoff-the larger the group, the more difficult it will be to reach a consensus. Part of the architect's role is to ensure that large stakeholder communities do not become an obstacle

TABLE

9-2 STAKEHOLDER ROLES

Stakeholder Class Acquirers Assessors

Description
.
"

..

Oversee the procurement of the system or product

.... -,.
,-~.~"

.._._-,-<_._--.,--

PRINCIPLE A good stakeholder in an architecture is i'lformed, committed, authonzed, and representative.

Oversee the system's conformance to standards and legal regu lation Explain the system to other stakeholders via its documentation and training materials
"

Communicators Developers Maimainers

We explain each of these criteria in Table 9-1.

. ...

__

,._._------~-._._---,~-"'--"-"'_.,-

Construct and deploy the system from specifications (or lead the teams that do this) Manage the evolution of the system once it is operational
.

TABLE

9-1

CRITERIA FOR A GOOD STAKEHOLDER

- ----'_.'- -.-._-------,,--

-'-_._----.~--_

... _-,--"_. __ ..

Suppliers
~-,~--_._-,-~---~--~-~-,-_.

__ ----_
.

.. _.~--,-

Criterion Informed Committed

Description
--'"--~.,-,,--,-,_

...

__... __
_-.

Build and/or supply the hardware, software, or infrastructure on which the system will run Provide support to users for the product or system when it is running

.".

Do your stakeholders have the information, the experience, and the understanding needed to make the right decisions?
------- --,-,.--- --~

Support staff

.,

-.._, ..

,",._._,._~~----~_.~---~

Are your stakeholders willing and able to make themselves available to participate in the process, and are they prepared to make some possibly difficult decisions?
.. _.- -'---"
' - " ' ~ ' - - - " - - _._--~-

System administrators Run the system once it has been deployed Testers Users Test the system to ensure that it is suitable for use
--'

--,_._--.,.,.,-

Define the system's functionality and ultimately make use of it

112

PART

1/

THE PROCESS OF SOFTWARE ARCHITECTURE

r'

CHAPTER 9

'

IDENTIFYING AND ENGAGING STAKEHOLDERS

113

to making progress. This requires you to actively manage the decision-making process and have a clear understanding of the relative importance of the needs of each stakeholder group. Doing this will help you defend your architectural decisions when challenged by stakeholders who feel that their needs have been ignored.

Assessors
Assessors oversee the system's conformance to standards and legal regula tions. Assessors may come from the organization's own internal quality con trol or conformance departments, or they may be external legal entities. Assessors' concerns are focused around testing (to demonstrate conform ance to requirements) and on formal, demonstrable compliance.

l!J
~

STRATEGY

If you have a large stakeholder group, you need to actively man age it to ensure that its size does not impede progress. In particular, 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 rep resentation across the board, including nontechnology stakeholders (such as acquirers and users) and technology-focused ones (such as developers, sys tem administrators, and maintainers).

Communicators
Communicators explain the system to other stakeholders. Internal or public trainers provide training for support staff, developers, maintainers, and so on, and technical authors create manuals for the users and administrators of the product or system. In the case of a product, the marketing department needs to communicate its key features, strengths, and benefits to potential customers. Communicators' interests lie in understanding the rationale behind and the details of the architecture and explaining it to technical and lay audiences.

Developers
Developers construct and deploy the system from specifications; in other words, they take it through the software development lifecycle from design, code, and test to acceptance. Developers need to understand the overall architecture but also have specific concerns that focus on development issues such as build standards, choice of platform, language, and tools as well as other issues such as maintainability, flexibility, and the preservation of knowledge over time. This category also includes development managers, who plan the devel opment activities and lead the teams that do the work.

Let's define the stakeholder classes in a little more detail.

Acquirers
Acquirers oversee the procurement of the system or product. Acquirers typi cally include senior management, which provides or authorizes funding for product or system development, and may also include the purchasing and le gal departments, which represent the commercial interests of users in negoti ations with third-party suppliers. In a system development project, acquirers are often referred to as busi ness sponsors, and for a product development, acquirers are likely to be se nior executives from the sales, marketing, and technology groups. There may also be investor representation in this group if specific external investment is required to fund the project. In seniority terms, acquirers are usually your most important stakeholders. Acquirers' concerns typically center around issues such as alignment with strategic objectives, return on investment, and the costs, timescales, plans, and resources involved in building and running the system. Their goals are usually value for money and efficient expenditure of resources during deliv ery and operation.

Maintainers
Maintainers manage the evolution of the system once it is operational. Main tainers' concerns focus on issues such as development documentation, instru mentation (facilities for operational system monitoring), debug environments, production change control, and the preservation of knowledge over time.

Suppliers
Suppliers build and/or supply the hardware, software, or infrastructure on which the system will run, or possibly they provide specialized staff for sys tem development or operation.

114

PART II

'

THE PROCESS OF SOFTWARE ARCHITECTURE

r.'1.
, :,"
I

CHAPTER 9

IDENTIFYING AND ENGAGING STAKEHOLDERS

115

Suppliers are a slightly special class of stakeholder: They are not usually involved in building, running, or using the system, but they may impose Con straints due to the limitations or requirements of the products they supply. For example, a software application may mandate a particular version of the operating system to run, or may run only on certain hardware configurations, or may impose limitations on the number of concurrent connections or maxi mum data size. It is essential that you factor such constraints into the design of the architecture.

Users
Users define the system's functionality and will ultimately make use of it. In the case of internal systems, users are internal staff who may be dealing with customers or performing back-office functions, In the case of a software prod uct, users are the eventual purchasers of the product; here it is necessary for the product manager to represent their interests in some way, for example, by market testing. In some scenarios (e.g., e-commerce or other customer-facing systems), users may be members of the public; again, it is necessary to repre sent their interests secondhand. Users' concerns obviously center around scope and functionality; how ever, they have operational concerns too, such as performance and security, although the architect may need to bring these to the users' attention.

Support Staff
Support staff (help desk, technical support, customer service departments, and so on) provide support to users of the product or system when it is run ning. Support staff concerns revolve around having the information required to solve problems with users who may be communicating via telephone, e-mail, or the Internet-or in person.

EXAMPLES
We can illustrate the characteristics of these stakeholder classes by means of some examples.

System Administrators
System administrators run the system once it has been deployed. In large scale commercial environments, system administrators play a key role be cause operation of the system is essential to the continuity of the business. In some scenarios, such as products aimed at the domestic PC market, the sys tem administrators may also be the users. System administrators may focus on a wide range of concerns, such as system monitoring and management, business continuity, disaster recovery, availability, resilience, and scalability.

An Off-the-Shelf Deployment Project

An off-the-shelf deployment project involves the selection, tailoring, and im plementation of an existing software package and so involves the develop ment of less software than a traditional system development project. However, the role of stakeholders is still vital, and many of the stakeholders from a traditional software development project are still relevant to an off-the shelf deployment project.

Testers
Testers act as the conscience of the system development team. They systemat ically test the system in order to establish whether or not it is suitable for de ployment and use. Although developers also perform testing, testers should be independent and do not have the same sense of ownership of the system's implementation. This, along with their specialist knowledge and experience, means that they can perform a more thorough and objective job of evaluating the system than the other stakeholders can. Testers may be part of the same team as the developers or may be in a separate organizational unit or even a distinct organization (e.g., independent testing may be subcontracted to a specialist testing company). Wherever they are found organizationally, testers are concerned with establishing require ments, designing tests to prove whether requirements have been met, and building systems on which to run their tests.

EXAMPLE Company A, a manufacturer of computer hardware, wants an enterprise resource planning (ERP) system to better manage all as pects of its supply chain from ordering through delivery. Management anticipates the system being constructed from a custom off-the-shelf (COTS) package combined with some in-house development for special ized aspects oJ functionality. The new system must be deployed within one year, in time for a meeting where shareholders will consider future funding for the company. Acquirers of the system include the business sponsor (senior man agement), who will authorize funding for the project, along with the purchasing department and representatives of IT, who will evaluate a number of potential ERP packages.

116

PART II

'

THE PROCESS OF SOFTWARE ARCHITECTURE

CHAPTER 9

IDENTIFYING AND ENGAGING STAKEHOLDERS

117

The users of the system cover a wide range of internal staff, including those who work in order entry, purchasing, finance, manufacturing, and distribution. Developers, system administrators, and maintainers are staff mem bers of the internal IT department, and assessors are taken from the in ternal acceptance test team. Communicators include internal trainers, and support is to be provided by an internal help desk (possibly in con junction with the COTS supplier).

A Partnered Development
A partnered development project involves one organization using the services of another to provide systems or services it would normally provide with its own internal resources. These projects result in stakeholders who would typi cally be found within the acquiring organization actually being found within the external service organization. This can make it more difficult to identify and interact with these stakeholders.

A Software Product Development Project

A software product is usually developed by a specialist supplier, with the de velopment often partially funded by external investors. The intended users of the product will be in other organizations that, it is hoped, will purchase the product once it is complete. The stakeholders for such projects are often spread across a number of organizations.

EXAMPLE Company B, an educational software supplier, wants to de velop a product that will be used by college lecturers to manage their schedules of classes. Company B has formed a partnership with a local college and has obtained some venture capital funding for the product. The system will run on PCs and will be inexpensive and easy to operate. Acquirers in this case include senior management and product man agers at Company B, the educational partner, and representatives from the venture capitalists. Users of the system are college lecturers and administrative staff; note that these users do not actually exist as such because no one has yet bought the product. User representation will have to be obtained in some other way (e.g., by talking to some potential users of the product) . Developers and maintainers are product development staff from Com pany B, and assessors are taken from the three partner organizations. There are no real system administrator stakeholders in this example (this needs to be factored into the architecture, for example, by making the system self-managing). Support staff might be provided by Company B and/or colleges that buy the product. Communicators include technical authors from Company B who write the user guide.

EXAMPLE Company C, an established financial organization, wishes to expand its presence on the Internet with the ability to market a range of financial services to members of the public. These services are aimed at residents of the country where Company C is based, as well as some in ternational customers. Company C plans to contract out the development and operation of the system to an established Web developer. Acquirers include senior managers who will authorize funding for the project. Users include ordinary members of the public, who will access the public-facing Web site (as in the previous example, these don't exist yet), along with internal administrative staff, who will carry out its back-office functions. Developers and system administrators are staff from the Web devel opment company. Assessors include Company C's internal accounting and legal staff, as well as external financial regulators from any country in which Company C wants to trade. Communicators and support staff are provided by Company C and/or the Web development company.

PROXY STAKEHOLDERS
We can see from the examples in the previous section that it may not be pos sible to identify all stakeholders until the system is developed. While some stakeholders will almost always be identifiable-particularly the acquirers and probably the users-others may not physically exist as a group. In these situations, you must identify proxy stakeholders. The proxy is an individual or group who predicts the concerns of the real stakeholders and ensures that they are given as much weight as other concerns. For a new product, for example, the user stakeholders are potential cus tomers. Your proxy user stakeholders might be the product managers from the marketing group, armed with the results of market testing, or members of the target user population willing to be involved in the product's inception.

118

PART II

THE PROCESS OF SOFTWARE ARCHITECTURE

CHAPTER 9

IDENTIFYING AND ENGAGING STAKEHOLDERS

119

lID

When real stakeholders cannot be identified (e.g., when a User community does not yet exist), the architect should identify proxy stakehold ers to represent their interests. As much as possible, the proxy stakeholders should meet the same criteria as their real counterparts.
STRATEGY

CHECKLIST
Have you identified at least One stakeholder of each class? If not, is the omission justified? Have you informed the stakeholders of their responsibilities (e.g., as de fined in the previous section), and have they agreed to these? In particular, does each stakeholder understand the level of commitment involved, in terms of attending meetings, reViewing documents, and making decisions? Is each stakeholder aware of the particular role to fulfill (acquirer, user, and so on)? For each group of stakeholders, have you identified and engaged a suit able representative? Does this proxy have the knowledge and authority to speak on behalf of the group? For each stakeholder group that does not yet exist (e.g., customers for a new software product), have you identified and engaged a suitable proxy? If suppliers are to be included as stakeholders, are their responsibilities and (if appropriate) contractual obligations clearly understood by both sides?

STAKEHOLDER GROUPS
Another possible complication occurs when a stakeholder actually represents a class of person, such as user or developer, rather than an individual. It may be impossible to capture and reconcile the needs of all members of the class in the time you have available, or you may not have the stakeholders at hand (e.g., in the case of potential users of a new product in development). A stakeholder can also be a more external group, such as a professional standards body, the company's quality assurance department, or external le gal regulators. The same principle applies in this case-you need to select rep resentative stakeholders authorized to stand in for the whole group.

lIJ

Where a stakeholder comprises a group, team, or organization, it is necessary to select and authorize one or more stakeholder representatives to speak for the group.
STRATEGY

SUMMARY
Understanding the role of the stakeholder is fundamental to understanding the role of architecture in the development of a software product or system. In this chapter, we showed how to select good stakeholders-those who are in formed, committed, authorized, and representative-and defined a set of stakeholder classes, including the folloWing: Acquirers, who oversee the procurement of the system or product Assessors, who oversee the system's conformance to standards and legal regulation Communicators, who explain the system to other stakeholders Developers, who construct and deploy the system from specifications Maintainers, who manage the evolution of the system once it is operational Suppliers, a special class of stakeholders who may impose constraints on the architecture due to characteristics of their products Support staff, who proVide support to users for the product or system when it is running

STAKEHOLDERS' RESPONSIBILITIES
Effective stakeholders fulfill the following responsibilities. They ensure that all of their concerns are clearly communicated to the architect. Representative or proxy stakeholders clearly convey to the architect all of the concerns of the people they represent. They make decisions in a timely and authoritative manner and stick to them. If the stakeholders do not have the authority to make a decision, they es calate it appropriately and obtain a decision from someone who has that power. They review the AD to ensure that the system meets their concerns and is-as far as they can ascertain-functionally correct.

I
I

r..
;, ,

120
PART

II THE PROCESS OF SOFTWARE ARCHITECTURE

;:1

.. ......
'

, ,

System administrators, who run the system once it has been deployed Testers, who test the system to ensure that it is fit for use Users, who define the system's functionality and will ultimately make use of it We also discussed proxy stakeholders, who represent the interests of temporarily nonexistent stakeholders (such as the users of a new product), and explained the responsibilities of stakeholders in general.

10
I DENTI FYI NG
AND USING SCENARIOS
your stakeholders. practical terms, this T needs ofon your architecturalIndesign must be able tomeans that the system built based perform certain tasks while exhibiting certain properties (such as its performance or security) that are important to the stakeholders. Architecture definition is inevitably a process of complex tradeoffs be tween competing needs. In the midst of this, it is very easy for you to lose sight of a particular system's key priorities and for these tradeoffs to start be ing driven by personal preferences or imagination, rather than stakeholder needs. A good way to stay grounded when developing your architecture is to continually consider how the ideas you are developing will actually work in practice. One of the most powerful techniques we have come across is to de fine and apply scenados to your architecture. The idea of an architectural scenario is simple but worth defining formally nonetheless. he most important goal of your software architecture is that it meets the

FURTHER READING
As mentioned at the beginning of this chapter, we based our definition of stakeholders on that presented by the IEEE standard Recommended Practice Jor Architectural Descdption [IEEEOO], which defines stakeholders in terms of an architecture definition process. Several software architecture books [BASS03; CLEM02; GARL03] have useful discussions of the idea of an architectural stakeholder.

DEFINITION An architectural scenario is a crisp, concise description of a situation that the system is likely to face in its production environment, along with a definition of the response required of the system.

A scenario can capture a particular set of interactions with its users to which the system must be able to respond, the processing that must happen at a particular poim in time (such as month end), a particular peak load situ ation that could occur, a change that might need to be made to the system. or any other situation that the system needs to be designed to handle.