Applying the Incremental Commitment Model to Brownfield System Development

Transcription

1 Applying the Incremental Commitment Model to Brownfield System Development Barry Boehm 1 1 University of Southern California, USA, boehm@usc.edu Abstract The Incremental Commitment Model (ICM) is a risk-driven process model generator for which common risk patterns generate common special-case system definition and development process models. The increasing importance of Brownfield (legacyconstrained) vs. Greenfield (unconstrained) application systems created a challenge of determining an ICM Brownfield risk pattern and an associated set of special-case process guidelines. This paper presents a case study of a failed Brownfield project, and shows how the concurrent-engineering activities, risk assessments, and anchor point milestones of the ICM could have avoided the failure. It compares the resulting ICM special-case Brownfield process with two leading Brownfield approaches, the CMU-SEI SMART approach and the IBM Brownfield approach, and finds them compatible and complementary. Keywords software-intensive systems engineering, brownfield development, Incremental Commitment Model, legacy systems, software re-engineering, refactoring, lifecycle models, service-oriented architecture, software process. implementation, but was dropped at a cost of $40 million after two failed tries to provide continuity of service, due primarily to the infeasibility of incrementally phasing out the legacy software and business processes compatibly with the new system s incremental capabilities. 1 Introduction Today and increasingly in the future, most large softwareintensive system (SIS) developments will be constrained by the need to provide continuity of service while migrating their services away from poorly structured and documented legacy software applications. The International Data Corporation has estimated that there are 200 billion lines of such legacy codes in current operation [1]. Yet most SIS process models contain underlying assumptions that an application project starts from scratch in an unconstrained Greenfield approach to developing requirements and solutions. The Incremental Commitment Model (ICM) is a risk-driven process model generator for which common risk patterns generate common special-case system definition and development process models. The increasing importance of Brownfield (legacy-constrained) vs. Greenfield (unconstrained) application systems created a challenge of determining an ICM Brownfield risk pattern and an associated set of special-case process guidelines. This paper presents a case study of a failed Brownfield project, and shows how the concurrent-engineering activities, risk assessments, and anchor point milestones of the ICM would have avoided the failure. In the failed project, a major US corporation used a Greenfield systems engineering and development approach to develop a new Central Corporate System to replace a patchedtogether collection of strongly-coupled and poorly documented COBOL business data processing programs. The system included an early Enterprise Resource Planning (ERP) system that was well matched to the corporation s overall financial needs, but not to its detailed business processes, which included various workarounds to compensate for difficulties with the legacy software. The new system was well organized to support incremental The ICM organizes concurrent systems engineering and acquisition processes around anchor point milestones at which the concurrent activities can synchronize and stabilize, and at which the project s risks of going forward can be better assessed and fitted into a risk-driven stakeholder resource commitment process. The paper presents the two primary views of the ICM and shows how the risk-driven commitment milestones enable stakeholders to determine which special case process best fits their situation. In particular, the ICM s concurrent activities of Understanding Needs, Envisioning Opportunities, System Scoping and Architecting, Feasibility Evidence Development, and Risk/Opportunity Assessment enable projects to focus specifically on their legacy system constraints and on opportunities to deal with them. With respect to the failed-project case study, the paper shows how the application of the ICM to the full Brownfield corporate situation could have avoided the failures of the Greenfield development. Its Understanding Needs activity could have determined the ways in which the legacy system had intertwined financial and other business services. For examples, Project included budgeting and scheduling, work breakdown system accounting, earned value management intertwined with requirements, version and configuration management; Contract included expenditure category management, billing, and receivables management intertwined with deliverables management and engineering change proposal tracking; with similar intertwining in Personnel and Marketing.

