Application Release Automation Tools

For: Infrastructure Market Overview: Application Release & Operations Professionals Automation Tools by Amy DeMartine, January 29, 2015

Key Takeaways

Unleash Your Ability To Release Software That Your Company Depends On Software is enabling enterprises to create products and processes to win, serve, and retain customers, and thus you must release software rapidly and continuously. ARA tools model, package, and deploy application releases and their associated configurations as the business technology solution progresses through the life cycle.

Software-Powered Businesses Need Your Speed, Confidence, And Reliability ARA tools give you control over how you create and deploy environments and how and when to deploy releases. The management of consistent environments is critical to ensuring that what you develop and test is the same as what you deliver to customers in your production environment. This control, coupled with automation, gives you the ability to release software quickly and reliably.

Enable Control And Support Frequency Of Software Releases For Your BT Agenda The ability to release software confidently and automatically into different environments is a key part of the software development life cycle. By automating and integrating this function, ARA tools can increase the flow of the overall life cycle while ensuring the reliability of these releases.

Forrester Research, Inc., 60 Acorn Park Drive, Cambridge, MA 02140 USA Tel: +1 617.613.6000 | Fax: +1 617.613.5000 | www.forrester.com For Infrastructure & Operations Professionals January 29, 2015

Market Overview: Application Release Automation Tools Unleash Your Agility With Release Automation For Better Business Results by Amy DeMartine with Kurt Bittner, Glenn O’Donnell, Eveline Oehrlich, and Michelle Mai

Why Read This Report

Releasing software packages between environments such as development (dev), test, and production (prod) is a necessary part of the modern delivery life cycle. Application release automation (ARA) tools help firms release software consistently and in an automated fashion to these different environments as a key part of getting business technology solutions to end customers. Various levels of abstraction exist in ARA tools to define models of the hardware and software required by the business technology solutions, giving you the flexibility to deploy the software packages on-premises and in various cloud instantiations. These levels of abstraction, along with key integrations with other tools in the modern service delivery life cycle, complicate the decision factors for choosing the right ARA solution for your needs. Potential clients of ARA tools need to look for vendors that can automate modeling, packaging, and deployment of application releases and their associated configurations and that have built-in connections with existing modern service delivery tools.

Table Of Contents Notes & Resources 2 Break Your Operational Paradox Of The Pre- Forrester interviewed 12 vendor and user Digital Age With ARA Tools companies: Attunity, Automic Software, BMC Software, CA Technologies, Electric Cloud, 4 Begone Those Dreaded Scripts! HP, IBM, Inedo, Octopus, Serena Software, 5 The Key Criteria That Make Up Leading ARA XebiaLabs, and Zend Technologies. Tools

8 The ARA Landscape Offers Varied Support Related Research Documents Of Requirements What Makes Modern Service Delivery Modern? recommendations December 3, 2014 15 Choose A Vendor That Makes Modern Service Delivery Real Gear Up For Modern Service Delivery December 3, 2014 16 Supplemental Material Seven Habits Of Highly Effective DevOps October 2, 2014

© 2015, Forrester Research, Inc. All rights reserved. Unauthorized reproduction is strictly prohibited. Information is based on best available resources. Opinions reflect judgment at the time and are subject to change. Forrester®, Technographics®, Forrester Wave, RoleView, TechRadar, and Total Economic Impact are trademarks of Forrester Research, Inc. All other trademarks are the property of their respective companies. To purchase reprints of this document, please email [email protected]. For additional information, go to www.forrester.com. For Infrastructure & Operations Professionals Market Overview: Application Release Automation Tools 2

Break Your Operational Paradox Of The Pre-Digital Age With ARA Tools In the pre-digital age, we made choices between speed, quality, and cost: to achieve two of these goals, we had to sacrifice one. In the digital age, customers use digital devices and expect digital services that they will get either from you or your competitors.1 By using automation and changing the way we develop and release digital services into smaller and faster releases, we can achieve speed, quality, and cost objectives at the same time.2 The role of tools in the modern service delivery life cycle is to automate processes to increase the quality and speed of delivery of business technology solutions while reducing cost. ARA tools are converging workload automation and release management tools, as they create release packages of business technology solutions that then are moved between different phased environments, such as dev, test, and prod. This sounds deceptively simple. However, the devil is in the details, and you must first understand the full stack, from infrastructure to your application, and decide how much of the stack you will govern to understand which features of ARA tools you require.

