A Creative Intellect Consulting Executive Summary Report

CIC Guide: Continuous Delivery Realization Enterprise DevOps realities and a path towards Continuous Delivery A Creative Intellect Consulting Executive Summary Report IT as a competitive advantage is an often used sound bite in management presentations. How to achieve that advantage is something that is far less clearly articulated. Increasing the speed of software development is one key approach to gaining competitive advantage by being able to react to changing market requirements and emerging trends. Before faster development can be effective, however, it needs to also be matched by a greater cadence in the deployment process. This is often a more complex challenge than finding competitive advantage. This Executive Summary report highlights key insights from exploring the collaborations between IT development and IT operations being employed by a cross section of organizations across the market landscape. By drawing on the experiences of a number of large enterprises, the study was also able to investigate their understanding of, and capacity for, Continuous Delivery within the context of development and operational interactions. This report also profiles the support delivered to improving Enterprise development and operations relations (DevOps) by Serena Software s Release Management and Automation portfolio. In particular, the guide looks at the vendor s goals for enabling organizations to better cater for Continuous Delivery for the most appropriate application targets. Bola Rotibi, Research Director, Creative Intellect Consulting Ian Murphy, Principal Analyst, Creative Intellect Consulting April 2013 Creative Intellect Consulting is an analyst research, advisory and consulting firm focused on software development, delivery and lifecycle management across the Software and IT spectrum along with their impact on, and alignment with, business. Read more about our services and reports at www.creativeintellectuk.com Creative Intellect Consulting Ltd 2013 Page 1

Table of Contents Executive Summary... 3 Serena s Continuous Delivery and DevOps Foundations... 7 Creative Intellect Consulting Ltd 2013 Page 2

Executive Summary Businesses want something different, something that can enable them to capture new markets. They want IT to deliver competitive advantage, not once a year, but on a continuous rolling basis. The success of companies such as Amazon, Apple, SalesForce, Google and Facebook show that this can be done. Software can be delivered quickly and reliably, leading to massive growth in the customer base and increased revenues. There is, of course, a significant difference between many Enterprise customers and those organizations listed above. For many IT departments, delivering software quickly and reliably is not easily achievable, given the processes in use. Enterprise customers have complex, hybrid infrastructure environments and platforms (mainframes, minicomputers, distributed computing platforms) and multiple endpoint devices. Their infrastructure contains components that may be decades old, but which are still running critical applications. The software that they are using can also be old, meaning running critical systems can be hard to replace. Finally, the processes that the enterprises are using will generally have evolved over time to accommodate multiple generations of IT. The aim of this report is to determine real world approaches for development and operations collaborations, and the application environments and organizational maturity where Continuous Delivery can be applied effectively. It also looks to help establish the mapping between existing ITIL/ITSM transformation strategies and the transition to Continuous Delivery and Cloud provisioning. In doing so, we aim to establish a definition for Continuous Delivery and the attributes for Enterprise DevOps that reflects the reality of what organizations are looking to achieve namely to improve the speed and frequency of deploying quality software and become a more adaptable and agile IT organization. Input from On the ground experiences As part of the research for this report, Creative Intellect Consulting Ltd (www.creativeintellectuk.com) interviewed a wide range of organizations. Respondents came mainly from large and small enterprises, as well as release management and continuous development and deployment consultants dealing with the following markets: US government departments, global financial institutions, European tax and revenue offices, automotive, retail and healthcare. The goal of each interview was to understand: existing operational and development processes; the level of focus on DevOps concerns; strategies for moving towards Continuous Delivery; the levels of self-service support; considerations for Cloud services and future needs. We sought to understand what was happening in practice, the technology and the process gaps and what was needed to meet the changing demands of the business. Rather than presenting the interviews in detail, this report looks at the patterns and approaches that are common (or, where relevant, different). A need for DevOps For many organizations out in the market place, the workflows within IT development and operations teams are generally well established. There are relatively solid operational processes in place, particularly for workflows like continuous integration and release management, that target a single platform technology (Java,.NET, Mainframes). Unfortunately, the right collaborations and communication between these two important stakeholder teams are not always well coordinated or orchestrated. In some extreme cases they are not even taking place, with development teams metaphorically throwing their delivered code or application modifications over the wall to the operations team. Creative Intellect Consulting Ltd 2013 Page 3