2 The ICM s Envisioning Opportunities activity could have identified opportunities to decouple the financial and nonfinancial elements of these services in ways that could make it feasible for them to interoperate with a element. Its System Scoping and Architecting activity could have repackaged the legacy software and developed the new architecture in ways that could support incremental phaseout of the legacy system, and its Feasibility Evidence Development activity could have assessed any outstanding risks and covered them with risk management plans that could be tracked to ensure project success. The paper concludes with a comparison of the resulting ICM special-case Brownfield process with two leading Brownfield approaches, the CMU-SEI SMART approach and the IBM Brownfield approach, and finds them compatible and complementary. 2 The ICM Activity Level View In order to rapidly and successfully adapt to increasing rates of change, projects need to be able to concurrently rather than sequentially assess and manage opportunities and risks; requirements, solutions, plans, and business cases; and hardware, software and human factors. Figure 1 extends the Rational Unified Process hump diagram in [2] to show how these are concurrently pursued with the ICM [3,4]. As with the RUP version, it should be emphasized that the magnitude and shape of the levels of effort will be riskdriven and likely to vary from project to project. In particular, they are likely to have mini risk/opportunitydriven peaks and valleys, rather than the smooth curves shown for simplicity in Figure 1. The main intent of this view is to emphasize the necessary concurrency of the primary success-critical activities shown as rows in Figure 1. Thus, in interpreting the Exploration column, although system scoping is the primary objective of the Exploration phase, doing it well involves a considerable amount of activity in understanding needs, envisioning opportunities, identifying and reconciling stakeholder goals and objectives, architecting solutions, life cycle planning, evaluation of alternatives, and negotiation of stakeholder commitments. For example, if one were exploring the initial scoping of a system of systems (SoS) for a metropolitan area s disaster relief, one would not just interview a number of stakeholders and compile a list of their expressed mission needs. One would also envision and explore opportunities for reusing (parts of) other metropolitan-area disaster relief systems; for obtaining development funds from federal agencies; and for applying maturing virtual collaboration technologies. In the area of understanding needs, one would concurrently assess the capability and compatibility of existing disaster relief systems in the metropolitan area to determine which would need the most work to reengineer into a SoS. One would also assess the scope of authority and responsibility of each existing system to determine whether the best approach would be a truly integrated and centrally-managed SoS or a best-effort interoperable set of systems. And one would explore alternative architectural concepts for developing and evolving the system; develop alternative phased plans to determine which improvements would provide the best early benefits and foundations for future growth; evaluate their relative feasibility, benefits, and risks for stakeholders to review; and negotiate commitments of further resources to proceed into a Valuation phase. Similar concurrency is needed all the way down to small time-constrained web applications. Every year, we use the ICM to teach software engineering by having over a dozen student teams define, design, develop, and deploy web applications for real clients in a fixed 24-week time period, with a 92% success rate. 2.1 How is All This Concurrent Engineering Synchronized and Stabilized? Figure 1 indicates that a great deal of concurrent activity occurs within and across the various ICM phases. To make this concurrency work, the anchor point milestone reviews are the mechanism by which the many concurrent activities are synchronized, stabilized, and risk-assessed at the end of each phase [5,6]. Each of these anchor point milestone reviews, labeled at the top of Figure 1, is focused on developer-produced evidence, instead of PowerPoint charts and Unified Modeling Language (UML) diagrams, to help the key stakeholders determine the next level of commitment. For example, the developer of a system with a requirement for a one-second real-time task completion for a safety-critical system should provide evidence based on prototyping, benchmarking, modeling, or simulation using representative workloads that the system as designed will meet the task completion time requirement, rather than just promise to "build it now and tune it later," as is frequently the practice in ad-hoc development or when using agile methods. If the requirement had been for a 1-second desirable, 3-seconds acceptable user response time for a non-critical system, agile would generally be fine. For the Exploration Commitment Review (ECR), the focus is on a review of an Exploration Phase plan with the proposed scope, schedule, deliverables, and required resource commitment, by a key subset of stakeholders. The plan content is risk-driven, and could therefore be put on a single page for a small and non-controversial Exploration phase since there is minimal risk of getting it wrong. A much riskier Exploration phase would require a more detailed plan outlining how the risks will be re-evaluated and managed going forward. For the Valuation Commitment Review (VCR), the risk-driven focus is similar; the content includes the Exploration phase results and a Valuation phase plan; and a review by all of the stakeholders involved in the Valuation phase. The Foundations Commitment Review (FCR) and the Development Commitment Review (DCR) reviews are based on the highly successful AT&T Architecture Review

