Vincent B. Goldsmith, PMP, CSM, profile picture
Uploaded byVincent B. Goldsmith, PMP, CSM
PPTX, PDF2,134 views

PMI Presentation2

The document discusses key considerations for planning a system migration project. It emphasizes the importance of understanding business and technical drivers, analyzing the legacy system portfolio to determine the best path forward for each application, recovering accurate requirements, and developing a business architecture to guide the technical architecture. Planning outputs include defining the migration scope, schedule, and updating various project management plans.

Embed presentation

Downloaded 79 times
Project Planning for System Migrations Vincent Goldsmith, PMP, CSM
Agenda  Introduction  Migration Goals  Drivers  Portfolio Analysis  Requirement Recovery  Business Architecture  Target Architecture  System Design  Migration Paths  Implementation  Risk Mitigation  Stakeholder Buy-in  Conclusion
Introduction • 25 years project management experience • 15 years in IT • Senior Project Manager with GDIT • Currently assigned to a CMS Pay-for- Performance Healthcare Project (representative current and past clients and associations shown)
PMBOK Alignment Initiating Planning Executing Monitoring and Controlling Closing Integration Scope Time Cost Quality Human Resource Communications Risk Procurement Stakeholder
What is System Migration? It is the transferring of IT resources to a newer hardware infrastructure or software platform for the purpose of keeping up with current technologies and/or to gain better business value in the long run.
Why This Is Important • A lot of IT development is improving an existing system, usually resulting in the adoption of new software or hardware technologies (e.g. migration). • Examples of IT Migrations: – Cloud Migrations (SaaS, IaaS, PaaS, etc.) – Service Oriented Architecture (SOA) – Open Source to Custom Code (or back again) – Operating Systems – Data migrations
Why This Is Important • IT Migrations are complicated because of the following: – Differences in source and target architectures – Known and unknown dependencies – Undocumented requirements – Impact to business operations – Applications are rarely portable across different technologies – Developers and/or users are not trained in new technologies – Non-routine processes and procedures (reengineering doesn’t happen every day) Project planning is important because IT projects are hard enough without these complications….
70% of organizations have suffered at least one project failure in the prior 12 months – KPMG (2010) 60% of projects failed to meet schedule, budget and quality goals – IBM (2008) 37% of business process change projects fail to deliver benefits – Logica (2008) 38% of data migration projects fail – Computer Business Review (2013) GAO: $10 billion worth of current federal IT contracts could fail – Washington Post (2014) 17 percent of large IT projects go so badly that they can threaten the very existence of the company – McKinsey & Company (2012) Why This Is Important From people who have studied this stuff…
Excuses – Excuses - Excuses • “If managing technology pays your mortgage, you usually explain away those failures by pointing to your gray world: gray requirements, gray resources, gray planning, gray risks. The only vibrant color in your life is the brilliant hue of overly optimistic project scheduling.” – “Why Tech Projects Fails, 5 Unspoken Reasons”, Information Week, April 2013
We Do It To Ourselves • The biggest barriers to success are people factors IBM (2008) – Changing mindsets and attitudes – 58%. – Corporate culture – 49%. – Lack of senior management support – 32% – Underestimation of complexity listed as a factor in 35% of projects • “Fuzzy business objectives, out-of-sync stakeholders, and excessive rework” mean that 75% of project participants lack confidence that their projects will succeed from the start of the project (Geneca 2011).
We Can Do Better
Planning Goals
Goals for a Migration Project • Successful migration of applications or data to new software and hardware technologies. • Least amount of business disruption or risk to business operations. • Predictable timeline for when functionality will be migrated. • Adoption and use of migrated products and services.
Outputs of Migration Planning Scope • What applications are in scope for migration • System boundaries Schedule • Timeline for implementation • Date of completion Project Management Plan • Updates to Quality Management Plan, Risk Management Plan, Communications Plan, etc.
Scope, Schedule and Project Management Plan MIGRATIONCOMPLETE Migration Planning Framework Target Architecture Portfolio Analysis Requirement Recovery Business Architecture Implementation Migration Path Establish Baseline RETAIN REPLACE REFACTOR RETIRE REVISE REBUILD REHOST System Design Identify Drivers Road Map STAKEHOLDER BUY-IN RISK MITIGATION QUALITY ASSURANCE
Business & Technical Drivers
78% of respondents reported that the “Business is usually, or always, out of sync with project requirements” – Geneca (2011)
Main Drivers for Migration • The current system no longer performs as expected or needed. • A faster or better performing technology becomes available. • The old system becomes deprecated and support is difficult or no longer available for it. • The company is taking a change in direction. • Cost of development or support.
Other Considerations • Migration is sometimes driven by IT management and not business management, but that doesn’t mean the business needs shouldn’t be addressed. • Analyzing drivers may uncover business reasons that will end-up driving your strategy or schedule: – security concerns, capacity or performance concerns, data quality concerns, compliance reasons, new business initiatives that can’t be accomplished in the legacy architecture • Reasons to migrate can be both business or technical in nature.
Perceived Benefits Perceived Benefit (example) Business Technical Rapid Time to Market X X Deliver New Capabilities X X Modernize Applications X Accommodate Scalability X Free-up Data Space X Operational Efficiencies X Provide Access to More Users X Improve Performance X X Better Data X Improve Security X X Leverage existing investments X X
Other Considerations • Fully understanding the business drivers allows you do the following: – Establish a timeline acceptable to the business that accommodates their schedules and deadlines – Prioritize functionality or applications that need to be migrated (scope) – Form a plan for the migration that minimizes business risk while maximizing business value
Drivers are not Static • They need to be revisited throughout the migration process to determine if they are still relevant or if benefits are being realized. • All the analysis and decisions that follow should be assessed as compared to the drivers.
Legacy System Analysis
Legacy Systems They represent: • Huge Investment • Baseline for Future Functionality
Portfolio Analysis All applications are reviewed by representatives of the business and technical teams and judged according to the following: • Functional Value • Technical Value Qualitative judgments are given quantitative values and a weighted score is calculated for each application. Applications are reviewed and a decision is made on the prospects of the applications. Return-on-Investment (ROI) should be calculated and evaluated against the cost of migration.
Functional Analysis Evaluate Legacy Systems to see if they meet the needs of the business (examples): • Business Need/Functionality (don’t migrate what you can eliminate) • Business efficiency or workflow automation • Performance • Usability • Strategic Fit
Technical Analysis Evaluate Legacy Systems to see if they meet the needs of the people supporting the technology (examples): • Technical Maturity • Technical Debt • Data Dependencies • Architecture • Portability • Reliability • Interoperability • Cost of development and support
Legacy Data Issues Evaluate Legacy Systems for data quality issues (examples): • Bad data in legacy system • Duplicate data in legacy system • Unknown or unenforced archiving policies • Upstream data dependencies or third-party data needs
Possible Decision Outcomes Decision Definition Retain No changes made to application Replace Discard existing application and replace with COTS Refactor Making application or configuration changes to upgrade application without changing functionality Retire The functionality of the application is no longer needed by the business. Revise Extending existing legacy application functionality to accommodate business needs Rebuild Completely rebuilding the application with a brand new architecture Rehost Deploy applications to a different hardware environment and/or changing the infrastructure
Legacy Portfolio Analysis Application Portfolio Decision Analysis FUNCTIONALVALUE TECHNICAL VALUE RETAIN REBUILD REFACTOR RETIRE REVISE REPLACE REHOST
Requirement Recovery
Undocumented Requirements • Incomplete requirement documentation is an issue in legacy systems migrations. • Unclear requirements are one of the contributing factors to IT project failures, so it is important to document all of the business requirements. • Business requirements should be further broken down into functional and non-functional requirements and/or technical and functional specifications. • Legacy requirements may change depending on the outcome of the Portfolio Analysis.
Sources of Requirements • Re-elicit requirements • Reverse engineer existing applications by reviewing code • Review Business Architecture and BPMNs • Review training materials, user guides, release notes for info • Review test cases if available • Analyze inputs and outputs
Requirement Management Still Applies • Have a requirements management plan • Requirements should describe functionality and outcomes, not technical implementation • Requirements and associated documents should be kept under change management • Maintain clear traceability of requirements • Strive for enterprise-wide requirements as opposed to application-specific requirements
More Info There is an abundance of scholarly papers on how to elicit, derive, and represent user requirements, including: • Semantic Analysis • Analyst Constrained Language (ACL) • Norm Analysis • Etc.
Business Architecture
Business Architecture • Business architecture defines how the enterprise needs to operate in order to achieve business objectives. • It is the first architecture activity that takes place. • The existing business architecture is usually defined within the legacy system. • It should be verified, analyzed, and updated as necessary. • Business processes not being brought forward into the new system should be removed.
TOGAF Business Architecture Steps (The Open Group Architecture Framework) 1. Select Reference Models, Viewpoints, and Tools 2. Develop Baseline Business Architecture Description 3. Develop Target Business Architecture Description 4. Perform Gap Analysis 5. Define Candidate Roadmap Components 6. Resolve Impacts Across the Architecture Landscape 7. Conduct Formal Stakeholder Review 8. Finalize the Business Architecture 9. Create Architecture Definition Document
Other Considerations • Value engineering and possible cost-cutting should be made part of the process. • Validate and redefine business rules. • Identify cross-process dependencies. • Identify inputs & outputs of the system boundaries within the business architecture. • Adhere to standards and governance.
Outputs of Defining the Business Architecture The following diagrams should be considered as possible outputs of the Business Architecture process (more from Togaf-modeling.org): • Business Footprint diagram • Business Service/Information diagram • Functional Decomposition diagram • Goal/Objective/Service diagram • Use-case diagram • Organization Decomposition diagram • Process Flow diagram • Events diagram
Business Footprint Diagram Provides a clear traceability between a technical component and the business goal that it satisfies, while also demonstrating ownership of the services identified. Source: togaf-modeling.org
Functional Decomposition Diagram Shows on a single page the capabilities of an organization that are relevant to the consideration of an architecture. Source: togaf-modeling.org
Target Architecture
Target Architecture • It serves as the overall framework for the solution architecture. • It is the formal documentation of the desired future vision - defining and validating future requirements and the optimization of opportunities. Additionally… • It is the high level plan for the relationship between business and application systems. • It defines the relationship between business and information. • It describes the relationship between business and technologies.
Describing the Target Architecture • Data Standards: – Coding and values for data – Structures and formats for data – Ownership of data – Restrictions on access • Applications Standards: – Standard/shared applications and services that support specific business functions – Application communication, interfaces and interoperation – Access, presentation, and style • Technology Standards; – Hardware product standards – Software product standards – Software development standards
Creating the Target Architecture (example process) Source: A Practical Guide to Federal Enterprise Architecture
System Design
System Design System design is the complete set of documents necessary to implement the applications. Documents can include: • Data Models • Interface Control Documents • Configuration Documents • System Implementation Plans
System Design • Trace technical solutions at the component level to requirements. • Design the system so it can be implemented iteratively to accommodate your migration path. • There might not be a one-to-one relationship between new components and legacy components. • Review performance and security issues that may arise between new and existing applications and architectures. • Enforce standards and change control with new system designs.
System Design • Design for common shared elements when possible. • Have a preferred mechanism for common capabilities (build these first): – Authorization – Communication/email – Synchronization – Error handling – Event logging, etc.
Design for Incremental Migration • Changes in protocols or database formats should accommodate existing data, applications and devices in order to be backward compatible. • Wrapping existing applications with new APIs can facilitate incremental migration while allowing for backward compatibility.
Migration Paths
Transition Architecture: “In Flight” • When choosing a migration path there are three basic strategies: – a completely new implementation. – a radical “all or nothing” change (i.e., switch on, switch off). – a phased approach to introduce new capabilities with parallel legacy and migration systems running simultaneously. • Of these, a phased approach is the lowest risk method and allows for easy and quick wins to prove the migration will work.
“As Is” System UI Business Logic Data UI Business Logic Data UI Business Logic Data UI Business Logic Data UI Domain Business Domain(s) Data
“To Be” System UI Business Logic Data Business Logic Business Logic Business Logic UI Domain Business Domain(s) Data Cloud Big Data Appliance
Iterative System “In Flight” Option: Migrate by App UI Business Logic Data UI Business Logic Data UI Business Logic UI Business Logic Data UI Domain Business Domain(s) Data Cloud
Iterative System “In Flight” Option: Migrate UI Business Logic Data Business Logic Data Business Logic Data Business Logic Data UI Domain Business Domain(s) Data UI
Business Domain(s) Iterative System “In Flight” Option: Migrate by Domain UI Business Logic Data UI Business Logic Data UI Business Logic Data UI Business Logic Data UI Domain Data
Iterative System “In Flight” Option: Data Migration UI Business Logic Data UI Business Logic UI Business Logic UI Business Logic UI Domain Business Domain(s) Data Cloud Big Data Appliance
“To Be” System UI Business Logic Data Business Logic Business Logic Business Logic UI Domain Business Domain(s) Data Cloud Big Data Appliance
Implementation
Implementation • Identify enterprise architecture and implementation priorities for development teams. • Identify deployment issues and determine corrective actions. • Pay attention to the scope of migration efforts and iterative development schedule. • Extract, clean, transform and de-duplicate the data. • If necessary prepare scripts for data, server or database migrations.
Implementation Teams • Current technical and or business SMEs have detailed knowledge critical to not just the ongoing O&M of the system, but they are also critical to the migration effort. • New technical SMEs may be needed for the development or implementation of new systems. • Implementation Teams made up of a mix of current and new technical and business resources maximize potential for success.
Implementation Team Example Application UI Developer Service Developer Database Developer Functional SME Component 1 Legacy Developer Migration Developer Legacy Developer Legacy SME Component 2 Migration Developer Legacy Developer Migration Developer Legacy SME Component 3 Migration Developer Migration Developer Migration Developer Legacy SME
Training • Training for the existing technical staff is needed so that new habits and design practices will be used when working with the new architecture.
Risk Mitigation
Risk Mitigation • Parallel environments (ongoing legacy operations and migration implementation) should be leveraged. • Establish and maintain configuration management control of the legacy system even while migrating. • There should be a separate and distinct reengineering process that doesn’t interfere with the ongoing operations of the legacy system. • When outside services are needed, carefully define and monitor their roles.
Risk Mitigation • Restrict migrations to off-hours when usage is low and won't interfere with your ongoing operations. • Maintain a clear audit trail of all data migration activitity (who, what and when). • Validate and test the data-migration process. • Don’t plan to go live in one big upload at the end – work incrementally. • Training – training – training.
D Quality
Quality Assurance • Parallel environments will allow you to compare migrated test results to baseline. • UAT testing should be done on migrated components (training will be needed). • Maintain traceability of test cases back to requirements.
Data Quality Assurance • Back-end testing is critical when migrating incrementally because you want to be able to test components as they are developed. • Testing of the migration run (ETL) should be done to make sure all three stages are functioning correctly. • Test the migrated data to ensure it's accurate and in the expected format. • If scripts are being used to migrate data, servers, etc. – the scripts should be tested thoroughly as well.
User and Developer Buy-in Stakeholder Buy-In
Stakeholder Buy-In • “75% of project participants lack confidence that their projects will succeed, even from the start of the project”
Stakeholder Buy-In • Development team and User buy-in is critical to success (many IT implementations fail due to insufficient adoption of new technology). • Provide adequate training and communication in both the technical content and the reason for the change.
Stakeholder Buy-In • Get input from legacy SMEs, Technical Staff and Users very early in the process – and ask them for their opinions. • Create a team-oriented reengineering plan. • Have a subset of users who are involved throughout the migration process. • Project and team onboarding should include an overview of the migration strategy. • Demonstrate products early and often. • Overcommunicate progress and success. • Celebrate wins early and often.
Sponsorship • The migration project should have a senior manager sponsor. • Management needs to be committed for the long haul. • Management edicts should not override technical realities.
Conclusion
Review • Work early and often to achieve and maintain stakeholder buy-in (users and technical staff) through training and communication. • Continue to revisit business and technical drivers to make sure you’re delivering value. • Develop a comprehensive strategy with achievable and measurable milestones for the project. • Deliver incremental migration.
Scope, Schedule and Project Management Plan MIGRATIONCOMPLETE Migration Planning Framework Target Architecture Portfolio Analysis Requirement Recovery Business Architecture Implementation Migration Path Establish Baseline RETAIN REPLACE REFACTOR RETIRE REVISE REBUILD REHOST System Design Identify Drivers Road Map STAKEHOLDER BUY-IN RISK MITIGATION QUALITY ASSURANCE
And Remember …We Can Do Better
More Information • Five Options for Migrating Applications to the Cloud: Rehost, Refactor, Revise, Rebuild or Replace (.pdf) – Gartner • A Practical Guide to Federal Enterprise Architecture (GAO) • The Object Management Group (OMG) • The Open Group Architectural Framework (TOGAF) • Information Technology Infrastructure Library (ITIL) • Software Engineering Institute (SEI) • Project Management Institute (PMI) • AgileModeling.com (for modeling and documentation) • Togaf-modeling.org (for modeling and documentation)
The End
Questions linkedin.com/in/VincentGoldsmith Vincent Goldsmith VinnyGoldsmith@gmail.com 301-452-7906