Welcomed acknowledgement for a DevOps focus Within the organizations interviewed, there is great appetite for improving the operational processes as well as the collaboration and alignment between the development and operations teams. Many of those interviewed had attained reasonable levels of maturity in their IT organizational processes, although not all processes were consistently applied throughout. There was keen awareness for having in place important operational processes, as defined by the ITIL and ITSM libraries, and best practices to help support throughput gains made from agile development procedures. However, while ITIL and ITSM provided the foundations for many improvement strategies, the level of consistent support and implementation was patchy. A vision for Continuous Delivery... The task of Continuous Delivery is a growing focus area for both IT development and operations organizations, particularly with respect to supporting a level of service automation and business agility with the fast deployment of desired services. The number of releases varies per organization, but there is no doubt that many would like it to be on an upward trajectory. Of those interviewed, many felt that Continuous Delivery was an initiative that aligned well with the ability to release more, no matter who is executing the release management process. So it is about smoothing the path to production deployment. Some of those interviewed see the potential of mobile apps; not business critical, but an opportunity to see the development team deploy directly to an internal App Store environment hosted via the Cloud....but a lack of clarity in its application The capacity for Continuous Delivery is not always well understood, especially in the context of development and operational throughput. Many organizations are looking to understand how the ITIL/ITSM model, which they have begun to use to transform and improve their operational processes, maps to support both Continuous Delivery and Cloud provisioning. The drive for Continuous Delivery presents a mandate for DevOps One of the insights that a drive for Continuous Delivery firmly exposes, is that it is about how you manage the process between IT development and operations teams to create a smother bridge and progression path to deployment. It is not about trying to create a third DevOps department that is made up of the other two. Organizations need to stop with the mindset of thinking about having a DevOps manager, a DevOps this and DevOps that. Once lead roles within both teams work on how to manage handover and making the processes smoother and not a step of stop start points, organizations will find that DevOps becomes a given. Ultimately DevOps is about process integration with the right level of collaboration and communication occurring between IT development and operations. It is that simple. Tooling direction required Many organizations do not necessarily know which specific tools are necessary to support Continuous Delivery. This is not altogether surprising when both IT development and operations teams already have considerable arsenals of tooling platforms in place to do a mix of management and process functions (e.g. help desk, problem resolution, configuration management, change management, defect tracking etc.). A question many ask is how should the various tool chains already in place interact and align to support Continuous Delivery or Deployment? More importantly what should be the makeup of the various tool chains in operation to deliver strong Continuous Delivery or Deployment support? Creative Intellect Consulting Ltd 2013 Page 4

Vendors like Serena, with its focus on orchestration of workflows especially for release management and automation, and IBM with its orchestration for Cloud deployment and workflows have been smart in their directions for supporting Continuous Delivery. Improvements in core systems required Enterprises have been deploying distributed applications for over two decades. In that last decade there have been two things that have exponentially increased the complexity. The first is the increase in the reuse of components across multiple applications. The second has been the introduction of virtualization, meaning that the physical location of distributed application components is hard to track. The primary tools used inside organizations to maintain a record of hardware and software are Asset Management and the Configuration Management Database (CMDB). In practice, however, many applications and particularly distributed system components are not properly recorded. There are concerns that many CMDBs have not caught up with the wide use of virtualization, so the creation of multiple instances of an application may go completely unrecorded leading to patching errors. Another key concern is that as we move towards a world where everything is software defined, the CMDB, in its current guise, has no way of distinguishing between hardware and software changes. For example, change a firewall and most CMDB will see that as a hardware change. Open a firewall port to allow specific traffic through as part of a software upgrade and it will not be recorded by the CMDB because it is not seen as a change to the firewall per se. This is a gap that we believe vendors urgently need to address, especially as software defined networks and environments in general look to be the next big datacentre change. A lack of best practices is hindering a move to Continuous Delivery There is very little in the IT world that is really new. The vast majority of 'new' technologies, techniques, processes and tools are really just improved versions of things that have gone before. Yet, despite the money spent on IT solutions and systems, it was evident from our interviews that too many organizations were struggling to find best practice advice. Interviewees pointed at vendors as not doing enough to show how to bring tools together, how to create more stable processes and how to create effective Continuous Delivery (CD) processes. This was a surprise, because not only are there plenty of examples of CD across the industry, the vast majority of large enterprises already have working models. For example, deployment of patches and new software to endpoint devices is an automated process: if an endpoint device is detected as not having being used for a period of time it will receive an update, and it will then be restarted to ensure that all patches are properly installed. Any device that is not patched may find itself unable to connect to certain network resources until this is resolved. Scaling that process up to the delivery of software to production and the way change management is used inside the datacentre is entirely achievable. However, there was a distinct view that the experimentation of how this should be done should be based on vendor examples rather than organizations doing this themselves. The path to Continuous Delivery and for improved DevOps requires commitment There are many challenges facing organizations in managing their operational processes that make the move towards CD and the implementation of a strategy for Enterprise DevOps difficult. The issues range from rising complexity (application and infrastructure) and lack of sufficient automation for predictable and repeatable processes, to poor process quality, poor discipline and management/organizational inertia. So even though the knowledge of ITIL and ITSM is high, the lack of sufficient support for important operational processes and best Creative Intellect Consulting Ltd 2013 Page 5

