Change Management in Hybrid landscapes 2017
0 likes•382 views
The document discusses change management in hybrid landscapes, highlighting the complexity of managing multiple application and development platforms, and the necessity of standardized change management to improve operations. It emphasizes the importance of integrating development and operations (DevOps) for effective collaboration and efficient release cycles, underscoring the challenges faced in traditional SAP change processes. Additionally, it advocates for automation and leveraging existing digital resources to enhance development processes without discarding current methodologies.
Change Management in Hybrid landscapes 2017
- 1. Change Management in Hybrid Landscapes Chris Kernaghan Principal Consultant Bluefin Solutions
- 2. What are Hybrid Landscapes 2 • Multiple Location • On Premise and Cloud • Hosted and Cloud • Multiple Stack • ABAP and HCP • ABAP and SaaS • Mutliple Technology • ABAP and BI • ABAP and JAVA (PaaS) • ABAP and SaaS
- 3. The Challenge to SAP System Owners • Multiple application and development platforms • Release cycles not aligned with the business • Landscape complexity • Data quality issues • Incomplete testing 3
- 4. Why do we have Change Management • ITIL Definition • The goal of the change management process is to ensure that standardized methods and procedures are used for efficient and prompt handling of all changes, in order to minimize the impact of change-related incidents upon service quality, and consequently improve the day-to-day operations of the organization • Auditing and compliance • Legal requirement to record changes made and by whom • Record the life cycle of a system • Ability to map the functionality/implementation of a system from cradle to grave • Provide consistency • Deploying changes the same way, for example using automation • Reviewing change and measuring against standards • Increase stability • Rejecting changes which have insufficient testing evidence • Improve practice • Measuring success and failure of change requests and implementations 4
- 5. Is current Change Management going to cope • There are lots of environment management methodologies • DevOps • Lean • Agile • ITIL • No-One likes change management – but they all think it is necessary • Developers - Stifle innovation • Operations - Disrupt operations and never handed over properly • Business – Take way too long to deliver anything • Users – Rarely deliver expected outcomes 5
- 6. Culture
- 7. Onsite Onshore Offshore Agile Delivery Model Understanding the level of collaboration necessary to support story development is critical to developing a sustainable and scalable offshore Agile Delivery Model. • “Follow the sun” Agile projects are much more expensive due to productivity losses brought on by delayed and ineffective communications, lower collaboration, etc. • Distributed teams can be effective. Distributed people tend to reduce collaboration and effectiveness. • Projects in the Complete Zone require limited collaboration and can easily be sent offshore • Projects in the Complicated Zone require some collaboration and can be considered for onshore or offshore. Careful analysis is required to determine how close to complete the project is • Projects in the Complex Zone require the most collaboration and should only be considered for onshore, unless the entire team is co-located offshore, including the business SME • Projects in the Chaos Zone don’t work in any framework. The goal for these should be to get them to complex
- 8. DevOps Teams Structures 8 Different organizations need different team structures for effective Dev and Ops collaboration {Dev} {Ops}{DevOps} 2 There is so little separation between Dev and Ops that all people are highly focused on a shared purpose so much so there is no distinct or visible Operations team. Fully Shared Ops Responsibilities1 Smooth collaboration between Dev teams and Ops teams, specializing where needed, sharing where needed. Dev and Ops Collaboration 3 Designed to bring Dev and Ops closer together, ideally towards a Type 1 (Dev and Ops Collaboration), and eventually make itself obsolete. DevOps Team as an Integration Project An Ops team within Dev acts as a source of expertise about operational features, metrics, monitoring, server provisioning, etc., and does most of the communication with the Operations team. DevOps Embedded in Dev4
- 9. Why does traditional SAP Change take so long • Inter-connected modules • Multiple partners/stakeholders • Agreeing downtime • Manual testing • Unit Testing – often incomplete/bad data • Integration Testing – often not enough people or environments • UAT – often not a priority item • Compliance and Auditing 9
- 10. Typical SAP Release cycle (Traditional) 1 Release 1 Month 1 Month 2 Month 3 Hyper care UAT Testing Development Refresh Pre-Prod Regression Testing Go Live Hard Freeze Move to QAS Unit Testing Integration Testing Soft Freeze No New entries
- 11. Hybrid Release cycle 1 Month 1 Month 2 Month 3 Hyper care UAT Testing Refresh Pre-Prod Regression Testing Development Unit Testing Move to QAS Integration Testing Hyper care UAT Testing Refresh Pre-Prod Regression TestingDevelopment Unit Testing Move to QAS Integration Testing Hyper care Go Live OP Hard Freeze OP Soft Freeze Code deploy
- 14. Continuous movement • Continuous Integration • is a development practice that requires developers to integrate code into a shared repository several times a day. Each check-in is then verified by an automated build, allowing teams to detect problems early. • Continuous Delivery • is a series of practices designed to ensure that code can be rapidly and safely deployed to production by delivering every change to a production-like environment and ensuring business applications and services function as expected through rigorous automated testing. • Continuous Deployment • is the next step of continuous delivery: Every change that passes the automated tests is deployed to production automatically. Continuous deployment should be the goal of most companies that are not constrained by regulatory or other requirements. 1
- 15. Continuous Pipelines 1 Write code Write code Unit test Unit Test Transport to QAS Transport to QAS Integration Tests Application Acceptance Tests UAT Tests Deploy to PRD Deploy to PRD Post Deploy Tests Write code Unit Test Transport to QAS Application Acceptance Tests Deploy to PRD Post Deploy Tests Manual Step Automated Step Automated Process Manual Process Non-Automated pipeline Continuous Delivery pipeline Continuous Deployment pipeline
- 16. Traditional SAP landscape 1 Opentext Windows 2012 SQL Server 2012 GRC Windows 2012 SQL Server 2012 Reporting Ad-hoc reporting using Live office & web Intelligence BObj General Ledger Payroll Controlling AP/AR Archiving Data services Extract Transform Load (ETL) Integration engine User Presentation layer SAP PI Solution Mgr. BW 7.4 Windows 2012 PI 7.4 Windows 2012 SQL Server 2012 NW Portal 7.4 Windows 2012 SQL Server 2012 Business Objects 4 & Data Services Windows 2012 SQL Server 2012 Business object explorer Dashboard and Web intelligence TREX 7.10 Windows 2012 Solution Manager 7.1 SPS 9 Windows 2012 SQL Server 2012 Business Objects 4.1 Windows 2012 SQL Server 2012 SAP ECC 6 EhP 7 Windows 2012 SQL Server 2012 SAP Portal BOds BW on HANA BObj OpenText TREX Compliance Risk identification/ management BW GRC ECC MDM NW 7.4 ABAP MDM Windows 2012 SQL Server 2012 SAP Web Dispatcher NW 7.4 Windows 2012 NW CE NW CE 7.2 Windows 2012 SQL Server 2012 HP Quality Centre NW 7.4 Windows 2012 SQL Server 2012 Centralised Testing and Defect management SUP Relay Server Reverse Proxy SAP SUP Sybase Unwired Platform 2.3 Windows 2012 SQL Server 2012 DMZ
- 17. Hybrid Architecture 1 AWS SuccessFactors Ariba SAP Hana Cloud Platform S4 Landscape Customer DMZ HANA DB/CI Application Server(s) Gateway/Fiori Server SLT Server PI Server User Internal Network Other SAP systems Non-SAP systems SAP Cloud Connector SAP Data Services B.Obj App tier B.Obj Database Hadoop Master Hadoop Node1 Hadoop Node2 Hadoop Node3 S3 Storage PaaS Dev Support
- 18. Change Management Technologies • SAP CTS+ • A change management system from SAP to be envied • Business Objects Promotion Management • A highly flexible tool • SAP HANA Transports • A transport mechanism which is not SAP Dependent • SAP NWDI (Prior to CTS+) • A horrific implementation which was usually underspeced • PaaS Platforms – SAP HCP • Lots of new an exciting tools and processes 1
- 19. Hybrid Architecture with Support Systems 1 Non-SAP Development Support GitHub SuccessFactors Ariba SAP Hana Cloud Platform S4 Landscape Customer DMZ HANA DB/CI Application Server(s) Gateway/Fiori Server PI Server User Jenkins SAP Cloud Connector SAP Data Services B.Obj App tier B.Obj Database Selenium Web driver CucumberChef/Puppet
- 20. Example process flow for HCP developments 2 GitHub SAP Hana Cloud Platform S4 Landscape Customer DMZ HANA DB/CI Infrastructure Config Manager Gateway/Fiori Server Developer SAP Cloud Connector Jenkins Git Repo 1 2 Cucumber Build Artifacts User Application Server 3 4 3 5 6 6
- 21. Infrastructure Management • Most infrastructure can be managed via either a Management Console or an 2 How to manage Infrastructure which is often outside formal control or uses technology which falls outside the experience of your staff Old World • Plan and document each server • Manually build the Application stack • Manually monitor and check the landscape • Implement a change process to reduce changes • Deal with issues reactively New World • Plan and document each server • Define the server in code and deploy for automated build • Server automatically integrated into monitoring framework during build • Configuration management software monitors configuration against build scripts • Automated Notification of violations/issues
- 22. Code Management 2 Old ABAP/JAVA World • Single Code line for each application • Standard editor • Automated build/compile process upon commit • Single code repository • Limited sharing of code • Abstraction of change making it difficult to see objects in change • Difficult to merge to trunk across different environments New ABAP/JAVA/HCP World • External repositories (Github) • Multiple editors – SE80, WebIDE, Eclipse • Automated build processes • Increased code sharing capability • Requirement for additional tools to provide more complete processes • New tools to SAP ecosystem • Multiple code lines and applications to be managed – object locking • Merge to trunk can be a nightmare In today’s world of multiple SAP environments, a change and release tools should be considered. The ability to inspect changes and evaluate for pre-requisites, version conflicts and limited testing is invaluable with project timelines.
- 23. Build Management and Automated testing 2 Old ABAP/JAVA World • Automated build process (Activation/NWDI) • Single toolset to fit all • 3rd Party automated testing – rarely used • Configurable deployment – rarely used • Single stream actions • Abstraction of change making it difficult to see objects in change • Configurable alerting of steps – rarely used New ABAP/JAVA/HCP World • OpenSource web testing frameworks available • Need to build an integrated deployment process • Multiple stream actions • Multiple toolsets • Easy to see object level changes with right tools • Configurable alerts used heavily • Automated deployment used heavily
- 24. Hybrid Release cycle 2 Month 1 Month 2 Month 3 Hyper care UAT Testing Refresh Pre-Prod Regression Testing Development Unit Testing Move to QAS Integration Testing Hyper care UAT Testing Refresh Pre-Prod Regression TestingDevelopment Unit Testing Move to QAS Integration Testing Hyper care Go Live OP Hard Freeze OP Soft Freeze Code deploy
- 25. The art of the possible • Everything as Code • Software defined (SD) networks • SD Storage • SD Servers and OS configuration • Ability to have two different cadences of change • Multiple code deploys for applications with single SAP Releases • Use of configuration management tools to keep landscapes in sync and monitor them • Faster development of discrete applications • Higher degrees of automation increases velocity • Limiting development to standard exposed On-Premise functions enables faster testing 2
- 26. Conclusion – Call to action • Leverage your existing digital resources internally to learn about how to do this type of development • Do not throw out your existing processes – enhance them • Trust your developers • Share code and experiences with peer groups • Introduce Peer Review to your change process • Implement higher degrees of automation to your processes – you don’t need really expensive license heavy tools in an UI5/Fiori/Dynpro/HTMGui world 2
- 28. How to Connect with Me E: [email protected] M: +61 xxxxx xxxx P: +61 x xxxx xxxx Li: linkedin.com/in/myname/ @twitterhandle
Editor's Notes
- #15: Continuous Integration is easy in SAP as it’s a single code repository Continuous Delivery – when doing automated delivery every change made goes into production, even breaks and fixes Continuous Deployment