identifying and engaging stakeholders

8/2/2019 Identifying and Engaging Stakeholders

1/7

108

PART II THE PROCESS OF SOFTWARE ARCHITECTURE I

We explained that a good way to visually represent aspects of the scope isto use a context diagram. Production of such a diagram is a good way to beginyour work with the stakeholders.We explained that stakeholder concerns may be specific and measurable 9in which case. we call them requirements) or may be vague and looselystated but n onetheless still important to your stakeholders. We described howto effectively document your stakeholders' concerns.We defined an architectural principle as a fundamental statement of belief. approach. or intent that guides the definition of an architecture. We explained how principles are extremely useful in creating a framework forarchitecture definition and showed how you can use principles to trace backyour architectural decisions to business drivers and goals.Finally. we considered various types of architectural constraints. such asstandards. guidelines. strategies. and policies. You must take all of these intoaccount when designing your architecture.

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

IDENTIFYING AND ENGAGINGSTAKEHOLDERS

A s we saw in Part 1, the people affected by a system are not limited those who use it. Systems are not just used: They have to be designand built; they have to be operated; they may have to be repaired; they ausually enhanced; and. of course, they have to be paidJor.Each of these activities involves a number-possibly a significant number-of people distinct from the users. Each of these groups of people has own requirements. its own interests. and its own needs from the system. Wrefer collectively to these people as stakeholders. In Part 1we defined a stakholder as follows.

DEFINITION A stakeholder in a software architecture is a person. group. entity with an interest in or concerns about the realization of the architecturCorrectly identifying stakeholders and gaining their commitment is oof the most important (yet underrated) tasks in software development. Tconcept of architectural stakeholder is clearly explained in the IEEE standaRecommended Practice Jor Architectural Description. and our discussibuilds on theirs.