ARA Tools Create Release Packages On the surface, creating release packages sounds simple. ARA tools model and package software code to be released on a specific set of hardware. However, these packages are deceptive. How much governance you are able to exert over your release package depends on how you create your model. Your model can:

■ Support modular design of the application. The business technology software may be created in a modular fashion and may therefore have a design to make parts of the software reusable and to hide complexity.3 Therefore, you must decide on what software to include, where to get it from, what order to install it in, and any dependencies you need to create a complete application model.

■ Define configuration. You can model configurations to show how the application, the middleware, or the infrastructure must be modified from their out-of-the box state to function properly. For example, any modifications to the OS or web servers fall into this category. These configurations can also define the login password and location of any systems of record that need to be integrated into the configuration.

■ Manifest middleware. Many applications require middleware. Middleware software packages also have release versions. Applications can depend on certain features or bug fixes of a particular release version of middleware. Pairing a version of the application to the right versions of middleware ensures that you have the right building blocks for the application.

■ Model infrastructure. The underlying infrastructure can also have a modular design. Modeling what the infrastructure contains can be as simple as the system the application runs on to the entire ecosystem of infrastructure, including the network, integrations to be modeled by service virtualization tools, and systems of record.

Release packages can contain a combination of these components but must include a model for the application itself. The most basic release package model would include a bill of materials of the different prebuilt software components and the order in which to install them. The more you put into your model, the more you can understand the scope of what is required to run your business technology solution. In this case, your model is like the graphics resolution of a TV: the more detail, the higher the resolution. When you pair a version of the application model with the configuration, middleware, or infrastructure model, you have defined a version of the release package (see Figure 1). You can then make changes to any of these components to make the next version of the release package.

Figure 1 Release Packages Are A Manifest In A Snapshot Of Time

Sample release package

Application version A.1 model

Con guration model

Middleware model

Infrastructure con guration model

119004 Source: Forrester Research, Inc. Unauthorized reproduction or distribution prohibited.

ARA Tools Move Release Packages Between Phased Environments As a version of the business technology solution moves through the life cycle, it typically starts in the dev environment, moves to the test environment, and then into the prod environment. Using continuous development techniques, versions can be in various stages of the life cycle at the same time (see Figure 2). Once you’ve defined a release package, you can deploy it on-premises or on any variation of cloud platform. You can create dev and test environments at will using these release packages.

Figure 2 ARA Tools Create Release Packages And Move Them To Support The Life Cycle

Various Various Version Version Version Version Version D B and C B.2 B.1 A.3 A.2 A.1 versions versions

Development Test Production environments environments environment

119004 Source: Forrester Research, Inc. Unauthorized reproduction or distribution prohibited.

Begone Those Dreaded Scripts! Even though releasing code into different environments as the life cycle continues seems like a simple problem to solve with scripting, it will only get you so far in your ability to continuously release code in a reliable and cost-efficient manner before you need a tool. Because release packages are moving through the life cycle continuously, you need to automate this process to accommodate many packages moving through different stages of release. Could this be handled by scripts? Yes. Scripts can very effectively accomplish the basics of ARA functionality. However, there are several drawbacks to using scripts for this process, such as:

■ The inability to visualize what release package is in which environment. Each release could have a different version of the environment that it is using. For example, a new web server could be used in version B.1 versus the A.1 version in production. Scripting makes it difficult to see these release package and environment pairs and understand where each version is running.

■ Difficulty in scaling. In a continuous delivery model, release packages are small, and many are deployed in various stages from dev, test, and production environments. Each of these release packages could be using a different version of the environment. Scripts would need to be modified for each release package and environment pair. As the number of release packages increases, the number of changes required in scripting can increase to an unmaintainable state.

