16.5 Stakeholder Ideal Profiles


To create the stakeholder profiles, we translated stakeholder priorities into inputs for SAM. As described in Chapter 15, SAM bases its analysis on logically related groups of data. The translation required mapping program elements to database records, program elements to business objects, and transactions to program elements. Subjective decisions arose in defining the boundaries of logical data groupings. Because of the tangled relationships between call structure and data access, consultation between the SAM operator and a requirements analyst was often required to resolve boundary disputes. There was also a temptation to bias data groups to better distribute size across the iterations. Unfortunately, this could bias the results so that less viable profiles appeared less costly than they were.

Figure 16-1 illustrates the relative size of the business objects and remains constant for each profile. Each profile consisted of three graphs:

  1. Size dispersed over increments . Size for business objects was estimated using a lines-of-code (LOC) count of the corresponding legacy program elements.

  2. Ratio of program elements to adapters. This bar graph shows the number of program elements migrated in an increment and the corresponding number of adapters produced during the increment. Adapters from the legacy system to the modern component ”adapters ”are distinguished from adapters from modern component to the legacy system ”inverse adapters.

  3. Business object completion. These graphs illustrate the degree to which a business object is completed at the end of an increment. As already mentioned, business object completion was a primary progress indicator.

Figure 16-1. Size of business objects

graphics/16fig01.gif

The remainder of this section presents each stakeholder group 's ideal project profile, highlights areas for potential compromise, and provides some observations.

User Representatives

Figures 16-2, 16-3 and 16-4 illustrate the user representative profile. As shown in Figure 16-3, this profile resulted in two large initial increments, conflicting with the desires of both the architecture team and management for a small initial increment.

Figure 16-2. User representative profile: size of increments

graphics/16fig02.gif

Figure 16-3. User representative profile: program elements versus adapters

graphics/16fig03.gif

Figure 16-4. User representative profile: business object completion

graphics/16fig04.gif

Figure 16-3 illustrates the user representatives' priorities resulting in the highest number of program elements affected during the first increment (118), as well as a significant number of adapters of both types ( subtotal of 48). This indicates that the first increment would be challenging and conflict with management's perception of risk. This profile also required a total of 95 adapters, a number sure to get the legacy maintainers' attention.

The user representative profile shown in Figure 16-4 results in the following order of business object completion:

  • Increment 1 ” Requisition

  • Increment 2 ” Demand Planning

  • Increment 3 ” Orders, Inventory, and Work in Process

  • Increment 4 ” Audit History, Asset Management, and Funds Control

  • Increment 5 ” Catalog and System Management

The user representatives' low value of Audit History and Catalog ”because of their limited contribution to this group's daily tasks ”was another area of potential conflict. Conversely, these two business objects were attractive to management because of their relatively small size and perceived low complexity. The fragmentation of business object work over the increments appeared to be within the architecture team's tolerances.

Architecture Team

Figures 16-5, 16-6 and 16-7 define the architecture team's profile. The architecture team's first increment represented 8 percent of the total system size, which was consistent with management requirements. The shape of the curve is appealing with its smooth ramp-up , but drops off in increment 5.

Figure 16-5. Architecture team profile: size of increments

graphics/16fig05.gif

Figure 16-6. Architecture team profile: program elements versus adapters

graphics/16fig06.gif

Figure 16-7. Architecture team profile: business object completion

graphics/16fig07.gif

The architecture team's priorities required 77 adapters ”18 fewer than in the user representative profile. The first increment does not include inverse adapters, so it fails to address management's concern that the initial increment touch all elements of the modernization effort. The third increment of the architecture team's profile includes the most program elements (99), still slightly fewer than the user representative's 118 in the first increment.

As requested by the architecture team, History/Audit finished in the first increment. To keep the increment small, the interfaces for the other business objects provided the inputs required by History/Audit, but little else was targeted . Fragmentation of business object work was surprisingly high, as several required four increments to complete, and one required work in all five. The order of completion was as follows :

  • Increment 1 ” History/Audit

  • Increment 2 ” Funds Control

  • Increment 3 ” Requisition and Catalog

  • Increment 4 ” Orders, Work in Process, and Asset Management

  • Increment 5 ” Inventory, Demand Planning, and System Management

The fact that Inventory is not completed until the last increment conflicts with those stakeholders who believe inventory to be a core , irrefutable supply function that should be addressed early.

Legacy System Maintainers

Figures 16-8, 16-9 and 16-10 illustrate the legacy system maintainers' profile. The legacy maintainers' approach decoupled the dependencies between increments. Some 481K lines of code, or 62 percent of the total system size, were allocated to the flexible category. This category was reserved for work that could be allocated to any increment.

Figure 16-8. Legacy maintainer profile: size of increments

graphics/16fig08.gif

Figure 16-9. Legacy maintainer profile: program elements versus adapters

graphics/16fig09.gif

Figure 16-10. Legacy maintainer profile: business object completion

graphics/16fig10.gif

The legacy system maintainers' profile had the lowest number (41) of adapters. These 41 adapters were all of the legacy-to-component variety, which would reduce the overall amount of complexity involved in the modernization effort.

Business object completion for the legacy system maintainers showed a considerable degree of flexibility. The program elements in the category of flexible allocation could make a number of orders practical. For example, History/Audit could be first, followed by anyone 's choice.

Management

Figures 16-11, 16-12 and 16-13 illustrate the management profile. The managers' effort did not fully align with their own desires and reflects compromise. The second increment was large, at 437K lines of code, or 56 percent of total system size.

Figure 16-11. Management profile: size of increments

graphics/16fig11.gif

Figure 16-12. Management profile: program elements versus adapters

graphics/16fig12.gif

Figure 16-13. Management profile: business object completion

graphics/16fig13.gif

A positive side effect of this profile was that most adapter work was concentrated in the big second increment. This could also be viewed as a risk. However, the total number of adapters for this profile was 63, not as low as for the maintainers' profile (41) but still 32 fewer than in the user representatives' profile.

Fragmentation of business object work was low, with five business objects requiring three increments. The bulk of work was slated for the second and third increments. The management profile completed business objects in the following order:

  • Increment 1 ” History/Audit

  • Increment 2 ” Inventory

  • Increment 3 ” Orders, Work in Process, Catalog, Asset Management, and Funds Control

  • Increment 4 ” Requisition

  • Increment 5 ” Demand Planning and System Management

Completing Inventory in the second increment was a good omen for consensus building, but Demand Planning was a priority for user representatives, and they were unlikely to wait until the last increment.



Modernizing Legacy Systems
Modernizing Legacy Systems: Software Technologies, Engineering Processes, and Business Practices
ISBN: 0321118847
EAN: 2147483647
Year: 2003
Pages: 142

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net