1. Managing Change Optimizing Value through an Evolutionary Development Strategy Revolution in Military Logistics, Seamless Vision, GCSS-Army Prime Directive and the Central Hypothesis

2. Background Software Complexity is IncreasingSoftware Complexity is Increasing The CCB Process is not Evolutionary… its Reactionary!The CCB Process is not Evolutionary… its Reactionary! The ECP Process is not StandardThe ECP Process is not Standard Currently, ECP’s cause a Paradigm Shift in Software DevelopmentCurrently, ECP’s cause a Paradigm Shift in Software Development

3. Evolutionary Change Means Value! ECP’s must be carefully and continuously assessed in order to preserve, enhance, or minimize the loss of value-added over time. The ubiquitous nature of change underlies all software work. Change is inevitable; the challenge is to properly manage it. Modifying software is dangerous and can be costly if improperly managed. What are the metrics?

4. Change effects multiple business functions. MISSIONS High Level Functions Manage Intensive Items Provide Asset Visibility Maintain Interfaces Maintain Accounts Maintain History Process Requests Status Reconciliation Manage Stock Report Battle Loss Adjust Parameters Maintain Planning Data Adjust Stock Levels Conduct What-if Analysis Manage Backlog Report Production Maintain Reference Data Post Accountable Records Inventory Stock Research Cross-References Process Referrals Execute Distribution Process Credit Support Financial Transactions Conduct Split Operations Report Readiness Produce Electronic Forms Execute Financial Controls Execute Budget Guidance Report Performance Track Movements Logistical Management Logistical Planning Readiness – Sustainment Supply Control Logistics Automation Support Financial Contracts Provide Map Backgrounds Support Free Text Messages

5. How do we reduce uncertainty? Process must include Factory to Foxhole ICT+ analyses consolidated ECPs Results of analysis posted to Web page Process centrally directed but always open Process supports GCSS-Army vision and user requirements

6. Building a Solution Develop a “systems evolution in-the-large” enterprise model that reflects: –needs of the customer –organization’s strategic goals and objectives –business operations of the enterprise –transition considerations –global system and software engineering issues –technology considerations Carnegie Mellon University, Software Engineering Institute: “An Enterprise Model for the Evolution of Legacy Systems” John Bergey, Dennis Smith August 26, 1997

7. How can we measure our ability to effect change? Technical Capture the following metrics: Problem recognition time Administrative delay time Maintenance tools collection time Problem analysis time Change specification time Active correction time Local testing time System testing time Maintenance review time Total recovery time …then optimize! Functional Savings Performance Effectiveness

8. ICT+ Organization Standing ICT AMC (CECOM), TRADOC (CASCOM) LOGSA CSS SME (part-time) Medical -AMEDD Personnel- SSI Finance -ASA-FM AMC SMEs ODCSLOG METT-T MACOM REPs

9. Vision/Central Hypothesis Managing Change in GCSS-Army AWE F XXI Process Contentious Issues CTSF Policy Doctrine Directives BPR Technology ECP’s ICT+ GOWG PM GCSS-Army Experimental Results Decision to Build Develop Version X.x GCSS-Army ECP’s With High Impact Potential Low Impact ECP’s Decision to Prototype COC PM Technical Cost/ Assessment

10. Recommendations For GOWG to approve process Resource team and write detailed procedures

11. Back up Slides

12. Change will Occur Everything is a moving target! The environment in which a program resides is continuously changing: New computer hardware capabilities appear about every 24 months New Operating Systems or new releases of old Operating System’s appear regularly Peripheral equipment is changed frequently Yet the useful life of a software system may be expected at 10 or more years and function smoothly under a continuous assault of change agents.

13. Contributing to the problem... Program funding available Contracts for hardware and software not linked / mutually supporting for synchronized release Hardware acquisition process Doctrinal Changes New Business Processes Organizational Change Political Relationships among MACOM’s No one had CSS system development oversight until the GOWG!

14. How can we improve our process?

15. GCSS-ARMY CCB Evaluation... Central Hypothesis ECP’s Prime Directive Decision to continue or terminate Decision to continue or terminate VisionTrainingCSS/JointOther Council of Colonels GOWG MACOM’s ICT+ PM ILOGS PEO STAMIS Decision to continue or terminate Refine Fund/DevelopHold Refine

16. Policy Automation Evolution Army has lagged commercial industry! Why.... Industry Centralized mainframes Decentralized Microcomputers World Wide Networks (Inter/Intranet) Local Networks (LAN/WAN) Army Centralized mainframes Decentralized Microcomputers Local Networks (LAN/WAN) 1960s1970s1980s1990s 1960s1970s1980s1990s CBRS & PPBES Same Life Cycle Mgmt for Tank & Info Sys Changing Priorities Why.... Technology Explosion