3 Figure 1 - The ICM activity categories and level of effort. Board procedures described in [6]. For the FCR, only highrisk aspects of the Operational Concept, Requirements, Architecture, and Plans are elaborated in detail. And it is sufficient to provide evidence that at least one combination of those artifacts satisfies the Feasibility Evidence criteria shown in Figure 2 (similar to the RUP Life Cycle Objectives milestone), as compared to demonstrating this at the DCR for the particular choice of artifacts to be used for development. 3 The ICM Phase View Figure 2 emphasizes that shortfalls in feasibility evidence are sources of risk, and should be addressed by risk management plans. The degree of risk in going forward into the next phase is the key decision criterion that stakeholders need to consider in committing their resources to support going forward into the next phase. An overview of the ICM life cycle stages and phases is shown in Figure 3. It identifies the major life cycle stages of System Definition (Stage I) and System Development, Operations, and Production (Stage II). It shows the Stages concurrently engineered life cycle phases, the stakeholder commitment review points, and their use of feasibility rationales to assess the compatibility, feasibility and risk

4 Pass/Fail Feasibility Evidence Description Evidence provided by developer and validated by independent experts that if the system is built to the specified architecture, it will: Satisfy the requirements: capability, interfaces, level of service, and evolution Support the operational concept Be buildable within the budgets and schedules in the plan Generate a viable return on investment Generate satisfactory outcomes for all of the successcritical stakeholders Shortfalls in evidence are sources of risk All major risks resolved or covered by risk management plans Serves as basis for stakeholders commitment to proceed associated with the concurrently-engineered artifacts; and the major focus of each life cycle phase. There are a number of alternatives at each commitment point. These are: (1) the risks are negligible and no further analysis and evaluation activities are needed to complete the next phase; (2) the risk is acceptable and work can proceed to the next life cycle phase: (3) the risk is addressable but requires backtracking; or (4) the risk is too great and the development process should be rescoped or halted. These risks are assessed by the system s success-critical stakeholders, whose commitment will be based on whether the current level of system definition gives sufficient evidence that the system will satisfy their value propositions. Thus there are many risk-driven paths through the life cycle. A more risk-seeking set of stakeholders will tend to go forward or skip phases at a decision point; for the same level of risk, a more risk-averse set of stakeholders may choose to extend the previous phase, rescope, or discontinue the project. Figure 2 Pass/Fail FED Overview. Figure 3 Overview of the Incremental Commitment Life Cycle Processes.