■ The inflexibility of environment location. Each environment could be hosted in a different location, such as on-premises, private cloud, hybrid cloud, or public cloud. For example, the prod environment may be located on-premises, the testing environment in a hybrid cloud, and the development environment hosted in the public cloud. Developers of the scripts would need to understand and script to each environment and understand how to create release packages that install in each environment. This inhibits the flexibility to deploy different environment locations.4

■ The inability to easily interpret models that determine actions. Because scripts are procedural, they can be effective for driving action sequences. With more complex services, however, simple sequential execution is rarely effective and maybe even impossible. You need your tools to interpret the descriptive service and application models and then take the appropriate actions as needed to create a new reality as defined in the model. Scripts are inadequate for such model interpretation as decision triggers.

■ Unwieldy support burden. Scripts are tough to manage when the authors are totally dedicated to script coding and support. This is almost never the case. Because scripts tend to be a part-time job, even the authors find it difficult to return to the script code for enhancements or debugging. If the author leaves the organization, any knowledge of the script usually disappears with that person, rendering support extremely painful. Commercial tools are far superior in this dimension.

The Key Criteria That Make Up Leading ARA Tools The two main basic capabilities of ARA tools are creating release packages and moving these packages between phased environments. For both of these basic functions, ARA tools will allow scripting to extend the out-of-the-box functionality. Don’t fall into the scripting trap inside the ARA tool. Focus on out-of-the-box functionality to limit your exposure to maintenance and development of scripts.

Criteria That Support Creation Of Release Packages Release packages are a set of models that define the manifest of the hardware and software required by the business technology solution. The more you put into this model, the more governance you have creating the environment as well as maintaining the integrity from drift and being able to roll back in case of failure. The complexity of creating and versioning these release packages means:

■ You must have governance over all release package models. The first level of governance is the definition of the model, so that no matter where the model is deployed, all environments are configured according to that model. This eliminates issues caused by drift of the environment. The second level of governance is being able to version the models. Versioning allows you to track which changes in the environment match specific versions of the application. If issues occur, you can track exactly what changes were made to pinpoint the problem and resolve it.

The requirements for ARA solutions: ARA tools must model the application even when the application is built in a modular fashion. A key capability is assembling the application from multiple builds. Additionally, ARA tools must allow for version control of the application release along with creating and versioning a bill of materials so that you can track all the component versions of the application and any middleware. You need to version the hardware environment that the application runs on as well as any infrastructure and configurations. Understand your needs for governance today and in the future to decide which tool has the right features for your business technology solution. If another tool owns the release pipeline management, the ARA tool will need to be kept in sync with this higher-level model, preferably through an open application programming interface (API) with appropriate security.

■ You must be able to roll back to a previous working state. If a newly released application package doesn’t work properly, the quickest path to getting back to a working state is to roll back to a previous working version. One part of the business technology solution you do not want to roll back is the customer data, which would cause customer satisfaction issues when customers have to re-input information. You want the capability to roll back the release package but also to keep customer data, called roll forward.

The requirements for ARA solutions: ARA tools are limited to rolling back only what is in the model. Anything else must be manually rolled back, thus opening you up to human error and insufficiently rolling back all of the software or configurations.

■ You must track drift. Because you have modeled your application, your underlying technology configuration, and the supporting software, you will know what the expected state will be in every instance of the business technology solution in every phase of development, test, and production. A drift indicates that someone has deviated the released application from its current state. Some ARA tools are able to detect a drift away from this model so that the drift can be corrected or the model can be modified to accommodate a required change.

The requirements for ARA solutions: ARA tools can only track drift of what is modeled. For example, if configurations are not modeled, you can’t track a drift in them. Tracking drift is a popular ARA tool feature that only gets more powerful when more of the stack is modeled.

Criteria That Support Moving Release Packages Moving release packages between dev, test, and prod environments is another key function of ARA tools.5 However, if the environment doesn’t exist, ARA tools will also have to create the environment before deploying the application. Using ARA tools gives you the flexibility to deploy to any on- premises or cloud instantiation by ensuring that all environments mimic what will be deployed into production. To get full functionality from an ARA tool for moving packages:

■ You must be able to create and decommission environments at will. If the environment doesn’t exist, a new one can be stood up based on your release package. This is helpful if you need to create environments in development or test. The benefit of this is that you are saving dollars on those systems when not in use. ARA tools can either do this creation and decommission as part of their base functionality or call other environment management tools to do so.

The requirements for ARA solutions: ARA tools have to be able to deploy to the OS or container that your business technology solution requires. Linux and Windows are the most popular OS flavors today supported by ARA tools. If public or hybrid cloud environments need to be created, ARA tools must support these cloud vendors. Amazon Web Services (AWS), Microsoft Azure, and VMware vSphere are the most popular supported cloud vendors today by ARA tools. ARA tools also have the possibility of decommissioning an environment based on a trigger, so that when the task is complete, the environment is returned to the available pool of resources. Integration with the various tools needed to perform these functions (e.g., Microsoft System Center, BMC BladeLogic Server Automation, VMware’s vCloud Suite) will be a key criterion for any ARA solution.

■ You must be notified if errors occur. If moving release packages between environments or creating or decommissioning environment errors out for reasons such as failing to provision an environment or any part of the deployment, you need to be notified so you can take corrective actions.

The requirements for ARA solutions: ARA tools support error notifications and can happen at a minimum either through the ARA graphical user interface (GUI) or through email or both. Some tools support other methods of notifications, but these are the most supported options by far.

■ You must be able to quickly define deployment rules. Different components of the release package may have a certain installation order. For example, you should install the OS, make any configurations required to the OS, install any middleware, make any configurations to the middleware, and, finally, install the application, in that order. Deployment rules can be quite complex and may include manual steps, especially when you first start implementing your ARA tool.

The requirements for ARA solutions: Most ARA tools have a GUI for deployment plans where you can drag and drop certain actions and rules. You can also use the prebuilt third-party plug-ins to augment the deployment to automatically install commonly used components. This feature is common across process automation tools such as run book automation or workload automation.

■ You must be able to easily create a model from an existing environment. When you are just starting the implementation of your ARA tool, the quickest way to get a model for your application release package is to take a snapshot of your existing production environment. This is also useful if development wants to test different environment configurations for performance. When you find the right one, you can take a snapshot to use as the release package.

The requirements for ARA solutions: This is not a common feature of ARA tools yet, but this feature gets you kick-started in your ARA tool implementation and allows flexibility in the future to first implement the release package and then model it later. How detailed the model is when taking a snapshot varies by vendor.

■ You must be able to have the ARA tools be callable by the continuous integration (CI) tools. CI tools provide workflow automation capabilities primarily focused on the build and testing process and can kick off a deployment of a release if the right conditions are met.6 The use of CI tools can help automate the life cycle and achieve uninterrupted flow through the life cycle.

The requirements for ARA solutions: By supporting an integration with the CI tools, ARA tools are able to be called to move releases between environments and deploy environments if needed. The most common CI tool support by ARA tools are Jenkins, Microsoft TFS, and JetBrains Teamcity.

The ARA Landscape Offers Varied Support Of Requirements The following profiles of prominent vendors can help steer you toward those vendors that are most likely to offer an ARA solution that fits your requirements. This section describes (in alphabetical order) the capabilities these vendors include (see Figure 3, see Figure 4, and see Figure 5).7 Prominent vendors include:

■ Attunity Maestro/Attunity RepliWeb. Attunity Maestro is a deployment automation and data workflow management platform. Maestro integrates with the Attunity RepliWeb for management and automation. Attunity RepliWeb is a replication and transfer automation solution for application releases, Internet Information Services (IIS) updates, content deployments, and WAN file synchronization.

■ Automic One Automation. The Automic One Automation platform is an end-to-end solution for planning, coordinating, and automating software release processes, including automated deployment of applications across large-scale server environments.

