Governing the Control and Delivery of Change in IT

Governing the Control and Delivery of Change in IT An MKS White Paper By: Gary Guttridge Principal Change Manage IT Ltd. Page 1 of 19

1. INTRODUCTION When a business requirement passes along the application delivery life cycle and becomes a functional update to a production service for the business and customer, how many times will it have been subject to change management? How many change management systems and processes does it take to govern and control the delivery of IT changes? The simple answer is far too many, incurring unnecessary expenditure and impeding the delivery of IT function and service to our users. This paper offers a viable solution -- unified change management. 2. DEFINING THE APPLICATION LIFE CYCLE In the following picture we show the application delivery life cycle beginning with the application change arriving first as a managed business requirement and moving through analysis and design to be modeled and then developed. The basic assumption here is that the design and development is iterative, rapid -- even agile -- and is managed through some supporting development methodology. Essential parts of this supporting development methodology are several instances of change management, managing all the different aspects of requirement through to production delivery. Note that if our application development is outsourced or we run our business on applications supplied by an ERP vendor then the same cycle of business requirement through to test and production will still be required but without the development phase. However we source our IT business solutions we are required to ensure regulatory compliance and control of changes throughout the delivery process. Page 2 of 19

Picture 1: The Application Delivery Life Cycle 3. WALLS AND FENCES AROUND THE LIFE CYCLE Maybe our IT organization has just evolved or maybe we specifically choose to organize our IT according to specialty or perhaps we decide to minimize the relationship points between the user and IT. Whatever the reason, from an ALM perspective, we inevitably end up with no one owner of the IT processes involved in application delivery. We create individual fiefdoms, each with its own wall or fence around it, protecting its domain from the intervention of others. The diagram below shows a common example of organization of responsibilities across the life cycle. In this example, business analysts own the requirements process and the interface to the user and we create an artificial barrier between IT development technicians and the business. Those same development technicians are protective of their development processes, they own their own version control repository, their own build and deploy mechanisms and often, in order to control their own quality, they insist on owning the system test environment. Page 3 of 19

Picture 2: Fences and Walls within the Application Delivery Life Cycle If we have a separate quality assurance department or test team, they may also try and take ownership of system test, but they should fiercely protect and establish quality gates around user acceptance testing. However, user acceptance testing should also be an area of direct concern for business requirements analysts as it is here that the originally agreed requirements are rehearsed for the user and finally accepted. (This is an essential quality gate in any change process for application delivery). In this life cycle, operations testing are also specified. Typically this area is a closely guarded responsibility of the operations pre-delivery functions and is an essential part of Service Transition as specified in ITIL Refresh V3 (June 2007). And finally, in our example life cycle, the change management function delivering the service into production and then running and maintaining that service is specified. Note that here is the only formal requirement for change management and a description of this and associated management functions is fully described in ITIL V3 Best Practices for Service Transition. The fences in our picture above serve to indicate where an IT organization will naturally develop protected domains of responsibility and these become barriers to a fluid life cycle delivery process. The Chinese wall on the other hand is specifically there to indicate the regulatory Page 4 of 19

requirement for a division of responsibility between those who build and deliver things and those who run them on a daily basis. Whereas the fences can be removed, for good governance we must maintain the Chinese wall. 4. MANY INSTANCES OF CHANGE MANAGEMENT Picture 2 shows only one instance of change management and this is the formally defined operations instance as specified under all versions of ITIL and representing a foundation stone of good production service management. At minimum, it is good practice for an IT organization to maintain a forward schedule of approved IT changes which can be communicated across the whole of IT and to the business. Conflict between changes, delivery schedules and business/project expectation are resolved through the management of this change schedule. But within the application life cycle and particularly within each of the protected areas there are other instances of change management. These instances of change management will have varying degrees of formality and rigor, they typically provide limited change information exchange with other change management processes and they require their own support, maintenance and management. We may not recognize that we are doing all these instances of change management but we are in some form or another (or we should be!). Page 5 of 19

