IBM Software Deployment 20131030 PDF

Front cover
The Software Deployment Mystery - Solved d

A Customer Guide
Reveals best practices and methods proven to drive deployment success Offers actual customer experience as a guide Helps make the most of your relationship with IBM
Sandor Hasznos Carolyn Hungate Calvin Lawrence Fernando Zuliani
Bill Bierds Jeremy Gibson David Backman Mike Ransom Reid Byers Charles P. Brown
ibm.com/redbooks
International Technical Support Organization The Software Deployment Mystery - Solved A Customer Guide August 2004
SG24-6070-02
Note: Before using this information and the product it supports, read the information in Notices on page ix.
Third Edition (August 2004) This edition applies to the IBM Software Group Software Deployment Method.
Copyright International Business Machines Corporation 2003, 2004. All rights reserved. Note to U.S. Government Users Restricted Rights -- Use, duplication or disclosure restricted by GSA ADP Schedule Contract with IBM Corp.
Contents
Notices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ix Trademarks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . x Preface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xi The team that wrote this redbook. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xii Become a published author . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiv Comments welcome. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xv Chapter 1. Why focus on software deployment . . . . . . . . . . . . . . . . . . . . . . 1 1.1 What makes software deployment so difficult . . . . . . . . . . . . . . . . . . . . . . . 3 1.2 Why have a Software Deployment Method . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.3 The Software Deployment Team. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.4 The Software Deployment Method . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 1.4.1 Phase 0: Prepare for deployment . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 1.4.2 Phase 1: Refine and promote the plan . . . . . . . . . . . . . . . . . . . . . . . . 6 1.4.3 Phase 2: Deploy software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 1.4.4 Software deployment method: A continuous process . . . . . . . . . . . . . 8 1.5 Software deployment best practices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 1.6 The readiness plan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 1.7 Solution Assurance Review. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 1.8 Software solution work products . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 1.9 Software deployment: A two-way street . . . . . . . . . . . . . . . . . . . . . . . . . . 12 Chapter 2. Roles and responsibilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 2.1 Internal team . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 2.1.1 Enterprise Business Sponsor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 2.1.2 Stakeholders, sponsors, and project leads . . . . . . . . . . . . . . . . . . . . 16 2.1.3 Global Project Lead. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 2.2 Team IBM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 2.3 IBM Client Team . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 2.3.1 IBM Client Executive . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 2.3.2 IBM Client Representative . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 2.3.3 IBM Client IT Architect . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 2.4 IBM Software Team. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 2.4.1 IBM Software Sales Representative (SSR). . . . . . . . . . . . . . . . . . . . 20 2.4.2 IBM Specialty Software Sales Representative (SSSR). . . . . . . . . . . 20 2.4.3 IBM Software IT Architect (SWITA). . . . . . . . . . . . . . . . . . . . . . . . . . 20 2.4.4 IBM Software IT Specialist (ITS) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
Copyright IBM Corp. 2003, 2004. All rights reserved.
iii
Chapter 3. Software deployment best practices . . . . . . . . . . . . . . . . . . . . 23 3.1 Identify an Enterprise Business Sponsor and stakeholders . . . . . . . . . . . 25 3.2 Centralize software fulfillment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 3.3 Implement a license management tool and process . . . . . . . . . . . . . . . . . 27 3.4 Hire deployment services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 3.5 Determine your deployment readiness . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 3.6 Commit to self-sufficiency . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 3.7 Define a time-to-value and ROI strategy . . . . . . . . . . . . . . . . . . . . . . . . . . 30 3.8 Communicate and market the vision . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 3.9 Software deployment workshop . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 Chapter 4. Value realization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 4.1 Value statement and value timeline . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 4.2 The buying decision . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 4.3 Return on investment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 4.3.1 Hard (tangible) ROI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 4.3.2 Soft (intangible) ROI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 4.3.3 Realizing value with hard and soft ROI . . . . . . . . . . . . . . . . . . . . . . . 37 4.3.4 ROI must support the business strategy . . . . . . . . . . . . . . . . . . . . . . 37 4.3.5 An approach to analyzing ROI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 4.3.6 When business goals are met, everyone wins . . . . . . . . . . . . . . . . . 38 4.3.7 Example ROI: Current value . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 Chapter 5. Software deployment Phase 0: Prepare for deployment . . . . 41 5.1 Step 0: Create the Software Deployment Team . . . . . . . . . . . . . . . . . . . . 42 5.1.1 Owners and participants . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 5.1.2 Inputs, tasks, and outputs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 5.1.3 Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 5.2 Step 1: Review the deployment documentation . . . . . . . . . . . . . . . . . . . . 44 5.2.1 Owners and participants . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 5.2.2 Inputs, tasks, and outputs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 5.2.3 Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 5.2.4 Documentation review tips . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 5.3 Step 2: Develop a high-level deployment plan . . . . . . . . . . . . . . . . . . . . . 47 5.3.1 Owners and participants . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48 5.3.2 Inputs, tasks, and outputs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48 5.3.3 Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48 5.4 Step 3: Establish the deployment partnership. . . . . . . . . . . . . . . . . . . . . . 49 5.4.1 Owners and participants . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49 5.4.2 Inputs, tasks, and outputs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50 5.4.3 Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50 Chapter 6. Software deployment Phase 1: Refine and promote plan . . . . 51 6.1 Step 4: Refine the deployment plan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
iv
The Software Deployment Mystery - Solved - A Customer Guide
6.1.1 Owners and participants . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53 6.1.2 Inputs, tasks and outputs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53 6.1.3 Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54 6.2 Step 5: Finalize the deployment plan . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54 6.2.1 Owners and participants . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55 6.2.2 Inputs, tasks, and outputs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55 6.2.3 Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55 6.3 Step 6: Conduct the initial deployment kickoff meeting. . . . . . . . . . . . . . . 56 6.3.1 Owners and participants . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56 6.3.2 Inputs, tasks, and outputs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57 6.3.3 Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58 Chapter 7. Software deployment Phase 2: Deploy software . . . . . . . . . . . 59 7.1 Step 7: Achieve the quick deployment wins . . . . . . . . . . . . . . . . . . . . . . . 61 7.1.1 Owners and participants . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61 7.1.2 Inputs, tasks, and outputs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61 7.1.3 Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62 7.2 Step 8: Execute the deployment plan . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63 7.2.1 Owners and participants . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63 7.2.2 Inputs, tasks, and outputs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63 7.2.3 Benefit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64 7.3 Step 9: Identify new business needs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64 7.3.1 Owners and participants . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65 7.3.2 Inputs, tasks, and outputs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65 7.3.3 Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65 7.4 Step 10: Update the business plan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65 7.4.1 Owners and participants . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66 7.4.2 Inputs, tasks, and outputs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66 7.4.3 Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66 Chapter 8. Managing software deployment projects . . . . . . . . . . . . . . . . . 67 8.1 Project timing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69 8.2 Getting started. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69 8.3 Managing the success of your first project . . . . . . . . . . . . . . . . . . . . . . . . 70 8.3.1 Managing at the milestone level . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71 8.3.2 Handling project management challenges . . . . . . . . . . . . . . . . . . . . 71 Chapter 9. Managing global software deployment projects . . . . . . . . . . . 73 9.1 How the coverage model works . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76 9.2 Global deployment checklist . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76 9.2.1 Global level activities (primary, full-time coverage) . . . . . . . . . . . . . . 77 9.2.2 Local sites (secondary, part-time coverage) . . . . . . . . . . . . . . . . . . . 78 9.2.3 Local sites (tertiary, on-demand coverage). . . . . . . . . . . . . . . . . . . . 78 9.3 More about the global deployment activities . . . . . . . . . . . . . . . . . . . . . . . 78
Contents
9.3.1 Identify the Enterprise Business Sponsor . . . . . . . . . . . . . . . . . . . . . 79 9.3.2 Obtain a list of software deployment locations . . . . . . . . . . . . . . . . . 79 9.3.3 Arrange full-time and part-time coverage . . . . . . . . . . . . . . . . . . . . . 79 9.3.4 Arrange on demand (tertiary) coverage . . . . . . . . . . . . . . . . . . . . . . 79 9.3.5 Conduct bi-weekly meetings with global deployment teams . . . . . . . 79 9.3.6 Checkpoint deployment satisfaction . . . . . . . . . . . . . . . . . . . . . . . . . 80 9.3.7 Provide regular progress reports. . . . . . . . . . . . . . . . . . . . . . . . . . . . 80 9.4 A global deployment coverage example . . . . . . . . . . . . . . . . . . . . . . . . . . 80 Chapter 10. Software deployment resources: Support, education, tools 83 10.1 License management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85 10.1.1 Taking control of software licenses . . . . . . . . . . . . . . . . . . . . . . . . . 86 10.1.2 IBM Tivoli License Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86 10.2 Communication tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87 10.2.1 Instant messaging, Web conferencing, and team workplaces . . . . 87 10.2.2 Easy Access Portals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88 10.3 Self-help . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89 10.3.1 Problem management. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89 10.3.2 License acquisition and entitlement with Passport Advantage . . . . 89 10.3.3 Software maintenance via Passport Advantage . . . . . . . . . . . . . . . 89 10.4 Premium support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90 10.5 Education . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91 10.6 Deployment services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91 Appendix A. Software solution work products . . . . . . . . . . . . . . . . . . . . . . 93 Work products used by SDM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94 Work product examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100 Architecture decisions document . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100 Architecture overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102 Business context diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103 Component model. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104 Component flow model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106 Current IT environments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106 Current business organization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111 Envisioned goals and issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112 Current IT standard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114 Mapping business initiatives to projects . . . . . . . . . . . . . . . . . . . . . . . . . . 116 Mapping projects to proposed products and solutions . . . . . . . . . . . . . . . 117 Non-functional requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118 Operational model. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120 Project description. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121 System context diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122 Systems context diagrams for an integration architecture . . . . . . . . . . . . 123
vi
Use cases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125 Viability assessment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127 Appendix B. Software deployment checklist . . . . . . . . . . . . . . . . . . . . . . 129 Software deployment steps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130 Phase 0: Prepare for deployment. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130 Step 0: Create the Software Deployment Team . . . . . . . . . . . . . . . . . . . . 130 Step 1: Review the contract content and critical deployment documents . 131 Step 2: Develop a high-level deployment plan . . . . . . . . . . . . . . . . . . . . . 132 Step 3: Establish a deployment partnership . . . . . . . . . . . . . . . . . . . . . . . 133 Phase 1: Refine and promote the plan. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133 Step 4: Refine the high-level deployment plan . . . . . . . . . . . . . . . . . . . . . 133 Step 5: Finalize the deployment plan . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134 Step 6: Conduct deployment kickoff meetings . . . . . . . . . . . . . . . . . . . . . 135 Phase 2: Deploy software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136 Step 7: Achieve quick deployment wins . . . . . . . . . . . . . . . . . . . . . . . . . . 136 Step 8: Execute the deployment plan . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137 Step 9: Identify new business needs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137 Step 10: Update the business plan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138 Appendix C. Global software deployment checklist . . . . . . . . . . . . . . . . 139 Global-level activities executed by global deployment lead . . . . . . . . . . . . . . 140 Local sites (secondary part-time coverage) . . . . . . . . . . . . . . . . . . . . . . . . . 142 Local sites (tertiary on demand coverage) . . . . . . . . . . . . . . . . . . . . . . . . . . 142 Appendix D. Additional material . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143 Locating the Web material . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143 Using the Web material . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144 How to use the Web material . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144 Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145 Related publications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151 Online resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151 How to get IBM Redbooks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151 Help from IBM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152 Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153
Contents
vii
viii
Notices
This information was developed for products and services offered in the U.S.A. IBM may not offer the products, services, or features discussed in this document in other countries. Consult your local IBM representative for information on the products and services currently available in your area. Any reference to an IBM product, program, or service is not intended to state or imply that only that IBM product, program, or service may be used. Any functionally equivalent product, program, or service that does not infringe any IBM intellectual property right may be used instead. However, it is the user's responsibility to evaluate and verify the operation of any non-IBM product, program, or service. IBM may have patents or pending patent applications covering subject matter described in this document. The furnishing of this document does not give you any license to these patents. You can send license inquiries, in writing, to: IBM Director of Licensing, IBM Corporation, North Castle Drive Armand, NY 10504-1785 U.S.A. The following paragraph does not apply to the United Kingdom or any other country where such provisions are inconsistent with local law: INTERNATIONAL BUSINESS MACHINES CORPORATION PROVIDES THIS PUBLICATION AS IS WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESS OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF NON-INFRINGEMENT, MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Some states do not allow disclaimer of express or implied warranties in certain transactions, therefore, this statement may not apply to you. This information could include technical inaccuracies or typographical errors. Changes are periodically made to the information herein; these changes will be incorporated in new editions of the publication. IBM may make improvements and/or changes in the product(s) and/or the program(s) described in this publication at any time without notice. Any references in this information to non-IBM Web sites are provided for convenience only and do not in any manner serve as an endorsement of those Web sites. The materials at those Web sites are not part of the materials for this IBM product and use of those Web sites is at your own risk. IBM may use or distribute any of the information you supply in any way it believes appropriate without incurring any obligation to you. Information concerning non-IBM products was obtained from the suppliers of those products, their published announcements or other publicly available sources. IBM has not tested those products and cannot confirm the accuracy of performance, compatibility or any other claims related to non-IBM products. Questions on the capabilities of non-IBM products should be addressed to the suppliers of those products. This information contains examples of data and reports used in daily business operations. To illustrate them as completely as possible, the examples include the names of individuals, companies, brands, and products. All of these names are fictitious and any similarity to the names and addresses used by an actual business enterprise is entirely coincidental. COPYRIGHT LICENSE: This information contains sample application programs in source language, which illustrates programming techniques on various operating platforms. You may copy, modify, and distribute these sample programs in any form without payment to IBM, for the purposes of developing, using, marketing or distributing application programs conforming to the application programming interface for the operating platform for which the sample programs are written. These examples have not been thoroughly tested under all conditions. IBM, therefore, cannot guarantee or imply reliability, serviceability, or function of these programs. You may copy, modify, and distribute these sample programs in any form without payment to IBM for the purposes of developing, using, marketing, or distributing application programs conforming to IBM's application programming interfaces.
ix
Trademarks
The following terms are trademarks of the International Business Machines Corporation and the Rational Software Corporation, in the United States, other countries, or both: Approach AIX APL2 CICS/ESA CICS Database 2 DB2 Universal Database DB2 GDDM ImagePlus Informix IBM ibm.com IMS LearningSpace Lotus MQSeries MVS OS/2 OS/390 Passport Advantage Rational Unified Process Rational Redbooks (logo) Redbooks RS/6000 RUP S/390 SmartSuite SP1 Tivoli TME VisualAge WebSphere zSeries 1-2-3
The following terms are trademarks of other companies: Intel, Intel Inside (logos), MMX, and Pentium are trademarks of Intel Corporation in the United States, other countries, or both. Microsoft, Windows, Windows NT, and the Windows logo are trademarks of Microsoft Corporation in the United States, other countries, or both. Java and all Java-based trademarks and logos are trademarks or registered trademarks of Sun Microsystems, Inc. in the United States, other countries, or both. UNIX is a registered trademark of The Open Group in the United States and other countries. SET, SET Secure Electronic Transaction, and the SET Logo are trademarks owned by SET Secure Electronic Transaction LLC. Other company, product, and service names may be trademarks or service marks of others.
Preface
To solve any mystery, detectives rely on their experience along with proven tools and techniques to unravel the conundrum. This IBM Redbook addresses the often illusive mystery known as software deployment success. The information, practices, and methods presented in this book have enabled many IBM customers to achieve their business and Information Technology (IT) goals more quickly and efficiently. IBM has accumulated a wealth of knowledge and experience in software deployment. The technologies we have developed, the best practices we have authored, and the employees we have cultivated are our greatest assets. Like a detective explaining how the mystery was solved, we use this redbook to pass on to you our customers the experience, knowledge, and wisdom we have accumulated after years of solving software deployment mysteries. The primary audience for this redbook is the person who has ultimate ownership for software deployment performance. We refer to this person as the Enterprise Business Sponsor (EBS). Secondary audiences include anyone who is engaged in software deployment activities. Both audiences benefit from the practices and procedures described. This redbook refers to a core team known as the Software Deployment Team (SDT). This team consists of representatives from both your company and the software vendor. The mission of the SDT is to maintain ongoing and clear communication between you and your vendor. Chapter 2, Roles and responsibilities on page 15, describes in detail the SDT and the concept of partnership. The best practices, presented in Chapter 3, Software deployment best practices on page 23, were developed after years of studying deployment challenges and their root causes. Where possible, we encourage you and all of our customers to follow them. When we refer to success in this redbook, we are talking about holistic success. It is important to recognize that, while independent achievements are important, holistic success can only be recognized when software is deployed and is executing as envisioned. For that reason, we include the discussion in Chapter 4, Value realization on page 33. This chapter focuses on calculating value and discusses the concepts of return on investment (ROI) and rate of return (ROR). It also drills down into creative ways you can measure value such as hard ROI and soft ROI.
xi
The premise of this book is that a proactive and disciplined deployment approach is required to get the expected business value from any purchase of software. The method described in Chapters 5 through 7 is called the Software Deployment Method (SDM). The SDM is not the only process that you can use to deploy software, but it is an example of a repeatable process that has proven successful time and time again. Chapter 8, Managing software deployment projects on page 67, provides hints and tips for managing large-scale deployment projects. Chapter 9, Managing global software deployment projects on page 73, helps you manage deployment on a global scale. And Chapter 10, Software deployment resources: Support, education, tools on page 83, describes tools and services that can help make software deployment more systemic and easier to manage. Throughout this book, you see testimonials, quotes, and success stories submitted by customers who have leveraged all or part of the deployment practices described. One of our customers, a major U.S.-based retailer who we refer to often throughout the book, not only follows the methods that are described, but they also use them as a source for their own customized deployment guidebook. For confidentiality reasons, we refer to this customer as GMR Corporation or GMR. During the life cycle of deployment, IBM will always be there to assist you, but it is our goal that you become self-sufficient. This involves building a team of highly skilled subject matter experts who can craft solutions that drive deployments that achieve your business and IT goals. Software deployment is a two-way street between you and your software vendor. We hope that the information presented in this book helps you maximize deployment success and value realization. Note: For the purposes of this redbook, we have used IBM as the vendor. The tools, techniques, and methods presented herein are applicable to any vendor with whom you deploy software.
The team that wrote this redbook

This redbook was produced by a team of specialists at the request of Lauren States (Vice President, Technical Sales and Deployment, IBM Software Group (SWG)) and Kim Waddell (Director ELA Deployment, SWG) to Maggie Blayney (Director of the ITSO). Bill Bierds, WW SWG - Program Executive, Customer Success Strategies Jeremy Gibson, Program Manager, Customer Success Strategies David Backman, Program Executive, Software IT Architect Community
xii
Mike Ransom, ITSO Project Leader Reid S. Byers, Software IT Architect Thanks to Nestl Corporation, Francisco Esteve (Nestl Globe Project Leader), and Fredy Schoch (IBM Software IT Architect at Nestl) for allowing their software deployment experiences to be included in this redbook. We appreciate the contributions, guidance, and direction provided by the IBM SWG Technical Leadership Council. Members of that council are: David Backman Senior Certified IT Architect Charles P. Brown Senior Certified IT Specialist Sandor Hasznos Certified IT Architect Carolyn Hungate Ease-of-Use Architect/Designer Calvin Lawrence Certified IT Architect Fernando Zuliani Certified Senior Consulting IT Specialist The contributions of following individuals from IBM are also appreciated: Mohammed Ajab Software Deployment Architect John Barker Software Deployment Architect Pete Bouchard Senior Certified IT Architect Tom Carr Certified Project Manager, Software Deployment Architect Rob Coventry Technical Sales Manager, Central Region Architects Nicki Cowley ELA Competency Center Specialist Paul Edwards PMP, Certified Project Manager, Software Deployment Architect Kathy Hofstrom Business Unit Executive, Technical Sales, Central Region, IBM Americas
Preface
xiii
Jess Knowles, Lotus Services Sales Representative Kathleen OLeary Program Manager Mac Pogue Certified Project Manager, Software Deployment Architect Jennifer Ramirez Software Deployment Architect Lauren States VP Technical Sales and Deployment Beverly Vandahl Program Manager - ELA Deployment Kim Waddell Director ELA Deployment William Welch Software Deployment Architect Julie Czubik Techincal Editor, International Technical Support Organization, Poughkeepsie Center
Become a published author

Join us for a two- to six-week residency program! Help write an IBM Redbook dealing with specific products or solutions, while getting hands-on experience with leading-edge technologies. You'll team with IBM technical professionals, Business Partners and/or customers. Your efforts will help increase product acceptance and customer satisfaction. As a bonus, you'll develop a network of contacts in IBM development labs, and increase your productivity and marketability. Find out more about the residency program, browse the residency index, and apply online at:
ibm.com/redbooks/residencies.html
xiv
Comments welcome
Your comments are important to us! We want our Redbooks to be as helpful as possible. Send us your comments about this or other Redbooks in one of the following ways: Use the online Contact us review redbook form found at:
ibm.com/redbooks
Send your comments in an Internet note to:

redbook@us.ibm.com
Mail your comments to: IBM Corporation, International Technical Support Organization Dept. JLU Building 107-2 3605 Highway 52N Rochester, Minnesota 55901-7829
Preface
xv
xvi
Chapter 1.
Why focus on software deployment

Customer example: GMR Corporation (GMR) is a growth company focused on a wide range of merchandise retailing. Their operating strategy is to provide the highest value to consumers through multiple store formats. In the most current fiscal year, GMR Corporation reported revenue over $40 billion U.S. In December 2002, GMR made an enterprise-wide purchase of software from IBM. Early in the deployment, they recognized the need for a structured method to deploy their software and they turned to IBM for assistance. Throughout this book, we refer to GMR and other customers who leveraged various aspects of this book (that is, the Software Deployment Method (SDM)) and as a result, achieved greater success and improved return on investment (ROI).
Software deployment is defined as the process of putting software and software solutions into use or action and ultimately driving business success.
The extensive experience of IBM in deploying software has revealed that many of our customers do not recognize the level of commitment that is required from them to achieve software deployment success. Also, some customers are not
taking steps that are necessary to achieve business value. Consider these examples: A deployment strategy is not mapped out, early projects are not identified, and the scope and schedule of software implementation are not considered. A transition plan from the purchasing team to the implementation team does not clearly articulate expectations, roles, and responsibilities. Identified deployment projects do not finish on time. Software deployment is inherently complex and involves multiple components or organizations. Therefore, reactive project management results in delayed implementation due to challenges that arise late in the deployment process. Successful solutions and the deployment processes are not leveraged across the broader enterprise. The customer and IBM organizations are tasked with a single implementation. Therefore, they do not focus on leveraging the lessons, experiences, and investment from this single need across the broader environment. The lack of focus in these areas has resulted in less than optimal return from a software purchase. It has also spawned situations where multiple projects are run in parallel with inadequate infrastructure or mechanics to leverage common components, tasks, resources, lessons, etc. These experiences suggest that successful software deployment does not just happen. It requires proactive focus and attention from both you and IBM in the following areas: Understanding and qualifying the initial demand (projects) Identifying the core team, with individuals from IBM and your company, that will coordinate the overall software deployment process Developing a deployment strategy that will achieve the defined business goals Continually defining new projects that will help you overcome new challenges To address these needs, this redbook and the Software Deployment Method described within were established.
Note: As of the printing of this redbook, IBM Software Group has twelve specialty areas that span the five IBM SWG brands. The brands are Data Management, Lotus, Rational, Tivoli, and WebSphere. The specialty areas are Automation, Business Integration, Business Intelligence, Content Management, Development Tools, Document Management, Linux, Pervasive, Portals/Dynamic Workplace, Security, and Storage.
1.1 What makes software deployment so difficult

Regardless of the size or scale of the software deployment, you must address several challenges to its success: Separation of the negotiation team from the implementation team. Ideally, key members of the implementation team and key stakeholders participate in the development and negotiation of any agreement. This begins the sense of ownership and ensures that the business goals drive the product selection process. If these teams are separate, a complete transition is key. Roles and responsibilities must be crisply defined, assumptions clarified, and expectations documented. It is too easy for early projects to falter or become delayed as teams try to collect information and direction from the negotiation process after the fact. When an agreement is closed, all projects may not be concretely defined to maximize software utilization. Because of this, additional projects must be identified to put the purchased software to use. In addition, new or changing business needs will arise and must be responded to throughout the deployment cycle. Often times, the person or persons who will own software deployment from your organization are not identified or may be out of the loop during project identification and product selection. Therefore, there may be members of your team who are integral to the deployment process and are unaware of the products that were purchased and what business challenges the agreement was crafted to solve. Some organizations or individuals may be opposed to the vendor or the products purchased. This can potentially undermine the success of one or more projects. The deployment of software sold can cross a wide range of departments, lines of businesses, and multiple contacts that may or may not have been included in the selling or negotiation phases of the agreement. Therefore, it is not uncommon for the IBM team to call on individuals who may not be fully aware of your overall corporate Information Technology (IT) strategy. This can create challenges during the deployment phase. That is to maximize
Chapter 1. Why focus on software deployment
deployment performance, the entire IT organization must be aligned behind one mission, regardless of how tactical the individual needs may be. It is not uncommon for software to remain unused for long periods of time during the term of the agreement. Recognizing this situation early and putting actions in place to rectify it are critical steps to avoid surprises.
1.2 Why have a Software Deployment Method

We believe that the key to deriving value from your software depends on the adherence to a common roadmap or method that solves your business problems. Following this roadmap helps the individuals assigned to deployment, within your organization and IBM, to act as one team that is focused on a common goal. This redbook describes the Software Deployment Method that, when followed, should maximize your chance of deployment success.
1.3 The Software Deployment Team

Many individuals from your company, IBM, and partners must work together smoothly to ensure the successful deployment of your software. In this book, we refer to this team as the Software Deployment Team. Your representatives on the SDT are: Enterprise Business Sponsor (EBS) Stakeholders and sponsors Project managers The IBM representatives on the SDT are: Software Sales Representative (SSR) Specialist Software Sales Representative (SSSR) Software IT Architect (SWITA) Software IT Specialists Services representatives (IBM Global Services, Brand, Education, Support, etc.) The partner representatives on the SDT are: Third-party project managers IBM Business Partners assisting in administrative or deployment functions Third-party implementation consultants
The SDT should meet as required to develop software deployment strategies and review software deployment progress. For further information about the roles and responsibilities of the SDT, refer to Chapter 2, Roles and responsibilities on page 15.
1.4 The Software Deployment Method