■ BMC Release Lifecycle Management Suite. The BMC Release Lifecycle Management Suite manages software release planning, coordination, application packaging, and deployment automation. The BMC Release Lifecycle Management Suite consists of BMC Release Process

Management, BMC Release Package and Deploy, and a limited license of BMC BladeLogic Server Automation for application automation. The community website for third-party plug-ins is https://communities.bmc.com/community/bmcdn/bmc-devops.

■ CA Release Automation. CA Release Automation is a continuous delivery solution to orchestrate and automate complex application release deployments from development through production. The community website for third-party plug-ins is support.ca.com.

■ Electric Cloud ElectricFlow Deploy. ElectricFlow Deploy automates and standardizes application deployments throughout the software delivery process. The community website for third-party plug-ins is https://github.com/electriccommunity/electriccommander.

■ HP Continuous Delivery Automation. HP Continuous Delivery Automation models infrastructure and application requirements while managing versions, configurations, and other application components. The community website for third-party plug-ins is for HP passport login only at https://hpln.hp.com/.

■ IBM UrbanCode Deploy. UrbanCode Deploy orchestrates and automates the deployment of applications, databases, and configurations into development, test, and production environments. UrbanCode Deploy with Patterns extends these capabilities with environment management capabilities that enable users to design, deploy, and update full-stack environments on multiple clouds. The community website for third-party plug-ins is https://developer.ibm. com/urbancode/plug-in s/ibm-urbancode-deploy.

■ Inedo BuildMaster. BuildMaster facilitates everything from continuous integration to database change scripts to production deployments. The community website for third-party plug-ins is http://inedo.com/buildmaster/integration.

■ MidVision RapidDeploy. RapidDeploy is a tool used to automate the deployment, configuration, and release of middleware, applications, and databases. The community website for third-party plug-ins is http://www.midvision.com/rapiddeploy-plugins-new.

■ Octopus Deploy. Octopus Deploy is a deployment automation system for .NET developers. Octopus works with your build server to automate releases of ASP.NET applications and Windows Services into test, staging, and production environments, whether they are in the cloud or on-premises. The community website for third-party plug-ins is http://library. octopusdeploy.com/#!/listing.

■ Serena Deployment Automation. Serena Deployment Automation is an application-centric deployment automation solution that supports continuous delivery and the deployment pipeline by simplifying and automating deployments across all environments. The community website for third-party plug-ins is http://help.serena.com/doc_center/doc_center.html#sda.

■ XebiaLabs XL Deploy. XL Deploy is an automation solution to support DevOps and continuous delivery teams. The community website for third-party plug-ins is http://xebialabs. com/products/plug-ins.

■ Zend Server. Zend Server provides a PHP stack including application release automation for PHP. The community website for third-party plug-ins is https://github.com/zend-patterns.

Figure 3 Prominent ARA Vendors

Vendor Product Name(s)Version Attunity Attunity Maestro 2.0 Attunity RepliWeb 6.1 AutomicOne Automation 11.0 BMCBMC Release Lifecycle Management Suite4.4 CA Technologies CA Release Automation 5.0 Electric CloudElectricFlow Deploy 5.1 HP Continuous Delivery Automation 1.3 IBMIBM UrbanCode Deploy 6.1 InedoBuildMaster 4.4 MidVisionRapidDeploy 3.5 OctopusOctopus Deploy 2.5.10 Serena Software Serena Deployment Automation 5.1.3 XebiaLabsXL Deploy 4.5 Zend Zend Server 7.0

119004 Source: Forrester Research, Inc. Unauthorized reproduction or distribution prohibited.

Figure 4 Creating Release Package Features

So ftw En vironment templates Single are bill of materials Infr Conﬁgu , logical release created as tr from mult Releases ve templateucture en Ro ration llback suppor