17. Revolution in Military Logistics The "Revolution in Military Logistics" (RML) will enable the logistics community to support the digitized forces of Army XXI and the Army After Next.

18. Vision 2010 Concepts –Anticipatory Logistics & Personnel Support Split-based Operations –Sustained Tempo, Enhanced Throughput Operations, Velocity Management, Battlefield Distribution System –Total Asset Visibility, Objective Supply Capability Enablers –Integrated Maneuver & Combat Service Support Systems –Command & Control Total Asset Visibility – Modular Organization, Movement Tracking System –Wireless Management Information Systems Technologies –Information Age Technologies for Inventory Control – More Durable Materials – Over-the-Air Software Diagnostics & Repair – Automated Cross-Leveling and Rerouting

19. Change is Maintenance Software doesn’t break but... Corrective Maintenance: It is unreasonable to assume that testing will uncover all flaws and errors resident in a program. In fact, large software programs normally test only the functionality along the critical path for the system. Adaptive Maintenance: The environment in which a program resides is continuously changing. Yet the useful life of a software system may be expected at 10 or more years and function smoothly under a continuous assault of change agents. Adaptive maintenance extends the useful life of the system. Perfective Maintenance: As the system is exercised, users are able to identify enhancements, modifications to existing functions, and recommend new capabilities that optimize their work. This type of maintenance accounts for the majority of all effort. Preventive Maintenance: This activity is focused on preparing the software to improve future maintainability or reliability, or to provide the basis for future enhancements. This area of maintenance can be characterized by BPR activities. Roger Pressman, Software Engineering: A Practicioneer’s Guide

20. Hardware Capability vs Cost 0 5000 10000 85899397 '01'05 DISK (MB) 0 50 100 85899397 '01'05 RAM (MB) 0 500 1000 85899397 '01'05 0 5000 10000 8587899193959799 '01'03'05 WORKSTATION LAPTOP SERVER n Yearly, exponential capability increase! n Relatively same current-year costs! n $3,000 today buys at Staples what $1,000,000 bought 10 years ago 80286 80396 80486 PENTIUM PENTIUM-PRO PENTIUM II-MMX MHz Cost

21. Rate of Change in Software Development 19401950196019701980199020002010 Machine Code Assembler COBOL FORTRAN BASIC PASCAL JCL C SQL C-Shell dBase 4GL C++ Visual Basic HTML Java ??? Algorithms Modular Design Structured Programming Data Modeling CASE GUI and Event Coding Objects and N-Tiers Change is Constant: Language Design Paradigm Operating System

22. What happens if value-added is not assessed? In 1996 the hardware to host an Army STAMIS fielded to Korea was selected before software development was complete. The hardware consisted of a 486 33 Mhz desktop PC, with a 270 MB hard drive and 16 MB RAM. By 1997, in one of the incremental upgrades, the STAMIS code alone had grown to ~210 MB! Add ~10 MB for the Operating system and a virus checker, the system had little capacity to store files. As a result PEO STAMIS had to fund hard drive upgrades for the fielded systems to operate as intended. The final code was not complete. Less than a year later, the PM moved to lap tops... The TACCS Tactical Army CSS Computer System, fielded in 1985, was used by SARSS-I (supply), SAMS (maintenance), SAAS (ammo), SPBS-R (property), SIDPERS (personnel). The TACCS is a $ 25K 80186, 8 Mhz ruggedized computer with a 67 MB hard drive. It requires two men to carry the system and is still being used in the field. [In 1985 Intel introduced the 80386 chip.] Today, 13 years later the Army is replacing the TACCS with 486’s. The 486 is obsolete. When will we learn. The field can be adversely effected for years...

23. Other Services GCSS-Army Tactical GCSS-Army Complexity of the System TacticalOperationalStrategic GCSS GCCS ABCS DFBS DMLSS RCAS AGCCS MCS FAADC3IISYSCON ASAS AFATDS CSSCS TC-AIMS-II SIDPERS Tactical ATCCS Logistics Other Services

24. Without value-added analysis... ULLS SAMS SARSS CCSS SIDPERS TAMMIS SAAS SPBS SDS ATAV ATLASS AMSS AIT CAV-II CEFMS DFBS SSN LIDB RCAS DES DPAS GCSS FS2000 FAMPS DMLSS DLMS RTRP l Perpetuation of resource intensive ways of doing business! l Budgeteers drive the process! l Piecemeal modernization - “Paving the Cow Path” l Continuous sub- optimization! l No possibility to keep up with a digitized force!