SELECTION OF STAKEHOLDERSIt is. in our experience. a subjective choice whom you select to populate yocommunity of stakeholders. We have found, however, that casting your nmore widely at the beginning is important in the long term (although in th


2/7

110 PART II THE PROCESS OF SOFTWARE ARCHITECTURE .pr. "c ' CHAPTER 9 IDENTIFYING AND ENGAGING STAKEHOLDERS,tshort 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, youcan be sure that they will complain at the end, when making changes is muchharder-and making architectural changes may be practically impossible.

STRATEGY The selection of stakeholders is a subjective activity; b ut in general, the wider the s takeholder community, the better you r chances of delivering a successful product or system.

[IDUnfortunately, there are no purely objective criteria for determiningwhether you ha ve correctly identified your stakeholders. Whom you select depends on a range of factors including the goals of the system, organizationaland political considerations, availability of resources, and cost and timescaleconstraints.(We sometimes find, for example, that stakeholders are consulted in aspirit of openness, to demonstrate a desire to reflect a wide range of concerns, rather than an absolute need to take account of their views. There isabsolutely nothing wrong with this, as long as it contributes to the success ofthe 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 thatyou 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 tohelp make sure your list is right.

PRINCIPLE A good stakeholder in an architecture is i'lformed, committed, authonzed, and representative.We explain each of these criteria in Table 9-1.

TABLE 9- 1 CRITERIA FOR A GOOD STAKEHOLDER

Criterion Description- - ' " - - ~ . , - , , - - , - , _ . ~ - , ~ - - _ . _ - , - ~ - - - ~ - - ~ - ~ - , - _ . __ ..._-__ .".Informed Do your stakeholders have th e information, the experience,and the understanding needed to make the right decisions?

- - - - - - - --,- ,.--- --- . -.._ ,. , " , . _ . _ , . _ ~ ~ - - - - ~ _ . ~ - - - ~ Committed Are your stakeholders willing and able to make themselves

TABLE 9- 1 CRITERIA FOR A GOOD STAKEHOLDER (CONTINUEO)Criterion DescriptionAuthorized Can you be sure that decisions made now by your stakeholdwill not be reversed later (at potentially high cost)?Representative If a stakeholder is a group rather than a person, have suitarepresentatives been selected from the group? Do those repsentatives meet the above criteria for individual stakeholde

CLASSES OF STAKEHOLDERSIn Table 9-2, we classify stakeholders according to their roles and concernsMost system development projects include representatives from mosnot all of these stakeholder groups, although their relative importance will oviously vary from project to project. However, if you do not at least consieach class, you will have problems in the future.

Widening your set of stakeholders leads to a tradeoff-the larger group, the more difficult it will be to reach a consensus. Part of the architecrole is to ensure that large stakeholder communities do not become an obsta

TABLE 9- 2 STAKEHOLDER ROLES

Stakeholder Class Description. " ..Acquirers Oversee the procurement of the system or product

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


3/7

12 PART 1/ l THE PROCESS OF SOFTWARE ARCHITECTURE i CHAPTER 9 ' IDENTIFYING AND ENGAGING STAKEHOLDERSto making progress. This requires you to actively manage the decision-makingprocess and have a clear understanding of the relative importance of the needsof each stakeholder group. Doing this will help you defend your architecturaldecisions when challenged by stakeholders who feel that their needs havebeen ignored.STRATEGY If you have a large stakeholder group, you need to actively manage it to ensure that its size does not impede progress. In particular, you needl!J to balance and prioritize the needs of the different stakeholder groups, so thatwhen conflicts occur, you can make sound, well-reasoned decisions.

It is also worth noting that, although we don't consider the architect'sneeds explicitly, when acting in that role you are also an architectural stakeholder. (We assume that you can represent yourself adequately to ensure thatyour views are taken into account!)PRINCIPLE The architect must ensure that there is adequate stakeholder rep resentation across the board, including nontechnology stakeholders (such asacquirers and users) and technology-focused ones (such as developers, system administrators, and maintainers).

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

AcquirersAcquirers oversee the procurement of the system or product. Acquirers typically include senior management, which provides or authorizes funding forproduct or system development, and may also include the purchasing and legal departments, which represent the commercial interests of users in negotiations with third-party suppliers.In a system development project, acquirers are often referred to as business sponsors, and for a product development, acquirers are likely to be senior executives from the sales, marketing, and technology groups. There mayalso be investor representation in this group if specific external investment isrequired to fund the project. In seniority terms, acquirers are usually yourmost important stakeholders.Acquirers' concerns typically center around issues such as alignment withstrategic objectives, return on investment, and the costs, timescales, plans,and resources involved in building and running the system. Their goals areusually value for money and efficient expenditure of resources during delivery and operation.

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

CommunicatorsCommunicators explain the system to other stakeholders. Internal or putrainers provide training for support staff, developers, maintainers, and soand technical authors create manuals for the users and administrators ofproduct or system. In the case of a product, the marketing department needcommunicate its key features, strengths, and benefits to potential customeCommunicators' interests lie in understanding the rationale behind the details of the architecture and explaining it to technical and lay audienc

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

MaintainersMaintainers manage the evolution of the system once it is operational. Matainers' concerns focus on issues such as development documentation, instmentation (facilities for operational system monitoring), debug environmenproduction change control, and the preservation of knowledge over time.SuppliersSuppliers build and/or supply the hardware, software, or infrastructure owhich the system will run, or possibly they provide specialized staff for sytem development or operation.


4/7

. , , , '1 CHAPTER 9 IDENTIFYING AND ENGAGING STAKEHOLDERS14 PART II ' THE PROCESS OF SOFTWARE ARCHITECTUREI

Suppliers are a slightly special class of stakeholder: They are not usually Usersinvolved 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 theoperating system to run, or may run only on certain hardware configurations,or may impose limitations on the numbe r of concurrent connections or maximum data size. It is essential that you factor such constraints into the designof the architecture.Support StaffSupport staff (help desk, technical support, customer service departments,and so on) provide support to users of the product or system when it is running. Support staff concerns revolve around having the information requiredto solve problems with users who may be communicating via telephone, e-mail,or the Internet-or in person.

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

TestersTesters act as the conscience of the system development team. They systematically test the system in order to establish whether or not it is suitable for deployment and use. Although developers also perform testing, testers shouldbe independent and do not have the same sense of ownership of the system'simplementation. This, along with their specialist knowledge and experience,means that they can perform a more thorough and objective job of evaluatingthe system than the other stakeholders can.Testers may be part of the same team as the developers or may be in aseparate organizational uni t or even a distinct organization (e.g., independenttesting may be subcontracted to a specialist testing company). Wherever theyare found organizationally, testers are concerned with establishing requirements, designing tests to prove whether requirements have been met, andbuilding systems on which to run their tests.

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

EXAMPLESWe can illustrate the characteristics of these stakeholder classes by meanssome examples.

An Off-the-Shelf Deployment ProjectAn off-the-shelf deployment project involves the selection, tailoring, and implementation of an existing software package and so involves the develoment of less software than a traditional system development projecHowever, the role of stakeholders is still vital, and many of the stakeholdefrom a traditional software development project are still relevant to an off-thshelf deployment project.

EXAMPLE Company A, a manufacturer of computer hardware, wan ts an enterprise resource planning (ERP) system to better manage all aspects of its supply chain from ordering through delivery. Managementanticipates the system being constructed from a custom off-the-shelf(COTS) package combined with some in-house development for specialized aspects oJ functionality. The new system must be deployed withinone year, in time for a meeting where shareholders will consider futurefunding for the company.

Acquirers of the system include the business sponsor (senior management), who will authorize funding for the project, along with thepurchasing department and representatives of IT, who will evaluate anumber of potential ERP packages.


5/7

116 PART II ' THE PROCESS OF SOFTWARE ARCHITECTURE r CHAPTER 9 IDENTIFYING AND ENGAGING STAKEHOLDERS 11!The users of the system cover a wide range of internal staff, includingthose who work in order entry, purchasing, finance, manufacturing, and

distribution.Developers, system administrators, and maintainers are staff members of the internal IT department, and assessors are taken from the internal acceptance test team. Communicators include internal trainers,and support is to be provided by an internal help desk (possibly in conjunction with the COTS supplier).

A Software Product Development ProjectA software product is usually developed by a specialist supplier, with the development often partially funded by external investors. The intended users ofthe product will be in other organizations that, it is hoped, will purchase theproduct once it is complete. The stakeholders for such projects are oftenspread 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 theirschedules of classes. Company B has formed a partnership with a localcollege 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 managers at Company B, the educational partner, and representatives fromthe 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 hasyet bought the product. User representation will have to be obtainedin some other way (e.g., by talking to some potential users of theproduct) .Developers and maintainers are product development staff from Company B, and assessors are taken from the three partner organizations.There are no real system administrator st akeholders in this example(this needs to be factored into the architecture, for example, by makingthe system self-managing). Support staff might be provided by CompanyB and/or colleges that buy the product.Communicators include technical authors from Company B who writethe user guide.

A Partnered DevelopmentA partnered development project involves one organization using the serviceof another to provide systems or services it would normally provide with itown internal resources. These projects result in stakeholders who would typcally be found within the acquiring organization actually being found withthe external service organization. This can make it more difficult to identiand interact with these stakeholders.

EXAMPLE Company C, an established financial organization, wishes toexpand its presence on the Internet with the ability to market a range offinancial services to members of the public. These services are aimed atresidents of the country where Company C is based, as well as some international customers. Company C plans to contract out the developmentand operation of the system to an established Web developer.Acquirers include senior managers who will authorize funding for theproject. Users include ordinary members of the public, who will accessthe public-facing Web site (as in the previous example, these don' t existyet), along with internal administrative staff, who will carry out itsback-office functions.Developers and system admini strators are staff from the Web development company. Assessors include Company C's internal accountingand legal staff, as well as external financial regulators from any countryin which Company Cwa nts to trade.Communicators and suppo rt staff are provided by Company Ca nd/orthe Web development company.

PROXY STAKEHOLDERSWe can see from the examples in the previous section that it may not be possible to identify all stakeholders until the system is developed. While somstakeholders will almost always be identifiable-particularly the acquireand probably the users-others may not physically exist as a group. In thessituations, you must identify proxy stakeholders. The proxy is an individuor group who predicts the concerns of the real stakeholders and ensures thathey are given as much weight as other concerns.For a new product, for example, the user stakeholders are potential cutomers. Your proxy user stakeholders might be the product managers fromthe marketing group, armed with the results of market testing, or members the target user population willing to be involved in the product's inception.


6/7

CHAPTER 9 IDENTIFYING AND ENGAGING STAKEHOLDERS18 PART II THE PROCESS OF SOFTWARE ARCHITECTURE

CHECKLISTSTRATEGY When real stakeholders cannot be identified (e.g., when a Usercommunity does not yet exist), the architect should identify proxy stakeholdlID ers to represent their interests. As much as possible, the proxy stakeholdersshould meet the same criteria as their real counterparts.STAKEHOLDER GROUPS

Another possible complication occurs when a stakeholder actually representsa class of person, such as user or developer, rather than an individual. It maybe impossible to capture an d reconcile the needs of all members of the class inthe 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 professionalstandards body, the company's quality assurance department, or external legal regulators. The same principle applies in this case-you need to select representative stakeholders authorized to stand in for the whole group.

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

STAKEHOLDERS' RESPONSIBILITIESEffective stakeholders fulfill the following responsibilities.

They ensure that all of their concerns are clearly communicated to thearchitect. Representative or proxy stakeholders clearly convey to the architect all ofthe concerns of the people they represent. I They make decisions in a timely and authoritative manner and stick to rthem. I If the stakeholders do not have the authority to make a decision, they escalate it appropriately and obtain a decision from someone who has thatpower. They review the AD to ensure that the system meets their concerns andis-as far as they can ascertain-functionally correct.

Have you identified at least One stakeholder of each class? If not, is omission justified? Have you informed the stakeho lders of their responsibilities (e.g., asfined in the previous section), and have they agreed to these? In particular, does each stakeholder unders tand the level of commitminvolved, in terms of attending meetings, reViewing documents, andmaking decisions? Is each stakeholder aware of the particular role to fulfill (acquirer, usand so on)? For each group of stakeholders, have you identified and engaged a suable representative? Does this proxy have the knowledge and authorito speak on behalf of the group? For each stakeholder group that does not yet exist (e.g., customers for new software product), have you identified and engaged a suitable pro If suppliers are to be included as stakeholders, are their responsibilitiand (if appropriate) contractual obligations clearly understood by bo tsides?

SUMMARYUnderstanding the role of the stakeholder is fundamental to understandthe role of architecture in the development of a software product or system.this chapter, we showed how to select good stakeholders-those who are formed, committed, authorized, and representative-and defined a set 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 legregulation Communicators, who explain the system to other s takeholders Developers, who construct and deploy the system from specifications Maintainers, who manage the evolution of the system once it isoperational Suppliers, a special class of stakeholders who may impose constraints othe architecture due to characteristics of their products Support staff, who proVide suppor t to users for the product or systemwhen it is running


7/7

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 tha t it is fit for use Users, who define the system' s functionality and will ultimately make

use of itWe 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.

FURTHER READINGAs mentioned at the beginning of this chapter, we based our definition ofstakeholders on that presented by the IEEE standard Recommended PracticeJor Architectural Descdption [IEEEOO], which defines stakeholders in termsof an architecture definition process.Several software architecture books [BASS03; CLEM02; GARL03] haveuseful discussions of the idea of an architectural stakeholder.

..' 10IDENTIFYINGAND USING SCENARIOS

T he most important goal of your software architecture is that it meetsneeds of your stakeholders. In practical terms, this means that the sysbuilt based on your architectural design must be able to perform certain tawhile exhibiting certain properties (such as its performance or security)are important to the stakeholders.Architecture definition is inevitably a process of complex tradeoffs tween competing needs. In the midst of this, it is very easy for you to sight of a particular system's key priorities and for these tradeoffs to starting driven by personal preferences or imagination, rather than stakehoneeds.A good way to stay grounded when developing your architecture icontinually consider how the ideas you are developing will actually workpractice. One of the most powerful techniques we have come across is to fine and apply scenados to your architecture.The idea of an architectural scenario is simple but worth defining formnonetheless.

DEFINITION An architectural scenario is a crisp, concise description situation that the system is likely to face in its production environment, alwith a definition of the response required of the system.A scenario can capture a particular set of interactions with its userswhich the system must be able to respond, the processing that must hap

at a particular poim in time (such as month end), a particular peak load sation that could occur, a change that might need to be made to the systemany other situation that the system needs to be designed to handle.

identifying and engaging stakeholders

Documents