Drif s ve vironmen iple builds ve ve ve t tr rs rs rs rs rs ione ione ione ione ione ac te ke d d d d t d d d Attunity Maestro and RepliWeb • Automic One Automation •• •••••• BMC Release Lifecycle Management Suite •• ••• CA Release Automation •• •••••• Electric Cloud ElectricFlow Deploy • • •••• HP Continuous Delivery Automation •• ••••• IBM UrbanCode Deploy •• ••• ••• Inedo BuildMaster •••• MidVision RapidDeploy •• •••••• Octopus Deploy •• •• Serena Deployment Automation •• •••••• XL Deploy •• •••••• Zend Server •• •••• • Capability as part of the tool • Partial capability • Capability provided by another tool 119004 Source: Forrester Research, Inc. Unauthorized reproduction or distribution prohibited.

Figure 5 Moving Release Package Features

5-1 Support for continuous integration tools

Je At tBrain lassian Bamboo Microsof Cont s Te inua CI Hudson Jenkin amCi t TF s ty S Attunity Maestro and RepliWeb • Automic One Automation • • • • BMC Release Lifecycle Management Suite • • • • CA Release Automation • • • • Electric Cloud ElectricFlow Deploy • • • HP Continuous Delivery Automation • IBM UrbanCode Deploy • • • Inedo BuildMaster • • • • MidVision RapidDeploy • • • • • Octopus Deploy • • • • • Serena Deployment Automation • • • • • XL Deploy • • • • • Zend Server • • • Capability as part of the tool • Partial capability • Capability provided by another tool 119004 Source: Forrester Research, Inc. Unauthorized reproduction or distribution prohibited.

Figure 5 Moving Release Package Features (Cont.)

5-2 Supported OS targets

Wind Mac OS Solari IBM IBM Linu AI ow X i z x s s Attunity Maestro and RepliWeb • • • • Automic One Automation • • • • • • BMC Release Lifecycle Management Suite • • • • CA Release Automation • • • • • Electric Cloud ElectricFlow Deploy • • • • • • • HP Continuous Delivery Automation • • IBM UrbanCode Deploy • • • • • • • Inedo BuildMaster • • • • • MidVision RapidDeploy • • • • • • Octopus Deploy • Serena Deployment Automation • • • • • • • XL Deploy • • • • • • • Zend Server • • • • • Capability as part of the tool • Partial capability • Capability provided by another tool 119004 Source: Forrester Research, Inc. Unauthorized reproduction or distribution prohibited.

Figure 5 Moving Release Package Features (Cont.)

5-3 Supported cloud environment targets

Centur

Amaz Google Cloud Plat yLink Cloud (S RedHat Rackspace Clou on Microsof VMw We IBM Soft IBM Bluemi are vSpher b Se OpenSt Open t Az rv av La Shif ices fo vis ye rm ur ac ) x r e k d t e

Attunity Maestro and RepliWeb • • Automic One Automation • • • BMC Release Lifecycle Management Suite • • CA Release Automation • ••• • • • • Electric Cloud ElectricFlow Deploy • • • • HP Continuous Delivery Automation • • • IBM UrbanCode Deploy • • • • • • • • • • Inedo BuildMaster • • • MidVision RapidDeploy • • • • Octopus Deploy • • Serena Deployment Automation • • • • • XL Deploy • • • • • • • • Zend Server • • • • • • • Capability as part of the tool • Partial capability • Capability provided by another tool 119004 Source: Forrester Research, Inc. Unauthorized reproduction or distribution prohibited.

Figure 5 Moving Release Package Features (Cont.)

5-4 Managing movement of release packages features

Create en Automa GUI for depl vironment from a co Mix of automat ti cally decommission Email no GUI no an en manual step oy ment plan ti vironmen ti ﬁcat ﬁcat ic an ions io py s d n s t

Attunity Maestro and RepliWeb • • • • Automic One Automation • • • • • • BMC Release Lifecycle Management Suite • • • • • • CA Release Automation • • • • • Electric Cloud ElectricFlow Deploy • • • • • • HP Continuous Delivery Automation • • • • IBM UrbanCode Deploy • • • • • Inedo BuildMaster • • • • • MidVision RapidDeploy • • • • • • Octopus Deploy • • Serena Deployment Automation • • • • • • XL Deploy • • • • • Zend Server • • • • • Capability as part of the tool • Partial capability • Capability provided by another tool 119004 Source: Forrester Research, Inc. Unauthorized reproduction or distribution prohibited.