practices will hinder progress. It is not just best practices, as defined by the framework libraries, but proven best practices from vendors that is lacking for many of those interviewed. Without sufficient proof of success, enterprise IT will feel they are taking a risky leap. Ultimately, an organization s capacity to support CD and / or deployment is more than an approach for collectively addressing the people, processes, technology, and tooling perspectives. Nor is it just about the IT organization being able to drive both the tactical and the strategic agenda. This is an outcome that is likely to occur since IT will be in a better position as a result of its capacity to deliver quickly and more frequently. What it is about is whether all parts of the business can embrace the reality of what CD truly means, the commitment and support required and the cultural and organizational mindset changes needed. Those who have experienced implementing Agile development practices, SOA and other process initiatives will be well versed in the challenges this presents. Creative Intellect Consulting Ltd 2013 Page 6

Serena s Continuous Delivery and DevOps Foundations Software has always been about competitive advantage to business, whether it is the accounting system, stock control database or software on a mobile device carried by a field sales team. Simply having the software, however, is no longer enough. Business units want software to reflect current trends. For too long, software updates have lagged months, or even more, behind the need. One of the biggest problems in accelerating the delivery of new features and software is the speed of development. The arrival of Agile development has brought users and developers closer together. Operations teams are now increasingly getting involved in Agile teams and beginning to bring an understanding of the challenges of speeding up the cadence of software delivery. Although organizations are beginning to increase that cadence, they need the right tools, processes, organizational support and mindset to make it happen. Serena s strength in Continuous Delivery and deployment is the strength of its process support. While customers will have tools for the physical design, writing and testing of software, tools that Serena does not have, it can provide the underlying foundations for a set of continuous processes. What Serena brings to customers is a proven process environment that is integrated with ITIL and ITSM, supports high levels of automation and can help operations teams match the accelerated development of software. From ALM to CRM (Change and Release Management) with the backing of orchestration and interoperability From Application Lifecycle Management (ALM) to Serena s Change and Release Management (CRM), Serena has a long history of tools that provide process support for application development and delivery. There are three groups of tools. 1. IT Front Office suite: The tools here provide a portal between IT and the business. It enables the business to see the status of all applications and application requests. IT can use it to post updates on work in progress and to show the business the current state of IT services. It can also be used to help refine the current work schedule by providing a voting mechanism on which changes are the more important and allow IT to assess business requests. 2. Orchestrated Apps: This covers all the Serena tools for developers. Some of the tools such as Requirements Manager and Development Manager are multi-platform, including the mainframe. Agile Planner provides a collaborative space for managing Agile teams. The last, but most important tool for improving the cadence of delivery is Serena Release Manager. This is an automated solution with its own workflow that integrates with an equivalent tool in for operations. 3. Orchestrated Ops: There are two tools in this space, but quantity of tools should not be confused with capability of tools. Service Manager is an automated IT service delivery process linked to the Service Desk. It enables the service desk to see what is happening across the entire operational landscape. Serena Release Manager ensures a smooth, automated handover, from development to operations, offering benefits to both groups. As well as these three tool suites, Serena has a range of other products. Some of these are function specific, such as Dimensions CM, which is a Software Configuration Management suite. Others are platform specific such as ChangeMan ZMF, which is a multiplatform Change Management and mainframe modernization solution. Recognising that customers have to support multiple platforms, and especially with the increased attention on the mainframe in recent years, Serena has focused on interoperability, orchestration and ease of use across its wider product portfolio. By taking this approach, Serena has sought to reduce tool complexity for customers, but simplicity has to extend beyond the tools from a single vendor. To meet that need, Serena has its own Web Services solution that enables heterogeneous tool integration across vendors and, unlike many of its competitors, across platforms. Creative Intellect Consulting Ltd 2013 Page 7