More Related Content

PPSX
DITA introduction
byRaghunath (Gautam) Soman
 
PPTX
Angular Best Practices To Build Clean and Performant Web Applications
byAlbiorix Technology
 
PPTX
Segmenting your Network for Security - The Good, the Bad and the Ugly
byAlgoSec
 
PDF
3d printing technology in architecture.pdf
bySaniya661779
 
PPTX
Simple and Effective Enterprise Architecture with Tools you Already Own
byChandra Knabel
 
PPT
Togaf 9 template business footprint diagram
bySandeep Sharma IIMK Smart City,IoT,Bigdata,Cloud,BI,DW
 
PPTX
Effectiveness Of Service Oriented Architecture In Enterprise Architecture F...
bymdfachowdhury
 
PPTX
Real life content migrations
byHaniel Croitoru
 
DITA introduction
byRaghunath (Gautam) Soman
 
Angular Best Practices To Build Clean and Performant Web Applications
byAlbiorix Technology
 
Segmenting your Network for Security - The Good, the Bad and the Ugly
byAlgoSec
 
3d printing technology in architecture.pdf
bySaniya661779
 
Simple and Effective Enterprise Architecture with Tools you Already Own
byChandra Knabel
 
Togaf 9 template business footprint diagram
bySandeep Sharma IIMK Smart City,IoT,Bigdata,Cloud,BI,DW
 