25. Carnegie Mellon University, Software Engineering Institute: “An Enterprise Model for the Evolution of Legacy Systems” John Bergey, Dennis Smith August 26, 1997 An Enterprise Model Target Operational Environment Legacy Operational Environment Organization System Evolution Tasks Systems Eng Software Eng Customer Project Technologies Support Environment Migration Strategy Requirements Legacy System Target System Improved product Evolutionary path Influence Using Drive Performs Analyze, manage, transform Report Progress/ Status Generate Negotiate Specify desired capabilities and qualities of Influence Drive Manages Resolves

26. What is Value-added analysis? The market example... Value-added analysis is similar to the assessments made by commodity brokers when buying and selling options. Options are time sensitive investment vehicles that allow the owner to buy / sell a holding based on his view of the market dynamics over a set period of time. The buy / sell decision is based on an attempt to maximize value given the context of the market and various environmental parameters. To minimize uncertainty in making his decision, the option trader continuously assesses the profit margin of his holding. If he exercises his option too early or late, he may not realize the maximum potential of his investment. ECP’s evaluated in this manner will maximize the benefits to the system, soldier, and the Army by focusing the efforts of the developer.

27. Value-added by ECP’s can be maximized for all systems! User Involvement Req/BPR Req/Business Process Reengineering Fielding RAD Rapid Acq Dev ICT+ Configuration Control Value added is assessed by ICT+ ECP insertion is synchronized with ongoing development ECP value added is maximized GOWG Prioritizes High impact ECP’s based on the assessed value to the system ECP Request CCB Prioritizes ECP’s based on ICT+ analysis and DCSLOG mandates

28. Where will these experts come from? Put the SDC-Lee functional experts back under the control of the CASCOM Commander ECP’s are responsive to the needs of the field and synchronized with the evolution of the system CASCOM is back in the loop as the users’ representative ECP’s are worked as requirements based on value-added to the system CASCOM can assess the value-added by ECP’s in the light of the program requirements, evolving doctrine, and the future of Army logistics CASCOM has more influence over what is built by the developer Hire industry to assist in value-added metrics analysis

29. Information Dominance Impact of the revolution in information technology. –Increases in processing power, storage capacity, and speed. –Plummeting hardware costs relative to capabilities The software component has been, and will remain, the crucial element. Information processing applications are a critical component of our weapons and management systems. It is imperative that the software component of these systems be developed as an integral part of the systems engineering process.

30. Software Complexity is Increasing “Stove pipe” systems are being eradicated by all proponents: information is a resource and must be managed corporately The Army’s Information Systems are becoming increasingly interdependent: source data entry - universal visibility / utilization Changes made to one system effect multiple domains The Army does not “speak” with one voice when it addresses change: every agency involved in software development has a unique process for implementing change The current CCB process is driven by special interests: the evolutionary development (vision) of large scale software programs must be a holistic process across multiple domains

31. The CCB Process is not Evolutionary… its Reactionary! The current CCB process is static: ECP’s constrained / prioritized by functional domains > Field, Policy, Higher HQ ECP’s funded by fiscal waterfall ECP’s effect on the evolution of the software not constant with a vision for the program CCB / ECP insertions not in synch with the development / evolution of the software (life cycle dependent) No overall Vision A constant barrage of ill-timed ECP’s retards the evolution of the system!

32. The ECP Process is not Standard Every organization has a unique method to capture ECP’s: AMC, Software Development Center-Lee, and PM ILOGS Logistics Modernization Program Impacts –Central Design Activities Out-sourced (LSSC, ILSC) –SDC-Lee Downsized No overarching vision What’s the standard??? Should we combine remedy based tools with customer assistance applications?

33. Currently, ECP’s cause a Paradigm Shift in Software Development User Involvement Req/BPR Req/Business Process Reengineering Fielding RAD Rapid Acq Dev ICT+ Configuration Control CCB Spiral Development for Software but... Waterfall Development for ECP’s ECP’s value added is not maximized! DCSLOG Mandates Dominate ECP Request

34. How a Retail level ECP is worked... ECP is generated by: Field, Directives, Technical changes DCL and PM develop candidate list of ECP’s to be presented to the CCB The CCB’s approves / changes the ECP list as they relate to the DCSLOG’s mandates SDC-Lee is a contractor for PM-ILOGS !!! CASCOM as the user’s representative can not enforce the “Must do’s” delineated by the CCB ( $ driven) Enormous queue of ECP’s awaiting funding! Result