Making strong headway through Release Management Serena Release Management consists of several elements as outlined in Figure 3 Figure 3: Serena s Release Manager Portfolio Source: Serena Software A key element in Serena Release Manager is the Unified Release Calendar (URC). This provides a single place for all changes to be recorded across application development and ITSM. With its integration into Serena Service Manager, the URC acts as a foundation for orchestrating IT management and ensuring that all scheduling is properly coordinated. Release Control provides a multi-platform workflow for Release Management Release Control is a series of policy driven workflows. It ensures that each release goes through the appropriate phases, such as QA and integration, while capturing the sign-off approvals to enable it to progress to the next stage. It provides a method to enforce processes, not just on a global basis, but at an individual release or release class basis. This is particularly powerful, because it means that a risk-based approach can be applied to each release and the workflow tuned accordingly. By default, the data captured is fed into an audit system to ensure compliance with both corporate standards and regulators. By providing a planning capability, Release Control ensures that any changes are notified to all those involved in the release. This ranges from business units to developers, QA to operations. It provides an easy to access portal whereby the current status of each release can be monitored, including the release schedule to ensure that there are no unplanned changes. Creative Intellect Consulting Ltd 2013 Page 8

Release Vault secures everything Release Vault acts as the secure storage location for all data related to a release. This ranges from the approval signatures and audit data that come from Release Control, to the code to be deployed. The latter is important as Release Vault becomes part of the multi-staging mechanism of code where the code, once released from QA is moved from the local SCM to the Release Vault. In doing this, Serena has ensured that there can be no untracked or unauthorised changes to code through any mechanism and that the Release Vault becomes the single source of trust. A critical feature delivered by Release Vault is that of automated rollback. This is a critical feature that not only ensures that no system is left in an uncertain state after a deployment failure, but is part of the corporate disaster recovery and business continuity planning. Release Automation improves the cadence of software delivery Effective automation means a reliable, predictable process. When applied to Release Management it means that software is deployed in minutes rather than weeks, increasing business agility and reducing workload. Serena believes that an effective automated solution can reduce deployment times by over 90%. To improve the cadence of software delivery, Release Automation requires a proven and trusted test methodology. This methodology must be constantly reviewed by the operations and development teams to ensure that it meets the standards for reliability of software in production. As well as improving software delivery, release automation delivers a set of additional benefits such as: Reduced costs for deploying applications Releasing operations staff to maintain the infrastructure Improved reliability of software by the removal of human error It is wrongly believed by many that an improved Release Automation process is just about speed of deployment. Over 75% of operational costs for software are about deployment, patching and maintenance. Properly implemented, Release Automation can deliver fiscal savings, as well as providing a more reliable and predictable environment. Orchestrated solutions and interoperability bring processes together The complexity of the modern application landscape means that few companies are supporting a single platform or technology layer. Instead, they need to be able to deploy to multiple solutions and this often means using platform specific solutions. One of the risks with platform specific solutions is the loss of integrity of the Release Management process. Serena has moved to deal with that in several ways: 1. Serena has platform specific solutions that are integrated at the Release Management level. This means that Release Control can provide coherent and integrated process control and scheduling. It also means that the Release Vault mechanism is not compromised. This is especially important when it comes to cross-platform deployment or the sharing of cross-platform resources, as in the case of distributed system development. 2. Serena web services enable developers to build integration with non Serena products. The web services enable the import and export of workflow, schedules, audit data and code. The latter being especially critical so that the Release Vault can hold all code before it is deployed. 3. Operations and development teams own and utilise a wide range of tools from multiple vendors. Serena s Orchestrated IT approach allows customers to continue using the tools that they are familiar Creative Intellect Consulting Ltd 2013 Page 9

