Spanning people, processes, and technologies: The business case for Collaborative DevOps

1,722 views

Published on

Published in: Technology, Business
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
1,722
On SlideShare
0
From Embeds
0
Number of Embeds
16
Actions
Shares
0
Downloads
33
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

Spanning people, processes, and technologies: The business case for Collaborative DevOps

  1. 1. IBM Software December 2011Thought Leadership White PaperSpanning people, processes, andtechnologies: The business case forCollaborative DevOpsMichael Rowe, Strategy and Market Development, IBM Rationaland Peter Marshall, Strategy and Planning, IBM Tivoli
  2. 2. 2 Spanning people, processes, and technologies: The business case for Collaborative DevOpsExecutive summary not dismiss the very real upheaval experienced by the technicalThere’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 posespractices designed for coordinating software development teams risk.1 Though it is important to innovate regarding new productwith IT operations teams. The talk is being driven by companies and service offerings, many enterprises have back office systemschallenged 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 toAll companies today require agility in their business processes. revenue. This is why—along with regulatory requirements thatWhile many companies limit the scope of DevOps to deploy- impact large, established, businesses and markets—enterprisement automation, IBM takes a much broader view. DevOps is architecture and change control boards are prevalent in largereally about improved automation, integration, collaboration, established companies.and optimization of development and operations, the ultimategoal being improved business outcomes. This paper explores The hidden costs of competing interestsDevOps from this broader perspective and attempts to clarify Some refer to DevOps as simply “bridging the gap” betweenthe 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 variousStartups 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, wesmall startup and an established enterprise. In a startup, the see that the VP of IT Operations and the VP of Developmentprimary focus is on developing a new offering. Constant and both typically report to the CIO. If the two teams are not talkingsmall 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 metricsover 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 orcompromising revenue streams; rather it is about defining a While tension between two groups can be a good thing—and itproduct and creating or validating a business model. The is used extensively in research and development to help innovatepotential for failure during the development of new offerings faster—by providing your development and operations teamsforces 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 toa major business re-alignment, the company’s need to retain operations, which results in operational problems, is one signmarket share and protect revenue streams creates a different set that the metrics are not aligned.of priorities. No doubt, the greatest threat to an establishedbusiness is an inability or unwillingness to change. But we must
  3. 3. IBM Software 3A 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, butNowhere 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 withoutappropriate operational impact analysis and preparations. To provide comprehensive accounting, and to adopt a unified approach to cost reduction, both organizations can use theFrom 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 settingof differing types of cost. For both teams, the cost is associated priorities. As partners, both the development and operationswith a loss that is to be avoided. Development is focused on organizations must plan how to reduce costs both to thedelivering 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 adoptingcosts (both direct and indirect) associated with failures in live, business agility, they must minimize technical debt that wouldproduction IT systems. Balancing these two types of cost can be otherwise be passed to the operations group. In taking thisa problem, because the usually simple, bifurcated analysis fails to approach to realizing business benefits, organizations can engagesee 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 debtThis 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 benefitcost structure. Technical debt essentially refers to the costs As with any new technological concept, many companies whoimposed 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 definitiondoes 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 aboutstage will primarily be carried by the operations organization. In deployment automation. While deployment automation is aan 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 longledger of the operations group. From a business perspective, of as you have a robust governance process already in place; butcourse, the cost is a bottom line issue. The later in the software automating bad practices is never a good idea, since automationlife cycle problems are addressed, the more expensive they can result in institutionalizing practices and making them morebecome. 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. 4 Spanning people, processes, and technologies: The business case for Collaborative DevOpsThis is why at IBM we consider DevOps in a broader context. products that choose to adopt the standards. We find this isRecognizing that both development and operations teams work not a new problem, and therefore should be a simple firstaccording to distinct product and service life cycles, IBM views step in improving the responsiveness of both development andDevOps as a collaboration between the development and opera- operations when addressing production issues.tions life cycles. Collaborative DevOps can raise the abilityof the business to change and do so with reduced risk. This Deploy and run applications collaboratively with enterpriserequires a set of capabilities that span people, processes, and architecture alignmenttechnologies. IBM sees at least three key areas that need to be Enterprise architecture alignment through asset repositoryaddressed 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 businessBuild applications using collaborative incident management changes. Enterprise operations and development teams bothCollaborative incident management aligns with agile develop- have repositories of searchable data that provide a much morement 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 Managementparties without the need for adhoc reporting and meetings, then Database); in development this data may be stored in athey can better focus on their specific roles and responsibilities. variety of asset repositories (from the software configurationAnd when all interested parties have access to information about management system to more formal asset repositories, suchall changes in real time, fewer errors occur. By leveraging as IBM® Rational® Asset Manager software).existing incident systems within the operations space and looselyintegrating them to agile task systems in development, businesses A well-populated CMDB represents those assets that areare able to improve response time, while breaking down the silo supposed to be in the production environment. Many tools arenature 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 Dependencycapabilities. 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 yourdards that can support home grown systems, as well as vendor enterprise architecture to leverage this as-is data for the existing
  5. 5. IBM Software 5operating environment can greatly improve the business’s ability we also need to make sure that we are automating the rightto perform impact analysis when identifying changes to the pro- processes and ensuring that the right rules and architecturalduction environment. By understanding the actual landscape and principles are being adhered to.implications of a product change, operations and developmentcan 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 availabletory, we not only learn the impact of future changes, we can also regarding the production environment. Being able to take thisreduce the time it takes for problem resolution when a problem information as the foundation for planning new functionalitydoes 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 deploymentsthe ability to reduce the duration of any such impacts, and in the enterprise today are completely green field activities. Evenpotentially eliminate them all together through better planning, simple new capabilities will leverage existing data and services inwe 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 usingdrive 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 automationDeployment planning and automation is the third area where Here is a simple example of the benefits of architecturalCollaborative DevOps can make a difference. As we’ve seen in constraint: Application servers are usually not deployed on thethe two prior areas of DevOps focus, we can significantly reduce same device as database servers when designing a system thatrisk 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 areGetting a common lexicon, common data, and improved access driven by development, we increase the likelihood that a newlyto 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 functionalchange 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 itincrease 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 orearlier, automation is where most people begin thinking about staging, and ultimately into the production environment. ByDevOps—the ability to reduce human error through scripting contrast, when deployment planning is done manually, viaand 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. 6 Spanning people, processes, and technologies: The business case for Collaborative DevOpsThe growing interest in DevOps For more informationOur customers have begun to show more interest in the idea of To learn more about IBM solutions for CollaborativeDevOps. Why? We believe it is not just because of the market- DevOps, please contact your IBM marketing representativeing 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/devopsronments. Specifically, the cloud has become a trigger for manyIT shops to consider self-provisioning of development/test envi- Additionally, IBM Global Financing can help you acquire the ITronments. We also see an increasing number of our customers solutions that your business needs in the most cost-effective andleveraging the principles of agile development and starting to strategic way possible. We’ll partner with credit qualified clientsunderstand 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 costdelays in development has caused the business to desire this of ownership. IBM Global Financing is your smartest choice tosame 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/financingability to quickly react to changing market conditions, and theywant this capability within their enterprise. Additional resources: ArticleMarket forces are causing companies to increase the rate of “Virtualizing the Application Lifecycle in the Cloud,” bychange to their production environments. This increases risk Steve Abrams, in Electronic Design, October 16, 2011for 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.aspxpowerful solution that can help address these concerns. This article by Steve Abrams, Distinguished Engineer and ChiefFor years, IBM has been helping customers increase their rate Architect for Cloud Computing, describes the path to cloudof change while reducing the risk to their production systems. computing for development and testing, beginning with using anIBM is considered by many to be a leader in providing an end- Infrastructure as a Service (IaaS) cloud to obtain virtual machinesto-end, integrated, automated, and optimized Collaborative for development and test environments. Abrams also providesDevOps 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. 7. IBM Software 7Podcasts “Collaborative Development and Operations” with Tivoli’s VP“Deployment and Agile Projects” featuring agile development of Marketing, Scott Hebnerexpert Scott Ambler http://www.youtube.com/watch?v=4gi_OY1-9JIibm.com/software/rational/podcasts/2011/#143 Video featuring Scott Hebner at IBM Rational InnovateScott 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 thataddressing DevOps challenges offers to agile project teams and “Collaborative Development and Operations & OSLC” withthe business. IBM Director of Supply Chain Transformation Michael Martine http://www.youtube.com/watch?v=rWOSbc0YKi0“Collaborative Development and Operations” featuringIBM marketing executives Gina Poole and Scott Hebner Video featuring Michael Martine at IBM Rational Innovateibm.com/software/rational/podcasts/2011/#142 conference 2011 in Orlando, FL.IBM Vice Presidents for Rational and Tivoli marketing describe Websitehow to facilitate better collaboration between development and Service Management Connect:operations and offer a path to increased innovation, better ibm.com/developerworks/servicemanagementbusiness agility, and effective and integrated managementthroughout the software and services life cycle. A website that can help you connect, learn, and share with Integrated Service Management (ISM) professionals. Here youVideos 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 implementPeter Spung, IBM Rational ISM solutions.http://redmonk.com/tv/2011/06/05/devops-ibm-with-pete-marshall-peter-spung-ibm-rational-innovate-2011DevOps has a lot to offer to all IT organizations. IBM has takennotice and started getting involved. While at the IBM RationalInnovate 2011 conference, Pete Marshall and Peter Spung offertheir views on DevOps and what IBM can offer.
  8. 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

×