Effectiveness Of Service Oriented Architecture In Enterprise Architecture F...
bymdfachowdhury
 
Real life content migrations
byHaniel Croitoru
 

Similar to PMI Presentation2

PPT
Migration Strategies & Methodologies
bySaqib Raza
 
PDF
898975372-Leaving-Legacy-Software-Behind-a-Modern-Migration-Roadmap.pdf
byKsoft Technologies
 
PPTX
Navigating Complexity: A Practical Guide to Successful Legacy to Cloud Migration
byAnsibytecode LLP
 
PDF
Migration Decoded
byCognizant
 
PPT
What do I know about my customers?
byDataValueTalk
 
PDF
Application Migration for Business Growth
byShiv Technolabs Pvt. Ltd.
 
PPTX
Systems Migration
byrichchihlee
 
PDF
App Migration Services for Modern Businesses
byShiv Technolabs Pvt. Ltd.
 
PDF
A guide to successful payment switch migrations
byOpus Consulting Solutions
 
PDF
A Guide to Successful Application Modernization through Data Migration Services
byAndrew Leo
 
PDF
Legacy system migration
byRosemaryGeorge6
 
PDF
Legacy Application Migration
byRosemaryGeorge6
 
PDF
Application Modernization Roadmap
byJones Adams
 
PDF
Too Damn Old: Convincing the Business it’s Time to Upgrade Your Geriatric App...
byAll Things Open
 
