Spanning people, processes, and technologies: The business case for Collaborative DevOps
1 like946 views
This document discusses the business case for a collaborative DevOps approach between development and operations teams. DevOps at IBM takes a broader view than just deployment automation, aiming to improve automation, integration, collaboration, and optimization across the development and operations lifecycle to achieve better business outcomes. Key benefits of collaborative DevOps include aligning metrics and priorities between teams to reduce conflicting incentives, adopting a shared view of technical debt to minimize costs passed between teams, and gaining efficiencies across the entire software development and delivery process.
Spanning people, processes, and technologies: The business case for Collaborative DevOps
- 1. IBM Software December 2011 Thought Leadership White Paper Spanning people, processes, and technologies: The business case for Collaborative DevOps Michael Rowe, Strategy and Market Development, IBM Rational and Peter Marshall, Strategy and Planning, IBM Tivoli
- 2. 2 Spanning people, processes, and technologies: The business case for Collaborative DevOps Executive summary not dismiss the very real upheaval experienced by the technical There’s a lot of talk these days about DevOps—the shortened teams tasked with implementing changes to business processes. form of “Development and Operations”—which refers to Introducing change to either technologies or practices poses practices designed for coordinating software development teams risk.1 Though it is important to innovate regarding new product with IT operations teams. The talk is being driven by companies and service offerings, many enterprises have back office systems challenged by a fast-moving market, an ever changing regulatory that are highly dependent on known inputs and outputs to pro- landscape, and transformational change. vide a smooth flow of financial and customer information. Even small changes can introduce potentially devastating impacts to All companies today require agility in their business processes. revenue. This is why—along with regulatory requirements that While many companies limit the scope of DevOps to deploy- impact large, established, businesses and markets—enterprise ment automation, IBM takes a much broader view. DevOps is architecture and change control boards are prevalent in large really about improved automation, integration, collaboration, established companies. and optimization of development and operations, the ultimate goal being improved business outcomes. This paper explores The hidden costs of competing interests DevOps from this broader perspective and attempts to clarify Some refer to DevOps as simply “bridging the gap” between the business-based reasons for a DevOps initiative. development and operations. While at a very high level this is true, the real gaps that need to be bridged are the various Startups vs. the established enterprise disconnects between processes, measurements, technologies, Let’s begin by looking at DevOps in the different contexts of a and data. If we look at traditional organizational structure, we small startup and an established enterprise. In a startup, the see that the VP of IT Operations and the VP of Development primary focus is on developing a new offering. Constant and both typically report to the CIO. If the two teams are not talking small refinements of key business processes are the norm. The to each other, then there is a problem. But this lack of communi- goal of developing the core business offering takes precedence cation probably means that the CIO’s organizational metrics over many operational activities. This is as it should be. The risk and measurements need to be recalibrated. to the business is not in alienating established customers or compromising revenue streams; rather it is about defining a While tension between two groups can be a good thing—and it product and creating or validating a business model. The is used extensively in research and development to help innovate potential for failure during the development of new offerings faster—by providing your development and operations teams forces startups to work quickly to achieve value. with incompatible metrics and different incentives, you are building a system designed to fail. The well-known finger point- By contrast, unless an established enterprise is going through ing that erupts when development throws code over the wall to a major business re-alignment, the company’s need to retain operations, which results in operational problems, is one sign market share and protect revenue streams creates a different set that the metrics are not aligned. of priorities. No doubt, the greatest threat to an established business is an inability or unwillingness to change. But we must
- 3. IBM Software 3 A CIO’s efficiency is measured by the impact of information been fixed earlier in the development cycle. Technical debt, systems on the business’s ability to drive revenue or reduce costs. therefore, isn’t just a question of organizational cost tracking, but Nowhere in this mission is a requirement to stop all change or an issue that impacts the business’s bottom line. to constantly introduce new functionality to the business without appropriate operational impact analysis and preparations. To provide comprehensive accounting, and to adopt a unified approach to cost reduction, both organizations can use the From a business perspective, the conflict in priorities and focus notion of technical debt (even without quantifying it in mone- between development and operations can be thought of in terms tary terms) to develop a more mature approach to setting of differing types of cost. For both teams, the cost is associated priorities. As partners, both the development and operations with a loss that is to be avoided. Development is focused on organizations must plan how to reduce costs both to the delivering new application code quickly, and avoiding any lost business—their original priority—and to their partner organiza- opportunity to deliver new business functionality to end-users. tion. For development, this means that as they deploy people, Operations is focused on getting things right, and avoiding the processes, and tools to reduce the cost associated with adopting costs (both direct and indirect) associated with failures in live, business agility, they must minimize technical debt that would production IT systems. Balancing these two types of cost can be otherwise be passed to the operations group. In taking this a problem, because the usually simple, bifurcated analysis fails to approach to realizing business benefits, organizations can engage see a linkage between the two. in a mature, business-focused collaboration that takes the DevOps discussion beyond simply a technology focus. The concept of technical debt This is where the concept of technical debt can be useful, The long view on Collaborative DevOps: because it offers a way for both sides to see a common, holistic Three areas of benefit cost structure. Technical debt essentially refers to the costs As with any new technological concept, many companies who imposed on one organization by the actions of another. For focus on a single function that is 100 percent buzzword- example, if a development organization, in the interest of time, compatible will try to position their product as the full definition does not ensure the performance of a new or updated applica- of the concept. We are witnessing this trend with many automa- tion, the costs of dealing with a performance problem at a later tion tool providers. In their mind, DevOps is only about stage will primarily be carried by the operations organization. In deployment automation. While deployment automation is a an accounting sense, development has moved the cost of non- key component of DevOps, it is not the entirety of DevOps. scalability off its own books and placed the cost of failure on the Certainly, automated deployment is a worthwhile benefit as long ledger of the operations group. From a business perspective, of as you have a robust governance process already in place; but course, the cost is a bottom line issue. The later in the software automating bad practices is never a good idea, since automation life cycle problems are addressed, the more expensive they can result in institutionalizing practices and making them more become. The overall cost to the business in this scenario will difficult to improve in the long run. typically be greater than it would have been had the problem
- 4. 4 Spanning people, processes, and technologies: The business case for Collaborative DevOps This is why at IBM we consider DevOps in a broader context. products that choose to adopt the standards. We find this is Recognizing that both development and operations teams work not a new problem, and therefore should be a simple first according to distinct product and service life cycles, IBM views step in improving the responsiveness of both development and DevOps as a collaboration between the development and opera- operations when addressing production issues. tions life cycles. Collaborative DevOps can raise the ability of the business to change and do so with reduced risk. This Deploy and run applications collaboratively with enterprise requires a set of capabilities that span people, processes, and architecture alignment technologies. IBM sees at least three key areas that need to be Enterprise architecture alignment through asset repository addressed for an enterprise to execute successfully in a linkage addresses the operations team’s need to reduce risk asso- Collaborative DevOps manner. ciated with production change. There is a saying that goes, “If you don’t know where you’re going, how will you know when 1) Build applications using collaborative incident management you are there?” That is, you need to have a plan and an approach to ensure that you are going in the right direction. Enterprise 2) Deploy and run applications collaboratively with enterprise architecture is about defining that path your business is taking, architecture alignment and understanding how the systems need to change in order to get you farther along that path. Most enterprise architectures 3) Manage applications collaboratively through deployment are currently documented in presentation and drawing tools. planning and automation Unfortunately, this means that the data can quickly become stale, and that its value to the business is diminished as the business Build applications using collaborative incident management changes. Enterprise operations and development teams both Collaborative incident management aligns with agile develop- have repositories of searchable data that provide a much more ment processes that are proven within the enterprise. When accurate picture of the current state of the enterprise. In opera- development and operations can both provide data to the right tions this is known as a CMDB (Configuration Management parties without the need for adhoc reporting and meetings, then Database); in development this data may be stored in a they can better focus on their specific roles and responsibilities. variety of asset repositories (from the software configuration And when all interested parties have access to information about management system to more formal asset repositories, such all changes in real time, fewer errors occur. By leveraging as IBM® Rational® Asset Manager software). existing incident systems within the operations space and loosely integrating them to agile task systems in development, businesses A well-populated CMDB represents those assets that are are able to improve response time, while breaking down the silo supposed to be in the production environment. Many tools are nature of many existing problem tracking systems. IBM has been available for discovering what hardware, software, and middle- leveraging the Open Services for Lifecycle Collaboration specifi- ware is actually operating in production. IBM offers this capabil- cations to enable our own collaborative incident management ity with IBM Tivoli® Application Discovery and Dependency capabilities. We have worked with the OSLC community Manager software, which can be used to identify configurations, (http://open-services.net) to create incident management stan- including versions of code running on devices. Allowing your dards that can support home grown systems, as well as vendor enterprise architecture to leverage this as-is data for the existing
- 5. IBM Software 5 operating environment can greatly improve the business’s ability we also need to make sure that we are automating the right to perform impact analysis when identifying changes to the pro- processes and ensuring that the right rules and architectural duction environment. By understanding the actual landscape and principles are being adhered to. implications of a product change, operations and development can better address the change in a common and collaborative As described in the previous section on enterprise architecture, manner. By linking the CMDB to the development asset reposi- there is typically a treasure trove of information available tory, we not only learn the impact of future changes, we can also regarding the production environment. Being able to take this reduce the time it takes for problem resolution when a problem information as the foundation for planning new functionality does occur. Many production errors are caused by out of sync ensures that we can upgrade existing systems. Given the interde- conditions or an incorrect configuration during a move to pendencies of enterprise systems—supply chains, the cloud, production. By providing development and operations with related provisioning models, and so on—almost no deployments the ability to reduce the duration of any such impacts, and in the enterprise today are completely green field activities. Even potentially eliminate them all together through better planning, simple new capabilities will leverage existing data and services in we help operations and development address their joint mission: the enterprise. This means we need to understand what is there, To provide the business with the tools and systems that and how a change may impact the whole enterprise. By using drive revenue. software-modeling tools that understand the complexity of your production environment you will be able to impose the architec- Manage applications collaboratively through deployment tural constraints that presentation tools simply cannot provide. planning and automation Deployment planning and automation is the third area where Here is a simple example of the benefits of architectural Collaborative DevOps can make a difference. As we’ve seen in constraint: Application servers are usually not deployed on the the two prior areas of DevOps focus, we can significantly reduce same device as database servers when designing a system that risk while providing the business with needed changes if we can will eventually scale upward. By understanding, documenting, increase the collaboration between development and operations. and clearly communicating the system requirements that are Getting a common lexicon, common data, and improved access driven by development, we increase the likelihood that a newly to information empowers both development and operations to deployed feature does not adversely impact production perform- better address the needs of the business while implementing ance. After the deployment model addresses all the functional change with a higher level of efficiency and effectiveness. and architectural requirements, the process of automation becomes accurate and can truly reduce the risk to the business. Once you have a good foundation for communications, you can By automating this approved deployment plan, we can test it increase the trust between development and operations, allowing in the various environments as necessary—including unit test, them to move forward and embrace automation. As we noted functional test, system test, performance test, pre-production or earlier, automation is where most people begin thinking about staging, and ultimately into the production environment. By DevOps—the ability to reduce human error through scripting contrast, when deployment planning is done manually, via and repeatable processes. While this is an accurate description, presentations or spreadsheets, each new environment causes additional uncertainty—for example, will all of the required steps be accurately executed and in the right sequence?
- 6. 6 Spanning people, processes, and technologies: The business case for Collaborative DevOps The growing interest in DevOps For more information Our customers have begun to show more interest in the idea of To learn more about IBM solutions for Collaborative DevOps. Why? We believe it is not just because of the market- DevOps, please contact your IBM marketing representative ing and analyst buzz, but because new methods for deploying or IBM Business Partner, or visit: software have enabled businesses to dynamically provision envi- ibm.com/software/rational/devops ronments. Specifically, the cloud has become a trigger for many IT shops to consider self-provisioning of development/test envi- Additionally, IBM Global Financing can help you acquire the IT ronments. We also see an increasing number of our customers solutions that your business needs in the most cost-effective and leveraging the principles of agile development and starting to strategic way possible. We’ll partner with credit qualified clients understand that their operational metrics are, at times, at odds to customize an IT financing solution to suit your business goals, with these practices. The clear value in reducing the cost and enable effective cash management, and improve your total cost delays in development has caused the business to desire this of ownership. IBM Global Financing is your smartest choice to same capability for production environments. These companies fund critical IT investments and propel your business forward. have seen start-ups and internet based companies trumpet their For more information, visit: ibm.com/financing ability to quickly react to changing market conditions, and they want this capability within their enterprise. Additional resources: Article Market forces are causing companies to increase the rate of “Virtualizing the Application Lifecycle in the Cloud,” by change to their production environments. This increases risk Steve Abrams, in Electronic Design, October 16, 2011 for those who are not able to handle the necessary governance, http://electronicdesign.com/article/embedded/ discipline, and automation. Collaborative DevOps is one a Virtualizing-the-Application-Lifecycle-in-the-Cloud.aspx powerful solution that can help address these concerns. This article by Steve Abrams, Distinguished Engineer and Chief For years, IBM has been helping customers increase their rate Architect for Cloud Computing, describes the path to cloud of change while reducing the risk to their production systems. computing for development and testing, beginning with using an IBM is considered by many to be a leader in providing an end- Infrastructure as a Service (IaaS) cloud to obtain virtual machines to-end, integrated, automated, and optimized Collaborative for development and test environments. Abrams also provides DevOps solution that exceeds the capabilities offered by vendors details on a new set of best practices emerging for cloud com- solely focused on automating deployment. puting that extend the collaborative life cycle from application development to operations in a DevOps context.
- 7. IBM Software 7 Podcasts “Collaborative Development and Operations” with Tivoli’s VP “Deployment and Agile Projects” featuring agile development of Marketing, Scott Hebner expert Scott Ambler http://www.youtube.com/watch?v=4gi_OY1-9JI ibm.com/software/rational/podcasts/2011/#143 Video featuring Scott Hebner at IBM Rational Innovate Scott Ambler shares his view on DevOps, including what can be conference 2011 in Orlando, FL. done to optimize the impact on agile projects, and the value that addressing DevOps challenges offers to agile project teams and “Collaborative Development and Operations & OSLC” with the business. IBM Director of Supply Chain Transformation Michael Martine http://www.youtube.com/watch?v=rWOSbc0YKi0 “Collaborative Development and Operations” featuring IBM marketing executives Gina Poole and Scott Hebner Video featuring Michael Martine at IBM Rational Innovate ibm.com/software/rational/podcasts/2011/#142 conference 2011 in Orlando, FL. IBM Vice Presidents for Rational and Tivoli marketing describe Website how to facilitate better collaboration between development and Service Management Connect: operations and offer a path to increased innovation, better ibm.com/developerworks/servicemanagement business agility, and effective and integrated management throughout the software and services life cycle. A website that can help you connect, learn, and share with Integrated Service Management (ISM) professionals. Here you Videos can get access to developers and technical experts who provide “DevOps & IBM,” with Peter Marshall, IBM Tivoli, and their perspectives and expertise to help you implement Peter Spung, IBM Rational ISM solutions. http://redmonk.com/tv/2011/06/05/devops-ibm-with-pete- marshall-peter-spung-ibm-rational-innovate-2011 DevOps has a lot to offer to all IT organizations. IBM has taken notice and started getting involved. While at the IBM Rational Innovate 2011 conference, Pete Marshall and Peter Spung offer their views on DevOps and what IBM can offer.
- 8. © Copyright IBM Corporation 2011 IBM Corporation Software Group Route 100 Somers, NY 10589 U.S.A. Produced in the United States of America December 2011 All Rights Reserved IBM, the IBM logo, ibm.com, Rational, and Tivoli are trademarks or registered trademarks of International Business Machines Corporation in the United States, other countries, or both. If these and other IBM trademarked terms are marked on their first occurrence in this information with a trademark symbol (® or ™), these symbols indicate U.S. registered or common law trademarks owned by IBM at the time this information was published. Such trademarks may also be registered or common law trademarks in other countries. A current list of IBM trademarks is available on the web at “Copyright and trademark information” at ibm.com/legal/copytrade.shtml Other company, product or service names may be trademarks or service marks of others. 1 “The Innovator’s Dilemma” - http://books.google.com/books/about/The_innovator_s_dilemma.html Please Recycle RAW14291-USEN-00