with, and only add those Serena tools that they need to complement their existing environment. This eliminates the cost of retraining staff, protects investment in existing tools and reduces risk of data loss when porting data between systems. Hitting the sweet spot for customers and partners DevOps, Continuous Integration, Continuous Delivery and Continuous Deployment are all interconnected issues for enterprise IT departments. Moving towards one means being aware of its impact on the others. Serena has placed Release Management and Orchestration at the heart of their approach to improving the cadence of software delivery. But this is not just about speed for Serena, this is also about hardening processes, removing barriers and improving quality. The most important barrier to remove is that of development versus operations. Serena is dealing with this not by imposing a new framework, but by using Release Management to span the divide. It is a tricky thing to do because it is asking the product to have two owners, but Serena has been clever. Drawing on its experience with ITIL and ITSM, Serena has created a set of processes that build on what its customers are already doing. In this way, Serena isn't asking its customers to change what they are doing, but rather to adapt and standardise across the IT landscape. This is much easier to achieve than wholesale change and is something that can be implemented without creating resistance. By breaking Release Management into three key areas and then realigning its product portfolio into IT Front Office, Orchestrated Development and Orchestrated IT Operations, Serena has laid the foundations for its own product development going forward. The use of web services to enable integration with other products makes orchestration much easier. This is not just a benefit for Serena, but also its partners, such as Nolio, Emergen, LMC and Metaphor. Partners can now focus on deploying solutions for customers, rather than struggling with integrating products across multiple platforms. The use of web services to make it possible to write integration between Serena tools and those from other vendors is welcomed. As an industry standards interface, it takes away the risk of a proprietary integration and interoperability framework. However, Serena has, comparatively speaking, written very few interfaces to third party tools. Instead, it has left the majority of this to its partners, system integrators and customers. It is therefore important that the company is seen to be doing more to make the integration easier and simpler. Other integration and interoperability initiatives are coming to the forefront. One such example is the Open Services for Lifecycle Collaboration (OSLC) which has been around since 2008 and is gaining significant cross industry and market momentum, especially within end-user organizations. At present, Serena is not part of the OSLC community with its drive to deliver an industry standard interoperability spec. The company s experiences in delivering a portfolio of tools and services, able to sustain a workflow for Continuous Delivery and deployment and its support for process integration and orchestration, means it has much to offer the OSLC initiative. Competitive Landscape Serena is not the only vendor looking at improving the cadence of software development, delivery and deployment. However, it is one of a relatively select band that is looking across the whole ALM landscape and positioning its tools to be able to provide a continuous process in all three areas. ServiceNow, Microsoft, IBM and ThoughtWorks Studios are positioning their tools to compete with Serena. Some of the company s competitors can potentially offer a broader and rounded scope to their CD strategy owing to sizeable portfolios of products and services and wide ranging coverage of different technology platforms. However, the simplicity and singularity of focus Release management and automation is the value proposition that Serena brings to the table. Creative Intellect Consulting Ltd 2013 Page 10

It would also be a mistake to ignore those vendors who only cover part of the whole ALM landscape. Jenkins - Continuous Integration, Maven - Continuous Build, JUnit - Continuous Testing and Nolio - Release Management are all strong in their respective areas. What many of them lack though, is an integration landscape that will make it easy for them to be used as part of a larger suite. For those customers who want to use best of breed, but also want to have a common process control, then Serena is still attractive. Its integration and orchestration approach makes it easy to take competitive tools and deploy them as part of a Serena managed solution. End user direction Competitive advantage in today's business environment means getting the right software to users when they need it. Improving the cadence of software development has been happening for some time now: transferring that cadence to deployment is still considered by many to be fraught with risk. This is understandable, because the process of automated delivery is not well understood, many organizations do not possess the processes to support it and there is significant concern over risk. Despite that, it is possible to move towards a heavily automated development to deployment process with minimal risk through the use of quality processes. For those organizations that are already heavy process users, and have well established ITIL and/or ITSM practices in-house, this is not a huge step. For those who have weak processes, the key is in choosing a partner whose solution is not only process strong, but whose processes are built on ITIL and ITSM best practices. Serena has raised the bar, but has work still to be done Serena s orchestration capability and strategy is a smart move, and one that shows that the company recognizes that it is not the tool that matters, but the workflow and the management of that workflow, irrespective of the tools used along the way. The release process is a smart focus point to centre the workflow management process on, as it is a recognizable capability that most want to improve. There is no question that Serena has done much to raise the bar for CD. By placing web services integration and interoperability at the heart of the workflow process the company has made it easier for customers to adopt and integrate its products into the customer s environment. However, there is still work to be done. While Serena does a good job of tracking and recording change in Release Vault and providing a rollback capability, it does not have a tool for application component discovery. In complex systems, tracking new change is a start, but there is a need to discover what is already out there. That is not to say that others are doing a better job. It is fair to say that the whole software industry has failed in this regard, because discovery has never been seen as important. With multi-platform deployment, including cloud and increasing levels of virtualisation, knowing where something has been deployed is incredibly difficult. The general belief is that all that is important will be captured in the CMDB. Serena has its own CMDB in its Service Manager product, but it still needs to capture more information to fully solve this problem. Another area where Serena could do more, and one that is core to Serena's entire 'continuous' proposition, is automation support. Customers have spent significant sums on reengineering their processes over the last decade. To deploy effective automation, there is a need to understand those processes and be able to break them into smaller, repeatable, reliable processes. Serena has focused on the importance of repeatable and reliable, but has no tool to help customers visualise their processes and how to break them down. Despite this criticism, the work that Serena has done over the last three years has transformed their products and made them the benchmark against which to measure the work being done by others, such as IBM and Microsoft. Creative Intellect Consulting Ltd 2013 Page 11