PDF
Application Migration - What, When, Why, How?
byAjit Kumar
 
PDF
Maximizing ROI with Legacy Application Migration
byMindfire LLC
 
PDF
How to Migrate Without Downtime
byEnvision Technology Advisors
 
PDF
Four Essential Steps for Removing Risk and Downtime from POWER9 Migration
byPrecisely
 
PDF
Anytime a user can’t access that data, there’s a cost
byLabeedAhmadQamar
 
PDF
Application Migration - What, When, Why, How?
byAjit Kumar
 
Migration Strategies & Methodologies
bySaqib Raza
 
898975372-Leaving-Legacy-Software-Behind-a-Modern-Migration-Roadmap.pdf
byKsoft Technologies
 
Navigating Complexity: A Practical Guide to Successful Legacy to Cloud Migration
byAnsibytecode LLP
 
Migration Decoded
byCognizant
 
What do I know about my customers?
byDataValueTalk
 
Application Migration for Business Growth
byShiv Technolabs Pvt. Ltd.
 
Systems Migration
byrichchihlee
 
App Migration Services for Modern Businesses
byShiv Technolabs Pvt. Ltd.
 
A guide to successful payment switch migrations
byOpus Consulting Solutions
 
A Guide to Successful Application Modernization through Data Migration Services
byAndrew Leo
 