5 4 Applying ICM to the Case Study 4.1 Understanding Needs The first step in understanding the needs for an initiative is to determine its protagonist, who provided the primary impetus for it. In this case, it was the corporate sector President, based on several experiences of financial losses due to missed deadlines or errors in financial reporting, making payments, or tracking receivables. The next step is to identify and query success-critical stakeholders with respect to their perceptions of the needs and opportunities. Some examples of their responses would have been: Accounting and Finance: We have many reporting and payment deadlines with significant financial and corporate image problems if we miss them or get the responses wrong: taxes, contracts, invoices, accounts payable and receivable, etc. We have to hire too many people to do redundant data entry, data conversion, and data checking. These lead to convoluted internal and external business workflows. And we re always behind on finding and fixing side effects from changes in the software. Project Management: We need too many Program Office people to straighten out problems with our budgets, schedules, earned value management systems, purchases, travel and other direct costs. Our technical people spend way too much time dealing with these as well. And it takes the IT people way too long to fix the problems that we find. IT : We have too many change requests and problem reports, and not enough people to do more than patch our tangled mass of old software, run some old regression tests, and hope for the best. We know that this causes problems and makes future changes harder, but there s no time or staff to work the underlying problems. And we need to provide continuity of service; there s no time that we can shut things down until they re fixed. Besides these stakeholders, there are several other classes of internal and external success-critical stakeholders that are important to involve to fully understand the needs and to subsequently set priorities. These include enterpriselevel corporate personnel; customers; critical supply chain personnel; software development, database administration, and clerical personnel; marketing and sales personnel; etc. These people can help both in understanding the problem symptoms, but also in understanding their root causes and identifying opportunities for improvement. 4.2 Root Cause Analysis Results Prioritization of the stakeholder needs confirmed that fixing the central financial data processing situation was the toppriority issue needing resolution. The primary root cause of most of its problems, and of the challenges in migrating to a new system while providing continuity of service, was the highly coupled tangle of financial and non-financial services among the business software packages. Compounding the difficulties was the fact that these were organized around services other than financial services, such as contract services and project services, as shown in Figure 4. Contract Legacy Business Budgeting Project Staffing Deliverables Management Billing Work Breakdown Structure Earned Value Management Subcontracting Scheduling Progress Tracking Change Tracking Reqs, Configuration Management Figure 4 Legacy systems, patched, highly coupled financial and non-financial services. 5 Envisioning opportunities; System Scoping The major opportunity identified in discussions with the stakeholders, with related organizations, and technical experts was to re-engineer the legacy software into a service-oriented architecture (SOA) in a way that the financial software services could be independently addressed. To provide continuity of service, it was also important to organize the transition into increments of development that corresponded to the re-engineered legacy components, and to predicate cutover to new increments of software on their passage of a much more comprehensive set of regression tests and parallel operations with the legacy system. This approach corresponds to a macro version of the test-driven refactoring approach developed by the agile methods community [7]. However, refactoring the legacy software and performing incremental development of the replacement software are only one of several initiatives that are key to achieving the resulting benefits of faster and more reliable business process execution, reduced clerical staff, more satisfied customers, and improve financial performance. A good way to identify these complementary initiatives is the use the DMR Consulting Group s Results Chain approach [8], which links Initiatives to Contributions and Outcomes, subject to Assumptions. Additional initiatives critical to achieving the desired outcomes here would include reengineering the relevant business processes and workflows; coordinating interfaces with corporate financial operations and external interoperators; data conversions; and training and re-careering of clerical personnel. The ICM includes an extension of the Results Chain, called the Benefits Chain, that includes the identification of success-critical stakeholders [9].

6 Legacy Business Contract Project Contract Billing Subcontract payments Contract Non- Deliverables mgmt. Terms compliance General Accounting Budgeting Earned value Payroll General Non- Progress tracking Change tracking Project WBS Expenditure categories Project Non- Scheduling Staffing Reqs CM Figure 5 Result of Legacy System Re-Engineering 6 System Architecting, Life Cycle Planning, and Feasibility Evidence/Risk Assessment The result of refactoring the legacy software is shown in Figure 5. It reorganizes the legacy software into a set of services that preserve the previous Contract and Project, but that separate out the so that they can be replaced by new increments of software. As shown in Figure 3, the ICM approach to concurrent legacy re-engineering and architecture development of the new software proceeds in three Stage I system definition phases. In the Exploration phase, enough analysis of the legacy software and the proposed reengineering of it in Figure 5 is done to provide a Feasibility Evidence Description (FED) [10] that convinces the stakeholders that the risks of incrementally committing to the next phase of detailed prototyping and architecting are acceptable. Usually, by the end of the Exploration phase, the project has understood the SIS needs and opportunities well enough to decide which ICM special-case process is determined by the project s risk pattern. Table 1 shows three of the closest special cases to the case study, as documented in [11]; the discussion below indicates under what conditions each would have been selected. Table 1 Characteristics of the Risk-Driven Special Cases of the ICM Special Case Example Size, Complexity Change Rate (%/Month) Criticality NDI Support Organizational and Personnel Capability 3. Architected Agile 7. NDIintensive Business data processing Supply chain management 11. Brownfield Incremental legacy phaseout Med 1-10 Med-High Good; most in place Med-High Med-Very High NDI-driven architecture High-Very High Med-High NDI aids legacy replacement Legend: NDI: Non-Development Item; SOA: Service-Oriented Architecture. Agile-ready Med-high NDI- experienced; med-high Legacy-SOA reengineering In the case study as described, the project has acceptable risk levels with respect to the size, complexity, change rate, criticality, NDI support, and capability levels in the Brownfield row, and therefore fits the Brownfield special case project. However, if the legacy assessment concluded that the complexities of re-engineering the legacy software exceeded the capabilities of the available personnel but could be replaced by NDI software familiar to the organization and personnel, the project would have chosen the NDI-intensive special case to completely replace the legacy system. If the application were smaller and less critical and the organization had agile-ready personnel, the Architected Agile special case could be used to do besteffort refactoring of the legacy software.

