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