As shown in Figure 1-1, the Software Deployment Method consists of three phases and 11 steps. Although these phases and steps are discussed throughout this book in a serial manner, in practice they often overlap and repeat throughout the life cycle of deployment. The phases are: Phase 0: Prepare for deployment. Phase 1: Refine and promote the plan. Phase 2: Deploy software.
Phase 0
Step 0: Create Software Deployment Team Step 1: Review Documents
Phase 1
Step 4: Refine Deployment Plan Step 5: Finalize Deployment Plan
Phase 2
Step 7: Achieve Quick-wins Step 8: Execute Deployment Plans
Step 2: Develop High-Level Deployment Plan
Step 3: Establish Deployment Partnership
Step 6: Conduct Deployment Kickoff
Step 9: Identify New Business Needs
Step 10: Update Business Plan
Prepare
Refine and Promote
Deploy
Figure 1-1 Overview of the Software Deployment Method
1.4.1 Phase 0: Prepare for deployment

The overall purpose of this phase is for you and IBM to build the groundwork required for successful deployment. The steps in this phase are:
Step 0. Create the Software Deployment Team (SDT): During this step, you,
IBM, and any partners who may be involved work together to determine the team that will be focused on the overall success of the software deployment. This team is called the Software Deployment Team.
Step 1. Review the critical deployment documents: The purpose of this step is
to obtain a common understanding among the SDT of the critical documents that will be used in the deployment process. During this step, the SDT reviews documents such as the contract, roles, and responsibilities, business context diagram, requirements, solution concepts, etc.
Step 2. Develop a high-level deployment plan: The purpose of this step is to

create a high-level mapping of products to your projects and assign ownership at a project level. The high-level deployment plan defines a list of initial deployment projects, identifies sponsors and owners from within your business for known projects, groups deployment into logical chunks, contains a deployment timeline, and includes a services assessment. During this step, you should also consider your readiness for deployment by reviewing the software deployment best practices and the readiness plan content, which are both described later in this redbook.
Step 3. Establish a deployment partnership: This step involves holding a

formal meeting between your deployment owners, participants, or both and IBM to come to closure on major issues that must be addressed. Such issues include deployment best practices, identification of the sponsor, or determining whether services will be used. This should solidify the partnership between you and IBM and help ensure that both groups realize that deployment is a two-way street. Keep in mind that you are ultimately responsible for the deployment. During this step, the SDT identifies quick deployment wins that act as both technical proof points and create momentum. It also defines critical success milestones and criteria. They agree on roles and responsibilities and introduce the software deployment best practices and the readiness plan. You and IBM should agree on the high-level deployment plan created in the previous activities and discuss a deployment services strategy.
1.4.2 Phase 1: Refine and promote the plan

This phase begins after an agreement is in place and when critical inputs are reviewed again to inspect any changes made during final negotiations. Also, during this phase, the deployment plan is refined and the deployment kickoff meeting or meetings are held. The steps in this phase are:
Step 4. Refine the high-level deployment plan: The purpose of this step is to
revise the solution architecture and deployment plans to reflect any changes made during the final negotiations. During this step, the SDT reviews all inputs to Steps 1 and 2 (for example, the contract and list of deployment projects and owners) to determine if anything has changed. The team also completes a thorough review of the requirements, architecture, components, interfaces, and any performance modeling that has been done. A key output from this step is a refined deployment plan.
Step 5. Finalize the deployment plan: The purpose of this step is to obtain
final agreement with the deployment plan among the SDT. During this step, the SDT reviews all inputs to Step 3 and agrees on project controls. Also, during this step, you and IBM should discuss the plans for one or more deployment kickoff meetings.
Step 6. Conduct deployment kickoff meetings: The purpose of this step is to

market and communicate the deployment plan and overall vision to all current and potential users within your company. This is typically done in the form of a meeting or a series of meetings attended by your stakeholders (team project leads, IT leads, and lines of business leaders) and the full IBM team. It is imperative that key leaders and present or future stakeholders attend. Use these meetings as the forum to bring together the stakeholders, sponsors, and implementers and explain the business goals, IT vision, contract details and content, and the deployment plan. Explain what will be accomplished, why it is important, how this will be done over time, and when major milestones are expected to be reached. The kickoff meetings should create awareness, understanding, and enthusiasm for the deployment that is about to begin.
1.4.3 Phase 2: Deploy software

The purpose of this phase is to begin executing against the deployment plan. It starts with the carefully selected quick deployment wins and then moves on to the other projects. During this phase, project management is critical. The steps in this phase are:
Step 7. Achieve quick deployment wins: The purpose of this step is to

implement the quick deployment wins and, in doing so, demonstrate success. This will build momentum, confidence, and credibility, which are vital in the beginning stages of deployment. This is also the time to revise any processes defined during earlier planning that have not worked as expected.
Step 8. Execute the deployment plan: The purpose of this step is to build on
the success and momentum of the quick deployment wins. This is also when you begin deploying projects that were defined before and during the product selection. During this step, project management is critical. You should monitor carefully your stakeholders satisfaction and progress toward deployment goals (timeline and financial).
Step 9. Identify new business needs: Due to the dynamic nature of business,
your business needs that were not known or identified during Phases 0 and 1 typically arise after deployment has begun. These new business needs may be satisfied with software that was part of the original agreement, or they may require the purchase of additional software that will be deployed in new projects. This is referred to as the software gap. To prepare for and meet the
new business needs, the SDT should return to Phase 0 and follow the roadmap for its planning and implementation.
Step 10. Update the business plan: The purpose of this step is to complete
any purchase of software, and potentially additional services and education, that will meet the new business needs identified in Step 9. In this step, you also make the appropriate changes in the existing plans that will accommodate its deployment.
1.4.4 Software deployment method: A continuous process

Figure 1-2 illustrates that the SDM is a continuous process. The outer circle represents the activities that should occur prior to the software acquisition. The inner circle represents the necessary steps to ensure that software is deployed properly. After a new software requirement is defined, SDM Steps 0 through 3 should occur in sequence (outer circle). After the purchase of software is completed, the life cycle enters what is called the software deployment mill. In the mill, SDM Steps 6 through 10 are executed (inner circle). These steps include deployment kickoff and communication cadence, quick deployment win execution, and deployment plan execution. Also, in the mill is the requirement that new demands constantly be uncovered. This can be a demand for software already purchased that burn down licenses that are not yet deployed. Or it can be a demand for new software requirements that require an acquisition to occur. After a new software requirement is defined, the business plan is updated in Step 10. If this software is already purchased, the process continues within the mill back to Step 6 (kickoff and communication). This, in effect, increases the size of the mill because more deployment activity is underway. If the software identified in Step 9 requires an acquisition, then Step 10 jumps to Step 1 (from the inner circle to the outer circle). This is where the new software can be properly built into the contract and the high-level deployment plan (Steps 1 and 2). The assumption is that you can skip Step 0 because the Software Deployment Team is already established. Step 3 leads to the required acquisition, and when the new software is fed into the deployment mill, the size of the mill increases.
Software Deployment Method

Software Acquisition New Software Requirement Defined
Software Deployment Method Steps
Step 10: Purchase Software & Update Business Plan

Step 8: Execute Deployment Projects
Step 4&5: Refine & Finalize High Level Deployment Plan
Step 3: Establish Deployment Partnership with Vendor
Software Deployment Mill
Step 0: Create SW Deployment Team
Step 7: Execute Quick Deployment Wins Step 6: Kick-off & Communication
Step 2: Develop High Level Deployment Plan
Step 1: Review Contract Content & Critical Deployment Documents
Figure 1-2 Software Deployment Method cycle
Figure 1-3 introduces the positive impact an effective deployment strategy can have on return on investment. As the software deployment mill increases in the number of active and completed deployment projects, the deployed license count increases exponentially. As the mill increases in size it begins to approach the size outer circle (purchase volume). When the inner circle grows to the size of the outer circle, ROI has been achieved.
Return on Investment Timeline
Software Deployed
ROI
Software Deployed
Step 11: Purchase Software & Update Business Plan
Software Deployed
Time
Figure 1-3 Software Deployment Method value timeline
1.5 Software deployment best practices

Deployment success and value realization require that you focus on the following best practices: Identify an Enterprise Business Sponsor and stakeholders. Centralize software fulfillment. Implement a license management tool and process. Hire deployment services. Determine your deployment readiness. Commit to self-sufficiency. Define a time-to-value and ROI strategy. Communicate and market the vision. For assistance in understanding the best practices and applying them to your organization, IBM can host a software deployment workshop. This workshop includes the Enterprise Business Sponsor, the Software Deployment Team, and
10
key stakeholders from your organization. It is designed to both deliver the benefits of the best practices and to discuss any gaps that need to be addressed You can find more information about these best practices in Chapter 3, Software deployment best practices on page 23. For more information about value realization, time-to-value, and ROI, see Chapter 4, Value realization on page 33.
1.6 The readiness plan

After you commit to purchase IBM Software, it is critical that your employees acquire the skills and process knowledge necessary to successfully implement the solution. The readiness plan is designed to facilitate the communications and planning between you and IBM at critical junctures. It is prepared by the IBM Software IT Architect or Technical Specialist. The number of readiness plans that are required depend on several factors such as the people who are involved, the complexity of the environment, and the number and complexity of projects. A well-executed readiness plan proactively addresses implementation issues. In turn, it promotes enhanced satisfaction with the IBM solutions. The readiness plan itself is a set of processes and work products that are designed to: Help ensure your expectations are properly set and met Identify issues and risks and set a proper course of action Help ensure your team has the appropriate skills for implementation Assign responsibilities and ownership of implementation tasks The readiness plan is a compilation of subplans that can be delivered in many different ways. The selection of plan elements is based on the needs of the solution. The timing of the delivery is highly dependent on each individual situation. The IBM team helps you fully understand the nuances of the readiness plan and crafts a readiness plan that is best for your situation. You should sign off on the readiness plan, which signifies your acknowledgement of the scope of responsibilities from both you and IBM.
1.7 Solution Assurance Review

Solution Assurance Reviews (SARs) are used to review proposed solutions. IBM subject matter experts perform these reviews to ensure that the solutions can deliver the features that you expect and that they are technically possible to implement.
11
We recommend that you incorporate the SAR process into your existing methods and use it proactively to minimize deployment challenges. If you have a particular situation where you want to consider a SAR, contact a member of your IBM Software team.
1.8 Software solution work products

One of the mantras at IBM is don't reinvent the wheel. In the spirit of reuse, we include examples of work products in Appendix A, Software solution work products on page 93. We mention many times throughout this redbook that planning and design are key attributes to any successful software deployment endeavor. The work products contained in this appendix have been used by IBM project managers and architects to drive successful deployment projects all over the world. If you have any questions about how to use these work products, contact your IBM Software Sales Representative, your IBM Software IT Architect, or your IBM Software Services representative.
1.9 Software deployment: A two-way street