Picture 3: Instances of Change Management in the Application Delivery Life Cycle The example in picture 3 shows ten instances of change management processes and the table below describes them and their characteristics within the application delivery life cycle. Change Management Repositories in the Application Life Cycle No Mgmt Discipline 1 REQUIREMENTS 2 APPLICATION PORTFOLIO (SERVICE PORTFOLIO ITIL V3) 3 PORTFOLIO PROJECT 4 SOFTWARE CONFIGURATION 5 & 7 BUILD AND DEPLOY Description A record of user requirements in a single repository (or folder, or spreadsheet) against which we can record updates and amendments to those requirements A portfolio of valid applications against which we can do work Enables us to understand application currency, and requires us to identify new and demise old applications Accounting for the use of time and materials on any project whether in-house or outsourced The version control repository, but today much more than that Repositories staging content for build and release require change control disciplines Repeat the same deployment processes into test and into production Page 6 of 19 Characteristics Records whether the requirement is accepted or rejected Provides authorized approval Tracks requirement through to delivery and acceptance by the user Maintains a track of which uses what! In SOA the service registry In ITIL 3 the service portfolio Maintains and negotiates project schedules, delivery schedules, resources and costs Associates and versions all artifacts in an application Enables a complete picture of an application update Essential to understanding configuration of any given application and any individual application delivery The essence of the integrity of our services and the applications that underpin them The definitive record of what is changing and under what authority the change was made Guarantees the integrity of build processes and the correct assembly of the application configuration for deployment, through delivery of authorized baselines Often lacks any discipline and control Composite build requires controlled build environment Only approved baselines should be deployed (*good governance) Produces full release manifest Deploy ONLY what we build ONLY what and ALL of what we deploy

6 CHANGE CONTROL FOR TESTING Test manager controls and manages changes to his own test environments 8 PRODUCTION CHANGE CONTROL ITIL Best Practice: an independent change control function for production PRODUCTION RELEASE MANAGEMENT Valued function for any IT organization irrespective of whether they adopt ITIL Minimum governance standard of development does not have access to production = deployment system under different access rights = Release Management 9 10 PRODUCTION CONFIGURATION MANAGEMENT arrives at test Test manager controls his own test configurations Test manager knows what versions he is running, what fixes he has received, what is outstanding etc. Outstanding defects should be against a certain application baseline and the fixes should managed as baseline upgrades (good governance and practice). Concerned with all changes to production Establishes schedules against known service commitments as well as business delivery requirements Independent change control function not associated with project delivery, cost or resource requirements Release management + authorized access with shared technical support Control requirement to ensure unauthorized additions do not reach production Requires authorized, audited change controlled repository from which production releases can be made and the contents authenticated and recorded Change controlled repositories inside production underpin the live run-time configuration used on any service day ITIL Best practice 5. WHAT DOES THIS COST US IN DUPLICATION, EFFORT AND TIME? All the above instances of change management may not be exhaustive, but even contemplating this amount of bureaucracy is exhausting! Exactly how much change management are you doing and how much is necessary? These are difficult questions to answer, but if you consider all your existing application delivery processes including those without any particular formality and rigor then you are likely to find many pockets of un-formalized change management occurring. If your company is committed to implementing process standards like CMMI, or best practices like CoBit and ITIL, then you will find examples of different groups trying to formalize and enforce these change management disciplines. Whatever the cause, whatever the analysis and findings, the way we generally do change management across the application life cycle, is many times, many different ways, with far too much bureaucracy and unnecessary cost and resource. Look at our same life cycle again from a cost and duplication perspective. Page 7 of 19

Picture 4: Duplication of Common Change Management Functions Multiple change processes require us to be using resources in each of the disciplines to support those processes. We may not call all of them change managers but we have multiple people managing change, raising change documents, approving changes and monitoring changes. We will have multiple repositories (databases or folders or spreadsheets, whatever ) of change information all of which must be maintained and, for audit ability and governance, secured. From a process and procedure point of view we have multiple processes which are always a recipe for doing things twice and doing things inconsistently and unreliably. 6. SO HOW DO WE ELIMINATE THIS DUPLICATION? The obvious thing to do is to tear down the walls and fences that artificially divide the groups within our application delivery process and compel everyone to work to a common process and within a common system. It s perfectly possible to deliver a single unified change management process and system and recognizing that some of the current IT organization is likely to be defensive to change it seems superficially desirable to impose such a solution. Page 8 of 19