7 In the Valuation phase, a similar FED-based risk assessment and commitment review are held. Here, the FED results are based on the prototyping and modelingbased evidence of system development return on investment resulting from a top-level cost-benefit analysis of the legacy re-engineering activities, the architecting and infrastructure determination of the new software, and the additional success-critical Initiatives. A more detailed FED- based risk assessment and commitment review are held at the Development Commitment Review at the end of the Foundations phase, which prepares the detailed build-to specifications and plans for the first increment of development and phaseout of the corresponding re-engineered legacy software. It also prepares decreasingly detailed baseline specifications and plans for the later increments of development and phaseout of the corresponding re-engineered legacy software, along with detailed evidence of feasibility and risk management plans for any remaining risks. Once the stakeholders commit their resources to proceed, the program enters the ICM Stage II of Incremental Development and Operations (and Production if hardware is involved), as shown in Figure 3. To ensure on-schedule delivery of each increment, its features are prioritized, and lower priority features are deferred to meet schedule. The development team is stabilized by keeping increments short and diverting potentially-destabilizing change traffic to a parallel systems engineering team, which handles the change traffic (including deferred features), and rebaselines the specifications and plans for the next increment, so that the development team is ready to go with another increment of stabilized development once they have completed the current increment. As shown in Figure 1, the systems engineering team is also pro-actively understanding new business needs and envisioning new solution opportunities that keep the application continuously competitive. Also, the team should be staffed with a sufficiently critical mass of talented personnel that they can keep the software from degrading into the poorly structured and documented legacy software problems of the past. 7 Comparison of ICM, CMU-SEI SMART, and IBM Brownfield Approaches Table 2 summarizes the major comparisons of the ICM, the CMU-SEI Service Migration and Reuse Technique (SMART) [12, 13], and the IBM Brownfield approach [14]. Table 2 Comparison of ICM, CMU-SEI SMART, and IBM Brownfield Approaches Activity ICM CMU-SEI SMART IBM Brownfield Understanding Needs Envisioning Opportunities System Scoping Architecting Solutions Life Cycle Planning Feasibility Evidence Enterprise objectives Current shortfalls Stakeholder inputs Root causes ERP, DBMS COTS packages Legacy re-engineering Service-oriented architecture Prototypes (GUI, COTS) Operational Concept Application priorities Increment priorities Evolutionary development End-state architecture Infrastructure determination Legacy-SOA re-engineering Incremental definition Evidence/risk-driven commitment reviews Incremental development and concurrent rebaselining Complementary initiatives Business case elaboration Technical, cost, and schedule feasibility evidence Expert-validated evidence Business drivers Legacy Environmment Stakeholder inputs; Service Migration Interview Guide Reference architectures Candidate services Legacy code analysis and restructuring tools Business processes Business goals Target SOA environment Quality of service levels Architectural views definition Legacy-SOA re-engineering Migration strategy identification and creation guidelines Ordering of increments SMART Tool support Complementary initiatives Top-level feasibility summary Gap analysis: cost, risk, legacy quality Pilot project Business context Legacy inventory Stakeholder views Site survey View-Inventory- Transformation-Artifacts conceptualization process Architectural frameworks Systems context Computation-independent, platform-independent, and platform-specific models Component model Operational model Performance model Engineering Plan: discovery, engineering, development, and test Size and effort estimation Test case generation Architecture testing: evidence of satisfactory model performance Code testing