We recommend that the SDT follow the method described in this redbook because it has been proven to lead to successful software deployment. In turn, successful deployment helps you overcome your business challenges and achieve your business goals. It is important to realize that deployment is a two-way street between you and IBM, and that your success fuels our success as well. Let deployment begin.
12
Customer example: Soon after signing an Enterprise Agreement (EA) with IBM, GMR recognized the need for a single owner for the EA. The responsibility of the owner would be to ensure the successful deployment of the software purchased in the EA. GMRs Vice President of Architecture for Technical Services was placed in the role of Enterprise Business Sponsor (software deployment best practices #1) by his manager (the Chief Information Officer (CIO)). His first step was to identify a team of IT Managers to assist with identifying a deployment strategy for GMR. IBM already had in place sales and technical sales representatives, including a SSR and SWITA. These two groups, when combined, created the SDT (SDM Phase 0, Step 0). One teamGMR and IBMfocused on ensuring the success of the EA. The SDT quickly defined a high-level deployment plan that identified a long-term view of deployment direction. The SDT also defined quick deployment wins, five products from the EA to be deployed immediately. These quick wins were to be delivered in the near term to build confidence and generate excitement around the technology and solutions while supporting GMRs business objectives. The leader of GMRs EA Deployment Team identified product captains for the helm of each quick deployment win. Their responsibilities were to define and execute a realistic plan to use the software in at least one pilot project and to build the infrastructure to support use of the quick win software in future projects. In addition, they had the responsibility to communicate and market successes within GMR Technical Services. To facilitate this communication and marketing effort, GMRs EA Deployment Team devised an event entitled EA Land (SDM Phase 1, Step 6). EA Land was organized to allow the product captains to highlight their teams achievements during the first eight months of EA deployment work. Along with product tables and two demo rooms, staffed by GMR and vendor representatives, process tables were included, such as quality assurance, information architecture, and solution services. This ensured that the excitement about the EA products that was generated by EA Land did not overwhelm GMRs deployment process. Over 1,200 GMR IT professionals were invited to this event. Because of GMRs focus on planning, communication, and several other principles that are highlighted in this redbook, GMR achieved several early successes in their EA deployment effort. Along the way they also successfully designed and implemented a process to help ensure successful software deployments in the future.
13
14
Chapter 2.
Roles and responsibilities

Finding good players is easy. Getting them to act as a team is another story. Casey Stengel, famed manager of baseball's New York Yankees One of the many reasons you may have decided to do business with IBM is because we have many skilled professionals involved in the sales and deployment of our software, hardware, and services. The challenge when many people are involved is to ensure that the roles and responsibilities are clearly communicated to you. It is equally important that any expectations you have of IBM, and vice versa, are defined as early in the software deployment process as possible. One of the more common concerns found when analyzing deployments is that roles and responsibilities are not clearly stated up front. Then, as the deployment progresses, confusion arises over who is supposed to perform certain tasks or when they will be done. The foundation, therefore, for deriving value from your purchases begins with ensuring that your team and the IBM team know their own roles and the roles of each other. Who is supposed to do what? And when should they do it? This chapter describes that foundation.
15
2.1 Internal team

Your internal team members include an Enterprise Business Sponsor (EBS), project leads, stakeholders, sponsors, and a Global Project Lead if there is significant deployment planned in multiple locations.
2.1.1 Enterprise Business Sponsor

The EBS is generally appointed by a senior executive in the Information Technology (IT) organization. The EBS should represent your companys goals, take ownership for software deployment throughout the enterprise, and commit to the following responsibilities: Develop and promote an internal vision for attaining the maximum usage of purchased licenses, based on the benefit derived Work with the lines-of-business and IT leads to delegate responsibility for deployment success and return on investment (ROI) Represent the business globally, if applicable Define deployment milestones Assist with marketing and demand generation of the software portfolio within the organization Establish quick deployment win initiatives to establish project credibility as early as possible
2.1.2 Stakeholders, sponsors, and project leads

Stakeholders are those individuals who requested or will benefit from the solutions being provided. This group needs frequent feedback on designs, prototypes, and progress toward a final deliverable to maintain confidence in the solution and delivery team. Sponsors are those individuals who are funding the deployment work to provide the solution to the stakeholders. The sponsor may also have selected or approved the high-level architecture and products to be used in the solution. Sometimes, the stakeholder and sponsor are the same individual or group. Project leads are in charge of individual projects that contribute to the solution paid for by the sponsor and to be delivered to the stakeholders. They manage the day-to-day execution of the project vision and direct the efforts of the development specialists.
To make the most of your software investment and exploit the value of that investment, it is critical to have early and frequent communication with the
16
stakeholders and sponsors for each project. Both the marketing of successes and the alerting of obstacles become a vital part of keeping the projects on track. It is equally important to repeat the vision and ultimate goals for deployment projects to the project managers and implementers. Without this cadence of direction, projects can lose themselves in the day-to-day issues and lose site of the business reasons for the implementation. It is the progress toward meeting your business needs, more so than a particular technology or technique, that is the goal of any deployment.
2.1.3 Global Project Lead

The Global Project Lead (GPL) is assigned to global software deployments and coordinates all deployment activities going on around the world. This person should: Have excellent project management skills as well as experience on the global stage working with a variety of people from differing cultural backgrounds. Have experience managing complicated projects. This implies that they can handle complicated products, and combinations of products, and complicated geographical challenges. Be a self starter, constantly looking for opportunities to increase the deployment footprint. For more information about the GPLs role, refer to Chapter 9, Managing global software deployment projects on page 73.
2.2 Team IBM

Team IBM refers to the many people from IBM who are involved in making your software, hardware, and service purchases successful. While each person has their own unique focus and specialty, it is the goal of each individual to present a cohesive view of the IBM Company. When leveraged, the IBM team can be a tremendous asset to you. Their wealth of expertise is unmatched in the IT industry. Also their knowledge of your business goes far beyond the scope of the software that is being deployed. The IBM team members come from such organizations as IBM Global Services, the System Group (Server/Storage), IBM Global Finance, Personal Computing Division, Printers, Partner Channels (Global and Small to Medium), and the IBM Software Group. Almost every software agreement requires participation from these organizations. Leveraging such a diverse team can greatly enhance the deployment process.
Chapter 2. Roles and responsibilities
17
Typical examples of engaging multiple IBM organizations are IBM Global Services for implementation support, IBM Global Financing for financial assistance, and the System Group for the required servers and storage. The deployment process is enhanced if these organizations, in concert with IBM Software Group, are engaged early in the cycle of project development and architecture definition. Figure 2-1 provides an overview of the various IBM roles.
IBM Client Team Software Focused View

Server Group Global Services Software Group
Managing Director (MD) Client Executive/Client Director Client Representative/Client Manager Client IT Architect (CITA) Software Sales Representative (SSR) Software IT Architect (SWITA) SWG Brands Middleware Solution Areas* DB2 Business Intel, Content Mgmt/ Doc. Mgmt Specialty SSR IT Specialists Services Support Lotus Portals, Dynamic Workplace Specialty SSR IT Specialists Services Support Tivoli Automation, Security, Storage Specialty SSR IT Specialists Services Support WebSphere Business Integration, Pervasive Specialty SSR IT Specialists Services Support Rational Development Tool Specialty SSR IT Specialists Services Support
* Other solution areas that span SWG are: Linux and z-Series
Figure 2-1 IBM client team - Software-focused view
2.3 IBM Client Team

The IBM client team consists of the following members: IBM Client Executive IBM Client Representative IBM Client IT Architect
18
2.3.1 IBM Client Executive

The Client Executive builds a long-term business relationship with you by identifying opportunities to improve your business and delivering solution strategies that meet your business needs. The Client Executive maintains business relationships at the senior management level of your organization. The Client Executive is accountable for your overall satisfaction with IBM.
2.3.2 IBM Client Representative

The Client Representative builds long-term business relationships with you and your team by providing solutions to your business needs. This is accomplished by: Communicating the IBM solutions to gain understanding and commitment Engaging appropriate resources Helping to ensure overall satisfaction They partner with the software, hardware, and services representatives as needed to ensure a complete solution is presented. However, they also communicate your business and technical strategies back to Team IBM to maintain focus on your business needs.
2.3.3 IBM Client IT Architect

The Client IT Architect has a role similar to that of the Software IT Architect. The CITA has strategic responsibility for the entire technical IBM relationship across hardware, software, and services. A strong partnership between the CITA and your technical leaders is critical to guiding Team IBM and ensuring that the proposed solutions are appropriate to your technical vision.
2.4 IBM Software Team

The IBM Software Team consists of the following members: Sales (non-technical): Software Sales Representative (SSR): Cross-brand strategy and sales Specialist Software Sales Representative (SSSR): Single brand sales and tactical sales support Technical Sales: Software IT Architect (SWITA): Cross-specialty/cross-brand strategy and deployment Software IT Specialist (ITS): Single brand sales and tactical support
19
2.4.1 IBM Software Sales Representative (SSR)

SSRs formulate strategies that link IBM Software with your business strategies. The SSR should work closely with you to: Understand your business needs and propose IBM solutions to meet those needs. Manage customer relationships and problems. Negotiate future software agreements. Help you understand the IBM Software Strategy and how it is of value to you. Increase satisfaction with IBM Software solutions. Coordinate efforts of the IBM Software team to match your business strategy. Each SSR provides a single sales face to you across all of the IBM Software brands.
2.4.2 IBM Specialty Software Sales Representative (SSSR)

The SSSR focuses on one or more IBM software specialties and works with the SSRs, ITSs, and SWITAs in doing so. SSSRs have knowledge of IBM strategies and directions for the specialties they represent. They are responsible for positively impacting your satisfaction with the offerings within their respective specialties.
2.4.3 IBM Software IT Architect (SWITA)

Using the entire IBM Software portfolio as a palette, the Software IT Architect paints comprehensive technical solutions that solve your business and IT challenges. These comprehensive technical solutions translate your business vision into specific technical designs. After listening to and analyzing your business needs, the SWITA designs a solution that integrates into your IT environment and leverages the best technology available from IBM. The SWITA has an overall responsibility for the technical solutions delivered to you and helps ensure those solutions are successfully deployed. The SWITAs responsibilities are to: Work with you and the IBM team to translate your business vision and IT challenges into a specific design. Develop plans to prove or implement the technical design. Build and maintain relationships with your key IT decision makers. Direct the IBM activities required to design and implement a solution.
20
Focus on your technical strategy rather than on specific products or tactical implementation issues. Use tools and established methodologies to help you develop the strategy and vision for the IT systems and shape this vision into a specific technical design. Employ accepted design methods, patterns, and best practices when performing analysis and designing project phases. Understand the integration of the IBM Software products and how the solutions compare with those offered by our competition. Recommend appropriate education and services based on knowledge of your environment and skill levels. Investigate new software technology and design methods to provide proactive education. Manage the Solution Assurance Review (SAR) process. Help you understand and adopt the software deployment best practices. Help you prevent software from becoming shelfware. While the IBM Software IT Architect has an overall responsibility for the technical solutions, there are circumstances that require a more specialized architect to concentrate on the deployment of your software. The IBM Software Deployment Architect (SDA) assists you in the development of software solutions that use your existing software. They also use the entire IBM Software portfolio as a palette, but concentrate first on your existing and undeployed inventory. The assignment of an SDA is decided case-by-case. It is based on the complexity of your deployment, complexity of your contracts, or the geographic scope of your deployment plans. If you feel your deployment requires an SDA, you should discuss those needs with your Software Sales Representative. The SDAs responsibilities are to: Lead the design and deployment of technical software solutions by leveraging design methods, patterns, and best practices. Advise on the most architecturally sound combination of software to help ensure the efficient deployment of technical solutions. Customize documented deployment methods to facilitate solution success. Lead the IBM technical team to drive new and existing solutions to completion. Understand the integration of the IBM Software products and how the solutions compare with those offered by our competition.
21
Maintain an active role in the Solution Assurance Review process to ensure action items are closed and risks are mitigated. Help you understand the software deployment best practices. Help to ensure work products are documented and transferable to other technical professionals. Help to ensure software does not become shelfware.
2.4.4 IBM Software IT Specialist (ITS)

Employing a technical understanding of the capabilities of one or more specialty areas, the Software IT Specialist advocates solutions to your key IT decision makers. By using their technical knowledge and proven experience, the ITS provides a bridge between your technical challenges and IBM solutions. The responsibilities of the Software IT Specialist are to: Build and maintain a technical understanding of product capabilities. Understand your technical infrastructure and use this knowledge to identify potential solutions. Understand how IBMs software compares to our competition in their specialty area or areas. Ensure you are technically prepared for a successful implementation. Manage the Solution Assurance Review process.
22
Chapter 3.
Software deployment best practices

Best practices are tried and true methods that have a history of being successful. Deployment success and value realization are achieved when best practices are adhered to consistently throughout the Software Deployment Method. Through working with the many customers of IBM Software and seeing what works and what fails, we created the following list of software deployment best practices: Identify an Enterprise Business Sponsor (EBS) and stakeholders. Centralize software fulfillment. Implement a license management tool and processes. Hire deployment services. Determine your deployment readiness. Commit to self-sufficiency. Define a time-to-value and return on investment (ROI) strategy. Communicate and market the vision. It is important that you and the IBM team discuss and agree to follow these best practices, since they have proven to ensure the highest possibility of success. Table 3-1 summarizes the best practices that are described in this chapter.
23
Table 3-1 Summary of software deployment best practices Software deployment best practice Identify an Enterprise Business Sponsor Benefit Aligns business goals with Information Technology (IT) initiatives prescribed during software purchase decision Establishes an owner for software value, rate of return (ROR), and ROI Functions as a leader to track deployment progress and coordinate resources to execute projects Ensures that each person that has the desire to deploy software has the means of getting it efficiently and effectively Provides a control point from which software deployment progress can me monitored Allows you to verify your compliance with the terms and conditions of your software contracts Eases charge-backs between departments for requested software Provides intelligence regarding software deployment Allows better control of version management, patch delivery, upgrades, and general maintenance Gives you an opportunity to save money with accurate assessments of your software usage Ensures that an expert is engaged to help plan and execute the deployment Allows you to navigate the normal pitfalls of solution development by leveraging experienced consultants Dramatically increases the chances for deployment success Eliminates many of the unknowns associated with solution design and software deployment Guides you through the activities needed to improve software planning and deployment Helps to ensure that the deployment goes as smoothly as possible with the fewest challenges Ensures that, over time, the reliance on IBM services and support is minimized Reduces long term cost of ownership by building skilled teams, strong processes, and robust environments Provides common goals for the deployment teams to work toward Builds confidence with the achievement of quick wins Defines a schedule for achieving long term goals Provides a mechanism to gain community buy in
Centralize software fulfillment
Implement a license management tool
Hire deployment services
Determine deployment readiness
Commit to self-sufficiency
Define a time-to-value and ROI strategy
24
Software deployment best practice Communicate and Market the Vision
Benefit Increases the investment understanding by communicating the linkage between the strategic purchase and business goals Accelerates the rate of return and increases solution demand through advertised successes
3.1 Identify an Enterprise Business Sponsor and stakeholders

Customer example: The Chief Information Officer (CIO) of a major insurance company in Texas, U.S.A, has personally assumed ownership of their software agreement to drive their deployment projects. He delegates the day-to-day responsibilities to various project managers on his staff and maintains involvement with monthly status updates. Any inhibitors to their success are quickly dealt with so as not to impact their overall plan. Not only does the involvement of the CIO avoid any surprises, but also it ensures that his vision is continuously delivered and reinforced. Ownership for your deployment success may be at several different levels. For example, you may be the high-level Enterprise Business Sponsor and have delegated additional sponsorship to your direct reports. Or an IT executive may have delegated sub-sponsorship to separate lines of business. It is important that there is one executive who is responsible for the successful implementation of large or on-going transactions. If this person is you, seek out your local IBM team. They are eager to meet you and build the partnership necessary for your success. If the Software Deployment Team (SDT) feels that they cannot control the projects or implement any needed changes, it is possible they have not found or are not working with the Enterprise Business Sponsor. It may be that the individual given responsibility for deployment is not in the right position to drive success. The sponsor needs to know that there is a team ready to work together to achieve the business goals defined. It is with the Enterprise Business Sponsor that quick deployment successes need to be set. Ongoing successes should be expected and celebrated. The members of the SDT should work with the Enterprise Business Sponsor to identify any cultural, geographical, political, skills, or training challenges that need to be overcome. Define a strategy or plan to overcome each. It should also
Chapter 3. Software deployment best practices
25
be clear to everyone, from the Enterprise Business Sponsor to the individual developers, how to go about getting software support. The Enterprise Business Sponsor should also consider forming a Center of Excellence (COE), which provides a focal point for IBM Software expertise. This type of organization can facilitate the deployment at multiple phases in the deployment life cycle. While kicking off the deployment, a COE provides an internal organization and set of personnel that can increase the buy-in and willingness of other organizations to use the purchased software. This can be done with presentations, demonstrations, and proof-of-concept activities. During the deployment of software, a COE facilitates the sharing of skills, experiences, and resources across multiple projects. It accelerates and improves the quality of the entire deployment. Customer comment: The recommendation that one owner be defined for the successful deployment of software has been extremely beneficial. GMR Corporations (GMRs) VP of Technical Services
3.2 Centralize software fulfillment

Purchasing software for a large company involves a multitude of software packages, sometimes for a multitude of business projects, which need to be received, logged, distributed, and tracked. We give you the option to receive software on CDs or download them directly from our Passport Advantage Online Web site. This process is usually continuous until the software entitlements expire. Over time, the individuals or groups who need to receive software will likely change. It is important for you to initiate a centralized software fulfillment process as early as possible in the deployment life cycle. The key element of this process is having one party in your company be responsible for the receiptor downloadingof all software, logging its receipt, distributing it to those who need it, and tracking what is delivered. If it is not feasible to initiate this process within your company, consider contacting your IBM team to explore the option of using an IBM Business Partner for assistance.
26
Customer example: A leading health care provider in California, U.S.A., has partnered with IBM and their software partner to develop an electronic software delivery system that ensures the software is available to their users and tracked for accounting purposes. Not only can end users request authorization and download software electronically, but the system also produces a regular management report to the procurement office. This type of innovation has removed the burden of CD management, provided the tracking needed to demonstrate software utilization, and allowed the company to reduce their operation costs.
3.3 Implement a license management tool and process

In this age of distributed computing, departmental projects, and company locations that may span the globe, it is important to understand where your investments are and how they are being used. You may have contractual obligations to report on software usage or over usage, or you may use this information internally to manage costs or charge backs. Implementing a complete process with the appropriate tools allows you to fully understand your software usage. License management involves identifying: The licenses that are supposed to be installed The licenses that are actually installed The licenses that are actively being used The number of licenses that are forecasted to be installed Many companies have tried to accomplish this task with paper, spreadsheets, or e-mails. This tracking typically addresses only the first stage of license management, what is supposed to be installed. An equally critical stage is that of tracking what software licenses are actually installed and used, because departments may be charged for the software distributed to their community, whether or not it is used. Good record keeping and licence management techniques regarding your software installation and use can ensure that software is purchased at the required levels. At other times, an auditeither manual or with an inventory tooldiscovers widespread installation of software and leads you to believe that value is derived from that installation. In fact, software is often not removed or it is installed and later forgotten. If such an inventory is used to budget maintenance, you may be paying more than necessary to maintain support on unused licenses. Performing effective license management takes a combination of tools and processes. You should track both the software distributed that users should have
27
and use a tool to identify what is actually installed. Taking this a step further, the tool should ideally be able to tell you if the installed software is or has been used. Finally, you should factor in your projected deployment if using the data for budgeting purposes.
To address this need, IBM Software IT Architects (SWITAs) are experienced in creating complete and end-to-end processes to achieve this level of license management. We also developed a tool called IBM Tivoli License Manager (ITLM) to perform the installation inventory and create usage reports. Refer to Chapter 10, Software deployment resources: Support, education, tools on page 83, for further information about software deployment and license management tools.
3.4 Hire deployment services

Our most successful customers frequently engage with deployment services to augment their local expertise. These services personnel should be familiar with the products and be able to start planning and implementing your solutions immediately. They can also be helpful in transferring their experiences to your own staff and reduce the time you need to reach self sufficiency. Your IBM team has been involved with many services engagements and can help you determine what is needed for your unique situation. If you decide not to use an external services organization, then realize that your time-to-value may be further out than desired. Your internal staff needs more education and time to learn how to integrate the new technology into your existing environment. Customer example: GMR discussed the concept of including implementation services in their Enterprise Agreement. Ultimately they took them out to keep the initial cost down. Now that they are into their deployment, they are working on a separate services agreement that will provide help for any deployment teams that need it. In hindsight, they wish that they included the services in the original agreement.
3.5 Determine your deployment readiness

Anytime there is a transition in focus from product selection and negotiations to deployment activities, there is an opportunity for assumptions, unclear expectations, and added risk to your success. We developed a work product known as the readiness plan to document your readiness or preparedness for deployment and highlight any known risks. A readiness plan can be created at a
28
high level based on an overall vision and large purchase. However, we recommend a more detailed plan for each large or complex project before it begins. The IBM Software IT Architect, IBM Technical Sales Specialist, or both will work with your team members to collect the information needed to prepare a readiness plan. The plan may include some or all of the following subplans: Communications (including IBM support) Education and skills Architecture Deployment (Implementation, testing, and migration) Operations (Help desk support and systems management) Risks and dependencies Even if an upcoming project seems small and simple, it is to your advantage to consider all of these areas and document what is expected. This facilitates the identification of gaps and helps to direct corrective actions. Customer example: The Software Sales Representative working with a major customer in Italy always thought these plans and reviews were done for administrative purposes only. However, after experiencing several of them first hand, he and the customer realized how valuable they are at avoiding the pitfalls of a typical deployment engagement. We realize that doing this takes time. However, the time you invest here pays excellent dividends as you proceed with the deployment. These plans and thought processes help you to: Ensure that you have the right set of expectations and directives to successfully implement the proposed solution. Ensure that the IT solution lies within the art of the possible. Identify any issues and risks that may need to be escalated.
3.6 Commit to self-sufficiency

The goal of your IBM team is to decrease the level of involvement from IBM over time as you progress through your deployment plan. This is accomplished through a well-designed education plan that develops subject matter experts within your own organization for the solutions being implemented. You can kick start this by hiring deployment services, but you should strive to develop in-house expertise.
29
3.7 Define a time-to-value and ROI strategy

It is up to you to determine and communicate how you will calculate and measure value. This is typically stated as return objectives (ROI) and a time frame for that return (time-to-value). There are generally two different types of ROI used:
Soft ROI: This includes such examples as better monitoring or control

capabilities, transformation of IT or business processes, implementation of a strategic vision, and the adoption of a common look and feel.
Hard ROI: This includes such examples as headcount savings, system count
reduction, server consolidation, department or process closures, and outsourcing. You or the sponsoring executive should work with the Software Deployment Team to define the return objectives and map a timeline with value milestones. Revisit the milestones at least quarterly to help ensure that the deployment is moving forward effectively and delivering the intended results. Refer to Chapter 4, Value realization on page 33, for more information about this topic. Customer example: An insurance company based in Texas, U.S.A. has taken the time-to-value concept and applied it to their project selection process. In addition to the technical merits of a solution, the project managers work with the software vendor to show the business value that the project will provide and the expected time before that value is reached.
3.8 Communicate and market the vision

While your software partners and vendors are capable marketers of their products, they are not in the best position to market your vision. Therefore, the business drivers behind a software purchase are often not communicated within a company. Sometimes it is the inventory of software purchased and not deployed that gets forgotten. This internal marketing and communication should be led by you, the Enterprise Business Sponsor, to create demand, interest, and promote success. A key event that helps launch a large deployment effort is to host a deployment kickoff meeting. This meeting should take place soon after you close a software agreement. This event should introduce all of your stakeholders to the products purchased and how they fit into the vision. This is a good time to review these software deployment best practices. In addition, review any expectations that were set and the criteria that will be used to measure value. For more information
30
about the kickoff meeting, see 6.3, Step 6: Conduct the initial deployment kickoff meeting on page 56. Like the steady beat of a drum, communications should continue throughout the life of the deployment, marketing and surfacing deployment opportunities, and areas for improvement. The Software Deployment Team should monitor deployment progress and recommend adjustments in the communication plan. In general, keep those who need to know informed about the progress or inhibiting factors. An example of communications can be a newsletter or intranet Web page that keeps management and end users informed about recent accomplishments, milestones, and improvements. It is important to promote and validate the results of deployment often and to as many audiences as possible to keep up the momentum and excitement. Customer example: To facilitate this communication and marketing effort, GMRs EA Deployment Team devised an event entitled EA Land (SDM Phase 1, Step 6). EA Land was organized to allow the product captains to highlight their teams achievements during the first eight months of EA deployment work. Along with product tables and two demo rooms, staffed by GMR and vendor representatives, the Vice President (VP) of GMR Technical Services also asked to include process tables, such as quality assurance, information architecture, and solution services. The VP did this to ensure that the excitement about the EA products that was generated by EA Land did not overwhelm GMRs deployment process. Over 1,200 GMR IT professionals were invited to this event, and over 700 attended, an unprecedented turnout for an event of this type at GMR.
3.9 Software deployment workshop

IBM SWG has created a Software Deployment Workshop to compliment this redbook. It has been designed to help you build the internal skills and processes necessary to realize success from your IBM software purchases. This guided tour is presented to you and your stakeholders, and reviews the eight best practices that are enablers to your success. If you seek answers to any of the following questions, you could benefit from the workshop: What business and/or IT goals are you are hoping to accomplish through your software purchase? How will success and value be measured? What are the timelines and major milestone periods on the road to success? What deployment projects can be accomplished in the next 6 to 9 months to produce some quick deployment wins and gain confidence?
31
Is there a person or persons, across lines of business, responsible for realizing full value from the purchased software? Who will deploy software and handle knowledge transfer to your team? What personnel skill and experience gaps do you think may impact deployment progress? How is education delivered today (classroom, Web, etc.)? What internal matters (politics, factions, geographies, languages, cultures, etc.) exist that may impact deployment mindshare, buy-in, and progress? Across all lines of business, and within departments, how will the vision be articulated, goals be communicated, success be advertised, and potential challenges be averted? At the workshop we will work with you to set the right expectations, provide pre-workshop collateral, and offer follow-up suggestions to keep the momentum of deployment high. The workshop will: Introduce the Software Deployment Method. Determine what it means to plan for success. Identify quick deployment wins that will build confidence and momentum. Introduce Team IBM and review our core responsibilities. Step through deployment best practices and the readiness plan, and identify any gaps. Identify action plans to address gaps identified. Define value and determine how and when it will be realized. Sketch and discuss a high-level deployment plan that will achieve business goals. Schedule a follow-up meeting to checkpoint progress. To arrange for a Software Deployment Workshop for your team, contact your Software Sales Representative from IBM.
32
Chapter 4.
Value realization
The subject of how value is realized is far too often ignored. While neglecting or avoiding this topic may seem harmless, the impact on the overall success of your Information Technology (IT) and business goals can be dramatic. It is critical that you set aside time to regularly revisit the buying decisions that were made. This ensures that all parties involved in the deployment of software fully understand their roles and their responsibilities. This chapter reviews various ways in which value can be defined. You are given specific examples and supporting case studies to help you select a method that best matches your business. It is possible that you may not find a method that matches your needs. However, we hope that this chapter will foster discussions and work groups to develop a value realization strategy that works for you.
33
4.1 Value statement and value timeline

There is no right or wrong way to define value. When it comes to value the only thing you can do wrong is disregard it. The first step is to define a value statement. A value statement is not something you create once and set aside. It must be a living document that you can modify dynamically. Generally speaking, a value statement should describe the goals that were highlighted as part of the buying decision. Consider the following example: Our goal is to exceed 5% improvement in the availability, reliability, and efficiency of our ATM network. We will partner with IBM to achieve these goals and leverage their consulting, software, and hardware expertise to this end. To keep the value statement current, you must revisit it every time you purchase new hardware or software. The second step is to build a value timeline. The value timeline should also be dynamic in nature and include an illustration of key projects and key milestones. Figure 4-1 shows an example.
10/15/2003 Prototype
1/15/2004 User Testing
3/22/2004 HQ Rollout
6/15/2004 US Rollout
9/13/2004 Europe Rollout
12/15/2004 Asia Rollout
7/15/2003
Figure 4-1 Sample value timeline
4.2 The buying decision

If you are not familiar with the details of the buying decision, you need to find the person or persons and request a full debriefing. To begin, you need to know: What lines of business (LOBs) were involved in the negotiation process Who the key contacts are in these LOBs What business goals are being address by the latest software purchase What expectations were set as part of the decision making process
34
4.3 Return on investment

As early as possible, preferably before purchase is completed, the Enterprise Business Sponsor should determine how to realize return on investment (ROI). The work done up front to define ROI criteria will pay dividends throughout the entire life cycle of software deployment. ROI discussions typically lead to two types of measurements: Hard (tangible) ROI Soft (intangible) ROI According to most experts in this area, it is important to have both tangible and intangible ways to measure success. In many cases, the value may not be clearly defined in financial terms. Therefore, the only alternative is to look for non-financial benefits. A common misconception is that hard measures are good and soft measures are bad. It makes the most sense to determine what is best for your business and then measure and celebrate your successes. Hard and soft ROI can be developed at an individual product level. While this is not discouraged, it is important not to become lost in the details. It is more important to determine the overall benefits at the enterprise level and tie those benefits to your business vision.
4.3.1 Hard (tangible) ROI

Hard (tangible) ROI can be quantified with dollars or numbers. It is typically associated with:
Headcount savings: Solutions often provide automation or efficiencies that

allow more work to be done with the same number of employees (that is, additional employees dont need to be hired), or the current workload can be handled with fewer employees. Your Finance or Human Resources Department should know the full cost per employee, so these projections map cleanly to dollars saved.
System count reduction: Hardware has fixed costs associated with it.
Therefore, solutions connected with reducing hardware inventory through more efficient use of that hardware are tangible, and dollars saved can be shown.
Server consolidation: It may be cheaper to move solutions from several small

machines to fewer larger machines, while maintaining or improving the level of service. Again, since hardware costs are fixed, the dollars saved can be quantified.
Department closures: Solutions may eliminate the need for entire

departments. This may include headcount savings, system count reductions,
Chapter 4. Value realization
35
and server consolidations. It may also include the elimination of telephone, facilities, and real estate costs, all of which have associated savings. Professional studies that quantify hard ROI require significant time commitment, six to nine months in some cases. These studies involve questionnaires and interviews that may contain hundreds of questions. Since many departments in your company are asked to participate, your time investment can be quite high. When this process is completed, it may take several days or weeks for the analysis and results to be made available. For an additional word of advise, even hard ROI has a bit of subjectivity to it. Keep these points in mind before you embark on the long process of defining ROI in these manners. See Figure 4-2 on page 39 and Figure 4-3 on page 40 for good examples of how to calculate hard ROI based on software utilization.
4.3.2 Soft (intangible) ROI

Soft (intangible) ROI generally cannot be projected or have its progress measured in exact financial or other numeric terms. It involves such concepts as satisfaction, perception, usability, vision, etc. Consider the following examples of soft ROI:
Help the company achieve its strategic vision: It may be difficult to quantify
the value of attaining the business vision, but there should be no question as to the value of attaining it.
Enhance usability: For example, suppose that the many applications that
your employees had to work with all had the same look and feel. There can be productivity and satisfaction gains from achieving that goal.
Support business growth: Most businesses want to grow. Solutions that

support seamless business expansion are of value.
Streamline the way organizations work within the company: Efficiency is hard
to measure or prove, but employees usually know when it is missing. Solutions that re-engineer organizations or streamline processes may have soft ROI, but important ROI nonetheless.
Allow resource redirection: The better managed your environment is, the more time employees can be proactive rather that reactive. They can anticipate and plan for future business improvements. Improve employee satisfaction: Evaluate how your employees feel about their
jobs, their departments, the processes they follow, their productivity, the tools they use, their upper management, and their company. The challenge with soft ROI is that you need to determine how you will measure and track progress and performance. Step 6 of the Software Deployment Method
36
is when you hold a kickoff meeting with all the stakeholders. This is a good time to discuss how to calculate ROI. Everyone in this session must understand their responsibilities regarding deployment and ROI.
4.3.3 Realizing value with hard and soft ROI

Lets look at an example of how you may see both hard and soft ROI and how it may evolve over time. You may have a business goal to expand your company and add three new locations around the world to support customers more efficiently in their local languages. To support this goal, you purchase hardware and software for each location to support the business applications needed. The ROI for this project is soft because it results primarily in increased customer satisfaction and the attainment of a corporate goal. A year later there are advances in the hardware and software arena. A decision is made to consolidate the hardware onto fewer, but larger machines. This solution reduces your fixed hardware support costs and provide hard ROI. The original hardware may be returned (if leased) or redeployed to support other business needs. The quantity of software needed for the new locations may now be lower due to the lower number of machines or processors. This means that you can redeploy the now available software to support additional business needs and gain additional hard or soft ROI from the original, single purchase. This cycle may repeat over time. However, since your focus was on solving business problems and showing how each solution provided ROI, you can maximize that ROI over several projects.
4.3.4 ROI must support the business strategy

ROI helps an organization understand the value to be gained from investing in the deployment of software, hardware, and services. Whether the drivers for purchases are based on proactive needs or a reaction to trends and market direction, the desire to track and quantify benefits is usually absolute. Typically, the ROI is driven by the business looking to see an increase in productivity or some type of cost savings. Therefore, it is essential that you partner with your IBM team to quantify the benefits, tangible or intangible, and tie them directly to your companys business goals and objectives.
37
4.3.5 An approach to analyzing ROI

We recommend the following approach to measure ROI and the success of a deployment project: 1. Interview executives, managers, and employees. Gather business needs, current metrics, and possible benefits. 2. Review company data including organizations, processes, metrics, customer feedback, statistics on current states, and how knowledge is shared. 3. With the knowledge of practices and business processes within your companys industry, analyze and synthesize the data. 4. Create quantitative measures (spreadsheets) and qualitative measures (surveys and interview guides) to gather data concerning the benefits of implementing the solution for specific communities. 5. Determine the base line data for the quantitative and qualitative measures that you define. 6. Gather the new data after solutions are used by the people and communities for at least three months. 7. Calculate the benefits and define the value to the organization against the defined business requirements. 8. Make subsequent measurements and determine the on-going value. 9. Determine any need for changes in the metrics developed for measuring success or in the delivered solution. These steps offer an order and approach for identifying on-going measurements for success and lifetime ROI.
4.3.6 When business goals are met, everyone wins

The purpose of making investments in software, hardware, and services is to solve business needs and show business value. When business needs are solved, your business grows and improves. The results you get from these successes help build confidence in the Lines of Business you support. This makes your future deployment targets easier to plan and accomplish.
38
4.3.7 Example ROI: Current value

Figure 4-2 shows one way to illustrate the value of deployed software and the software gap left to deploy. It is based on the normal price for each software license, before any special discounting you may have. Licenses deployed or allocated to specific projects are compared with the value of licenses that have yet to be allocated to a project. Using this method helps you measure your progress against a specific software agreement.
Software Agreement Value Statement
Total # Licenses Licenses Software Purchased Deployed Allocated Gap 50 15 29000 10 29000 29000 30 500 350 5 25 250 40 5 29000 10 5000 750 15 300 100 2 25 250 5 0 0 0 20000 1500 10 200 100 2 0 0 5 10 0 0 4000 26750 5 0 150 1 0 0 License Value $17,000.00 $5,000.00 $25.00 $1,500.00 $25.00 $35.00 $200.00 $100.00 $1,000.00 $12,000.00 $9,500.00 $250.00 Deployed / Allocated Value $765,000.00 $25,000.00 $725,000.00 $15,000.00 $625,000.00 $78,750.00 $5,000.00 $50,000.00 $200,000.00 $48,000.00 Software Gap Value $85,000.00 $50,000.00 $0.00 $0.00 $100,000.00 $936,250.00 $1,000.00 $0.00 $150,000.00 $12,000.00
Product Data Management IBM DB2 UDB Enterprise Edition IBM Content Manager Lotus IBM Lotus Notes Seats IBM Lotus Domino Server IBM Lotus Sametime IBM Lotus Quickplace Rational IBM Rational ClearCase Tivoli IBM Tivoli License Manager IBM Tivoli Distributed Monitoring IBM Tivoli Enterprise Console WebSphere IBM WebSphere Application Server IBM WebSphere Application Developer
$237,500.00 $0.00 $62,500.00 $0.00 $2,836,750.00 $1,334,250.00
Additional Software Agreement Benefits IBM WebSphere architecture and implementation services IBM Tivoli License Manager quick start IBM DB2 data modeling and database consolidation services
$10,000.00 $5,000.00 $5,000.00 $20,000.00
Total Value: $2,856,750.00

Figure 4-2 Software deployment value and status by product
39
Figure 4-3 builds on the information collected in Figure 4-2. It groups the deployment by specific projects. You can use this to measure progress on a specific project or compare the amount invested in software and services against the expected benefit of that project.
Software Agreement Value Statement
Total # Licenses Licenses License Project Proposed Deployed Remaining Value Document Management Intranet IBM WebSphere Application Server 5 5 0 $9,500.00 IBM WebSphere Application Developer 50 50 0 $250.00 IBM DB2 UDB Enterprise Edition 10 7 3 $17,000.00 IBM Content Manager 10 5 5 $5,000.00 IBM Rational ClearCase 10 6 4 $200.00 IBM Tivoli Distributed Monitoring 25 17 8 $1,000.00 IBM Tivoli Enterprise Console 2 2 0 $12,000.00 IBM WebSphere architecture and implementation services IBM DB2 data modeling and database consolidation services Email & Collaboration IBM Lotus Notes Seats IBM Lotus Domino Server IBM Lotus Sametime IBM Lotus Quickplace IBM Rational ClearCase IBM WebSphere Application Server IBM WebSphere Application Developer License Management IBM Tivoli License Manager IBM WebSphere Application Server IBM WebSphere Application Developer IBM Tivoli License Manager quick start Deployed Value $47,500.00 $12,500.00 $119,000.00 $25,000.00 $1,200.00 $17,000.00 $24,000.00 $10,000.00 $5,000.00 $261,200.00 $2,507,250.00 29000 10 29000 29000 10 2 25 29000 10 5000 750 4 1 25 0 0 24000 28250 6 1 0 $25.00 $1,500.00 $25.00 $35.00 $200.00 $9,500.00 $250.00 $725,000.00 $15,000.00 $125,000.00 $26,250.00 $800.00 $9,500.00 $6,250.00 $907,800.00 $155,000.00 500 10 20 300 10 20 200 0 0 $100.00 $9,500.00 $250.00 $30,000.00 $95,000.00 $5,000.00 $5,000.00 $135,000.00 Project Investment $346,000.00
Figure 4-3 Software deployment value and status by product
40
Chapter 5.
Software deployment Phase 0: Prepare for deployment

The will to win is nothing without the will to prepare to win. Vince Lombardi, legendary football coach for the Green Bay Packers The overall purpose of preparing for your software deployment is to build the groundwork required for the successful deployment of your projects and solutions. The steps you take early in the deployment process facilitate a better understanding of your vision, enable successful kickoff meetings, and set the tone for a positive partnership between you and IBM. The following activities (shown in Figure 5-1) are discussed in this chapter: Step 0: Create the Software Deployment Team (SDT). Step 1: Review the deployment documentation. Step 2: Develop a high-level deployment plan. Step 3: Establish a deployment partnership with IBM.
41
Phase 0
Step 0: Create Software Deployment Team Step 1: Review Documents
Phase 1
Phase 2
Step 2: Develop High-Level Deployment Plan
Step 3: Establish Deployment Partnership
Prepare
Figure 5-1 Phase 0: Prepare for deployment
Customer example: GMR Corporation (GMR) defined an Enterprise Business Sponsor (EBS), created a Software Deployment Team, defined quick deployment wins, developed a high-level deployment plan, and established a strong partnership with IBM.
5.1 Step 0: Create the Software Deployment Team

When you are confident that you know which products you will purchase, start assembling the team that will deploy the products. Coordinate your efforts with the IBM Software Sales Representative (SSR) to create a team with members from both companies that will decide on deployment plans and projects. The team will also deal with any issues that come up in the deployment cycle. The typical roles that make up the SDT are: Business Sponsor Project leads IT architects Technical Specialists Services representatives Partner representatives (if involved)
42
The members should understand the common purpose behind the impending software purchase, decide on specific roles and responsibilities, and commit to working together to meet your goals. There should also be a commitment to known resource requirements.
5.1.1 Owners and participants

The responsible owners of this step are the EBS, the SSR, and the IBM Client Executive. The participants are the same as the owners.
5.1.2 Inputs, tasks, and outputs

Table 5-1 shows the inputs, tasks, and outputs for the creation of the Software Deployment Team (SDT).
Table 5-1 Inputs, tasks, and outputs for SDM Step 0: Create the SDT Inputs Need or requirement to form the team Tasks Create a Software Deployment Team that includes the following representatives: Enterprise Business Sponsor Project Managers Internal IT architects IBM Software Sales Representative IBM Software Technical Specialists IBM Software Deployment Architect IBM Software IT Architect IBM Services representative Outputs Software Deployment Team established. Team members understand their roles and responsibilities and are committed to the teams purpose and goals.
5.1.3 Benefits
The benefit of creating and maintaining the SDT is that the team members understand their roles and then accept the ownership for the deployment success.
Chapter 5. Software deployment Phase 0: Prepare for deployment
43
5.2 Step 1: Review the deployment documentation

After the SDT is formed, they should collect and review such documents as any current or pending contracts, business context diagrams, solution requirements and concepts. The purpose for the review is for the team to obtain a common understanding of the documents that will be used in the deployment process and the business needs that are driving your software purchases. At this point, it is critical to obtain from the Enterprise Business Sponsor a preliminary view of success and the expected value to be derived from the software purchase. The SDT should keep this in mind for the entire deployment process and use it to create the deployment plans. The team may need to revisit these goals and success criteria to be reminded of the business needs and prevent getting lost in the details of deployment. The SDT should thoroughly understand the content, terms, and conditions of any software purchase contract. Typically, this contains standardized terminology. However, because each agreement may be customized to meet specific needs, it may include special terms or clauses that need to be understood. The SDT should understand these customizations and how they affect the deployment process. If there are things that they dont understand, they should ask the team negotiating the contract.

The owners are the EBS, SSR, and the IBM Software IT Architect (SWITA). The participants include the project managers, internal IT architects, IBM Client Executive, IBM technical representatives and IBM service representatives. All members of the SDT should participate in this step.

Table 5-2 shows the input, tasks, and outputs for this review.
44
Table 5-2 Inputs, tasks, and outputs for SDM Step 1: Review the deployment documentation Inputs Draft contract Solution concept Requirements and use cases Business context diagram and description System context diagram Conceptual architecture Architectural decision document (ADD) Initial viability assessment Organization charts IT standards Current IT environment Project descriptions Tasks Discuss buying decision Ensure that the content and terms and conditions of the contracts are thoroughly understood Study substitution clauses Understand the status of maintenance and support Discuss any expectations Discuss license management tools and processes and how to track deployment Review the requirements, solution concepts, business context, conceptual architecture, and architecture decision document Review and refine the initial viability assessment (which includes the results of any Solution Assurance Reviews (SARs)) and confirm the solution Document the linkages between the planned projects and products Outputs List of open items for contract negotiation Updated viability assessment Draft goals and milestones document High-level mapping of business initiatives to projects Draft mapping of projects to products Initial software utilization report
5.2.3 Benefits
The benefits that result from this documentation review are that the SDT: Has a common understanding of the business vision and goals Agrees that the conceptual solution is viable and concurs with the viability assessment Confirms and agrees to the roles and responsibilities for both your company and IBM Has an awareness that the preparation phase of deployment has begun
45
5.2.4 Documentation review tips

Following are several tips for the documentation review:
Analyze the software in your inventory: Typically, you already own some IBM
Software from previous purchases. You may purchase new products that are recently released or that you didnt purchase before. It is important to perform a crosscheck between what you already own and what you are purchasing. Where do you stand with the deployment of your previous investment? Will some licenses from past purchases be used in conjunction with some newly purchased licenses to support your projects? Perform checks and balances to compare what you have with what you are going to purchase.
Understand substitution clauses: If you are purchasing through a large,

multi-year contract or negotiated special terms and conditions, your contract may include clauses that allow product substitutions. It is imperative that the SDT understand the verbiage and reasoning behind any substitution clauses. Substitution is not always straightforward and often has limitations in either quantity or product eligible for substitution. For example, you may not be entitled to substitute products between IBM Software product brands (such as WebSphere for Tivoli or Data Management for Lotus). Understanding the substitution rules now avoids surprises and assumptions that can lead to costly delays in the projects later.
Understand the status of maintenance and support: You may have purchased
maintenance in the past either with licenses or separate from the licenses. If you are making another software purchase, you will have new maintenance explained and you may want to bring all of your maintenance together. The SDT should determine which products are supported and who is receiving that support. All members of the SDT must fully understand any changes in the maintenance and support terms. Also, look ahead since the new solutions are defined to forecast who may need to be educated on the support process as you rollout the products.
Be aware of any global support needs: If you are a global company and the solutions you will deploy are in multiple countries or regions, ensure that all of your locations are educated in the support processes and are ready for the projects. You will work closely with your IBM team to set up these global locations for media, technical support in the local language and time zone, etc. It is best to address these needs early and avoid frustration when trying to accomplish this in a crisis. For more information about global deployments, see Chapter 9, Managing global software deployment projects on page 73. Be proactive: Through all of the above activities, the SDT should look ahead and address the needs before they become critical issues. Frequent discussions, a steady focus on the business goals, and early identification of potential issues will help you be proactive.
46
5.3 Step 2: Develop a high-level deployment plan

The high-level deployment plan should be a general mapping of products to projects and an assignment of ownership at the project level. The plan accomplishes the following tasks: Defines a list of initial deployment projects Identifies the sponsors and owners for known projects Groups the deployment into logical chunks Defines a deployment timeline This plan should also include ownership of any core infrastructure projects that are prerequisites for the implementation and management of the specific business oriented projects. Some examples include License Management, Problem Management, Configuration Management, Performance and Availability Management, Security, and Storage Management. These types of projects, whether based in software or manual processes, should be implemented before large-scale rollouts of the line-of-business projects to ensure the business solutions can be supported and managed. Early identification of ownership is critical because it provides the needed focus for these projects. It also ensures that they are implemented in a common manner across your entire enterprise, while minimizing redundant cost and effort. Ideally, you buy software based on identified needs. However, you may sometimes buy software based on projected needs or because of discount offers. Also, you may purchase software without a set of known projects that will use the software. Regardless of your reasons for buying the software, you should have a set of business goals in mind that you can mold into potential projects. These known or potential projects should drive the deployment planning and activities of the SDT. The list of projects should be started before any final contract negotiations conclude. The SDT should start by listing: All of the known projects All of the potential projects The IBM Software brands and products (if known) that will be involved The deployment locations The project owners and their contact information You may end up with a list of 60 projects and 60 separate project owners that will deploy over one 100 IBM Software products over the course of three years. Or, you may have three projects with one project owner and a broad identification of IBM Software brands to be deployed in one year. The objective is to identify the business goals, the projects that will support those goals, and the products needed to implement the projects.
47

The owners of this step are the project managers and the IBM Software IT Architect. The participants include the EBS, SSR, and all other members of the SDT.

Table 5-3 shows the inputs, tasks, and outputs for the high-level deployment planning.
Table 5-3 Inputs, tasks, and outputs for SDM Step 2: Develop a high-level plan Inputs Viability assessment Architectural decision document Solution architecture Component model Internal interface descriptions Goals and milestones Software deployment best practices High-level mapping of business initiatives to projects Draft mapping of projects to products Initial license utilization report Tasks Validate and refine the goals and milestones Group deployment into logical chunks based on business initiatives; assign ownership to the initiatives Refine the list of projects and assign ownership Create a high-level deployment timeline or phased execution plan for building the entire solution Assess gaps where services will be required Assess the need for infrastructure management projects Review an initial license utilization report and identify where existing software will be used and how new software will be tracked Determine any gap between products with defined projects and products that require further project definition Outputs Updated goals and milestones High-level, phased deployment plan Detailed mapping of products to projects to business initiatives Services requirements Environment and infrastructure requirements and projects Updated license utilization report
5.3.3 Benefits
The main benefit of creating a high-level deployment plan is that the SDT comes to agreement and understands the various aspects of the deployment. It should
48
be clear how the products purchased will be implemented to meet the business requirements and support the initiatives. Other benefits include: A high-level deployment timeline Identification of gaps in capabilities that may need to filled with services expertise Identification of gaps in identified projects that need additional attention
5.4 Step 3: Establish the deployment partnership

Successful deployments require a partnership between you and IBM, with all members understanding their unique roles. These roles and requirements were described in detail in Chapter 2, Roles and responsibilities on page 15. With you as the Enterprise Business Sponsor leading and setting the vision, the rest of the SDT helps execute on that vision. Three key activities that should occur before or at the closure of a software agreement are: Identify quick deployment projects Create a strategy to measure and meet ROI expectations Schedule deployment kickoff meetings You should also be ready to review any findings from the IBM teams readiness plan or gaps from the software deployment best practices (see Chapter 3, Software deployment best practices on page 23, for more information). Both the readiness plan and best practices are designed to help you be successful with your deployments. Customer example: The Chief Information Officer (CIO) of a major financial institution in Sweden recognized that the deployment of their enterprise wide software agreement required the focused efforts of a central team. Working with the CIO, IBM created a customized Web site that allowed the interested and authorized parties to go to one place to gather details about their enterprise agreement. At the CIOs request, IBM established a central point of contact to assist with contractual questions from the branches that were spread across four countries (regions). This type of leadership from the CIO greatly improved the communication and understanding of their very complex software agreement.

The owners include the Enterprise Business Sponsor and all other members of the SDT. The participants include key stakeholders and sponsors, the IBM Client Executive, and the extended teams from your company and IBM.
49

Table 5-4 shows the inputs, tasks, and outputs for establishing the deployment partnership.
Table 5-4 Inputs, tasks, and outputs for SDM Step 3: Establish the deployment partnership Inputs Updated goals and milestones High-level phased deployment plan Detailed mapping of products to projects to business initiatives Services requirements Skills gap analysis Environment and infrastructure projects Tasks Confirm buying decision and vision Identify quick deployment wins Define deployment milestones and measurements Review skills and projects gaps and define a strategy to address Review and discuss any roadblocks that could impact deployment Validate project owners Schedule date for first kickoff meeting Outputs Finalized goals and milestones Quick deployment win plan Validated high-level deployment plan Validated mapping of products to projects to business initiatives Validated gap analysis Validated environment or infrastructure projects Roadblock action plan Scheduled kickoff meeting
5.4.3 Benefits
You should realize the following benefits from the establishment of a deployment partnership: The SDT has an understanding of the goals and milestones associated with the software purchase. The SDT agrees to the high-level deployment plan. There is a strategy and timeline for the software deployment. There is a strategy to address skills and project gaps. The first deployment kickoff meeting is scheduled.
50
Chapter 6.
Software deployment Phase 1: Refine and promote plan

The next phase of your software deployment should, ideally, take place after any sales are complete and contracts are finalized. This allows the Software Deployment Team (SDT) to understand any last minute changes to the contracts and understand the documents prepared earlier. After you finalize and agree to the deployment plans, you are ready to start promoting the plans to the rest of your enterprise. This promotion activity continues throughout the timeline of the deployment plan, but starts by holding an initial kickoff meeting. The following activities (see Figure 6-1) are discussed in this chapter: Step 4: Refine the deployment plan. Step 5: Finalize the deployment plan. Step 6: Conduct the initial deployment kickoff meeting.
51
Phase 0
Phase 1
Step 4: Refine Deployment Plan Step 5: Finalize Deployment Plan
Phase 2
Step 6: Conduct Deployment Kickoff
Refine and Promote

Figure 6-1 Phase 1: Refine and promote the plan
Customer example: The kickoff meeting was crucial at GMR Corporation (GMR). They executed a kickoff with the EA team and the product captains. To ensure that IBM was on the same page, they also met separately to help formulate and validate GMRs plans. To ensure that this kickoff was not a one-time event with limited impact, GMR executed EA Land as the one-year EA anniversary approached. This event was effectively a trade show where GMR Technical Services showcases solutions and their deployment process. They also uncovered opportunities to extend the technology further into their enterprise. There were 700 confirmed GMR Information Technology (IT) people at EA Land, 500 in the demo sessions. That is a great turnout for this type of event at GMR, given that there are 1200 total people in IT who were aware of the event. Dave Backman, IBM Software IT Architect, for GMR Corporation.
6.1 Step 4: Refine the deployment plan

As you reach the final agreements on any pending software contracts, you may have last minute changes. SDT must review these changes after they are in a signed contract to evaluate how they may affect the deployment plan and
52
timeline. This should be a complete review of all documents to verify that the expected goals, requirements, products, and projects are still valid. The team should also review the architecture, components, interfaces, and any performance modeling that was done. The key output from this step will be a refined deployment plan. If you have been following this deployment method, you should already have a list of known and potential projects with assigned owners. After you finalize the software agreement, the SDT should finalize that list and check for any last-minute additions or changes. Since it is unlikely that you will start every project right away, it is important to meet with the project owners and explain the deployment plan and timeline. This shows the project owners that their needs are planned for and their projects will be addressed within an agreed to time frame. Some projects may be defined in sufficient detail and occur early enough in the timeline to perform project level deployment planning at this time. For these projects, the SDT works with the project owners to perform any necessary capacity and performance modeling. They should recommend a physical architecture and define or refine hardware and software requirements. They should also discuss environmental and infrastructure requirements for deployment. The IBM members may initiate a Solution Assurance Review (SAR) for the project at this time, if necessary. With this step completed, the majority of the planning for a successful deployment of the software is completed. Good planning leads to a smooth deployment.

The owners are the project managers and IBM Software IT Architect (SWITA). The participants include all members of the Software Deployment Team.
6.1.2 Inputs, tasks and outputs

Table 6-1 shows the inputs, tasks, and outputs for this step.
Chapter 6. Software deployment Phase 1: Refine and promote plan
53
Table 6-1 Inputs, tasks, and outputs for SDM Step 4: Refine the deployment plan Inputs Final contracts Architectural overview Component descriptions Interface descriptions Business initiatives Revisions to architectural plans High-level phased deployment plan Detailed mapping of products to projects to business initiatives Quick deployment win plan Goals and milestones Software deployment best practices Gap analysis Tasks Review the past activities, documents, and decisions Perform any necessary performance and capacity modeling Recommend a physical architecture Refine hardware and software requirements Discuss environmental and infrastructure requirements Create a draft of project controls Update the deployment and quick deployment win plans as needed Outputs Refined physical deployment plan Refined physical architecture Refined environmental and infrastructure requirements and systems management plan Proposed project controls Refined quick deployment win plan
6.1.3 Benefits
The benefit of this step is that the SDT revisits and refines the deployment plan, project details, deployment timeline, and supporting plans and documents based on any changes to the software contracts. It should be well understood what was purchased, why it was purchased, and how it will be deployed to meet the business goals and maximize the investment.
6.2 Step 5: Finalize the deployment plan

As the Enterprise Business Sponsor (EBS), you may have final approval authority of the deployment plan, timeline, and supporting documentation. Or, you may need to get final approval from the Chief Information Officer (CIO), Chief Executive Officer (CEO), Board of Directors, or another governing body within your company. This step in the deployment method is the time to present the finalized plans to this approval authority and promote the upcoming activities. You should highlight the work done in planning and preparation by the SDT and get buy-in from the project managers.
54

The owners include the Enterprise Business Sponsor and the IBM Software IT Architect. The participants include all members of the SDT, as well as key stakeholders and sponsors.

Table 6-2 Inputs, tasks, and outputs for SDM Step 5: Finalize the deployment plan Inputs Refined physical architecture Refined deployment plan, deployment timeline, and systems management plan Proposed project controls Refined quick deployment win plan Software deployment best practices Tasks Review and finalize the deployment plan Discuss any appropriate migration strategies Discuss any appropriate conceptual data model for legacy data Finalize the recommended physical architecture Finalize the systems management plan Gain agreement on project controls Update the quick deployment win plan, if needed Finalize project ownership Finalize software deployment milestones and metrics Outputs Final physical architecture Final deployment plan Final deployment timeline Final operational model Final systems management plan Final project controls Final quick deployment win plan Final goals and milestones Software deployment best practices understood and agreed upon
6.2.3 Benefits
The benefits of going through this step are: Executives are aware of the work done by the SDT to plan and prepare for a successful deployment. Final approvals are obtained on the plans and schedules. Goals and milestones are affirmed.
55
6.3 Step 6: Conduct the initial deployment kickoff meeting

Armed with the final plans, schedules, vision, and list of projects, it is time to conduct the initial deployment kickoff meeting. This is called the initial meeting because of the importance of repeating this type of kickoff meeting often. This meeting is attended by the stakeholders from your company and from IBM and should include team project leads, IT leads, and lines of business leaders. This meeting should create awareness, understanding, and enthusiasm for the deployment activities that are about to begin. The meeting should be led by you, the Enterprise Business Sponsor, as the leader within your company of the software deployment. Presentations may be made by the members of the Software Deployment Team, IBM client team or executive or other leaders that will be supporting the deployment effort. A high-level agenda should include: What software, hardware, and services were purchased Why the purchase was made The final deployment plan The final deployment timeline The overall vision and business goals should be explained to keep the discussions in line with the desired results. The SDT should present the roles and responsibilities described in Chapter 2, Roles and responsibilities on page 15, and the software deployment best practices described in Chapter 3, Software deployment best practices on page 23. Dozens of people may attend this kickoff meeting. Your goal is to inform the participants of what is to come and to create excitement and energy for the deployment. This type of meeting should be conducted with as many people as possible, perhaps at various locations. To maintain the enthusiasm, you should also conduct regular update meetings or events to celebrate your successes and highlight the activities to come. The concept of presenting to as many people as possible is important. Do not forget to invite and include the end users and final implementers in your meeting. They have as much to do with the success of the deployment as does a top-level executive.

The owners include the EBS, IBM Software Sales Representative (SSR), and the SDA or SWITA. The participants include key stakeholders and sponsors, end
56
users representing key projects, project managers, the extended team from your company and IBM, and all members of the SDT.

Table 6-3 Inputs, tasks, and outputs for SDM Step 6: Conduct initial deployment kickoff meeting Inputs Final contracts Architecture plans and descriptions Final high-level deployment plan and timeline Goals and milestones IT vision Software deployment best practices Roles and responsibilities Tasks Present the vision that drove the software purchase Link the products purchased to the business initiatives and vision Discuss the high points, terms and conditions, and critical aspects of any contracts Communicate the business value and benefit Show the business context and high-level architecture Present the high-level deployment plan and timeline Discuss the breadth of the deployment (local, regional, national, or global) Discuss the roles and responsibilities Discuss any known roadblocks and the plan to overcome Communicate the quick deployment win plan Discuss the software deployment best practices Present the key benefits of the major driver products Arrange for demonstrations of key products if necessary Outputs Synergy and enthusiasm for the upcoming deployment High-level understanding of the contracts Communicated vision and business value Understanding of roles and responsibilities and the software deployment best practices
57
6.3.3 Benefits
The benefits from this and similar meetings are: A reinforced partnership between you and IBM Communication of the vision and goals Awareness, understanding, and enthusiasm for the deployment An understanding of key responsibilities SDT credibility and accountability
58
Chapter 7.
Software deployment Phase 2: Deploy software

To deploy software is to put it into use. Even the best software can be of no benefit if it is not deployed. You can take this concept a step further and look at the business value you receive from putting the software into use. Up to this point, we discussed the planning and preparation for the software deployment, the importance of measuring the value that you will realize, and some of the preliminary steps necessary to market your vision and create an environment ready for success. Now comes the time to take what was planned and what is on paper and make it a reality through systematic execution of the plan and the deployment of the software. The purpose of this step is to execute the quick deployment win plans, ensure early deployment success, and execute the deployment plans and projects that follow the quick wins. Throughout this iterative process, you must also keep your eyes open for changes in the business needs and be prepared to adjust the plans as needed to ensure you can use your software investment to the fullest potential. You should also search for ways to apply the successes enjoyed from this deployment effort to future business plans. The following activities (see Figure 7-1) are discussed in this chapter: Step 7: Achieve quick deployment wins. Step 8: Execute the deployment plan.
59
Step 9: Identify new business needs. Step 10: Update the business plan.
Phase 0
Phase 1
Phase 2
Step 7: Achieve Quick-wins Step 8: Execute Deployment Plans
Step 10: Update Business Plan
Deploy
Figure 7-1 Phase 2: Deploy software
Customer example: GMR Corporation (GMR) executed quick wins, defined and executed other deployment plans, and identified new opportunities to repeat and build on the successes of the past year.
60
7.1 Step 7: Achieve the quick deployment wins

The purpose of this step is to demonstrate success early and build momentum and credibility in the beginning stage of deployment. This can be compared to the training wheels used to give a child confidence when learning to ride a bicycle. If you start with your largest and most difficult project, there are greater risks of delays and cost overruns, which can result in less-than-stellar deliverables. Get your feet wet with a few small projects. Test the processes you developed while you were planning the deployment. Make adjustments or alter timelines based on what you learn here. The Software Deployment Team (SDT) should carefully monitor the early projects to ensure you can being with the expected fast start. The team should stay focused on the early business goals to reduce scope creep and to provide the value realization expected.

The owners include the Enterprise Business Sponsor (EBS) and the IBM Software IT Architect (SWITA). The participants include the project managers, IBM Software technical representatives, IBM services representative, any IBM support representative or contact, and key stakeholders assigned to the selected quick deployment win projects.

Chapter 7. Software deployment Phase 2: Deploy software
61
Table 7-1 Inputs, tasks, and outputs for SDM Step 7: Achieve quick deployment wins Inputs List of projects and owners Project plans for quick deployment wins IBM readiness plan Software deployment best practices Tasks Assign project managers to quick deployment win projects (internal, IBM, or third party) Verify and augment the capabilities of the quick deployment teams assigned to the projects Execute the quick deployment win plan Manage the projects with project controls Conduct regular meetings with the project owners Monitor progress of quick deployment win projects against plans and make adjustments as needed. Implement recommendations defined during readiness discussions Address and resolve technical issues that may arise Maintain close contact with project owners, stakeholders, and sponsors Execute early phases of the education plan Monitor the satisfaction of the solution users Track software license usage Outputs Quick deployment win projects competed Initial business value realized Internal reference groups
7.1.3 Benefits
The benefits you should see as a result of this step are: Confidence in the deployment plan and SDT are built. Technologies are tested and understood. Credibility of the EBS, SDT, and IBM are reaffirmed. Technicians are trained. Internal reference groups are created that help support additional projects.
62
7.2 Step 8: Execute the deployment plan

Now that you have some successes, it is time to start the longer process of deployment as defined in your deployment plan. It is now time to tackle the bigger projects. During this time, project management and controls are critical. It is also important to maintain your awareness of the satisfaction of the user community and of the stakeholders and sponsors. This is an ideal time to repeat the deployment kickoff meetings held earlier and provide a status report on the quick successes and reset the expectations for the rest of the deployment. These meetings can now include live demonstrations of the early projects to reinforce the success and reiterate the vision. During this step, the SDT should maintain and manage to two lists: A list that identifies existing (underway) projects A list that identifies potential projects Refer to Chapter 8, Managing software deployment projects on page 67, for more information. The challenge for the SDT is to move projects from the potential list to the existing list at an acceptable rate that burns the software purchased and moves you closer to, or even beyond, the expected value.

The owners are the EBS and the SWITA. The participants include the EBS, the entire SDT, key stakeholders (for the duration of their assigned project), IBM representatives from services and support, the IBM Client Executive, and project teams developing and integrating the final solutions.

63
Table 7-2 Inputs, tasks, and outputs for SDM Step 8: Execute the deployment plan Inputs Final deployment and physical architectures Software deployment best practices IBM readiness plan Final environment and infrastructure requirements Final deployment plan Final systems management plan Final project controls Final goals and milestones Tasks Advertise quick deployment wins with meetings or open house events. Assign deployment project managers Educate additional users on IBM support processes Verify and augment capabilities of the deployment teams assigned to the projects Begin executing projects per the deployment plan Manage the projects with the project controls Monitor progress against the plan and make adjustments as needed Address and resolve technical issues that may arise Maintain close contact with the stakeholders and sponsors Monitor overall satisfaction Track software license usage Outputs Deployment milestone status reports License usage reports Value realization status reports Competed projects Deployment of software and the associated business value achieved
7.2.3 Benefit
The benefit of this step is the achievement of the defined business goals. This primary benefit is supported by the success of you, the Enterprise Business Sponsor, the rest of the SDT, and the successful partnership with IBM.
7.3 Step 9: Identify new business needs

Often there is some growth forecast over the term of a multi-year software agreement that may not be identified to a project at the time the purchase is made. If the identification of projects that use this software is vital to your value realization, then it is the responsibility of the SDT to assist you as the EBS in discovering or creating those projects. Also realize that as new projects are discovered, there may be a need to purchase additional software to augment that
64
which you already own. This software that needs project identification is referred to as the software gap.

The owners include the EBS, the Software Sales Representative (SSR), and the SWITA. The participants include the project managers or stakeholders that drive the requirements to improve your business.

Table 7-3 Inputs, tasks, and outputs for SDM Step 9: Identify new business needs Inputs Deployment plan Goals and milestones Gap analysis New business requirements Tasks Revise the deployment plan to include the new requirements. Seek out new demand. Manage these new projects as done in Step 8. Outputs Software gap is reduced or eliminated New projects are identified Value realized is increased
7.3.3 Benefits
The benefits of this step include: Higher usage of purchased software Increased value received from the original software purchase Increased visibility of the business benefits provided Satisfied stakeholders and end users who received new technology and improved processes
7.4 Step 10: Update the business plan

The final step in the Software Deployment Method is to take the success from the deployment, along with any challenges, and apply them to your future business plans. This also means returning to the first few steps in Chapter 5, Software deployment Phase 0: Prepare for deployment on page 41, and repeating the cycle for successful deployments.
65

The owners include the EBS, the SSR, and the SWITA. The participants include the extended IBM Software Technical team.

Table 7-4 Inputs, tasks, and outputs for Step 10 of SDM Inputs Projects identified in Step 9 that were not rolled into the current deployment plan Goals and milestones Software gap analysis New business requirements Tasks Incorporate any lessons learned from the recent deployment into future plans. Determine the technical needs of the identified projects. Apply current software inventory and new software purchases toward the future deployment plans. Return to Phase 0, Step 1. Outputs Refreshed strategy to meet the new business needs
7.4.3 Benefits
When the Software Deployment Method is incorporated into your standard processes, the end result is a successful deployment. This takes focus on the overall success and progress against the deployment plan. Other organizations will notice your success and request the implementation of additional business requirements. If you have a thorough method for deployment, then you can meet that need. You will also see an improved partnership with IBM by following the steps detailed in the previous chapters. You gain the benefit of many professionals working toward your success, and IBM has the satisfaction of knowing we assisted you in meeting your goals.
66
Chapter 8.
Managing software deployment projects

This chapter provides helpful hints on managing software deployment projects. Unlike other types of projects, software deployment has it own set of challenges and opportunities. This chapter is not a substitute for a formal project plan completed by a certified project management professional. We recommend that if the funding is available, you should hire a professional project manager. Again, we emphasize the importance of an Enterprise Business Sponsor (EBS). The EBS plays a key role in overall success at all levels of deployment activity. As described in Chapter 4, Value realization on page 33, the value statement and the value timeline need to be defined as close to the closure of your software agreement as possible. Neither of these documents is fixed. Instead, they are expected to adjust as deployment projects are executed, new projects are defined, and new software is purchased. A key point is that you must view the deployment holistically. To maximize success, you must allocate all software licenses to projects as early in the deployment life cycle as possible. The preferred time for this effort is in final stages of the negotiation. This is because all informed parties are at the table at this time. Too often one or two projects are defined and the momentum is lost. It is imperative that a concerted effort be taken to find homes for all licenses in your agreement.
67
At the beginning of this redbook, we defined deployment as putting software into use or action. Loading software onto a desktop or a server and never using it adds no value. When you plan and position deployment projects, ensure that the recipient organizations understand why this implementation is taking place and how best they can leverage these changes. This chapter provides information that will help you manage a successful deployment project that maximizes the value you receive from your software purchase. You see again the involvement of the Software Deployment Team (SDT). Refer to Chapter 2, Roles and responsibilities on page 15, where we introduce the IBM team with whom you will be working. We also define key representatives from your team. You may not recognize or use the titles that we selected, but hopefully you will recognize the responsibilities. Customer example: GMR Corporation (GMR) was particularly interested in developing a successful deployment game plan. To this end, they worked closely with their IBM Information Technology (IT) Architects to blend the Software Deployment Method (SDM) with their internal project planning process.
68
8.1 Project timing

From the SDTs perspective, a project is any effort that requires the installation and use of software licenses. Projects can use licenses at the beginning, middle, or end of a predefined deployment life cycle. It is not necessary that every license be in deployment motion immediately or simultaneously. A project may be as straightforward as installing a collaboration application on computers with a dozen users. It can also be as simple as delivering an upgraded version of an application to all of its current users. Or a project can be as complex as installing custom-written software at locations around the world, where thousands of licenses are required or installed as part of the process. Some projects last a week, while others can last a year. Clearly, project management rigor that is applied varies with the projects priority, complexity, and duration.
8.2 Getting started

When the software purchase is consummated, there is typically a vision for how the software should be used. There is a high-level algorithm developed for executing the vision. The algorithm factors in: The number of servers and workstations involved The number of gigabytes (GBs) of storage that are required to store the purchased software The SDTs hard work begins when the vision must be mapped into deployment activities (projects). There is no formula or standard when it comes to determining how many projects are required. Typically, on the first day of deployment, the SDT has a list of potential and funded projects, project owners, and what software each project will use. This list likely does not contain enough projects to deploy all the software purchased, but it starts things moving. Hopefully, it creates some successes that generate enthusiasm and demand for the remaining products that are in the portfolio. See 7.1, Step 7: Achieve the quick deployment wins on page 61. As an example of getting started, a purchase agreement for $10 million U.S. may specify $2.5 million in software to be used from four of the five IBM Software Group brands. The SDT works with each brand's sales person and technical sales person to determine an inventory for their $2.5 million. Then the SDT aligns the software with the anticipated projects, identifies an owner for each project, determines the start and end dates for each project, and sets a timeline for
Chapter 8. Managing software deployment projects
69
deployment. The IBM Software IT Architect assigned to the account is responsible for ensuring that all of the software in the agreement (across brands) integrates smoothly, but in some cases, the projects may not need to integrate at all. For example, there may be a totally independent Tivoli project that may not touch a data management project. However, many times projects need to integrate. Here is how an experienced IBM Software Deployment Architect (SDA) describes how he begins: Very quickly after a new software purchase occurs, I need to think about projects that can burn software licenses. I begin my conceptualization by going back to read and thoroughly understanding the contract. I then meet with the Software Sales Representative (SSR) and whoever else was involved with the purchase and understand where and how the customer envisioned using the licenses. It is important to write down the project list on paper. Memories are short, and by documenting this, we and the customer stay on the same page. After the project list is documented, I apply good project management principles. For example, I create a work breakdown structure for each project. I make sure we have a project lead allocated to individual projects. I may have to request management to identify when the people would be allocated. It is crucial to allocate one IBM focal point for each project as it becomes active. There should be one IBM counterpoint to each customer focal point per project.
8.3 Managing the success of your first project

There is a saying, You only get one chance to make a good first impression. This certainly applies to deployment. The SDT should work with the EBS to select the first project carefully and manage it so that it deploys on time. This builds confidence and momentum early in the deployment cycle. It also gives the EBS a great deal of credibility with peers and line-of-business stakeholders. Early in the deployment, your executives should exclaim, Look at this! Its terrific that were seeing value already! This success should be advertised and celebrated with all present and future stakeholders. Every account is different, but you have to do all you can to help ensure the first project is successful. If the SDT believes they cannot control the projects, including which ones should be deployed first or who should be assigned to lead them, it may be a sign that they are not working with the true EBS. The SDTs challenge is to partner with the real owners, those who care most about the success of the projects, and work with them to make things happen.
70
8.3.1 Managing at the milestone level

The most valuable advice that experienced Software Deployment Teams want to share with others is to manage at the milestone level. Let the individual project leaders manage the details of their projects (via detailed Gant charts produced by Microsoft Project or other project management tools). There may be dozens of projects underway. The SDT cannot let itself get bogged down into the details of managing each project. The SDT may advise project managers as they create their project plans, help ensure that projects have clear charters, or review completed plans, because an extra set of experienced eyes on these items can be quite helpful. The SDT can: See that each project starts well Check with the teams at critical points to help ensure things are on schedule Help ensure that action items required to keep projects moving are acted upon It is wise for the SDT to prioritize projects, too. They should spend more of their time on the hottest projects. Even then, they should manage them at the milestone level. As one SDT member said, We need to know what needs to be done to plan a project, but we dont need to be the ones doing it. Were not the executors.
8.3.2 Handling project management challenges

Over a multi-year deployment period, even the best SDTs encounter some challenges. Situations that SDTs should be prepared to handle are: The products purchased are now not matching the current requirements Scope creep Inexperienced project managers
Products purchased are not matching current requirements

As software deploys, you may discover that you have a shortage of licenses in one area or that you have much more than you need in another area. While this can be challenging, we recommend that you speak with your vendor sales representative and see if an arrangement can be made to adjust software quantities.
Scope creep
Scope creep refers to projects that gradually extend beyond their original charters and add functions that require software that was not in the original agreement. Scope creep can be harmful, because it can take a project off on a
Chapter 8. Managing software deployment projects
71
tangent and cause schedules to be missed. It is imperative that the EBS stay focused on the major deployment goals.
The inexperienced project leader

The EBS needs to help ensure that they have project leads with excellent project management skills. Project management certification is available and can be suggested in certain situations. Also, the work product examples in the Appendix A, Software solution work products on page 93, may be helpful to project leaders.
72
Chapter 9.
Managing global software deployment projects

If you are reading this chapter, chances are you have an interest in deploying software at several locations around the world. The lessons and experiences provided in this chapter help you effectively plan and manage a deployment that spans two departments in one building, two buildings in one city, two cities in one country (region), or two countries (regions) in one world. The word global is used liberally to describe the landscape of a business. In its simplest form, global implies that you are doing business in more than one location. This is an unfortunate minimization of a challenge that in itself can absorb the time of several full-time project managers and executives. Doing business globally implies geographical, cultural, and language barriers that must be overcome before business can be effectively executed. Deploying software is no different. Proper planning must be done if the breadth of software utilization is to be maximized. IBM was one of the first companies in the United States to tap into the worldwide market. Its presence in the major and minor geographies of the world has become an increasing source of business growth. As such, global software deployment happens frequently. Global deployments pose challenges above and beyond those faced in deploying software within a single location. As discussed in Chapter 3, Software deployment best practices on page 23, self-sufficiency
73
is key to the deployment success. This means that ownership must be established for the success of the software purchased by your business. IBM is one of few companies that actually has the capability to service global customers effectively. That being said, doing business in over 100 countries or regions with unique cultural, political, and business guidelines is complicated and fraught with potential pitfalls. It is because of these pitfalls that this chapter is included in this redbook. We are motivated to maximize global customer success. First, we recommend that you establish a global lead to be the project manager and coordinator of all software deployment activities going on around the world. This person should meet the following criteria: Have excellent project management skills as well as experience on the global stage working with a variety of people from differing cultural backgrounds. Have experience managing complicated projects. This implies that they can handle complicated products, and combinations of products, as well as complicated geographical challenges. Be a self starter, who is constantly looking for opportunities to increase the deployment footprint. We recommend that you have a team of project managers with a primary, secondary, and tertiary responsibility for software deployment success.
Primary sites = full-time coverage: A deployment site where the majority of deployment occurs. Full-time, dedicated, and focused deployment personnel who are hands on and proactive should be assigned. They are normally located in the city where most of the strategic global decisions are made. Their responsibilities span the entire scope of deployment from demand generation to deployment success. Their goal needs to be to maximize deployment in the given city. You may have several primary deployment sites depending on the configuration of your business. For instance, a major financial institution may have headquarters in New York City for the U.S., China (Hong Kong S.A.R.) for Asia, and Paris, France for Europe. It is likely that this company would have major deployment activities in all three cities. We recommend that each of these cities has a dedicated project manager focused on deployment. Secondary sites = part-time coverage: A deployment site where significant
deployment activity occurs, but not as significant as the primary site or sites. A part-time project manager should be assigned in these locations. They are proactive or reactive in this deployment as the situation requires. This means that they are monitoring and tracking existing projects, reacting to crisis situations, and keeping their eyes open for opportunities to deploy more software.
74
Tertiary sites = on-demand coverage: A deployment site where minor or less

complicated deployment projects occur. This situation receives tertiary attention from a project manager. This project manager is only engaged when they are asked. They are not normally probing for new software demand. Your IBM team will align their coverage in each city around the world based on your requirements. Under normal circumstances, support is maintained at a level that is commensurate with the deployment activities that occur in any given city. This IBM team generally consists of representatives from all parts of IBM, such as a Global Client Executive, a Global Software Sales Representative, and perhaps a Global Software Deployment Architect.
Chapter 9. Managing global software deployment projects
75
9.1 How the coverage model works

The size of a software agreement does not necessarily trigger the application of this type of global coverage model. When the high-level deployment plan is drafted, the cities in which software deployment will occur should be recorded. You and your IBM team should meet to assess the kind of coverage that will be required. If you decide to assign a global project manager, identify this person as quickly as possible. This global lead needs to identify the countries or regions (see Table 9-1) and cities where deployment will occur, how much, and when. Ideally, you will assign project leaders within each location that has significant deployment activity.
Table 9-1 Sample global software deployment coverage model Location Americas (New York) Americas (Other NA) Latin America EMEA Tokyo Singpore/India China (Hong Kong S.A.R.) Korea Australia Erris Pow Secondary Sanghoon Hark Tertiary Susan Potville Tertiary Choong Pong Tertiary Ricardo Ferano Secondary John Parker Primary lead city Company ABC John Williams Tertiary Dawn Dish Tertiary Ricardo Ferano Secondary Ted Fonderland Primary lead city Company XYZ
9.2 Global deployment checklist

Experience has shown that a Global Project Lead (GPL) will have a difficult time focusing on multiple deployment sites all over the world. This is because certain
76
sites will demand greater levels of attention at the expense of lesser sites that are perhaps not as problematic. A good example of this is a primary site where the majority of the software is being deployed. This site by nature absorbs much more of the project leaders attention. To combat this issue, a list of key global activities is provided in the following section. Revisit this list periodically to ensure that all important work items are being done.
9.2.1 Global level activities (primary, full-time coverage)

The following activities take place at a primary, full-time coverage site: Your decision making team determines, prior to the software purchase, that software will be deployed in multiple cities, countries (regions), or both around the world. Your executive team assigns a GPL to focus on software deployment at all sites. The GPL meets with the Software Deployment Team (SDT) and obtains a full understanding of the buying decision. Primary, secondary, and tertiary deployment sites are identified. The GPL works with the SDT to draft a high-level plan for software deployment with high-level milestones. All known deployments sites are placed in the timeline. This high-level plan must be dynamic. It is adjusted as deployment sites are discovered and milestones are achieved. The GPL obtains guidance on business goals and how return on investment (ROI) will be measured. See Chapter 4, Value realization on page 33. The GPL begins aligning site leaders in each deployment location. This alignment should be done in sequence with the deployment plan. The GPL identifies a team within the vendor who will assist them at the worldwide level. A Document of Understanding (DOU) should be written between the customer and the vendor. The vendor should commit to assigning or aligning resources with all deployment sites around the world. The vendor should provide names and full contact information. The GPL determines how software will be customized and implemented to match requirements. For example, they may decide to build a gold disk that can be used to ensure that all software deployment is identical on every desktop and server around the world. The GPL needs to monitor software deployment activity around the world to ensure that all activity falls within standard guidelines set at a global level.
77
The GPL meets periodically with all site leaders to review deployment progress and milestones. This meeting should include all sites that may not yet have begun deployment of software. The GPL schedules periodic meeting with your decision making team and the site leaders to checkpoint deployment progress and raise any critical issues. The meetings are used to review deployment milestones and value realization milestones. The GPL remains aware of all new software purchases around the world. When these purchases are finalized, all software should be immediately moved into software inventory. The GPL circulates a status report monthly to your decision makers, business sponsors, and the entire SDT around the world.
9.2.2 Local sites (secondary, part-time coverage)

The following activities take place at a secondary, part-time coverage site: Site leaders meet with local vendor teams frequently to discuss deployment plans and challenges. Site leaders report status to the GPL on a predefined frequency. They report deployment status, accomplishments, challenges, and escalation points. Site leaders drive deployment activities in their locations.
9.2.3 Local sites (tertiary, on-demand coverage)

The following activities take place at a tertiary, on-demand coverage site: Tertiary coverage is available in reactive situations only. Each deployment site that is not primary or secondary should at least have a named resource aligned with it to monitor and escalate challenges that may impact the deployment progress. Your vendor should also provide tertiary coverage at each one of these sites. This coverage should be aligned with the products, solutions, or both that are being deployed at each site. The right expertise should be available to help resolve issues quickly.
9.3 More about the global deployment activities

This section offers further details about the items in the global deployment activities list.
78
9.3.1 Identify the Enterprise Business Sponsor

One of the deployment best practices (see Chapter 3, Software deployment best practices on page 23) is that you should have a global sponsor who is focused on the global deployment success. This does not have to be one person. It can even be a team of three to four people with one person assigned to each geography. It is important that you align resources with each important deployment location.
9.3.2 Obtain a list of software deployment locations

The EBS should provide a list of global deployment locations and work with the GPL to identify the primary, secondary, and tertiary deployment sites, based on the coverage model. One project leader should be assigned per geography. This person should work in that geography with the deployment professional who is assigned.
9.3.3 Arrange full-time and part-time coverage

Per the description of the coverage model, resources should be assigned full-time and part-time to satisfy the deployment demands.
9.3.4 Arrange on demand (tertiary) coverage

Typically, the on-demand contact is from the technical team in the city, country, or region. If a technical contact is not available, assign the manager of the technical team. When the need arises, the manager assigns the appropriate technical person from their team. For these types of deployment efforts, you usually work with one product, such as systems management or application server, that is quite specific to your needs. In this case, the appropriate on-demand person may be a WebSphere or Tivoli specialist from IBM.
9.3.5 Conduct bi-weekly meetings with global deployment teams

Every other week, most GPLs hold two or more status conference calls: one call with the team in the primary geography and one call each with teams in the other geographies. The GPL roles up all the summary information into a status report. A level of coaching should occur in these calls. GPLs should push secondary and tertiary contacts to drive deployment. They cant be passive. They must be proactive.
79
9.3.6 Checkpoint deployment satisfaction

The GPL should meet with teams in each geography. While there is a team in the primary site, there are also teams in the local sites. Part of the GPLs role should be to travel every three to six months to meet each local deployment team and help ensure they are on top of what is happening.
9.3.7 Provide regular progress reports

The GPL should send frequent progress reports to the primary, secondary, and tertiary people, so they are informed about the progress in all of the geographies. The GPL needs to communicate the data and the stories behind the data. For example, communicate what the data is telling, or why the person in Paris should care about what is happening in China (Hong Kong S.A.R.). By interpreting the data and guiding decisions, the GPL builds credibility by demonstrating a combination of technical, project management, team building, and business skills.
9.4 A global deployment coverage example

Nestl is an example of a customer who understands how to deploy software globally. In 2001, Nestl initiated their GLOBE project, one of the largest and most ambitious restructuring projects ever launched in the industry. GLOBE standardizes Nestl on best practices for manufacturing, sales, marketing, and all relevant business worldwide. It creates common data formats and a common infrastructure for managing Information Technology (IT). The Nestl Globe Competence Center (GCC) defines Service Management with Tivoli under the leadership of Francisco Esteve. The GCC then distributes structures to the Globe Centers of the four primary zones around the world (Europe, Americas, Asia Oceania Africa, and the headquarters in Vevey, Switzerland) where local management can use it. This is one example of how Nestl has embraced global software deployment. Figure 9-1 shows the assignment coverage for the deployment that follows the model described in this chapter.
80
GCC (primary)
Vevey, Switzerland
GC EUR (secondary) Frankfurt, Germany
GC AMS (secondary) Phoenix, Arizona
GC AOA (secondary) Sydney, Australia
GC HQ, CSC (secondary) Bussigny, Switzerland Markets (tertiary) any country
Figure 9-1 Global deployment coverage for Nestl Corporation
81
82
10
Chapter 10.
Software deployment resources: Support, education, tools

Chapter 3, Software deployment best practices on page 23, introduces the software deployment best practices. This chapter presents the many tools available to help systemically execute against these best practices. We recommend that you take advantage of every tool, technique, process, and procedure available that will accelerate software deployment. The tools in this chapter fall into five primary categories: License management tools Communication tools Self-help tools (support, software entitlement) Education Deployment Services Most organizations have a customized set of that tools they leverage to manage projects and monitor deployment performance. It is not our goal to have only IBM products in place to fulfill your tool requirements. It is more important that you recognize any weaknesses in your tool strategy and take immediate action to address them. To learn more about any of the tools described in this chapter,
83
contact your IBM Software Sales Representative (SSR) or see the following Web site: http://www.ibm.com
84
10.1 License management

An example of a tool for managing the deployment of software licenses is IBM Tivoli License Manager (ITLM). This section presents portions of the white paper IBM Tivoli License Manager Intelligent software license management to help optimize business value that describes this tool. You can find this paper on the Web at: ftp://ftp.software.ibm.com/software/tivoli/whitepapers/ wp-license-mgr.pdf In todays business, no company can make money without taking care of Information Technology (IT) resources. IT is more than just a link in a production chain. For many companies, it is the key factor that improves the overall revenue, and even the smallest organization needs to set up an IT infrastructure to create a business. The larger your company is, the more complex the IT infrastructure must be to support the business. This infrastructure requires time and money to be managed, maintained, and extended. In a large organization scenario, a software solution that helps you track assets from a financial, contractual, and physical point of view is a critical business need. By having an integrated view of the hardware and software assets you own, you can plan for hardware and software maintenance and upgrade, and understand exactly what resources are needed to support your business. Typically, software assets are the key factor missing from asset management. The main portion of the investment required to set up an IT infrastructure is usually related to software, not to hardware. Taking care of the software products that are installed and run on a large infrastructure, including thousands of servers and desktops, is not a trivial task. However, there are several benefits in using an enterprise solution to accomplish this task. Some of them are: Legally enforce license agreements of procured products. Obtain information about the software that is actually needed. Strive for full utilization of procured products, paying support only on what is used. Gather data for total cost of ownership analysis. Collecting information about the software products that are installed and used within your IT infrastructure is the only way to achieve the benefits that were previously described. To do this, the use of a system explicitly designed for asset and license management and well-defined processes around that system are required.
Chapter 10. Software deployment resources: Support, education, tools
85
10.1.1 Taking control of software licenses

Software monitoring is the main issue in software asset management. As described in the previous section, it is the only way to tell exactly what products are really needed, especially for large environments. However, there is more than just software inventory in a complete solution for asset and license management. The real needs for asset management go far beyond a simple tool for software tracking. You likely need to know whether any of your departments are overbuying licenses because there is no way to tell if they are really needed, or whether it is exposing your company to the risk of non-compliant usage of software products. Taking control of your software licenses is just as important as tracking the life cycle of hardware assets. A solution that tells you if you are overspending or taking the risk of high penalties gives you an instrument to achieve these goals: Reduce overall cost of software license management and compliance monitoring. Produce the licensing data necessary to plan for license upgrades and migrations. Analyze the licensing data to determine if other options are more attractive. To attain these goals, license management comes into play. Your software procurement information must be properly reconciled with the software usage and inventory data. Only by doing this it is possible to tell whether you are paying more license fees than necessary, or whether you should buy new licenses as soon as possible to remove any compliance exposure.
10.1.2 IBM Tivoli License Manager

In the license management space is ITLM. ITLM can collect and maintain information about procured, used, and installed products. It then stores the information for analysis and reporting in a centralized and historical database. The administration server is responsible for maintaining the database and the access policies for allowing a system administrator to work with ITLM and browse the available software reports. The license procurement information is defined using the Web interface to the administration server. Using only a Web browser, the administrator defines the license procurement information that is needed to monitor the usage of a software product and enforce a license agreement when requested.
86
The information about available licenses, which can be defined on a product-by-product basis, is distributed automatically to the runtime servers. This provides support for the process of granting licenses to the requesting agents, which happens on the servers in real-time fashion. In this scenario, each agent is responsible for detecting each new application, validating the available information to identify the starting product, and requesting an existing license from a run-time server, so that the product usage can be authorized. Thus, license control can be done in real time, and the data collected on the runtime servers is used both for real-time reporting and periodic reconciliation with the administration server. You can use several settings to configure the behavior of the system in a more detailed manner. For instance, if you are not interested in applying license enforcement to the usage of licensed products, you may turn off the function that requires a license to be granted to the agent before a product can start.
10.2 Communication tools

Communication is another software deployment best practice. IBM leverages several tools to make communication easier and more efficient. They range from tools as common as e-mail to as specialized and configurable as portals. An important first step is that you move away from the perspective that communication is something used only to report problems and submit orders. The power of communication is felt most when it is easy, convenient, and difficult to avoid. A good example is the fuel gauge in a car. It is certainly critical that you know when your car is running low on gas, but it is also convenient to know when the tank is more than half full so you know you have nothing to worry about.
10.2.1 Instant messaging, Web conferencing, and team workplaces

Communication with your software vendor, your partners, or simply within your company is easier if you have the proper collaboration tools. Having real time and easy collaboration with tools, such as instant messaging and Web conferencing, creates better coordinated, better informed, and more agile organizations. Having the ability to create a team workplace is an excellent way to keep an entire Software Deployment Team (SDT) on the same page regarding requirement documents, project plans, deployment status, and challenges.
87
For more information about IBM tools in this area, see: http://www-3.ibm.com/software/collaboration/
10.2.2 Easy Access Portals

Easy Access Portals were created to give you a place to post helpful information about your software agreement with IBM. Such information as what products were purchased, what these products are designed to do, how deployment is progressing, and how to get product updates are all examples of what Easy Access Portal can provide. As part of your software relationship with IBM, your company may have access to a private, customized Easy Access portal. We organized your private Web portal to make it even easier to find what you are looking for. My Software Center, accessible via your companys private portal, is a central source for information about software product, support, and services. Whether you are interested in the latest software products and solutions for your industry, local events, or support, you can find it here. Working with your IBM team, you can customize My Software Center to help you understand the software products and services that you are entitled to use under your software agreement with IBM. It provides the ability to request media, submit questions to your IBM team, and to find information about the products included in your software agreement. To determine whether your company has an Easy Access Portal, contact your dedicated IBM representative. Easy Access Portals offer the following benefits: Improve ease of use by providing secure, private one-stop environment for evaluating products and services. Provide a seamless and private interface. Help you navigate IBM relevant sites, contacts, and collaboration centers. Provide 24x7 access to product, service, and support information, and can include continuous access to a range of news and product information. Contain multiple interactive help options online, or you may receive offline assistance from support, telesales and telecoverage contacts. Reduce the cost of doing business with IBM by using Shop Smart, Configure to Order, Order Direct, Track online and Get Help Fast features. Provide a suite of valuable applications to support your software, Learning Services and maintenance contracts, order status, and software delivery with eQuickship.
88
Are business-to-business (B2B) direct by integrating online ordering to procurement system.
10.3 Self-help
Self-sufficiency is another software deployment best practice from IBM. IBM has focused a great deal of energy on providing you the tools needed to be self-sufficient. Most of this work has been done in the problem management and in the software fulfillment space.
10.3.1 Problem management

IBM provides an extensive set of self-help tools around problem reporting, management, and tracking. Visit this site to begin: http://www.ibm.com/support
10.3.2 License acquisition and entitlement with Passport Advantage

IBM offers two license acquisition and maintenance programs: Passport Advantage and Passport Advantage Express. Passport Advantage is designed for larger enterprises. Passport Advantage Express is designed to meet the needs of small or medium-sized businesses. Passport Advantage is the IBM comprehensive software licensing and software maintenance program. It is a global program that is designed to save you money at every stage of your software acquisition and use. Passport Advantage is the most flexible and cost-effective way for you to reap the benefits of new releases of the latest technology and technical support to keep your business up and running, plus obtain volume pricing for significant software purchases. It can help lower your acquisition and administrative costs, facilitate migration to new platforms, boost productivity, and increase profits. For more information, see: http://www.lotus.com/services/passport.nsf/WebDocs/ Passport_Advantage_Home
10.3.3 Software maintenance via Passport Advantage

Passport Advantage includes a maintenance feature that complements your IBM Software purchases. It includes both product upgrades and technical support. It also fosters successful software deployments. With product upgrades, you get
89
complete upgrade and cross-platform migration coverage for most commercially available IBM distributed software Data Management, Lotus, Rational, Tivoli, and WebSphere Software. You can upgrade to new releases and new versions as the needs of your business dictate. Technical Support helps keep your users up and running wherever they are working in the world. This is our way of making sure you are covered with the technical support you need. This is your way of getting an increased return on your IBM investment of a total software solution.
Benefits
The benefits of obtaining maintenance via Passport Advantage are: Includes a full 12 months of software maintenance with each license Provides comprehensive and flexible upgrade coverage Protects technology investments Simplifies and improves software asset management Reduces acquisition and administration costs Streamlines budgeting for software upgrade and migration costs Provides immediate support coverage on newly acquired products during installation phase and for life cycle of product Incorporates flexible, easy-to-access, responsive, cross-platform support from IBM, worldwide Provides access to IBM Software technical support for all of your designated IT staff Simplifies acquisition and renewal of cross-platform support Enhances overall expected response time of two hours or less during normal business hours Provides 24x7 access to support resources for business-critical outages Increases self help via the Internet For more information, see: http://www.ibm.com/support
10.4 Premium support

All customers who pay for support and maintenance receive access to all Web-based and telephone support 24 hours a day 7 days a week. Please refer to your contract for specifics associated with the standard support offering from IBM. IBM Software Group also offers a level of support that goes beyond what
90
most vendors offer. IBM calls the offering Premium Support. Generally speaking, Premium Support provides you with an on-call support representative to assist with your specific support needs. It is recommended that you speak with your Software Sales Representative or Technical Sale Representative if you are interested in this kind of support.
10.5 Education
To be self-sufficient, a team must be developed that has the right blend of skills and experience to act independently of IBM support and services teams. This education can be obtained via knowledge transfer from deployment services or it can be a obtained via formal education made available by IBM. To learn more about education available to you, see: http://www-3.ibm.com/services/learning/training_cat.html
10.6 Deployment services

Car races are won by less than a tenth of a second. What makes or breaks the victory happens in the pit, where expert crew members swarm the car to change four tires, refuel and adjust the car in less than 20 seconds. These pit crew members are highly skilled in using the tools to perform this feat. IBM has its own e-business version of the pit crewthe IBM Services teams. Our teams offer skilled experts for Lotus, DB2, Tivoli, and WebSphere software. Worldwide, our technical consultants turn opportunities into wins, challenges into solutions, and skeptics into loyal customers. Just as the pit crew readies the car and driver for the win, the IBM services teams have the expertise to make you a winner with IBM Software. The IBM services teams are available to help design and develop application solutions that run on IBM middleware and provide services to support the proper installation, configuration and operation of the products. The teams have strong relationships with the IBM Business Partner community and IBM Global Services to provide a broad range of services to suit your needs. IBM services teams can support and mentor your implementation teams. Or they can help you improve the skills of your development staff through training and hands-on experience. All of our services are structured to ensure your success.
91
92
Appendix A.
Software solution work products

One of the mantras at IBM is dont reinvent the wheel. In the spirit of reuse, we present the information in this appendix. We mention many times throughout this redbook that planning and design are key attributes to any successful software deployment endeavor. The work products contained in this appendix have been used by IBM project managers and architects to drive successful deployment projects all over the world. If you have any questions about how to use these work products, contact you software sales representative, your software architect, or your software services representative.
93
Work products used by SDM

The following information describes each of the work products used by the Software Deployment Method (SDM).
Architecture decisions document (ADD)

This document lists critical architecture decisions or choices made in the design phase. It describes the rationale for making them.
Architecture overview diagram

An architecture overview diagram illustrates the basic ideas of the proposed architecture. It is the equivalent of the architects sketch. Depending on the context, the diagram may range from basic to detailed. Related work products are the system context diagram, component model, and operations model, where additional detail is conveyed. Typically, the architecture overview diagram evolves with greater level of detail as the architecture is better understood. The diagram serves as a means to confirm architectural understanding between you and IBM.
Business context diagram and description

Business context diagrams are used to document the identity of the business area being served by the development effort and its interactions with other business entities in its environment. These entities and interactions are the sources and channels for flows of information into and out of the business. This understanding is key to developing a system that is properly situated in your business. In addition, business context diagrams: Provide the source of business events that occur across the business boundary. Act as a framework for determining the set of business processes. Articulate the scope of the business area being served by the new information system. Various business context diagrams can be examined and discussed with you as a way to clarify which business interactions are in scope and which are out of scope of the system being developed.
Component model
The component model documents the following information for each component:
Responsibilities: Describes responsibilities from the view of a user of a component. The description is later refined into specific operations that constitute the application programming interface (API) for the component.
94
Required service levels: Describes the service level for the component in
regard to users and presentation, performance or capacity and availability design rationale, reasonableness and risk, and implementation approach.
Information Technology environment

This work product documents the customers existing logical and physical design, databases design, and Web environments (servers, firewalls, for example). It also documents your security requirements, operational parameters (24x7, for example), end-to-end performance requirements, and existing standards (naming and protocols, for example).
Customers organization
This work product description is simply an inventory (or chart) of organizational elements (structures, behaviors and enablers) for in-scope organizational units (for example, corporate organization, strategic business unit (SBU), functions, teams, and individuals). The influencers and owners may be key to defining who to call for a given solution. An organization chart may be color-coded, for example, to indicate who is directly involved in the decision process.
Envisioned goals and issues

Envisioned goals and issues include project ideas that emerged early in the sales process. The envisioned goals and issues work product is documentation about your:
Mission statements (sometimes called value statements, credos, or

principles) are the operational, ethical, and financial guidelines of your company (or functional areas). They articulate the goals, dreams, behavior, culture, and strategies of your company.
Vision statements are the long-term objectives of your company. They articulate your companys target marketplace, products and services. They also state the position that your company wants their products and services to have in the targeted marketplace, as well as the financial position (revenue, profit, etc.). Business goals are the short objectives of your company that have to be
achieved to enable the fulfillment of the vision. The focus of the Software Deployment Teams (SDT) should be on the business goals that relate to the projects that are part of your software purchase, for example, a specific functional area.
Critical success factors (CSFs) are the few, high-priority areas where
satisfactory results help to ensure the achievement of the business goals. The business issues can be used to identify the CSFs.
Appendix A. Software solution work products
95
IT standards
This work product documents all known Information Technology (IT) standards that the architecture must accommodate.
Non-functional requirements
This work product details all of the key features and characteristics that are required in the new system. It defines the constraints imposed upon it by other factors. These requirements form a basis for preliminary system sizing and for the first estimates of cost. The requirements, along with the component model, are used to produce the operational model. These requirements are often the most important single determining factor in the entire design.
Operational model
This work product specifies the hardware that the desired architecture requires.
Project descriptions
A project description document is written to communicate the project goals to all who need to know. It is critical for the entire team to understand the projects goals. Writing a project description helps to verify that everyone connected with the project agrees on its objectives. A statement of project goals gives the development team a context within which to work. It provides a concrete starting point for development. Project goals can raise issues of scope and function, which are best identified as early as possible. The project description work product is a brief answer to the question: What are we doing on this project and why? The content depends on the nature of the project. For example, on an application development project, the project goals describe the business requirements of the application to be developed. These are not functional requirements, but rather short descriptions of the business problems that the application should solve. For a business transformation project, the project goals are more general statements of objectives and business imperatives.
System context diagram

The system context diagram helps clarify the environment on which the solution will operate. This diagram documents all connections between the proposed system and external systems and components. Various attributes are associated with each connection. These attributes may include data description, protocol, formats, frequency, volume, and model of interaction (synchronous, asynchronous). This context constrains the proposed system in regard to the
96
interfaces that must be implemented. The system context diagram may provide a rationale for a make or break decision on whether to go forward.
Use cases
This work product specifies requirements in the areas of performance, capacity or volumes, scalability, availability, portability, maintainability, and usability. It also specifies requirements in systems management, security, infrastructure constraints, technology standards constraints, and geographic or configuration constraints.
Viability assessment
This work product describes architectural risks, prioritizes (high, medium, and low) the probability and impact of each, and identifies contingency plans for each risk item.
Value Realization Model (VRM)

The purpose of this work product is to ensure that you have a plan to measure deployment success. It includes work products and reports that will baseline and monitor performance during the entire deployment life cycle. The Value Realization Model is developed and updated continuously. It contains the following subwork products:
Goals and milestones: It is vital to work with the Enterprise Business Sponsor (EBS) at the beginning of the process to agree on and document the goals and milestones. This includes the overall vision, specific goals to be achieved with the IBM solutions purchased, important milestones to be used as checkpoints in the deployment, and the metrics used to measure success. This should also include a strategy to measure return on investment (ROI) and rate of return (ROR). For more information about ROI and ROR, see Chapter 4, Value realization on page 33. Finally, you develop a plan to achieve a quick deployment win. This should be a visible project that can be successfully deployed in three to six months and can act as a catalyst for future success. Gap analysis report: The gap analysis report lists products that will be burned by defined projects and products that have yet to be linked to planned projects. The unlinked products constitute the gap. Deployment milestone status report: Deployment milestones and metrics are the critical checkpoints and measures that the Software Deployment Team defines. The team follows them closely to ensure that deployment progress is on track. License utilization report: This report supports proper license management.
It may be the output of a license management tool such as IBM Tivoli License
97
Manager. This should identify what software licenses are installed, where they are installed, and which ones are actively used.
ROI/ROR status report: The ROI/ROR status report should re-state the strategy documented with goals and milestones and present an updated view of the progress.
Deployment plan
The deployment plan includes a full mapping of projects to products purchased. It is not meant to duplicate planning around a single project being executed. The content falls into two primary categories, Account Planning and Project Planning, as explained in the following sections.
Account planning
The Account Planning subwork products in the deployment plan include:
High-level mapping of business initiatives to deployment projects: Ideally,

you have a set of goals in mind for the software that they are purchasing. Those goals map to potential projects. When the agreement closes, these projects drive deployment activity. This subwork product is a mapping that links each project to the business goals or initiatives that drove the original purchase.
Documented linkages of deployment projects to products: Like the previous

mapping of projects to business initiatives, this subwork product documents the products included in each project. This provides a direct tie to the products just purchased. This tie can help to rejustify the software purchase to new management, identify gaps in projected deployment, and align the deployment timeline with the business initiative timeline.
Deployment services requirements: This subwork product lists the services

that the SDT believes is needed during deployment because they are critical to deployment success. The deployment team identifies these requirements during the preparation phase of deployment, reviews them with the EBS.
Status of environment and infrastructure requirements: Any ancillary

prerequisites or corequisites must be completed before or along side the actual software deployment for a successful project. These may include hardware acquisition and setup, third-party software, or the creation of a new organization to handle the customization and rollout of the solution. It is important that these are recorded and monitored to prevent the project from stalling.
Project Planning
The Project Planning subwork products in the Deployment Plan include:
Deployment quick-win plan: It is important that success be demonstrated as

early as possible in deployment, because it will generate momentum,
98
enthusiasm, support, and positive first impressions. The quick-win plan identifies projects selected for their high-probability of success, their importance to the business, and their ability to complete in a relatively short period of time. The plan also contains the milestones and metrics associated with the projects.
High-level deployment plan: The deployment plan is the deployment bible.

A high-level version is developed early in the deployment method. It defines a list of initial deployment projects, groups deployment into logical chunks, contains a deployment timeline, and includes a services assessment.
Architecture plan: The deployment architecture is the blueprint of what will be

deployed in the environment. It combines all of the work products to illustrate how the solution will be accomplished.
Deployment plan findings and action plan: In the process of defining and
documenting the deployment and architecture plans, important items may be missing or not accounted for. These may include necessary hardware that has not been budgeted for or the implementation of a new and complex solution that is missing education and training on the new software. These items need to be documented and an action plan must be created to address any deficiencies.
Milestone status report: There should be ongoing communication with the

Enterprise Business Sponsor to provide updates on the progress of the deployment projects against the business milestones. This should be a high-level report that communicates progress or identified inhibitors to maintain support for the deployment or overcome obstacles to success.
Project controls: Project controls provide documented processes and

deliverables in the project areas of scope, time, cost, quality, human resources, communications, risk, procurement, and other project elements as required by the situation. Each element is documented by the project manager and should be made available for review by management (yours and that of IBM) and serves as the overall assessment of the project.
Readiness plan
This work product was created to ensure that the IBM team evaluates your readiness for deployment. In regard to the following subplans, the SDT should consider where extra planning may be necessary to minimize deployment risk. The subplans are:
Communication plan: Considers who the stakeholders are and who the
sponsor or owner is for all internal and external communications. This plan also contains a support plan.
Education and skills plan: Documents the skills assessment, roles, and any
justification needed for education expenditures.
99
Architecture plan: Documents security requirements, systems and data

integration points, and functional requirements.
Deployment plan: Addresses implementation, testing, and migration. Operations plan: Identifies backup and recovery processes and owners, disaster recovery plans, help desk environment, systems management disciplines, availability management, logging, monitoring, etc. Risks and dependencies: Points out items that pose risks to the success of the
project or define boundaries that should be understood by all parties. This information helps to minimize surprises by identifying areas that need special attention.
Work product examples

There are several references to work products in this redbook. This appendix provides examples of many of those work products. They are listed alphabetically for easy reference. Throughout the examples, InsCo and ShopCo are used to represent a sample company.
Architecture decisions document

This document consists of a series of architectural decisions. Each decision is documented in a table as shown in Table A-1.
Table A-1 Example architecture decisions document Subject Architectural decision Issue Integration architecture Use a transformational hub architecture to provide more economical systems maintenance and to make the legacy systems more flexible. There is a large number of legacy systems, some of which are to be replaced. There is a disposition to buy over build. There is a large number of interfaces, cost of maintenance is large, and the system is rigid. Additionally, the corporation must provide the potential to be acquired or to acquire. A basic principle is that packages should lead infrastructure. Point-to-point connections between existing legacy systems create a rigid application environment into which it is difficult to install a new package. Because ShopCo is focused on cost reduction and has specified a direction of purchasing and integrating packaged business applications instead of building those applications, the elimination of a substantial number of the point-to-point interfaces will go a long way toward achieving this goal. Assumptions Systems will require maintenance modifications for the foreseeable future. Multiple redundant interconnections are much more expensive to maintain than single connections. Systems which have abstracted interfaces are easier to work with.
100
Subject Motivation Alternatives
Integration architecture Economy, flexibility, reliability, time to market. Ability to add packages and make changes in a timely way. Continue to support point-to-point connectivity going forward. System will become increasingly hard to maintain as new packages are added. Addition of new packages will itself become more difficult. Use modified integration hub architecture. Requires messaging protocol.
Decision Implications
A typical set of architectural decisions may include such decisions as: 1. Integration architecture: Use a transformational hub to provide more economical systems maintenance and to make the legacy systems more flexible. 2. Legacy application access: Use component or services architecture to provide economy of reuse for legacy applications, and to enable a transformational hub. 3. Application runtime architecture: Use a browser-client architecture instead of client/server or host-based development to lower support costs and to provide business function over Internet. 4. Application development architecture: Use an object-oriented paradigm for new development. Separate model, view, and controller cleanly. 5. Application development platform: Use Java as an object-oriented language for Internet-client development. Use the servlet-JSP-bean model to separate model-view-controller for object design. 6. Internet/intranet platform: Provide reliable production, test, and development platforms for Internet- and intranet-based systems. 7. Security for new systems: Provide enterprise-level security straight through from Web to host, including messaging system. Provide single signon for applications. 8. Workflow system: Use an external workflow system to reduce coding required when integrating applications with each other and with human workers. Use a system to control flow between applications and third-party packages. 9. Dependability of distributed systems: Provide availability or fault tolerance for RISC-based systems (and any Microsoft Windows systems running production applications). 10. Disaster recovery for Internet and intranet: Provide disaster recovery for all production systems, including Internet and intranet client applications.
101
11. Portal: Use a portal-based Web interface to provide a coherent and personalized user console. 12. B2B application integration: Use Web services as the standard interface for implementing remote application invocation. 13. Level of integration: Use a process integration style of integration for connecting applications together.
Architecture overview
The integration design is in three parts: the integration hub, the gateway, and the portal. Figure A-1 shows these three parts. The integration hub provides routing and transformation services between legacy applications and new packages, as well as with the gateway and portal. It also provides the facility for creating and maintaining the data warehouse by use of an extract, transform, load (ETL) tool. The gateway provides Internet and network access for machines. It consists of technologies such as electronic data interchange (EDI), messaging, and Web services. The portal provides Internet and intranet access for humans, and consists of the Internet infrastructure and associated devices.
legacy applications gateway

external external networks networks
workflow server portal application server (new apps) Citrix apps
integration hub
new packaged applications
EIP
content management system
Figure A-1 Example architecture overview
102
Business context diagram

This e-business solution deals with several complex systems. They include ShopCos legacy applications, the intranet, the Internet, the branch systems, business partners, and a series of new packages that will gradually replace the existing legacy systems. Specifically, this solution is intended to provide an architecture for combining these elements into a consistent whole. To ensure that this process begins with an accurate understanding of the existing flow of work and information throughout the system, we examined ShopCos current business context and illustrated it as shown in Figure A-2. Many of these systems will be replaced by packaged application over the next two years. The new packages that are not yet selected will necessarily be treated as black boxes for the sake of this architecture. The integration of the new systems with the existing structures, as well as with the projected workflow and Internet systems, raise architectural issues that can only be roughed out in general at this time.
debit/credit, authorization
Customer Customer
purchase price, promos, etc
Direct Multiple Store Store Support Support

coupon control
Third ThirdParty Party
Advertising Advertising Distribution Distribution Systems (C&S etc)

delivery info ordering store activity, orders
POS POS Store Store Management Management

personnel info labor, benefits
HR HR
Financial Financials Systems (Lawson etc) Executive Executive Systems Systems

sales info cash management
Merchandizing Merchandizing Price PriceManagement Management
Reporting Reporting Database Database
Figure A-2 Example business context diagram
103
Component model
The model shown in Figure A-3 illustrates use case #1, an intranet-based application that accesses a legacy system, a packaged application, and a black-box system sitting on a partners system at another location.
Browser
HTTP Service
Servlet
Business Object
Message Queu e
Routing/ Transfor m Hub
Message Queue
QueueEnabled Application
W eb Service
Adaptor
Packaged Application
HTTP Service
HTTP Service
Partner Web Service Business Partner
Partner Systems
Figure A-3 Example component model
The components in this model are:
Browser: In the best case, the system is browser-agnostic. Although it may

be possible to specify which browser is used internally, on the Web any may be used. The intention is to use only the basic browser services.
Hypertext Transfer Protocol (HTTP) Server: The HTTP server accepts a

Uniform Resource Locator (URL) request from the Internet or from the Mobile Connection Service. It either handles the request itself (in the case of simple Hypertext Markup Language (HTML)), or passes it along to a servlet to be handled.
Servlet: The servlet is the basic controller of the model-view-controller system. It determines which objects need to be used by the request and directs and organizes their activity. When its work is done, it returns a Java Server Page (JSP) to the browser. Business object: The business object contains the business logic for a
particular piece of work. It communicates with other objects as needed, notably data objects which handle access to the data and services. In general, these objects are built so that they can be handled with any standard graphic programming tool, in which case they are commonly called beans.
104
Message queue: The queue is a messaging system that provides assured

delivery (once and only once) of a message that is posted on it. The queue has security enabled on it so that only the appropriate recipient can open it.
Integration hub: This is really a two-fold component: A routing and

transformational hub. The routing node directs the message to the appropriate application queue or to a transformational node. A transformational node checks to see what kinds of conversion are to be performed on the message, performs the actual transformation, and forwards the message to another node or to an application.
Queue-enabled application: This is an application that has had code added to

it that can communicate with the messaging stack. The application is made capable of receiving and generating appropriate messages through this queue. It is also possible for an application to provide input and output to a queue by use of a flat file or database.
Adaptor: This component represents a packaged or custom adaptor that has

been created to allow a packaged application to converse on the queuing mechanism. Many are available from either the application vendor or third parties.
Packaged application: This represents any application that can be queue-enabled or that produces a file or database. Web Service: This service provides communication across the Internet using Simple Object Access Protocol (SOAP). It uses HTTP for its lower-level protocol. Partner system: This is a system running on a partners machine, whose
internals may or may not be known to the originating system.
105
Component flow model

Figure A-4 shows a sample component flow model. The flow of information among the components follows the standard object and queuing conventions for servlet, bean, and JSP. It passes through the routing engine and an adapter that was purchased in conjunction with the packaged application. The packaged application appears to the business object (and to the programmer) as another bean.
Browser
HTTP Server
Servlet
Business Object
R&T Engine
Adaptor
Packaged Application
URL request
Activate servlet
Request customer info
Queued request passed to routing
Queued request to Adaptor
API call
API response Return data pointer to servlet Queued return passed from routing Queued return data to calling object
Return JSP as HTML
Fill in JSP with data
Figure A-4 Example component flow model
Current IT environments
Current IT environments are typically depicted by application lists followed by diagrams. A sample list follows. Figure A-5 and Figure A-6 are sample diagrams that illustrate the current architecture.
IBM host systems software

OS/390 2.8 TME NetView 1.03 CICS/ESA Base V4.1.0 COBOL for OS/390.21 NetView Performance Monitor 2.4 DB2PM 4.1 Basic Telecom Access Method SP Print Management Facility 1.1.1 SDF II MVS 1.4 GDDM-IVU 1.1.3
106
GDDM Interactive Map Def 2.1.3 GDDM-GDS 1.1.3 VS Fortran 2.6 VS Cobol II 1.4.0 IBM Database 2 MVS 5.1.0 NetView DM for MVS 1.6.2 IMS Sys U/B Tools 5.1 NetView FTP for MVS 2.2.1 System Automation for OS/390 1.3 Escon Manager 1.3.0 MVS Bookmaster 1.4.0 OGL/370 1.1.0 Cobol for MVS 1.2 VisualAge Cobol for OS/390, APL2 2 PL/I MVS 2.3
Host applications
Bidders 6.0.0 IBIS A/P 7.1 IBIS G/L Inforem 1.1.7 Genesys Payroll 5.5 WACS 4.1 27 legacy systems
Non-IBM host systems software

Abendaid/MVS 9.2.1 Abendaid/FX 4.2 CA-11 2.2 CA-90s 1 CA DADS Plus 3.5 CA-Filesave 1.1.0 CA-Gener/OL 7.0.b
RS/6000 in-store system software

AIX 4.3.1 AIX Connect 1.1 E-Network Comm Server for SNA 5 Tivoli TME10 for AIX 3.1.4 Retail Connectivity Option 2.3 TPS 3270 Emulation 3.1.7 TPS 3270 Emulation 3.1.0 3151 Terminal Emulation
107
RS/6000 in-store applications

People Planner 6.1.9125 Time and Attendance 7B00.11 SG Comtec Suite 3.33 Electronic Label Technology 5.31 FacetTerm 3.4.3 PDX 4.0.3 Telxon 1.2 Lotus 1-2-3 for AIX 1.02 Informix 5.07
POS in-store system software

4690/OS 1 4690 Enhanced Remote Operator 1
POS in-store applications

Supermarket Application 1 Surepay C Supermarket Electronic Marketing 1
RS/6000 server system software

AIX 4.3 E-Network Comm Server for SNA 5 Tivoli TME10 for AIX 3.1.4 Java 1.1.5 Load Leveler 1.3.0 Performance Agent 2.2.1 PSSP 3.1
RS/6000 server applications

Priceman RWS Nitro World Information Systems PDX 4.0.3 Executive Support System 6.2 Cash and Sales 6.2 CIC
Applications available via server

Microsoft Access 2000 Microsoft Access 97 Microsoft Access
108
Microsoft Excel 2000 Microsoft Excel 97 Microsoft Office 2000 Microsoft Office 97 Corel Office 2000 Monarch 4 DBase 2.0 FoxPro 2.6 Lotus SmartSuite Millenium
Desktop software
Windows 95 B Windows 98 SE Windows 2000 5.00.2195 SP1 Personal Communications SmartSuite Millenium Global Dialer 2.5 Netscape 4.7 Acrobat Reader 3.25 Norton AntiVirus 4.1 PC Outline
Other software
Novell NetWare 4.11 OS/2 Notes 4.6 Microsoft Windows 98 98B Microsoft Windows NT 4 MAC-OS PSI Standard Desktop Platform 1.0 Excel 97
Example 1: Current application deployment

Figure A-5 shows the current application deployment. While most of the ShopCos systems were originally mainframe applications, some client/server applications were developed. Also, there is an increasing awareness of the benefits of development under Internet-based technologies. At the moment, the important platforms are S/390 and Windows Client/Server. The available UNIX hardware and expertise should be retained, because they constitute the most likely platform for the deployment of the Internet, intranet, workflow tool, and the integration hub. It is likely that ShopCo will also find that, as new business packages are implemented, the UNIX platform will become increasingly important both as the
109
systems platform for those packages and probably as servers for browser-based, Internet client applications.
Advertising Dept
Distribution GF NT Grocery Dry Goods POS POS (4690) Supermarket Pharmacy Toys Financial BA BT HH FT Returns HR
Item Management Pharmacy Bakery Toys Merchandising Catalog BN GT
Store Server (RS 6000) Store Management HR, CGO, etc
Advertising System 390
Store
Warehouse & Logistics DRS
Financial Peterson Marketz Purch RS 6000
Notes Mail, Priceline Promotion Access xBase/App Dev, etc Windows Intranet Domino Web
Distribution Center
Internet structure
Figure A-5 Example diagram that illustrates the current architecture
Example 2: Subsystem needing special attention

Because the ShopCo architecture represents the current default method of building Net-based applications, it is crucial to understand the underpinnings of this architecture. Figure A-6 illustrates the architecture. A browser, on the users desktop, is used to connect to the Web site. This browser then uses a plug-in to launch a Citrix session running on a Citrix server within the secure zone. Within this Citrix session, a second browser is launched. This browser then connects to an Internet Information Server (IIS) using an auxiliary storage pool (ASP). The IIS server runs a Visual Basic program which connects to a second IIS server on an Enterprise Information Portal (EIP)
110
machine. This IIS server then connects through WebSphere to EIP and then to the ImagePlus system. This somewhat unlikely and cumbersome configuration came about because the Brio system, used to provide reports, was unacceptably slow when the client was on the users desktop. However, it ran sufficiently well on the Citrix server, from which its image can be shown, page by page, on the desktop browser.
Nfuse Server Citrix Server Desktop Browser Citrix Plug- in Web Server Browser ASP
App Server IIS Visual Basic
EIP Server IIS
DB2 Image Plus Index Image Plus Data
WebSphere App Server
Brio Plug-in
BRIO
EIP SQL Server report data
Figure A-6 Example current architecture diagram
Current business organization

Over a period of three months, multiple interviews were conducted with the senior members of the ShopCos IT team highlighted in Figure A-7. In addition, there were several meetings with the Chief Information Officer (CIO), as well as several conferences with technical people at a lower level.
111
Jane Smythe President
Underwriting Michael Ho
Claims Thomas Jones
CIO James King
CFO Mark Ellerby
COO Betty Plonk
Branch Ops Jeremy Newl
Managed Care Allen Hobbes
Bill Howard Judy Wells
Data Mangmt Peter McAng Changes Web Apps Datamart GJS CoA Prime Notes/Web Actuarial Data Quality End User
Claims Connel McFarland
FNOL Mary Martin
Underwriting Henry Lakey Reporting Workers' Comp Comml Auto POKI Financial A/R Premium Corp Reporting Appl. Architecture Appl/Systems Support
Operations Pi Zaharko
Peter Vicot Client Systems Support Financial/Claims
Ann Riley Forms Call Center Quick Code Image Team
Rita Spannel Lotus Notes Admin Networking Services
Louis Jacaro Mail & Copy Printing Data Center Prod. Control
Peg Henry Help Desk Procurement & MAC Telecom
DBA
Figure A-7 Example business organization
Envisioned goals and issues

ShopCo has a legacy background of 3270-based host applications. Over the last few years, a concerted attempt was made to provide more advanced client interfaces for new systems. This resulted in the development of a moderate number of client/server applications constructed in Visual Basic and PowerBuilder. In the context of this mix of applications, the CIO made a carefully-reasoned build-dont-buy decision to begin to move toward application packages. This is intended to provide stable business functionality on a platform that can be more easily and economically maintained. An integration architecture is needed to facilitate the addition of new packages. (When the Cenfra package was installed, 30 different systems had to be modified, and even after that integration, it is still tightly coupled.) Two other efforts are to be combined with this move. The first of these, the integration of a new workflow with the imaging system, should be considered in
112
the context of the move to application packages. The second effort, to get more productive business use from the Internet and intranet infrastructure, should also be planned within the context of an overall integration architecture. To provide for these goals, the CIO has requested IBM to provide an integration architecture. This architecture is to include imaging, workflow, application integration, Web integration, and integration with business partner systems. The specific goals are: Reduce maintenance costs Implement packages Cenfra (rating) A new homeowners package A package for CPCS Policy Issuance System Premium Financial
Implement integration architecture: Replace home-grown messaging and polling mechanisms Use and reuse: Develop once, and use as needed Centralize information Client profile Agency/broker information
Replace aging imaging system Provide for e-mail, graphics, voice messages, direct fax, etc. Reduce time to market Implement packages Implement workflow Use integration architecture Engineering for agility Implement queuing Improve system maintenance Harden infrastructure Move critical and enterprise systems to open standards
Improve system reliability
Provide Internet infrastructure Provide gateway for external applications and Web services: Enable InsCo to broker online applications between agent and carrier.
113
Provide portal for employees, customers, and business partners. Standardize Web standards and development. The intranet infrastructure should support the development of an underwriters workstation. Version control of the Web site. The issues are: Some system level functions are home-grown, such as the polling piece of FNOL. It requires tending to make sure its running (InsCo actually wrote a program to check and see if its running). Image environment is 12 years-old, MODCA only, no voicemail, e-mail, etc. Islands of process are hard to maintain and integrate. This makes the move to packages much more difficult. Tightly integrated functions will make the move to packages much more difficult, for example, the need to decouple claims from check creation process. Many legacy applications need to integrate with new packages. Cenfras installation required 30 different systems to be modified, and even after that integration, it is still tightly coupled. Complicated legacy systems make it more difficult to develop application function quickly. Large number of legacy system interactions is expensive to maintain. Some systems are not reliable (FNOL is required to be recycled daily). If we bring products in, we dont have the opportunity to see all the features. There is no end-to-end security. There is no end-to-end systems management.
Current IT standard
While some extensive standards documents have been promulgated over the years, the most effective standards at ShopCo are de facto. This can clearly be seen by examining the current IT environment. The use of COBOL as an application development standard has been maintained more as a default than an active choice. Enterprise program development has with some exceptions been restricted to COBOL under CICS and IMS. Within the stores, the C language is in use, as is Informix. There is a limited amount of Visual Basic used in the client/server space, and some traces of the beginnings of Java development.
114
There does not appear to be an agreed upon standard for future application development. There is no specific standard for the Web platform. Database standards are DB2 Universal Database (UDB), with SQL server as a second option. But there is some Sybase and some Access, as well as FoxPro and Approach. At the same time, there is a decided and verbalized proclivity toward the use of packaged software. Although many of these package standards remain to be set, the decision to use packages where possible should itself be treated as a standard.
Host platform
S/390 Version 2.10 COBOL VSAM IMS Image Plus CICS Version 1.2 DB2 Version 6.2
Client/server platform
PowerBuilder Sybase Visual Basic Oracle Excel Access Ethernet (token ring) Windows 2000 Desktop (Windows NT) Windows 2000 Server (Novell) Brio
Server platform
AIX Sybase Powerbuilder MDI Gateway SNA Comm Server PeopleSoft Windows 2000 Server
115
SQLServer 7 FDR backup
Browser client
Citrix plugin IP IE 6.0
Mapping business initiatives to projects

Table A-2 shows an example of a table for mapping business initiatives to projects.
Table A-2 Mapping business initiatives to projects Topic Business goal Business initiative Project name Project description Key Strategic business goal Customers name for business initiative Customers name for the project or initiative Brief description Goal #1 Improve employee productivity Collaboration Advanced collaboration Enterprise-wide rollout of collaboration tools E = Mary Smith Goal #2 Reduce training costs Distance Learning Enterprise eLearning Training for merger, agents, call center, applications P = John Doe
Customer sponsor
E = executive P = project (include contract information) Customers project status
Project status Existing solution or competition Annual cost of existing solution or competition
Plan None
Plan *Placeware, *ASP Berbee LearningSpace ASP through Berbee Approximately $4,000 per month + per user access Yes
Unknown
Money in budget
Yes or no and amount if known
None
116
Topic Decision date Deploy date Comments
Key
Goal #1 10/01/2002 11/01/2002 Currently piloting 40 licenses of ST in the Minneapolis location. Looking at enterprise rollout.
Goal #2 08/09/2002 10/01/2002 Stated corporate evaluation in April/May by Dave Ms team
Mapping projects to proposed products and solutions

Table A-3 shows an example of a table for mapping projects to proposed products and solutions.
Table A-3 Mapping projects to proposed products and solutions Topic Project name Proposed IBM product or solution IBM Software part number Function Business value Key From business initiatives sales aid Product name PA number What does it do? Value to customer Project #1 Advanced collaboration SameTime D5CT2LL Real time chat and e-messages Less phone tab, less travel, faster response training 7000 Normal PA discounted price Or other non OTC if applicable Will calculate qty x bau rsvp L = lead M = member (include contact info) $201,000.00 L = Steve W $291,480 L = Tom B $28.12 Project #2 Enterprise eLearning LearningSpace Collaboration D5CPRLL Distance learning Reduced travel and tuition expense 7000 $41.64
Quantity BAU unit price MLC Total revenue IBM Lead/Team members
117
Topic Comments
Key
Project #1 Licenses of SameTime in the Minneapolis location. Looking at the enterprise rollout.
Project #2 Stated corp. evaluation in April/May by Dave Ms team.
Non-functional requirements
The non-functional requirements are explained in the following sections.
General
Because the projected changes to the system involve a large number of black-boxed applications (systems that are not yet selected), it is not possible to obtain accurate non-functional requirements in some cases. Although gross approximations can be used, the system must be sufficiently scalable to accommodate substantial differences in the actual build-out.
Performance
Average response time for external Internet-based applications is to be less than 7 seconds. To make this reasonable, a specific use case transaction time is assumed to be no more than 2 seconds. Exceptions to this are the ERV application, which must be less than 5 seconds, and the CCamp application, which must be less than 1 second.
Capacity/volumes
Store TLOG files run at an average of 15 MB per store per week over 102 stores. This constitutes a capacity of approximately 2 GB per week, or about 100 GB per year. This is required for the trickle system, ETL tool, and the data warehouse, and possibly the integration hub. The transactional systems must be able to accommodate 350 concurrent users. The users will generate a transaction every 5 seconds, on the average.
Scalability
Because the identity of many of the future packaged systems cannot be known with certainty, the integration scheme must be easily scalable within an order of magnitude, that is, a factor of 10. The possibility of mergers and takeovers requires this capability as well. Hardware upgrades must be able to be accomplished using the same class of server. That is they must be able to scale horizontally.
118
Availability/fault tolerance
The point-of-sale machines are critical to the business operation minute-to-minute. They should be managed to reduce the possibility of failure to a minimum. They must be available 24x7x365 for 72 stores, and 14x5x200 for the remainder. The current system of providing a single installable replacement for a store server is cumbersome. However, since there is currently a flexibility of several hours allowed in replacing an inoperative machine, it is not dangerous.
Usability
Applications must adhere to the ShopCo Common User Interface (SCUI) for all browser-based applications.
Portability
Because of the projected consolidation and migration of production machines in the third quarter, all applications developed for this system are required to be portable across runtime platforms. Projected package purchases and uncertainty as to merger possibilities also make it prudent to ensure that the new applications can run wherever they are required.
Maintainability
No specific requirements are noted.
Security
End-to-end security should be specified before application package selection. Single signon is a requirement, and application packages must be able confirm to the corporate standard. Security functions should not be performed within applications unless they are approved by the chief architect. In general, the system should have few entry points, should use hardened gateways, and should authenticate users at entry points, not within applications. The system must have a security code distributed to only a few nodes, must extend end-to-end, and must be based on modularity rather than an interdependence between security and applications.
Infrastructure constraints
MQSeries is the required messaging mechanism. Oracle is used for all GFV applications and DB2 is used for all others. Most business application are host legacy systems.
119
Geographic and configuration constraints

Configuration cannot include single points of failure. Configuration must support local deployment within both Western Europe and PAC RIM countries (regions).
Operational model
Figure A-8 shows an example of an operational model diagram.
Figure A-8 Operational model diagram example
120
Project description
This can be a highly detailed description of one specific project. This example is from an integration architecture that touches many different projects.
Group manager workbench

Provide the group manager with the decision support tools that are need to perform exception-based analysis. This includes the delivery of personalized corporate data. Automate the monthly financial and inventory reconciliation. Automate the store checklist process. Automate the back-feed data for two-way internal flow. The architectural implication is that this project requires a portal or personalization intranet infrastructure and attachment to the legacy system by an integration hub.
Implement TRN
Migrate to the TRN Market Point-of-Sale (POS) applications. Customize TRN application to cover high priority GFN customizations. Integrate existing host item maintenance and electronic payment systems with TRN. The architectural implication is that the integration hub is used to couple TRN to other systems.
Price optimization
Use a price optimization solution (DemandTec, or KhiMetrics) to facilitate more effective margin management. Need ADM numbers to expand beyond classical, rock, and early jazz categories. The architectural implication is that the addition and integration of package solutions is facilitated by use of the integration hub (and possibly the ETL tool).
new Item and Price Management

Consolidate Shopco item data into a single item master. Migration to a new item master is the foundation step for the migration to a new set of merchandising and decision support tools. Include data definition work to enable the transfer of item data. Need technology integration hub. The architectural implication is that the implementation of this application is greatly facilitated by the use of the ETL tool and the integration hub.
Data warehouse
The data warehouse provides the foundation for cost accounting, category management, and GYPSY replacement. The data warehouse provides a single
121
source of item data for all future ShopCo applications. It is dependent on the TLOG data. The architectural implication is that the implementation of a data warehouse is dependent on the trickle data movement mechanism and is greatly facilitated by the ETL tool.
Replace the DSD Receiving system

Replace the DSD Receiving system. Implement DEX to automate the store level direct delivery vendor receiving. This will ensure data integrity, improve productivity, and enable more detailed receipts at store level. The architectural implication is that if this system is determined to have to interface with legacy systems, then the presence of an integration hub (and possibly ETL tool) will make its implementation much simpler and less expensive.
System context diagram

Figure A-9 shows a simple system context diagram that indicates the position of the new system within other existing or future systems.
122
Business Partner Systems
New Packages
Branch Systems
New Architecture
Legacy Systems
Intranet & Internet Systems
Datamarts
Figure A-9 System context diagram example
The integration architecture interfaces with substantial number of existing legacy systems and with a series of new business packages which are not yet selected. Because these packages must be treated as black boxes, flexibility must be a primary criterion for architectural design. At the same time, the new system must integrate with Internet and intranet-based systems and business partner systems. Since many of these processes are executing outside of the enterprise center, security must also be taken as a primary issue. Finally, the addition of the new datamarts and the movement toward a unified ODS requires the new architecture to accommodate data integration as well as process integration.
Systems context diagrams for an integration architecture

Figure A-10 shows a systems context diagram for an integration architecture.
123
Shelf List
Categories
EDS CS
Category Managem ent
Time and Attendance
Financial System s
Drop Shipments
Distribution Systems
Direct Delivery End User Computing
Reclamation
EDI
Direct Store Support
Seasonal Applications
Pharmacy
Price Check
Human Resource s
EFT
Continu ous Replenishm t
Factor
Toys
Store Application s
Price Book
Store Order Processing
Figure A-10 Systems context diagrams example for an integration architecture
124
Use cases
Use cases in these architecture documents are not programming-level use cases, but rather high-level descriptions of how a system works. As shown in Figure A-11, this example involves more than one actor.
8
3-4, 5, 6-7 12-13
Social Worker
Judge
System
9
Safe Haven Clerk
10
11
Police Dispatcher
Social Work Supervisor
Figure A-11 Use cases diagram example
The following information further describes Figure A-11:
Actor: Social worker. Description: A social worker spends most of the time working in the field on
individual cases. The social worker frequently needs access to the departmental systems in real time.
Use Case #1: It makes provision for a child in danger. Event: A social worker is called to a household where she determines there is
a child in eminent danger. The child needs to be removed to a safe haven.
Actors: Social worker (and judge, safe haven clerk, police dispatcher,
supervisor).
125
Overview: The social worker uses a personal digital assistant (PDA) to connect to system. They select the eminent danger process, and complete the form to request court approval, safe haven, and police assistance. The system arranges and records all transactions and messages for the social worker to proceed. Preconditions: These are valid cause for removal of child. They include the
availability of a safe haven and the establishment of remote communications.
Termination outcomes: The social worker receives approval and assistance

for removing child.
Use case description

The use case in this scenario follows this sequence: 1. The social worker connects the PDA to a system and logs on. 2. The social worker selects the process and receives a search screen. 3. The social worker enters the name and address information. Then they click Search. 4. The screen returns a list. The social worker selects the correct items, clicks OK, and receives the case information. 5. The social worker selects an option for the application to remove child and receives form. 6. The social worker fills out the form and submits it. Then they log off the system. 7. The form information is received at the server and passed by the workflow system to the courts. 8. The approved request is passed to police dispatcher. 9. The approved request is routed to the safe haven desk and the custodian. 10.The approved request is forwarded to a social services supervisor. 11.When the workflow system successfully negotiates with all of these services, the social worker is alerted via the PDA with the instruction to read the approval message. 12.The social worker connects to system, logs on, and receives the message with the approval document, the name and address of the safe haven (with a map), and estimated time of arrival of police assistance. A programming use case for this scenario looks similar to the example shown in Figure A-12.
126
System
Social Worker
Social worker completes search screen SW completes seach sc reen System returns list System returns lis t Social worker selects case SW selects case System returns form System returns form Social worker completes form SW c ompletes form System returns authorization System returns authoriztion
Figure A-12 Programming use case example
Viability assessment
This example represents the initial assessment of viability for the current architecture. It may include risks, assumptions, issues, and dependencies. Table A-4 shows the risks section.
Table A-4 Example viability assessment Risk Ref. 1 Risk description Point-to-point connectivity for applications will become increasingly expensive and rigid. Probability (H/M/L) H Impact (H/M/L) H Contingency or mitigation Adopt integration architecture to avoid point-to-point connections. Initiative
127
Risk Ref. 2
Risk description Home-grown messaging functions will become undependable and expensive to maintain. Current Internet-client model (using Citrix) will become expensive and unwieldy. Lack of end-to-end security architecture will result in excessive exposure and maintenance cost. Security violation of the system running in the demilitarized zone (DMZ). Support cost for desktop will continue to rise
Probability (H/M/L) M-H
Impact (H/M/L) H
Contingency or mitigation Use standard third-party queuing mechanism.
Initiative
M-H
Provide a more standard and efficient browser-client model.
M-H
Provide end-to-end security for integration architecture.
Implement screened sub-net architecture.
Enforce existing desktop standards. Standardize on thin client intranet development. Standardize reporting tools. Provide desktop data backup. Standardize printing strategy.
Note the following explanations for probability and impact in Table A-4: Probability: High: The risk identified is probably going to occur, or is already occurring. Medium: The risk identified is about as likely to happen as not to happen. Low: The risk identified is unlikely but still worth considering. Impact: High: Resolution is likely to require difficult decisions, probably above the level of the project manager, which is likely to affect the schedule, budget, or functional completeness of the project. Medium: Special management attention is required, but it should be possible to contain the risk within the project plan. Low: Normal management attention should be sufficient to resolve the issue.
128
Appendix B.
Software deployment checklist

This appendix contains a series of checklists of the activities and tasks for the Software Deployment Method (SDM). You can print it and use it as a reminder of the items in each phase and to track your progress as you complete the items.
129
Software deployment steps

Activity Step 0: Create the Software Deployment Team Step 1: Review the critical deployment documents Step 2: Develop a high-level deployment plan Step 3: Establish a deployment partnership Step 4: Refine the high-level deployment plan Step 5: Finalize the deployment plan Step 6: Conduct deployment kickoff meetings Step 7: Achieve quick deployment wins Step 8: Execute the deployment plan Step 9: Identify new business needs Step 10: Update the business plan Owner(s) Date completed Notes
Phase 0: Prepare for deployment

Step 0: Create the Software Deployment Team
Activity Gather the Software Deployment Team Get commitment from each member Communicate roles, responsibilities, and expectations Owner(s) Date completed Notes
130
Step 1: Review the contract content and critical deployment documents

Activity Discuss the buying decision Ensure that the content, terms and conditions of the contract are thoroughly understood by all SDT members Study and understand any substitution clauses Understand the status of maintenance and support Discuss any expectations Discuss license management tools and processes and how to track deployment Review the requirements, solution concepts, business context, conceptual architecture, and architecture decision document Review and refine the initial viability assessment (which includes the results of any Solution Assurance Reviews (SARs)) and confirm the solution Document the linkages between the planned projects and products Owner(s) Date completed Notes
Appendix B. Software deployment checklist
131
Step 2: Develop a high-level deployment plan

Activity Validate and refine the goals and milestones Group deployment into logical chunks based on business initiatives; assign ownership to the initiatives Refine the list of projects and assign ownership Create a high-level deployment timeline or phased execution plan for building the entire solution Assess gaps where services will be required Assess the need for infrastructure management projects Review an initial license utilization report and identify where existing software will be used and how new software will be tracked Determine any gap between products with defined projects and products that require further project definition Owner(s) Date completed Notes
132
Step 3: Establish a deployment partnership

Activity Confirm the buying decision and vision Identify quick deployment wins Define deployment milestones and measurements Review skill and project gaps and define a strategy to address Review and discuss any roadblocks that could impact deployment Validate project owners Schedule date for first kickoff meeting Owner(s) Date completed Notes
Phase 1: Refine and promote the plan

Step 4: Refine the high-level deployment plan
Activity Review the past activities, documents, and decisions Perform any necessary performance and capacity modeling Recommend a physical architecture Refine hardware and software requirements Discuss environmental and infrastructure requirements Create a draft of project controls Update the deployment and quick deployment win plans as needed Owner(s) Date completed Notes
133
Step 5: Finalize the deployment plan

Activity Review and finalize the deployment plans Discuss any appropriate migration strategies Discuss any appropriate conceptual data model for legacy data Finalize the recommended physical architecture Finalize the systems management plan Gain agreement on project controls Update the quick deployment win plan, if needed Finalize project ownership Finalize software deployment milestones and metrics Owner(s) Date completed Notes
134
Step 6: Conduct deployment kickoff meetings

Activity Present the vision that drove the software purchase Link the products purchased to the business initiatives and vision Discuss the high points, terms and conditions, and critical aspects of any contracts Communicate the business value and benefit Show the business context and high-level architecture Present the high-level deployment plan and timeline Discuss the breadth of the deployment (local, regional, national, or global) Discuss the roles and responsibilities Discuss any known roadblocks and the plan to overcome Communicate the quick deployment win plan Discuss the software deployment best practices Present the key benefits of the major driver projects Arrange for demonstration of key products if necessary Owner(s) Date completed Notes
135
Phase 2: Deploy software

Step 7: Achieve quick deployment wins
Activity Assign project managers to quick deployment win projects (internal, IBM, or third party) Verify and augment the capabilities of the quick deployment teams assigned to the projects Execute the quick deployment win plan Manage the projects with project controls Conduct regular meetings with the project owners Monitor progress of quick deployment projects against plans and make adjustments as needed Implement recommendations defined during readiness discussions Address and resolve technical issues that may arise Maintain close contact with project owners, stakeholders, and sponsors Execute early phases of the education plan Monitor the satisfaction of the solution users Track software license usage Owner(s) Date completed Notes
136
Step 8: Execute the deployment plan

Activity Advertise quick deployment wins with meetings or open house events Assign deployment project managers Educate additional users on software support processes Verify and augment capabilities of the deployment teams assigned to the projects Begin executing projects per the deployment plan Manage the projects with the project controls Monitor progress against the plan and make adjustments as needed Address and resolve technical issues that may arise Maintain close contact with the stakeholders and sponsors Monitor overall satisfaction Track software license utilization Owner(s) Date completed Notes
Step 9: Identify new business needs

Activity Revise the deployment plan to include the new requirements Seek out new demand Manage these new projects as done in Step 8 Owner(s) Date completed Notes
137
Step 10: Update the business plan

Activity Incorporate any lessons learned from the recent deployment into future plans Determine the technical needs of the identified projects Apply current software inventory and new software purchases toward the future deployment plans Return to Phase 0, Step 1 Owner(s) Date completed Notes
138
Appendix C.
Global software deployment checklist

Experience has shown that a Global Project Lead will have a difficult time focusing on multiple deployment sites all over the world. This is because certain sites will demand greater levels of attention at the expense of lesser sites that are perhaps not as problematic. A good example of this is a primary site where the majority of the software is being deployed. This site by natural will absorb a lot more of the project leaders attention. To combat this issue, this appendix provides a list of key global activities. You should revisit this list periodically to ensure that all important work items are being done.
139
Global-level activities executed by global deployment lead

Activity Your decision making team determines, prior to the software purchase, that software will be deployed in multiple cities, countries, or regions around the world. Your executive team assigns a Global Project Lead (GPL) to focus on software deployment at all sites. The GPL obtains a full understanding of the buying decision. Primary, secondary, and tertiary deployment sites are identified. The GPL works with the Software Deployment Team (SDT) to draft a high-level plan for software deployment with high level milestones. All known deployments sites are placed in the timeline. This high-level plan needs to be dynamic. It is adjusted as deployment sites are discovered and milestones are achieved. The GPL identifies a team within the vendor who will assist them at the worldwide level. A Document of Understanding (DOU) should be written between the customer and the vendor. The vendor should commit to assigning or aligning resources with all deployment sites around the world. The vendor should provide names and full contact information. Owner(s) Date completed Notes
140
Activity The GPL determines how software will be customized and implemented to match requirements. For example, they may build a gold disk that can be used to ensure that all software deployment is identical on every desktop and server around the world. The GPL needs to monitor software deployment activity around the world to ensure that all activity falls within standard guidelines set at a global level. The GPL meets periodically with all site leaders to review deployment progress and milestones. This meeting should include all sites that may not yet have begun deployment software. The GPL schedules periodic meeting with your decision making team and the site leaders to checkpoint deployment progress and raise any critical issues. The meetings are used to review deployment milestones and value realization milestones. The GPL remains aware of all new software purchases around the world. When these purchases are finalized all software should be immediately moved into software inventory. The GPL circulates a status report monthly to your decision-makers, business sponsors, and the entire Software Deployment Team around the world.
Owner(s)
Date completed
Notes
Appendix C. Global software deployment checklist
141
Local sites (secondary part-time coverage)

Activity Site leaders meet with local vendor teams frequently to discuss deployment plans and challenges. Site leaders report status to the GPL on a predefined frequency. They report deployment status, accomplishments, challenges, and escalation points. Site leaders drive deployment activities in their location. Owner(s) Date completed Notes
Local sites (tertiary on demand coverage)

Activity Tertiary coverage is available in reactive situations only. Each deployment site that is not primary or secondary should at least have a named resource aligned with it to monitor and escalate challenges that may impact the deployment progress. Your vendor should also provide tertiary coverage at each one of these sites. This coverage should be aligned with the products, solutions, or both being deployed at each site. The right expertise should be available to help resolve issues quickly. Owner(s) Date completed Notes
142
Appendix D.
Additional material
This redbook refers to additional material that can be downloaded from the Internet as described below.
Locating the Web material

The Web material associated with this redbook is available in softcopy on the Internet from the IBM Redbooks Web server. Point your Web browser to:
ftp://www.redbooks.ibm.com/redbooks/SG246070
Alternatively, you can go to the IBM Redbooks Web site at:

ibm.com/redbooks
Select the Additional materials and open the directory that corresponds with the redbook form number, SG24-6070.
143
Using the Web material

The additional Web material that accompanies this redbook includes the following files: File name checklists.zip Description A Microsoft Excel spreadsheet that contains the templates in Appendix B, Software deployment checklist on page 129, and Appendix C, Global software deployment checklist on page 139.
How to use the Web material

Create a subdirectory (folder) on your workstation, and unzip the contents of the Web material zip file into this folder.
144
Glossary
ADD See architectural decisions document. architectural decisions document (ADD) Lists critical architecture decisions or choices made in the design phase. It also describes the rationale for making them. architecture overview diagram Illustrates the basic ideas of the proposed architecture. It is the equivalent of the architects sketch. Depending on the context, the diagram may range from basic to more detailed. Related work products are the system context diagram, component model, and operations model, where additional detail is conveyed. Typically, the diagram evolves with a greater level of detail as the architecture is better understood. The diagram serves as a means of confirming architectural understanding between IBM and the customer. backup and recovery plan Identifies the necessity for backup and recovery and how backup and recovery impacts the customers internal service-level agreements. Customers should identify who is responsible for backup and recovery and document the procedures in their support plan. best practices Actions recommended by experienced software deployment personnel. When followed through the life of the Enterprise Agreement (EA) and the Software Deployment Method (SDM), best practices help to ensure deployment success. business context diagram and description Used to document the identity of the business area being served by the development effort and its interactions with other business entities in its environment. These entities and interactions are the sources and channels for flows of information into and out of the business. This is key to developing a system that is properly situated in the clients business. business goals Brief objectives of the company that must be achieved to enable the fulfillment of the vision. CITA See Client IT Architect. Client Executive Builds a long-term business relationship with the client. Identifies IBM opportunities and develops solution strategies that meet the clients business needs. They maintain customer business relationships at the senior level with key decision makers and influencers. The Client Executive is accountable for total client satisfaction, IBM market share, revenue, and profit earned from the client. They partner with the Software Sales Representative (SSR) to drive software sales and partners with sales and technical specialists in hardware and services to drive respective sales. Client IT Architect (CITA) A role similar to that of the Software IT Architect (SWITA) and Software Deployment Architect (SDA). The CITA has IT responsibility for the entire IBM relationship with the customer, including hardware, software, and services. The relationship among the CITA and the software technical team is critical. Client Representative Builds a long-term business relationship with the client by providing total solutions to a clients business needs. The Client Representative identifies and qualifies IBM opportunities, engages the appropriate IBM resources, gains client commitment to solutions when appropriate, and ensures overall client satisfaction. The representative manages IBM opportunities while guiding the development of the solution and support strategies. They partner with the SSR to drive software sales and partners with sales and technical specialists in hardware and services to drive respective sales.
145
communications plan Reflects all the direct and indirect parties involved with the deployment project. Describes who is responsible for every aspect of the implementation. This plan should also describe the escalation process in case of problems. component models Documents that include responsibilities and required service levels for each component. The responsibilities are described from the view of a user of the component and later refined into specific operations. The service level for the component is described in regard to users and presentation, performance and capacity, and availability design rationale, reasonableness and risk, and implementation approach. critical success factor (CSF) The limited number of areas where satisfactory results ensure the achievement of the business goals. Business issues can be used to identify the CSFs. CSF See critical success factor. customers IT environment A work product that documents the customers existing logical and physical design, existing databases design, existing Web environments (servers, firewalls, for example), security requirements, operational parameters (24x7 for example), end-to-end performance requirements, and existing standards (such as naming and protocols). customers organization A work product description that includes an inventory of organizational elements (structures, behaviors and enablers) for the in-scope organizational units (for example, corporate organization, strategic business unit (SBU), functions, teams, and individuals). The influencers and owners may be key to defining who to call for a given solution. An organization chart may be color-coded, for example, to indicate who is directly involved in the decision process.
deployment architecture The blueprint of what will be deployed in the customer account. It combines the work products that depict the architecture to be deployed (architecture overview, operational model, and project descriptions for example) with the deployment plans, metrics, and milestones of how it will be accomplished. deployment kickoff meeting Markets and communicates the deployment plan (and vision) to all current and potential users within the customers environment. All key leaders must attend (the full IBM team and the customer team project leads, IT leads, and lines of business leaders). The kickoff meeting should create awareness, understanding, and enthusiasm for the deployment that is about to begin. deployment plan (high-level and detailed) A high-level version is developed early in the deployment method and defines a list of initial deployment projects, identifies customer sponsors and owners for known projects, groups deployment into logical chunks, contains a deployment timeline, and includes a services assessment. A more detailed version is developed later in the method as more projects and information are known. It is considered the deployment bible. EA See Enterprise Agreement. education plan Assesses the skills needed for successful deployment, current customer skills, and the steps to close all identified gaps. Enterprise Agreement (EA) A multi-platform software offering that includes IBM Eserver zSeries monthly license charges (MLC) and one-time charge (OTC). It is a special offering that contractually leverages the Enterprise Software and Services Option agreement. In most cases, this agreement replaces or amends other IBM agreements (for example, Passport Advantage) that are referenced under the offering. The average life of an EA is three years, but the term can be as short as one year.
146
Enterprise Business Sponsor Represents the customer and takes ownership for the software deployment throughout the enterprise. This sponsor commits to: Develop the internal vision for promoting the maximum utilization of purchased licenses, based on the benefit derived. Work with lines-of-business and IT leads to delegate responsibility for deployment success and return on investment (ROI). Represent the business globally, if applicable. Define deployment milestones for the entire term of the Enterprise Agreement. Assist with marketing and demand generation of the software portfolio within the organization. Establish deployment quick-win initiatives to establish project credibility as early as possible. envisioned goals and issues (project ideas that emerged early in the sales process) A work product that documents the clients mission statement, vision statement, to-be business goals, and critical success factors. execution environment plan Recommends an appropriate environment and level of discipline for development, test, and change management during deployment. gap analysis A listing of products that is burned by defined projects and products that have yet to be linked to planned projects (the latter is called potential shelfware). The unlinked products constitute the gap. Gap analysis is also referred to as software demand gap analysis. global software deployment The deployment of IBM licensed software for an account that has deployment locations that span two or more geographies. IT standards A work product that documents all known IT standards that the architecture must accommodate. ITS See Software IT Specialist.
license management Involves identifying which licenses are installed, which ones are active, and how many licenses are forecasted to be deployed. To assist in this area, Tivoli has a tool called IBM Tivoli License Manager that became available in November 2002. list of projects and owners A work product that lists all the potential projects, what brands are involved, the deployment sites, the customer owners, and their contact information. This helps to ensure that, when deployment begins, information is available to help drive deployment activity. Managing Director Has overall responsibility for the global relationship within the account, including responsibility for profitability. mapping business initiatives to deployment projects to products A work product that acts as a map that connects products with projects. It links each project to the business goals or initiatives that drove the original sale. migration plan The act of customers moving their current versions of software or hardware to newer versions (or to new platforms). Migrations can be complicated and may create cost and time overruns that can cause serious problems. Migration plans describe the activities and timetables for doing the migration. Some of those activities include customer code regression testing, execution environment tests, migration automation scripting, and back out planning. mission statements The operational, ethical, and financial guidelines of companies (or functional areas). They articulate the goals, dreams, behavior, culture and strategies of companies. This should be information that is already created by the client. Sometimes called value statements, credos, or principles. operational model A work product that specifies the hardware that the desired architecture requires.
Glossary
147
project descriptions Communicates the project goals to everyone who needs to know. Provides answers to the question, What are we doing on this project and why? The document provides brief descriptions of the business problems that the deployed projects will solve. quick deployment wins Projects selected for their high-probability of success, their importance to the customer, and their ability to complete in a relatively short period of time. The Software Deployment Team (SDT) wants the customer to complete these as early as possible in deployment because they generate momentum, enthusiasm, support, and positive first impressions. quick deployment wins plan Identifies projects selected for their high-probability of success, their importance to the customer, and their ability to complete in a relatively short period of time. The plan also contains the milestones and metrics associated with the projects. Rational Unified Process (RUP) A Web-enabled set of software engineering processes that provide you with guidance to streamline your teams development activities. readiness plan Fosters proactive communications between IBM and the customer and promotes smooth deployment. It is a set of processes and work products designed to: Level set customers expectations. Assign responsibilities and ownership. Determine the customers implementation readiness. Plan transition from pre-sales to post-sales activities. Assure that customers use cases (requirements) are met. Identify risks for mitigation and escalation.
return on investment (ROI) The value that a customer receives on their investment in software, hardware, and services. Hard ROI can be quantified with dollars or numbers and is associated with headcount savings, system count reduction, server consolidation, and department closures. Soft ROI is more difficult to project and quantify, and involves perceptions and satisfaction. ROI See return on investment. rollout plan and schedule Includes all the individual plans listed in the readiness plan, with a schedule and priority attached to each activity. RUP See Rational Unified Process. SAR See Solution Assurance Review. scope creep Projects that gradually extend beyond their original charters and add functions that require software that was not in the original contract. SDA See Software Deployment Architect. SDM See Software Deployment Method. SDT See Software Deployment Team. service level agreements A contract between the customer and their users for providing availability, capacity, scalability, performance, and security of the system. services requirements document A work product that lists the services that the Software Deployment Team believes the customer will need during deployment because they are critical to deployment success. The deployment team identifies these requirements during the preparation phase of deployment, reviews them with the customer, and hopefully convinces the customer to purchase them. software demand gap analysis A listing of products that is burned by defined projects and products that have yet to be linked to planned projects (the latter is called potential shelfware). The unlinked products constitute the gap.
148
software deployment Putting software into use or action. Achieving deployment success requires that the customers implement the software license on each endpoint and that they use this software to overcome challenges, achieve their IT goals, and gain a competitive advantage. Software Deployment Architect (SDA) Accelerates deployment of software solutions and designs additional technical solutions that leverage the entire IBM Software portfolio to resolve a customers business and IT challenges. The SDA should assume the role of trusted advisor to the customer. They should leverage this relationship to identify and design solutions that satisfy software purchased inside and outside the Enterprise Agreement. The SDA is key to customer satisfaction because they ensure that the customer realizes value from the EA. Since a multitude of projects and activities surround an EA, the SDA provides a single point of contact for EA-related questions and issues. Software Deployment Method (SDM) A recommended 3-phase, 11-activity process that a Software Deployment Team should follow when deploying software in an Enterprise Agreement environment. Ideally, the first phase and activity of SDM should begin when the possibility of the contract being signed is at approximately 80%. software deployment milestones and metrics The critical checkpoints and measures that the Software Deployment Team defines with the customer and then follows closely to help ensure that deployment progress is on track. Software Deployment Team (SDT) The individuals responsible for deployment success. This team should consist of: EBS SSR SDA, SWITA, or both IT Specialists from the brands Services representative(s) (IBM Global Services, Brand, Education, Support, etc.)
Software Group Team (SWG Team) Consists of the Software Sales Representative, the Software IT Architect, the Software Deployment Architect, the Specialist Software Sales Representative (SSSR), and the Software IT Specialists. Software IT Architect (SWITA) Designs comprehensive technical solutions that solve the customers business and IT challenges while maximizing IBM Software revenue. Software IT Architects are valued because they first listen to the customer and then analyze the customers business and IT challenges. They then design a comprehensive solution that integrates smoothly into the customers context, and that leverages the best of the entire IBM Software portfolio. Software IT Specialist (ITS) Advocates IBM products to technical decision makers. The ITS can create new revenue opportunity, champion brand image, and position IBM as the leader in providing software solutions that meet the customers technical challenges. The ITS also provides a bridge between the customers technical challenges and potential product solutions. Software Sales Representative (SSR) Sells IBM Software in selected large accounts or Small and Medium Business (SMB) territories and builds customer relationships. The SSR, along with the SWITA and SDA, have cross-brand responsibility, so they have overall responsibility for selling and customer success across the entire IBM Software Group (SWG) portfolio. SSRs are involved early because they work with the brand Specialist Software Sales Representatives, the Software IT Specialists, and the Software IT Architects to define and qualify an opportunity. Each SSR provides a single sales face to the customer across all the software brands in their assigned accounts. Solution Assurance Review (SAR) Minimizes deployment risk. Used to review solutions proposed to the customer during the selling or deployment phases of the EA. Ensures that the proposed solution delivers the features expected and that the solution is technically possible to implement.
Glossary
149
Specialist Software Sales Representative (SSSR) Sells a particular set of IBM Software and works with SSRs, Software IT Specialists, and Software IT Architects in doing so. They have knowledge of IBM strategies and directions for the products they represent. They are responsible for closing the sale and positively impacting the customers satisfaction with the engagement and offerings. SSR See Software Sales Representative. SSSR See Specialist Software Sales Representative. support plan Addresses how IBM will deliver support to the customer and how the customer will support their users during deployment. SWG Team See Software Group Team. SWITA See Software IT Architect. system context diagram Helps to clarify the environment on which the solution will operate. This diagram documents all connections between the proposed system and external systems and components. Associated with each connection are various attributes such as data description, protocol, formats, frequency, volume, model of interaction (synchronous, asynchronous), etc. This context constrains the proposed system with regard to the interfaces that must be implemented. The system context diagram may provide a rationale for a make or break decision on whether to go forward. systems management plan A comprehensive plan that documents the customers change and configuration management plan, security management plan, problem management plan, and who is responsible for solution uptime during deployment.
use cases A work product that specifies customer requirements in the areas of performance, capacity/volumes, scalability, availability, portability, maintainability, usability, systems management, security, infrastructure constraints, technology standards constraints, and geographic/configuration constraints. Value Realization Model (VRM) A software deployment work product that ensures that IBM and the customer fully understand how the customer plans to measure deployment success. viability assessment This work product describes architectural risks, prioritizes (high, medium, and low) the probability and impact of each, and identifies contingency plans for each risk item. vision statements The long-term objectives of the company. They articulate the companys target marketplace, products and services, and the position the company wants their products and services to have in the targeted marketplace, as well as the financial position (revenue, profit, etc.). VRM See Value Realization Model.
150
Related publications
The publications listed in this section are considered particularly suitable for a more detailed discussion of the topics covered in this redbook.
Online resources
These Web sites and URLs are also relevant as further information sources: Instant messaging, Web conferencing, and team workplace tools
http://www-3.ibm.com/software/collaboration
Problem management self help and support

http://www.ibm.com/support
Passport Advantage http://www.lotus.com/services/passport.nsf/WebDocs/ Passport_Advantage_Home Education http://www-3.ibm.com/services/learning/training_cat.html IBM Tivoli License Manager Intelligent software license management to help optimize business value ftp://ftp.software.ibm.com/software/tivoli/whitepapers/ wp-license-mgr.pdf
How to get IBM Redbooks

You can search for, view, or download Redbooks, Redpapers, Hints and Tips, draft publications and Additional materials, as well as order hardcopy Redbooks or CD-ROMs, at this Web site:
ibm.com/redbooks
151
Help from IBM

IBM Support and downloads
ibm.com/support
IBM Global Services

ibm.com/services
152
Index
A
account planning 98 Achieve the quick deployment wins 61 ADD (architecture decisions document) 94 analyze the software in your inventory 46 analyzing ROI 38 architecture decisions document (ADD) 94 architecture overview diagram 94 Architecture plan 99 architecture plan 100 business goals 95 IT environment 95 organization 95
D
department closure 35 deploy software 59 deployment kickoff meeting 30 Deployment Milestone Status Report 97 deployment plan 98, 100 deployment quick-win plan 98 deployment services 91 Develop a high-level deployment plan 47 documentation review tips 46
B
best practice 10, 23 centralize software fulfillment 26 commit to self-sufficiency 29 communicate and market the vision 30 define a time-to-value and ROI strategy 30 determine your deployment readiness 28 hire deployment services 28 identify an EBS and stakeholders 25 implement a license management tool and process 27 business context diagram and description 94 business goals 95 buying decision 34
E
Easy Access Portal 88 Easy access portals 88 education 91 education and skills plan 99 Enterprise Business Sponsor 16 entitlement 89 Establish the deployment partnership 49 example architecture decisions document 100 architecture overview 102 business context diagram 103 component flow model 106 component model 104 current business organization 111 current IT environments 106 current IT standard 114 envisioned goals and issues 112 mapping business initiatives to projects 116 mapping projects to proposed products and solutions 117 non-functional requirements 118 operational model 120 project description 121 system context diagram 122 systems context diagrams for an integration architecture 123 use cases 125
C
centralize software fulfillment 26 CITA (Client IT Architect) 19 Client Executive 19 Client IT Architect (CITA) 19 Client Representative 19 Client Team 18 communication plan 99 Communication tools 87 component model 94 Conduct the initial deployment kickoff meeting 56 conduct the initial deployment kickoff meeting 56 coverage model 76 Create the SDT 42 critical success factors 95 customer
153
viability assessment 127 Execute the deployment plan 63
L
license acquisition 89 license management 85 License Utilization Report 97 local site 78 tertiary, on-demand coverage 78
F
Finalize the deployment plan 54 full-time coverage 74
G
Gap Analysis Report 97 global deployment activities 78 checklist 76 coverage example 80 global level activities 77 Global Project Lead (GPL) 17 global software deployment 73 checklist 139 projects 73 global support needs 46 goals and milestones 97
M
managing at the milestone level 71 managing global software deployment projects 73 managing software deployment projects 67 getting started 69 managing the success of your first project 70 Milestone status report 99 mission statement 95 My Software Center 88
N
non-functional requirements 96
H
hard (tangible) ROI 35 hard ROI 30, 35, 37 headcount savings 35 high-level deployment plan 99
O
on demand coverage 75 operational model 96 operations plan 100 organization 95
I
IBM Client Executive 19 IBM Client IT Architect (CITA) 19 IBM Client Representative 19 IBM Client Team 18 IBM Software IT Architect (SWITA) 20 IBM Software IT Specialist (ITS) 22 IBM Software Sales Representative (SSR) 20 IBM Software Team 19 IBM Specialty Software Sales Representative (SSSR) 20 IBM Tivoli License Manager (ITLM) 86 Identify new business needs 64 inexperienced project leader 72 Instant messaging 87 internal team 16 IT environment 95 IT standards 96 ITS (IBM Software IT Specialist) 22
P
part-time coverage 74 Passport Advantage 89 Phase 0, Prepare for deployment 41 Phase 1, Refine and promote the plan 51 Phase 2, Deploy software 59 potential shelfware 97 Premium support 90 Prepare for deployment 41 primary site 74 primary, full-time coverage 77 Problem management 89 process tables 31 project controls 99 project descriptions 96 project lead 16 project management challenges 71 Project Planning 98 project success 70 project timing 69
154
R
readiness plan 28, 99 overview 11 realizing value with hard and soft ROI 37 Redbooks Web site 151 Contact us xv Refine and promote the plan 51 Refine the deployment plan 52 responsibilities 15 return on investment (ROI) 35 Review the deployment documentation 44 risks and dependencies 100 ROI (return on investment) 35 current value example 39 ROI/ROR Status Report 98 roles 15
S
SAR (Solution Assurance Review) 11 scope creep 71 SDT (Software Deployment Team) 4 secondary site 74 secondary, part-time coverage 78 Self-help 89 server consolidation 35 soft (intangible) ROI 36 soft ROI 30, 35, 37 software deployment 1 best practices 10, 23 challenges 3 checklist 129 continuous process 8 Phase 0, Preparing for deployment 41 Phase 1, Refine and promote the plan 51 Phase 2, Deploy software 59 tools 83 Software Deployment Method 4 Software Deployment Method (SDM) 5 software deployment resources 83 Software Deployment Team (SDT) 4 Software deployment workshop 31 software gap 7 Software IT Architect (SWITA) 20 Software IT Specialist (ITS) 22 software maintenance via Passport Advantage 89 Software Sales Representative (SSR) 20 software solution work products 93 Software Team 19
Solution Assurance Review (SAR) 11 Specialty Software Sales Representative (SSSR) 20 sponsor 16 stakeholder 16 status of maintenance and support 46 Step 0 benefits 43 Create the Software Deployment Team (SDT) 42 inputs, tasks, and outputs 43 owners and participants 43 Step 1 benefits 45 inputs, tasks, and outputs 44 owners and participants 44 Review the deployment documentation 44 Step 10 benefits 66 inputs, tasks, and outputs 66 owners and participants 66 Update the business plan 65 Step 2 benefits 48 Develop a high-level deployment plan 47 inputs, tasks, and outputs 48 owners and participants 48 Step 3 benefits 50 Establish the deployment partnership 49 inputs, tasks, and outputs 50 owners and participants 49 Step 4 benefits 54 inputs, tasks and outputs 53 owners and participants 53 Refine the deployment plan 52 Step 5 benefits 55 Finalize the deployment plan 54 inputs, tasks, and outputs 55 owners and participants 55 Step 6 benefits 58 Conduct the initial deployment kickoff meeting 56 inputs, tasks, and outputs 57 owners and participants 56 Step 7
Index
155
Achieve the quick deployment wins 61 benefits 62 inputs, tasks, and outputs 61 owners and participants 61 Step 8 benefit 64 Execute the deployment plan 63 inputs, tasks, and outputs 63 owners and participants 63 Step 9 benefits 65 Identify new business needs 64 inputs, tasks, and outputs 65 owners and participants 65 substitution clauses 46 support, education, and tools 83 system context diagram 96 system count reduction 35
operational model 96 project descriptions 96 system context diagram 96 use cases 97 viability assessment 97 Work product examples 100 Work products used by SDM 94
T
Team IBM 17 team workplaces 87 tertiary site 75 Tivoli License Management 147
U
Update the business plan 65 use cases 97
V
value realization 33 Value Realization Model (VRM) 97 value statement 34 value timeline 34 viability assessment 97 vision statement 95
W
Web conferencing 87 why have a Software Deployment Method 4 work product architecture decisions document 94 component model 94 customers IT environment 95 customers organization 95 goals and issues 95 IT standards 96
156
Back cover
The Software Deployment Mystery - Solved

A Customer Guide
Reveals best practices and methods proven to drive deployment success Offers actual customer experience as a guide Helps make the most of your relationship with IBM
To solve any mystery, detectives rely on their experience along with proven tools and techniques to unravel the conundrum. This IBM Redbook addresses the often illusive mystery known as software deployment success. The information, practices, and methods presented in this book have enabled many IBM customers to achieve their business and IT goals more quickly and efficiently. IBM has accumulated a wealth of knowledge and experience in software deployment. The technologies we have developed, the best practices we have authored, and the employees we have cultivated are our greatest assets. Like a detective explaining how the mystery was solved, we use this redbook to pass on to youour customersthe experience, knowledge, and wisdom we have accumulated after years of solving software deployment mysteries. The primary audience for this redbook is the person who has ultimate ownership for software deployment performance. We refer to this person as the Enterprise Business Sponsor (EBS). Secondary audiences include anyone who is engaged in software deployment activities. Both audiences benefit from the practices and procedures described.
INTERNATIONAL TECHNICAL SUPPORT ORGANIZATION
BUILDING TECHNICAL INFORMATION BASED ON PRACTICAL EXPERIENCE IBM Redbooks are developed by the IBM International Technical Support Organization. Experts from IBM, Customers and Partners from around the world create timely technical information based on realistic scenarios. Specific recommendations are provided to help you implement IT solutions more effectively in your environment.
For more information: ibm.com/redbooks

SG24-6070-02 ISBN 0738491284

IBM Software Deployment 20131030 PDF

Uploaded by

Copyright:

Available Formats

IBM Software Deployment 20131030 PDF

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

IBM Software Deployment 20131030 PDF

Uploaded by

Copyright:

Available Formats

Front cover

The Software Deployment Mystery - Solved d

Sandor Hasznos Carolyn Hungate Calvin Lawrence Fernando Zuliani

Copyright IBM Corp. 2003, 2004. All rights reserved.

The Software Deployment Mystery - Solved - A Customer Guide

The Software Deployment Mystery - Solved - A Customer Guide

The Software Deployment Mystery - Solved - A Customer Guide

Copyright IBM Corp. 2003, 2004. All rights reserved.

The Software Deployment Mystery - Solved - A Customer Guide

Copyright IBM Corp. 2003, 2004. All rights reserved.

The team that wrote this redbook

The Software Deployment Mystery - Solved - A Customer Guide

Become a published author

The Software Deployment Mystery - Solved - A Customer Guide

Send your comments in an Internet note to:

The Software Deployment Mystery - Solved - A Customer Guide

Why focus on software deployment

Copyright IBM Corp. 2003, 2004. All rights reserved.

The Software Deployment Mystery - Solved - A Customer Guide

1.1 What makes software deployment so difficult

Chapter 1. Why focus on software deployment

1.2 Why have a Software Deployment Method

1.3 The Software Deployment Team

The Software Deployment Mystery - Solved - A Customer Guide

1.4 The Software Deployment Method

Step 2: Develop High-Level Deployment Plan

Step 3: Establish Deployment Partnership

Step 6: Conduct Deployment Kickoff

Step 9: Identify New Business Needs

Step 10: Update Business Plan

Refine and Promote

Figure 1-1 Overview of the Software Deployment Method

1.4.1 Phase 0: Prepare for deployment

Chapter 1. Why focus on software deployment

Step 2. Develop a high-level deployment plan: The purpose of this step is to

Step 3. Establish a deployment partnership: This step involves holding a

1.4.2 Phase 1: Refine and promote the plan

The Software Deployment Mystery - Solved - A Customer Guide

Step 6. Conduct deployment kickoff meetings: The purpose of this step is to

1.4.3 Phase 2: Deploy software

Step 7. Achieve quick deployment wins: The purpose of this step is to

Chapter 1. Why focus on software deployment

1.4.4 Software deployment method: A continuous process

The Software Deployment Mystery - Solved - A Customer Guide

Software Deployment Method

Software Deployment Method Steps

Step 10: Purchase Software & Update Business Plan

Step 4&5: Refine & Finalize High Level Deployment Plan

Step 3: Establish Deployment Partnership with Vendor

Software Deployment Mill

Step 0: Create SW Deployment Team

Step 7: Execute Quick Deployment Wins Step 6: Kick-off & Communication

Step 2: Develop High Level Deployment Plan

Step 1: Review Contract Content & Critical Deployment Documents

Figure 1-2 Software Deployment Method cycle

Chapter 1. Why focus on software deployment

Return on Investment Timeline

1.5 Software deployment best practices

The Software Deployment Mystery - Solved - A Customer Guide