6.1 Demolish The Walls Not so simple as it first appears. The wall between development and production is a Chinese wall, meaning that it is there for a specific and in our case, a regulatory reason. There is a reasoned audit and compliance requirement to ensure a division of responsibilities between operations responsible for running of applications and services, and development who build, support and maintain applications and services. This manifests itself in two different organizational teams with different security rules and this almost always results in duplicate instances of a developed application, with different access rights to each instance and different change control processes for each instance. So the intractable problem is that we need to keep the wall but remove the duplication! 6.2 Tear Down The Fences Easier said than done! The fences have been established by teams for good reason. If it is good practice to enable experienced business analysts to skillfully evaluate and define business requirements of IT, then it makes no sense to enable IT technicians without those business skills to re-define them at will. So it is important to ring fence requirements management and the associated IT to business user relationships. Any test manager who wants to value his test results is concerned to maintain an environment independent from colleagues with development responsibilities who want only to change that environment constantly. There are many sound reasons to create a fenced-in quality assurance and test area and to protect that from changes for the duration of test runs that give confidence in application efficacy. So the intractable problem is how to enable a continuous change process without fences, that still maintains and functional independence where appropriate. 7. A CLEAR OBJECTIVE! Start by defining a clear objective for a unified change management process supporting change management across the whole of the application delivery life cycle. We want to introduce this so Page 9 of 19

that there is one instance of a change management system and this system is shared by all the users of change management. But importantly we can t start with the technology. 8. PEOPLE, PROCESS AND TECHNOLOGY The recommended implementation strategy for unified change management has to be: 8.1. People Deal with the organization issues first. Ensure you have buy-in across the organization to share a common change system. Ensure everyone understands the benefits and realizes that their own needs and protections are going to be recognized and sustained.. Begin by aligning required change management roles and responsibilities in each of the areas, to the new concept of unified change management. 8.2. Process Only when you have mandate for the principles of unified change management and have an understanding of the roles and responsibilities in respect of change management across your organization can you then turn to how the process of unified change management will work for you. The process will match your requirements for regulation, compliance and governance balanced against your individual company need for rapid application delivery, risk and reward. There is no one-size fits all. Standards such as ITIL and CoBit are best practices only and you need to be selective as to what works best for you. Similarly, CMMI rigor increases with the level of certification your organization demands. The rigor of your change management process must reflect this requirement. 8.3. Technology It s not impossible, but we cannot recommend a paper based change management process in this day and age. Therefore, change management processes must be, and are, supported by technology in one form or another. However herein lays a conundrum. Vendors tend to provide tools that specialize in different aspects of the application life cycle and so they should as in this way we get best of breed tools for each aspect of analysis, development and testing and production service management. These tools, operating as they do in a specific domain often require and are delivered with in-built change management either as a specific part of the tool or as implicit functionality. Consequently, we often have inherent duplication in process, technology and support encouraged by the different tools we use. Picture 5 below shows a number of different specialists prevailing in today s marketplace and each of these implicitly include change control functions in order to facilitate the processes supported by the software. Page 10 of 19

Picture 5: Vendor Specialist in the Application Delivery Life Cycle To eliminate this duplication we must do three key things: 1. Recognize that the technology we require for a unified change management system is a process management, workflow tool capable of embracing all the processes supported by the different silos of software. 2. Understand that where we have specialist and capable software already implemented within our delivery life cycle then we need to interface with it and support its change management capabilities within the unified change management system. We should not seek to replace or substitute its capabilities as a specialist product. 3. Where we do not have specialist tools we need to consider whether the extent to which we need specialist support can in fact be embraced within our composite workflow solution for unified change management. 8.4. Application Life Cycle Workflow Technology: MKS Integrity Page 11 of 19

Given all the above characteristics and concerns we must be careful to select appropriate, capable and, most importantly, fully flexible workflow software if we are to deliver on unified change management without disruption to our current implementation and function. The workflow software we choose must not only be capable of supporting all types of change management but it must be sufficiently flexible and undemanding, that it can service all varieties of user, from the most highly to the least technical, from the business strategist through to the service operator. It must be capable of supporting best practice wherever it encounters it (either in process or tools), it must be IT systems and process agnostic capable of running on and interfacing with anything and everything because it is an all embracing process. MKS Integrity offers this flexibility and is able to embrace any number of change management processes with a cohesion that enables the user to build a unified change management system. The flexibility of MKS Integrity allows the user to do this, either by interfacing with and enabling end to end change management of software already installed within the life cycle, or by using MKS Integrity on its own. MKS Integrity is sufficiently capable, given a number of additional supporting processes and templates available with the product, of providing a unified change management system from the beginning of the application life cycle through to production service delivery and running. 9. SO WHAT IS THE BENEFIT? What can you expect to gain from implementing a unified change management system? Consistency and Coherence If a single change record provides links between an originating business requirement through to a final production release then it implicitly provides a consistent and coherent information and knowledge track for that business and application deliverable. Unified System For all users of the change management system, wherever they sit in the life cycle or in the IT organization, there is one place to go to do change management and one place to obtain change management information. There is only one system that is telling us what the authorized delivery schedule is and only one place where competing change interests are documented and resolved. There is only one system to learn, one system to log on to and one definitive set of users and roles. From a systems maintenance and support perspective there is only one system to maintain, secure and service, there is only one set of security and access rights to maintain and only one instance of system administration. Enhanced Integrity and Audit ability: Improved and Simplified Governance Because the change record commences at the beginning of the life cycle and ends at production it is always possible to see where that change record has been, what its history is in terms of authorizations and approvals, what stages of the lifecycle it has been through and what difficulties it has encountered in transiting that life cycle. Not only is there a full change history available, but as the record transits the life cycle it is possible to ensure that the content of the Page 12 of 19

