Each group of stakeholders evaluates the componentization plan from its particular perspective. In the RSS case study, stakeholder views varied from, "I need to see risk mitigated early on; you can't squeeze it all out to the end" to "That sure looks like it will cause a lot of hard work on the legacy side." For the list of stakeholders in the RSS case study and their perspectives, see Section 4.2. The desires of each group, as captured during the individual meetings to construct the ideal profiles, follows . User RepresentativesUser representatives have the functional expertise required to carry out retail activities. These activities include, for example, ordering and shelving items, storing and picking, and resolving bottlenecks. Certain functions are so basic to the tasks the users perform on a daily basis that they have no trouble expressing their priorities. To some degree, the user representatives' priorities are neutralized by the choice of delivering a complete, operational system with each increment. This is best explained with the question: "If I get all functionality in some form or other every time, why do I care what order that you do it in?" However, considering that desired system improvements had been collecting in a backlog of legacy change requests for some time, the users keenly felt a need to put their core , critical activities first so that the promise of maintainable components could be quickly exploited. Their activities, listed in priority order, are as follows.
Architecture TeamWork on the enterprise architecture began at the organizational level before the start of the RSS modernization effort. The architecture team had already adopted the OAG model and its integration specification, OAGIS, as described in Section 9.5 and in Chapter 11. The architecture team used the concept of a business object to coalesce and encapsulate associated business logic. Therefore, the business object was viewed as the ideal measure of progress. The architecture team's perspective was enterprise-wide, as demonstrated in its priorities.
Legacy System MaintainersThe legacy maintainers advocated tackling the modernization effort based on transactions in the legacy system. In this view, dynamic analysis would identify a particular execution path for a given transaction and set of parameters. The legacy maintainers argued that extracting a complete transaction would have little impact on the legacy system. Given the maintainers' reasonable desire to minimize impact to the legacy system, the transaction approach made sense. Using logic similar to that used in the development of SAM, the maintainers saw the value of keeping program elements in logically related groups. As a result, the maintainers proposed logical groupings based on the transaction types that correspond to the following business events: [1]
A concern in following this approach was that these transactions might easily exercise large portions of the legacy system, resulting in one or two enormous increments that would countermand the incremental development and deployment approach. ManagementManagement's primary concern is managing risk. Risk was considered more important than achieving the corporate architecture, avoiding costs, or avoiding rework . Management was adamant that componentization was the view around which the project would be managed. In effect, the new architecture should take its place as the system's vision. Management had two other notable perspectives. The managers thought it important to begin with the retail supply core processes. The example given was the Inventory business object. The supply organization's ownership of inventory processes was not debatable. The managers' other perspective anticipated the scrutiny of midlevel management and of independent testers for additional operational testing. It was clear that each iteration's products must be testable as logical units. The management view of the first-iteration priorities was as follows:
ObservationsNone of the groups provided the order in which business objects should be completed. At this point, business object order was a dependent variable in SAM. Concerns among the groups often overlapped . Some of this stemmed from participants' previous experiences and some because a few participants contributed to more than one group. The exercise seemed to bring out the "manager" in all the participants. Recurring themes included the constraint that different priorities would impact the difficulty of the modernization effort and the view that the initial increment should serve as a pilot effort to reduce risk. |