16.4 Stakeholder Priorities

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 Representatives

User 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.

1. Stock must be available on the shelf. The ability to fill basic orders for items directly from the shelf is essential. Therefore, the basic management of inventory is a top priority, including computing required on-hand quantities and requisitioning new items from wholesale sources.

2. Stock must move from the shelf to the customer. Customers must be able to place their orders using a catalog and knowing the availability of substitutes. The retail clerk must be able to release the items to the customer and know that the inventory balance will reflect the transaction.

3. Inventory must be controlled. Support for receiving property into the warehouse or retail location must be automated. On-hand balances must be continually updated so that inventory position is available on demand.

4. Allocation of assets among retail locations must be tracked. Stockpiling of assets in one location to the detriment of another location must be avoided. Methods to monitor and rectify stock levels by lateral moves of property must be supported.

Architecture Team

Work 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.

1. Do things first that may be used by others. Throughout the organization, pockets of software had developed over the years . This resulted in considerable amounts of redundant code supporting basic capabilities. Any basic capability, such as inventory, had a good chance of being reused by other groups because many departments had varying needs to keep goods on their shelves .

2. Look at other modernization efforts in the organization. Across the organization, other, decentralized, development groups were planning modernization efforts. In the cases where these other groups were developing similar components, it made sense to develop common components that could serve both groups' requirements.

3. Seek early interoperability with external suppliers and systems. The architecture team promoted the adoption of industry standards. Standardization was expected to promote interoperability within the organization. However, OAGIS was also expected to better automate activities with suppliers and to provide opportunities to use off-the-shelf software products compliant with OAGIS.

4. Start with the Audit/History business object. The architecture team had performed considerable analysis to support selecting the Audit/History business object for the first increment. The main points of the argument were its relatively small size and low complexity. Functionally, it was expected to be the last action taken for all transactions. This meant that legacy-side adapters would not contend with returning values from a component but would be one-way: legacy to modern business object. Another attractive feature was that auditing requirements were stable. There was little likelihood of requirements churn or disagreement among the parties as to what was expected. The architecture team conceded that Audit/History was sensitive to a myriad of transactions, lessening its direct, unchanged usability across the organization. But the team countered with the attractiveness of Audit/History as pilot work. The qualities of this business object made it a low-risk effort suitable for a newly assembled team using unfamiliar technology.

Legacy System Maintainers

The 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]

^[1] It is interesting to note that this list is not ordered by the most frequently occurring transactions or by program elements that have become especially difficult and expensive to maintain.

• Receipt of goods

• Nondirected shipments

• Changes to descriptions of goods

• Reversal of transactions

• Freezing of inventory items

• Basic inquiry

• All remaining transactions

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.

Management

Management'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:

1. It should represent the overall program and mitigate as many risks as possible as early as possible.

2. It should be large enough to produce a fieldable product. This was reasoned to be about 10 percent of the entire effort, or about 6 months of work.

3. It should touch on complexity, integration framework services, and data management. Complexity would include samples of business objects, business object documents, adapters, and legacy COBOL working together. The integration framework services, such as security and portal presentation layer, should be exercised. Data management included its availability to operational data stores and data warehouse projects.

Observations

None 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.