Recommendations Choose A Vendor That Makes Modern Service Delivery Real Based on our analysis of the market, I&O professionals can use the following filters to identify the right ARA vendors for consideration:

■ Does the tool support the right target systems and cloud providers? Consider not only what is supported today but what you need to be supported in the future. Also, consider flexibility and the importance of deploying in different cloud environments.

■ How much governance do you want over your release package? If you are starting out, you may only be modeling the application itself, but eventually, you may want to consider modeling the other parts of the release package to get greater governance and understanding of what is changing with each new version.

■ Does the tool support the ecosystem of tools you use for modern service delivery? We have highlighted CI tools, but other tool integrations to consider are service management and automation, source versioning configuration management, project management, and issue tracking. At a minimum, look for support in your CI tool so that you can increase flow between life-cycle phases.

■ Does the tool add needed automation to your release process? At the end of the day, your ARA tool should fundamentally change your ability to automatically and reliably release into different environments. Choose a tool with the best overall out-of-the-box functionality to meet your needs.

Supplemental Material

Companies Interviewed For This Report Attunity IBM Automic Software Inedo BMC Software Octopus CA Technologies Serena Software Electric Cloud XebiaLabs HP Zend Technologies

Endnotes 1 For more information about how the digital age has changed your market, see the March 19, 2014, “Unleash Your Digital Business” report.

2 For more information about the new release cadence of modern service delivery, see the December 3, 2014, “What Makes Modern Service Delivery Modern?” report.

3 For more information about the modular design of packages, see the October 2, 2014, “The Seven Habits Of Highly Effective DevOps” report.

4 For more information on how containers might affect the future of deployment, see the October 21, 2014, “Brief: Why Docker Is All The Rage” report.

5 An “environment” in the context of services and applications usually refers to the collection of infrastructure, middleware, databases, and various supporting services that are needed to ensure the proper behavior of the service or application being released. Like all other aspects, environments must be properly modeled for best results.

6 For more information about tools and technology needed for the modern service delivery life cycle, please see the December 3, 2014, “Gear Up For Modern Service Delivery” report.

7 Community websites for third-party plug-ins are listed if they are available.

© 2015, Forrester Research, Inc. Reproduction Prohibited January 29, 2015 About Forrester A global research and advisory firm, Forrester inspires leaders, informs better decisions, and helps the world’s top companies turn the complexity of change into business advantage. Our research- based insight and objective advice enable IT professionals to lead more successfully within IT and extend their impact beyond the traditional IT organization. Tailored to your individual role, our resources allow you to focus on important business issues — margin, speed, growth — first, technology second.

for more information To find out how Forrester Research can help you be successful every day, please contact the office nearest you, or visit us at www.forrester.com. For a complete list of worldwide locations, visit www.forrester.com/about.

Client support For information on hard-copy or electronic reprints, please contact Client Support at +1 866.367.7378, +1 617.613.5730, or [email protected]. We offer quantity discounts and special pricing for academic and nonprofit institutions.

Forrester Focuses On Infrastructure & Operations Professionals You are responsible for identifying — and justifying — which technologies and process changes will help you transform and industrialize your company’s infrastructure and create a more productive, resilient, and effective IT organization. Forrester’s subject-matter expertise and deep understanding of your role will help you create forward-thinking strategies; weigh opportunity against risk; justify decisions; and optimize your individual, team, and corporate performance.

« Ian Oliver, client persona representing Infrastructure & Operations Professionals

Forrester Research (Nasdaq: FORR) is a global research and advisory firm serving professionals in 13 key roles across three distinct client segments. Our clients face progressively complex business and technology decisions every day. To help them understand, strategize, and act upon opportunities brought by change, Forrester provides proprietary research, consumer and business data, custom consulting, events and online communities, and peer-to-peer executive programs. We guide leaders in business technology, marketing and strategy, and the technology industry through independent fact-based insight, ensuring their business success today and tomorrow. 119004