Legacy system migration
byRosemaryGeorge6
 
Legacy Application Migration
byRosemaryGeorge6
 
Application Modernization Roadmap
byJones Adams
 
Too Damn Old: Convincing the Business it’s Time to Upgrade Your Geriatric App...
byAll Things Open
 
Application Migration - What, When, Why, How?
byAjit Kumar
 
Maximizing ROI with Legacy Application Migration
byMindfire LLC
 
How to Migrate Without Downtime
byEnvision Technology Advisors
 
Four Essential Steps for Removing Risk and Downtime from POWER9 Migration
byPrecisely
 
Anytime a user can’t access that data, there’s a cost
byLabeedAhmadQamar
 
Application Migration - What, When, Why, How?
byAjit Kumar
 

PMI Presentation2

  • 1.
    Project Planning for SystemMigrations Vincent Goldsmith, PMP, CSM
  • 2.
    Agenda  Introduction  MigrationGoals  Drivers  Portfolio Analysis  Requirement Recovery  Business Architecture  Target Architecture  System Design  Migration Paths  Implementation  Risk Mitigation  Stakeholder Buy-in  Conclusion
  • 3.
    Introduction • 25 yearsproject management experience • 15 years in IT • Senior Project Manager with GDIT • Currently assigned to a CMS Pay-for- Performance Healthcare Project (representative current and past clients and associations shown)
  • 4.
    PMBOK Alignment Initiating PlanningExecuting Monitoring and Controlling Closing Integration Scope Time Cost Quality Human Resource Communications Risk Procurement Stakeholder
  • 5.
    What is SystemMigration? It is the transferring of IT resources to a newer hardware infrastructure or software platform for the purpose of keeping up with current technologies and/or to gain better business value in the long run.
  • 6.
    Why This IsImportant • A lot of IT development is improving an existing system, usually resulting in the adoption of new software or hardware technologies (e.g. migration). • Examples of IT Migrations: – Cloud Migrations (SaaS, IaaS, PaaS, etc.) – Service Oriented Architecture (SOA) – Open Source to Custom Code (or back again) – Operating Systems – Data migrations
  • 7.
    Why This IsImportant • IT Migrations are complicated because of the following: – Differences in source and target architectures – Known and unknown dependencies – Undocumented requirements – Impact to business operations – Applications are rarely portable across different technologies – Developers and/or users are not trained in new technologies – Non-routine processes and procedures (reengineering doesn’t happen every day) Project planning is important because IT projects are hard enough without these complications….
  • 8.
    70% of organizationshave suffered at least one project failure in the prior 12 months – KPMG (2010) 60% of projects failed to meet schedule, budget and quality goals – IBM (2008) 37% of business process change projects fail to deliver benefits – Logica (2008) 38% of data migration projects fail – Computer Business Review (2013) GAO: $10 billion worth of current federal IT contracts could fail – Washington Post (2014) 17 percent of large IT projects go so badly that they can threaten the very existence of the company – McKinsey & Company (2012) Why This Is Important From people who have studied this stuff…
  • 9.
    Excuses – Excuses- Excuses • “If managing technology pays your mortgage, you usually explain away those failures by pointing to your gray world: gray requirements, gray resources, gray planning, gray risks. The only vibrant color in your life is the brilliant hue of overly optimistic project scheduling.” – “Why Tech Projects Fails, 5 Unspoken Reasons”, Information Week, April 2013
  • 10.
    We Do ItTo Ourselves • The biggest barriers to success are people factors IBM (2008) – Changing mindsets and attitudes – 58%. – Corporate culture – 49%. – Lack of senior management support – 32% – Underestimation of complexity listed as a factor in 35% of projects • “Fuzzy business objectives, out-of-sync stakeholders, and excessive rework” mean that 75% of project participants lack confidence that their projects will succeed from the start of the project (Geneca 2011).
  • 11.
  • 12.
  • 13.
    Goals for aMigration Project • Successful migration of applications or data to new software and hardware technologies. • Least amount of business disruption or risk to business operations. • Predictable timeline for when functionality will be migrated. • Adoption and use of migrated products and services.
  • 14.
    Outputs of MigrationPlanning Scope • What applications are in scope for migration • System boundaries Schedule • Timeline for implementation • Date of completion Project Management Plan • Updates to Quality Management Plan, Risk Management Plan, Communications Plan, etc.
  • 15.
    Scope, Schedule andProject Management Plan MIGRATIONCOMPLETE Migration Planning Framework Target Architecture Portfolio Analysis Requirement Recovery Business Architecture Implementation Migration Path Establish Baseline RETAIN REPLACE REFACTOR RETIRE REVISE REBUILD REHOST System Design Identify Drivers Road Map STAKEHOLDER BUY-IN RISK MITIGATION QUALITY ASSURANCE
  • 16.
  • 17.
    78% of respondentsreported that the “Business is usually, or always, out of sync with project requirements” – Geneca (2011)
  • 18.
    Main Drivers forMigration • The current system no longer performs as expected or needed. • A faster or better performing technology becomes available. • The old system becomes deprecated and support is difficult or no longer available for it. • The company is taking a change in direction. • Cost of development or support.
  • 19.
    Other Considerations • Migrationis sometimes driven by IT management and not business management, but that doesn’t mean the business needs shouldn’t be addressed. • Analyzing drivers may uncover business reasons that will end-up driving your strategy or schedule: – security concerns, capacity or performance concerns, data quality concerns, compliance reasons, new business initiatives that can’t be accomplished in the legacy architecture • Reasons to migrate can be both business or technical in nature.
  • 20.
    Perceived Benefits Perceived Benefit(example) Business Technical Rapid Time to Market X X Deliver New Capabilities X X Modernize Applications X Accommodate Scalability X Free-up Data Space X Operational Efficiencies X Provide Access to More Users X Improve Performance X X Better Data X Improve Security X X Leverage existing investments X X
  • 21.
    Other Considerations • Fullyunderstanding the business drivers allows you do the following: – Establish a timeline acceptable to the business that accommodates their schedules and deadlines – Prioritize functionality or applications that need to be migrated (scope) – Form a plan for the migration that minimizes business risk while maximizing business value
  • 22.
    Drivers are notStatic • They need to be revisited throughout the migration process to determine if they are still relevant or if benefits are being realized. • All the analysis and decisions that follow should be assessed as compared to the drivers.
  • 23.
  • 24.
    Legacy Systems They represent: •Huge Investment • Baseline for Future Functionality
  • 25.
    Portfolio Analysis All applicationsare reviewed by representatives of the business and technical teams and judged according to the following: • Functional Value • Technical Value Qualitative judgments are given quantitative values and a weighted score is calculated for each application. Applications are reviewed and a decision is made on the prospects of the applications. Return-on-Investment (ROI) should be calculated and evaluated against the cost of migration.
  • 26.
    Functional Analysis Evaluate LegacySystems to see if they meet the needs of the business (examples): • Business Need/Functionality (don’t migrate what you can eliminate) • Business efficiency or workflow automation • Performance • Usability • Strategic Fit
  • 27.
    Technical Analysis Evaluate LegacySystems to see if they meet the needs of the people supporting the technology (examples): • Technical Maturity • Technical Debt • Data Dependencies • Architecture • Portability • Reliability • Interoperability • Cost of development and support
  • 28.
    Legacy Data Issues EvaluateLegacy Systems for data quality issues (examples): • Bad data in legacy system • Duplicate data in legacy system • Unknown or unenforced archiving policies • Upstream data dependencies or third-party data needs
  • 29.
    Possible Decision Outcomes DecisionDefinition Retain No changes made to application Replace Discard existing application and replace with COTS Refactor Making application or configuration changes to upgrade application without changing functionality Retire The functionality of the application is no longer needed by the business. Revise Extending existing legacy application functionality to accommodate business needs Rebuild Completely rebuilding the application with a brand new architecture Rehost Deploy applications to a different hardware environment and/or changing the infrastructure
  • 30.
    Legacy Portfolio Analysis ApplicationPortfolio Decision Analysis FUNCTIONALVALUE TECHNICAL VALUE RETAIN REBUILD REFACTOR RETIRE REVISE REPLACE REHOST
  • 31.
  • 32.
    Undocumented Requirements • Incompleterequirement documentation is an issue in legacy systems migrations. • Unclear requirements are one of the contributing factors to IT project failures, so it is important to document all of the business requirements. • Business requirements should be further broken down into functional and non-functional requirements and/or technical and functional specifications. • Legacy requirements may change depending on the outcome of the Portfolio Analysis.
  • 33.
    Sources of Requirements •Re-elicit requirements • Reverse engineer existing applications by reviewing code • Review Business Architecture and BPMNs • Review training materials, user guides, release notes for info • Review test cases if available • Analyze inputs and outputs
  • 34.
    Requirement Management StillApplies • Have a requirements management plan • Requirements should describe functionality and outcomes, not technical implementation • Requirements and associated documents should be kept under change management • Maintain clear traceability of requirements • Strive for enterprise-wide requirements as opposed to application-specific requirements
  • 35.
    More Info There isan abundance of scholarly papers on how to elicit, derive, and represent user requirements, including: • Semantic Analysis • Analyst Constrained Language (ACL) • Norm Analysis • Etc.
  • 36.
  • 37.
    Business Architecture • Businessarchitecture defines how the enterprise needs to operate in order to achieve business objectives. • It is the first architecture activity that takes place. • The existing business architecture is usually defined within the legacy system. • It should be verified, analyzed, and updated as necessary. • Business processes not being brought forward into the new system should be removed.
  • 38.
    TOGAF Business ArchitectureSteps (The Open Group Architecture Framework) 1. Select Reference Models, Viewpoints, and Tools 2. Develop Baseline Business Architecture Description 3. Develop Target Business Architecture Description 4. Perform Gap Analysis 5. Define Candidate Roadmap Components 6. Resolve Impacts Across the Architecture Landscape 7. Conduct Formal Stakeholder Review 8. Finalize the Business Architecture 9. Create Architecture Definition Document
  • 39.
    Other Considerations • Valueengineering and possible cost-cutting should be made part of the process. • Validate and redefine business rules. • Identify cross-process dependencies. • Identify inputs & outputs of the system boundaries within the business architecture. • Adhere to standards and governance.
  • 40.
    Outputs of Definingthe Business Architecture The following diagrams should be considered as possible outputs of the Business Architecture process (more from Togaf-modeling.org): • Business Footprint diagram • Business Service/Information diagram • Functional Decomposition diagram • Goal/Objective/Service diagram • Use-case diagram • Organization Decomposition diagram • Process Flow diagram • Events diagram
  • 41.
    Business Footprint Diagram Providesa clear traceability between a technical component and the business goal that it satisfies, while also demonstrating ownership of the services identified. Source: togaf-modeling.org
  • 42.
    Functional Decomposition Diagram Showson a single page the capabilities of an organization that are relevant to the consideration of an architecture. Source: togaf-modeling.org
  • 43.
  • 44.
    Target Architecture • Itserves as the overall framework for the solution architecture. • It is the formal documentation of the desired future vision - defining and validating future requirements and the optimization of opportunities. Additionally… • It is the high level plan for the relationship between business and application systems. • It defines the relationship between business and information. • It describes the relationship between business and technologies.
  • 45.
    Describing the TargetArchitecture • Data Standards: – Coding and values for data – Structures and formats for data – Ownership of data – Restrictions on access • Applications Standards: – Standard/shared applications and services that support specific business functions – Application communication, interfaces and interoperation – Access, presentation, and style • Technology Standards; – Hardware product standards – Software product standards – Software development standards
  • 46.
    Creating the TargetArchitecture (example process) Source: A Practical Guide to Federal Enterprise Architecture
  • 47.
  • 48.
    System Design System designis the complete set of documents necessary to implement the applications. Documents can include: • Data Models • Interface Control Documents • Configuration Documents • System Implementation Plans
  • 49.
    System Design • Tracetechnical solutions at the component level to requirements. • Design the system so it can be implemented iteratively to accommodate your migration path. • There might not be a one-to-one relationship between new components and legacy components. • Review performance and security issues that may arise between new and existing applications and architectures. • Enforce standards and change control with new system designs.
  • 50.
    System Design • Designfor common shared elements when possible. • Have a preferred mechanism for common capabilities (build these first): – Authorization – Communication/email – Synchronization – Error handling – Event logging, etc.
  • 51.
    Design for IncrementalMigration • Changes in protocols or database formats should accommodate existing data, applications and devices in order to be backward compatible. • Wrapping existing applications with new APIs can facilitate incremental migration while allowing for backward compatibility.
  • 52.
  • 53.
    Transition Architecture: “InFlight” • When choosing a migration path there are three basic strategies: – a completely new implementation. – a radical “all or nothing” change (i.e., switch on, switch off). – a phased approach to introduce new capabilities with parallel legacy and migration systems running simultaneously. • Of these, a phased approach is the lowest risk method and allows for easy and quick wins to prove the migration will work.
  • 54.
  • 55.
  • 56.
    Iterative System “In Flight”Option: Migrate by App UI Business Logic Data UI Business Logic Data UI Business Logic UI Business Logic Data UI Domain Business Domain(s) Data Cloud
  • 57.
    Iterative System “In Flight”Option: Migrate UI Business Logic Data Business Logic Data Business Logic Data Business Logic Data UI Domain Business Domain(s) Data UI
  • 58.
    Business Domain(s) Iterative System “In Flight”Option: Migrate by Domain UI Business Logic Data UI Business Logic Data UI Business Logic Data UI Business Logic Data UI Domain Data
  • 59.
    Iterative System “In Flight”Option: Data Migration UI Business Logic Data UI Business Logic UI Business Logic UI Business Logic UI Domain Business Domain(s) Data Cloud Big Data Appliance
  • 60.
  • 61.
  • 62.
    Implementation • Identify enterprisearchitecture and implementation priorities for development teams. • Identify deployment issues and determine corrective actions. • Pay attention to the scope of migration efforts and iterative development schedule. • Extract, clean, transform and de-duplicate the data. • If necessary prepare scripts for data, server or database migrations.
  • 63.
    Implementation Teams • Currenttechnical and or business SMEs have detailed knowledge critical to not just the ongoing O&M of the system, but they are also critical to the migration effort. • New technical SMEs may be needed for the development or implementation of new systems. • Implementation Teams made up of a mix of current and new technical and business resources maximize potential for success.
  • 64.
    Implementation Team Example ApplicationUI Developer Service Developer Database Developer Functional SME Component 1 Legacy Developer Migration Developer Legacy Developer Legacy SME Component 2 Migration Developer Legacy Developer Migration Developer Legacy SME Component 3 Migration Developer Migration Developer Migration Developer Legacy SME
  • 65.
    Training • Training forthe existing technical staff is needed so that new habits and design practices will be used when working with the new architecture.
  • 66.
  • 67.
    Risk Mitigation • Parallelenvironments (ongoing legacy operations and migration implementation) should be leveraged. • Establish and maintain configuration management control of the legacy system even while migrating. • There should be a separate and distinct reengineering process that doesn’t interfere with the ongoing operations of the legacy system. • When outside services are needed, carefully define and monitor their roles.
  • 68.
    Risk Mitigation • Restrictmigrations to off-hours when usage is low and won't interfere with your ongoing operations. • Maintain a clear audit trail of all data migration activitity (who, what and when). • Validate and test the data-migration process. • Don’t plan to go live in one big upload at the end – work incrementally. • Training – training – training.
  • 69.
  • 70.
    Quality Assurance • Parallelenvironments will allow you to compare migrated test results to baseline. • UAT testing should be done on migrated components (training will be needed). • Maintain traceability of test cases back to requirements.
  • 71.
    Data Quality Assurance •Back-end testing is critical when migrating incrementally because you want to be able to test components as they are developed. • Testing of the migration run (ETL) should be done to make sure all three stages are functioning correctly. • Test the migrated data to ensure it's accurate and in the expected format. • If scripts are being used to migrate data, servers, etc. – the scripts should be tested thoroughly as well.
  • 72.
    User and DeveloperBuy-in Stakeholder Buy-In
  • 73.
    Stakeholder Buy-In • “75%of project participants lack confidence that their projects will succeed, even from the start of the project”
  • 74.
    Stakeholder Buy-In • Developmentteam and User buy-in is critical to success (many IT implementations fail due to insufficient adoption of new technology). • Provide adequate training and communication in both the technical content and the reason for the change.
  • 75.
    Stakeholder Buy-In • Getinput from legacy SMEs, Technical Staff and Users very early in the process – and ask them for their opinions. • Create a team-oriented reengineering plan. • Have a subset of users who are involved throughout the migration process. • Project and team onboarding should include an overview of the migration strategy. • Demonstrate products early and often. • Overcommunicate progress and success. • Celebrate wins early and often.
  • 76.
    Sponsorship • The migrationproject should have a senior manager sponsor. • Management needs to be committed for the long haul. • Management edicts should not override technical realities.
  • 77.
  • 78.
    Review • Work earlyand often to achieve and maintain stakeholder buy-in (users and technical staff) through training and communication. • Continue to revisit business and technical drivers to make sure you’re delivering value. • Develop a comprehensive strategy with achievable and measurable milestones for the project. • Deliver incremental migration.
  • 79.
    Scope, Schedule andProject Management Plan MIGRATIONCOMPLETE Migration Planning Framework Target Architecture Portfolio Analysis Requirement Recovery Business Architecture Implementation Migration Path Establish Baseline RETAIN REPLACE REFACTOR RETIRE REVISE REBUILD REHOST System Design Identify Drivers Road Map STAKEHOLDER BUY-IN RISK MITIGATION QUALITY ASSURANCE
  • 80.
  • 81.
    More Information • FiveOptions for Migrating Applications to the Cloud: Rehost, Refactor, Revise, Rebuild or Replace (.pdf) – Gartner • A Practical Guide to Federal Enterprise Architecture (GAO) • The Object Management Group (OMG) • The Open Group Architectural Framework (TOGAF) • Information Technology Infrastructure Library (ITIL) • Software Engineering Institute (SEI) • Project Management Institute (PMI) • AgileModeling.com (for modeling and documentation) • Togaf-modeling.org (for modeling and documentation)
  • 82.
  • 83.