8 As seen in Table 2, the three approaches share many similarities, but have particular unique strengths. The ICM s primary unique strengths are the strong emphasis on solution feasibility evidence as a basis of stakeholder review and commitment to proceed, and the evolutionary development approach featuring concurrent presentincrement stabilized development and next-increment change traffic handling and rebaselining. The SEI SMART approach s primary unique strengths are its Service Migration Interview Guide and its SMART Tool for producing a draft migration strategy and migration issues list. The IBM Brownfield approach s primary unique strengths are its View-Inventory-Transformation-Artifacts conceptualization process and its Discovery-Engineering- Development-Test implementation process. Overall, the three approaches are basically compatible and complementary. 8 Conclusions Application of the ICM to a case study of a failed Brownfield project showed that its risk patterns enabled it to generate a life cycle process for Brownfield projects that is basically compatible with two leading Brownfield approaches, the CMU-SEI SMART approach and the IBM Brownfield approach. The ICM s primary unique strengths are the strong emphasis on solution feasibility evidence as a basis of stakeholder review and commitment to proceed, and the evolutionary development approach featuring concurrent present-increment stabilized development and next-increment change traffic handling and rebaselining. However, the SMART and Brownfield approaches are stronger with respect to the specifics of Brownfield software development, and provide effective ways of pursuing Brownfield developments in concert with the ICM system definition and evolutionary development approach. 9 References [1] Price, H., and Morley, J. (2009), Create, Apply, and Amplify: A Story of Technology Development, SEI Monitor, February, p.2. [2] Kruchten, P. (1999), The Rational Unified Process, Addison Wesley. [3] Pew, R. W., and Mavor, A. S., (2007), Human-System Integration in the System Development Process: A New Look, National Academy Press. [4] Boehm, B. and Lane, J. (2007), Using the Incremental Commitment Model to Integrate System Acquisition, Systems Engineering, and Software Engineering, CrossTalk, October, pp [5] Boehm, B. (1996), Anchoring the Software Process, IEEE Software, July, pp [6] Maranzano, J. et al. (2005), Architecture Reviews: Practice and Experience, IEEE Software, March/April, pp [7] Fowler, M., Beck, K., et al. (1999), Refactoring, Addison Wesley. [8] Thorp, J. (1998), The Information Paradox: Realizing the Business Benefits of Information Technology, McGraw Hill. [9] Boehm, B., and Jain, A. (2006), "A Value-Based Theory of Systems Engineering," Proceedings, INCOSE [10] Boehm, B., and Lane, J. (2009), Better Management of Development Risks: Early Feasibility Evidence, Proceedings, CSER [11] Boehm, B., Lane, J., and Koolmanojwong, S. (2009), A Risk-Driven Process Decision Table to Guide System Development Rigor, submitted for presentation at the 2009 International Council on Systems Engineering (INCOSE) Symposium. [12] Seacord, R., Plakosh, D., and Lewis, G. (2003), Modernizing Legacy Systems, Addison Wesley. [13] Lewis, G. et al. (2008), SMART: Analyzing the Reuse Potential of Legacy Components on a Service- Oriented Architecture Environment, CMU/SEI-2008-TN [14] Hopkins, R., and Jenkins, K. (2008), Eating the IT Elephant: Moving from Greenfield Development to Brownfield, IBM Press.