associated changes are maintained throughout and nothing is lost (or added) along the way. This contrasts significantly with implementations where different sets of change management information are managed on diverse systems at different points in the life cycle. Reduced Bureaucracy Because there is only one change management system, the same users (e.g. development project managers) are not required to raise multiple instances of the same change information. It is not necessary to log on to multiple systems and with only one common instance of the change information it is much easier to enhance as the change develops across its delivery life. Greater Span of Change Information Coverage Because the unified change system can point to relevant information in other more comprehensive systems (e.g. for project portfolio information it can point to project and resource plans) such information does not have to be summarized and input specifically to the change management system. Because the composite change record can have as many attachments as appropriate it can encompass a far wider range of artifacts than a standard version control system delivering a release or a separate change management system delivering just change control information. Wider and More Productive Communication Because a unified change management system will be used by everybody, the communication coverage is far wider than with specific point solutions for change management. A wealth of information becomes available with each change as every specialist area in the life of the change contributes to the same deliverable over its life. Users of the change information, such as operations, therefore have a much more comprehensive view of what is being delivered to them and a much greater awareness of all the participants and contributors to a change. Cost and Resource Saving It is an obvious derivative of all the above that if there is improved change integrity, audit, communication and all with less bureaucracy then reduced costs and resources are going to happen. Here are few examples of why these savings happen. - less time is spent on doing change management (by everybody) - controlled communication = clear information on release contents, what is tested and what is not, what has been changed or dropped along the way etc - audit happens implicitly, requirements for governance derive from the system/process integrity of build and deploy = less regression due to incorrect configurations and uncontrolled software delivery relationships between user requirements and system delivery are coherent and disputes in UAT are clear and discernible for resolution with the user uncertainties over the production content and delivery are resolved within the life cycle and cease to be time consuming disputes awaiting final resolution at release time Page 13 of 19

10. A WORD ABOUT AUTOMATION With workflow technology such as MKS Integrity we are able to automate several parts of the change management process such as the mechanical activities associated with builds or deploys. These routine processes can be run under workflow controls based on the status of the unified change record, which itself can be based on any number of content and consistency checks plus required authorizations. The advantages of such automation in terms of reliability, consistency, control and audit ability cannot be underestimated. And, of course, automation means things get done much faster, as the system is not waiting for the availability of human interaction. Automation also allows us to run complex routines as part of the change process and maintain them once as part of a consistent change system support regime. In this way we relieve programmers and application managers from re-inventing the wheel every time they need to do a build or deploy and we prevent testing and operations from evolving their own unique designs for the same delivery processes. 11. SUMMARY Take one last look at the application life cycle, but this time from the perspective of a unified change management system using technology such as MKS Integrity for change management. Picture 6: Unified Change Management across the Application Delivery Life Cycle Page 14 of 19

