| As mentioned briefly in Chapter 3, stakeholders are people with a vested interest in the system. They typically include developers, testers, maintainers, system administrators, customers, vendors , sponsors, end users, architects , and representatives of interacting systems. RSS has five recognized groups of stakeholders: -
User groups: individuals who represent the various classes of RSS system users. Most were once users themselves but have gone on to management positions . These user representatives are able to represent the views of system users; understand the user characteristics, such as average time on job and educational background; have an understanding of business needs; and understand the impact of proposed solutions on training. Using managers as user representatives is a risk because they may be too detached from day-to-day operations. Operational users may provide too narrow a view of business needs. The major risk, however, is in not including user representatives, which may lead to a system that is not accepted. -
Development team: architects, designers, programmers, and testers. These people may or may not be familiar with the legacy system but are familiar with the modern technologies. Architects on the development team are responsible for the RSS-specific architecture. (By contrast, the architects on the architecture team are responsible for the corporatewide architecture.) The risk of not involving the development team is that its members may lack motivation to implement a plan they do not have confidence in. -
Architecture team: responsible for the corporatewide architecture that the development team has to adhere to in designing the RSS-specific architecture. The architecture team reports through a different management structure than the team responsible for the modernization effort. This arrangement is not unusual. An architecture team typically directs multiple simultaneous projects within an organization. Not having the architecture team as stakeholders may lead to a system that is inconsistent with organizational goals and objectives. -
Legacy system maintainers: programmers and engineers who have been maintaining the legacy system for more than 30 years . Their experience and knowledge are essential for the modernization effort; however, they can feel threatened by the eventual replacement of the system. -
Management: a focal point for pressures from within the organization and, to a lesser degree, entities outside the organization. Management is concerned primarily with accomplishing business objectives within defined cost and schedule constraints. Not including management may produce a modernization strategy that falls outside of these constraints. In general, stakeholders each bring their own unique perspectives, which are often at odds. For example, the architecture team is concerned primarily with corporatewide interoperability, cost reduction through sitewide licenses, and conformance to a standard architecture. The development team is concerned about the compatibility between specific products and the legacy system, modernizing the system within budget and schedule constraints, and achieving required system qualities. The perceived needs of the development team often conflict with the needs of the architecture team. For example, the development team may want to use a product that is compatible with the legacy software but not included in the corporate baseline required by the architecture group . The manner in which competing stakeholder interests are resolved depends on organizational structure, personalities, and so forth. |