In this picture change record #999 begins life as solely a business requirement, but on approval this gets modeled, design documents are added, a development occurs and content is attached. This content gets built and #999 and all its build content is deployed and tested. The test results and signoffs are added and operations complete their testing and signoff. Operations already have visibility of #999 during its development life but for the final deploy into their environments the access rights to the delivery content of #999 and therefore the control details of the change record are frozen and passed to Operations for production delivery. (preserving the Chinese wall ). Operations approvals are added and the delivery becomes a service addition to production services. In our example this is all accomplished using the one change management system and one repository in MKS Integrity. This paper concludes with a case study on the implementation of Unified Change Management. 12. CASE STUDY: IMPLEMENTATION EXAMPLE OF UNIFIED CHANGE MANAGEMENT Based on personal implementation experiences with one of the world s largest banking and finance institutions (HSBC), the following two examples show how change management process can be unified using MKS Integrity. Let s start with the understanding that our IT process is the glue that sticks together the way in which we facilitate our application delivery and the change management actions we are going to apply at each progression. The extent of those actions at any point in the life cycle will be determined by our need for regulatory compliance, our internal disciplines, our configuration of systems and how much we already satisfactorily do by way of process and change management. Where those actions occur will be determined by our organization and how we go about development and delivery practices. MKS Integrity is a workflow tool that maintains the persistence of the processes and actions we have glued together. Without such a workflow tool our processes would not be maintained and enforced and therefore our glue would come unstuck! 12.1 Example: Gluing together a build process! The complexity of builds and build environments for today s applications is such that we decided to build only once and in a controlled environment independent of development environments and prior to test environments. So how does this work from a unified change management system perspective? In the diagram below we needed to glue together four change management practices: 1. Change management for business requirements: To enable us to track the relationship between what we submit for build and the analysis, designs, models and originating business requirement. (Note: During my time at HSBC we completed the tracking of Page 15 of 19

business functions into the build with the understanding that we would be able to add requirements management as a later enhancement). 2. Change management within development: The processes associated with check out and check in, version control, reconciliation of all concurrent developments and authorized base lining of the content for build. 3. Externalized change management processes to meet regulatory requirements and governance. Example, the project manager is required to sign off the release before anyone can promote it to build. 4. External configuration change management: A build process must execute against a known and defined environment. That means we must externally change control the environment configuration within which our build processes run. The most common recognition of this process in Operation will be the change control of infrastructure changes. MKS Integrity provided the workflow (implemented process) which enabled us to glue these four disciplines together and support the four change management practices as one linear change management process. Picture 7: Gluing Together the Build Process Page 16 of 19

There were four important benefits immediately derived: 1. Functions delivered to build could be related to business requirement 2. Integrity and audit was an immediate derivative as all documents, models, requests for change become aligned to the same system and same change record 3. Regulatory requirements were serviced as part of the process, automatically happening as part of implementation of MKS Integrity 4. Control of the external environment within which the build was happening so we could control the underlying infrastructure on which the build process ran. 12.2 Gluing Together a Production Process Having brought together the four change management disciplines above, the next problem is how to eliminate duplication in testing and production. This can be especially difficult if there are already good change management practices in place and if change management systems or tools already exist. For the implementation at HSBC, MKS Integrity provided the answers. For production change and release processes supporting all platforms (including IBM mainframe) it was possible to interface existing systems and processes and control these from our defined Unified Change Management Process running on MKS Integrity. For test management, it was possible (planned implementation) to integrate existing test management tools with MKS Integrity in a similar manner. Picture 8 demonstrates gluing together production and test change management processes. Page 17 of 19

Picture 8: Gluing Together the Production Change Process There were four important benefits immediately derived: 1. There was now a full and directly traceable audit from the origination of the release through to the production delivery 2. Production change and release systems did not have to change and were supported within the overall unified change management process 3. The information and approval actions required by the production change management system decreases because this is already available as part of life cycle progression. This reduces user interaction with production change to the necessary minimum 4. There was much more and much earlier visibility of change and its progress across the organization with IT organization wide change communication and interaction Summary Using MKS Integrity, achieve unified change management best practices to improve governance over the control and delivery of change within the IT organization. MKS s unified platform Page 18 of 19

approach can automate and manage any IT workflow or software process, while uniting process frameworks such as ITIL, CMMI and CobiT, enabling you to better meet IT governance and compliance goals, achieve high levels of process maturity, measure performance with real-time software metrics and make substantial productivity gains for overall low total cost of ownership. For more information on MKS Integrity and the role it can play in unifying change management, contact MKS or visit www.mks.com. Contact MKS for further information on how MKS Integrity can help your organization achieve its software certification goals. Call Us: North America UK & Northern Europe Germany & Rest of Europe Japan Singapore Rest of World 1 800 613 7535 44 (0) 1483 733900 49 (0) 711 3517750 03-5789-5544 65 67 32 8768 519 884 2251 Visit Us: www.mks.com Email Us: sales@mks.com MKS is a trademarks or registered trademarks of MKS Inc. All other trademarks acknowledged. 2007. All rights reserved. Page 19 of 19