DevOps Strategies: General

DevOps Practices

In a previous blog posting we overviewed the concept of Disciplined DevOps, which is the streamlining of IT solution development and IT operations activities, as well as supporting enterprise activities.  In this blog posting we begin to overview strategies that support DevOps.  This posting overviews general strategies, and future postings will describe development, operations, release management, data management, and enterprise architecture strategies.

There are several “general” strategies that support DevOps:

  1. Collaborative work.  A fundamental philosophy of DevOps is that developers, operations staff, and support people must work closely together on a regular basis. An implication is that they must see one other as important stakeholders and actively seek to work together. A common practice within the agile community is “onsite customer,” adopted from Extreme Programming (XP), which motivates agile developers to work closely with the business. Disciplined agilists take this one step further with the practice of active stakeholder participation, which says that developers should work closely with all of their stakeholders, including operations and support staff–not just business stakeholders. This is a two-way street: Operations and support staff must also be willing to work closely with developers.
  2. Automated dashboards. The practice of using automated dashboards is called IT intelligence, effectively the application of business intelligence (BI) strategies for IT. There are two aspects to this, development intelligence and operational intelligence. Development intelligence requires the use of development tools that are instrumented to generate metrics; for example, your configuration management (CM) tools already record who checked in what and when they did it. Continuous integration tools could similarly record when a build occurred, how many tests ran, how long the tests ran, whether the build was successful, how many tests we successful, and so on. This sort of raw data can then be analyzed and displayed in automated dashboards. Operational intelligence is an aspect of application monitoring discussed previously. With automated dashboards, an organization’s overall metrics overhead can be dramatically reduced (although not completely eliminated because not everything can be automated). Automated dashboards provide real-time insight to an organization’s governance teams.
  3. Integrated configuration management. With an integrated approach to configuration management (CM), development teams not only apply CM at the solution level as is customary, they also consider production configuration issues between their solution and the rest of your organization’s infrastructure. This can be a major change for some developers because they’re often used to thinking about CM only in terms of the solution they are currently working on. In a DevOps environment, developers need to be enterprise aware and look at the bigger picture. How will their solution work with and take advantage of other assets in production? Will other assets leverage the solution being developed? The implication is that development teams will need to understand, and manage, the full range of dependencies for their product. Integrated configuration management enables operations staff to understand the potential impact of a new release, thereby making it easy to decide when to allow the new release to occur.
  4. Integrated change management.  From an IT perspective, change management is the act of ensuring successful and meaningful evolution of the IT infrastructure to better support the overall organization. This is tricky enough at a project-team level because many technologies, and even versions of similar technologies, will be used in the development of a single solution. Because DevOps brings the enterprise-level issues associated with operations into the mix, an integrated change management strategy can be far more complex, due to the need to consider a large number of solutions running and interacting in production simultaneously. With integrated change management, development teams must work closely with operations teams to understand the implications of any technology changes at an organization level. This approach depends on the earlier practices of active stakeholder participation, integrated configuration management, and automated testing.
  5. Training, education, and mentoring.  As you would expect, people will need help to learn and adopt your DevOps strategies.
  6. Continuous improvement.  Disciplined agile teams strive to learn from their experiences as well as from others so that they can continuously improve the way that they work together, including how they approach DevOps.
  7. One team.  An important aspect of the DevOps mindset is shifting away from a “them and us mindset” to an “us mindset.”  We all work together as a single, streamlined team.  An extreme form of this is the “you build it, you run it” philosophy where there are no separate development, operations, data administration teams but instead product teams who are responsible for the entire lifecycle of a product.

Our next blog posting in this series will overview development-oriented strategies.

Have any Question or Comment?

18 comments on “DevOps Strategies: General

Scott — I’m enjoying the new series on Disciplined DevOps — it’s high time to build it up 🙂 and so I look forward to more instalments. I’d like to clarify some terms and put some precision in place. Perhaps I’m wrong, if so — please correct me. “Developer” is a very overloaded term. To me, in this context, ‘developer’ is not a person who writes code, I’d rather understand it as a team member of the delivery team (could be a coder, tester, analyst responsible for requirements, an architect, or all of the above). Just the same way as DEV in DevOps in my mind refers to more than developers (coders). The other confusing term might be CM (configuration management) especially in the context of DevOps discussion where it may mean something different to DEV and OPS. DEV may interpret it as software configuration management wheres OPS would see it as configuration management in ITIL sense.


From what I understand, the steps to DevOps are:
– improve and adjust the process in general
– improve and adjust the process for making possible automation that can improve the process more
– introduce automation where it is enabled and help

The focus must be in a better process (where tools are included) not just in tools.

Agile manifesto says “Individuals and interactions over processes and tools”. Yes… but “Individuals and interactions” it is just a request for a smarter,fluid process versus a rigid process.


Scott, Enjoyed reading it. I think ( and have seen in some of the survey results ) the Application Performance Management ( APM ) is key to the Ops of the DevOps . APM focusses on area where the end-user ( and the ultimate consumer of the code in this software-defined business world ) touches the code. Would love to see your prospecting in your upcoming blogs .


@Mirek, good points. There’s nothing I can really do about Developer being an overloaded term. One of the things we need to get used to in this industry is inconsistent terminology. As far as configuration management goes, you’re right that developers and operations people tend to see it as different things. This is why we use the term integrated configuration management – we need to combine both senses of the term. I think I’ll expand on this idea in the final article.

@Valentin, very good observation about “Individuals and interactions”

@Anand, the way you describe APM seems like a watered down version of the end-user computing (EUC) movement from the 1980s, which in turn was a more realistic version of the “programming end users” vision of COBOL from the 70s. Neither really panned out. What is common are end users working with Excel and sometimes creating their own reports or queries using BI tooling. In the early 90s I wrote a fair bit about EUC and user centered development strategies but I doubt that it’s online any more.

Philippe Bach

Hi Scott,

Thanks for this great article.

I miss one word: security. What is your view on that point? Dev, test, production, … Agile, pragmatic, fast, … But we should not forget: in a secure way. How do you integrate security in the process? I am convinced by the approach, I would be interested to get feedback on successful security integration.

From my point, we should be fully part of the one team… Involved in each sprint. The challenge will reside in the risk acceptation process: the security actors have to be reactive… From the risk assessor to the Business CISO. To the traditionnal risk vs cost paradigm, we now have to add the user experience… Most of the agile projects are linked to mobile apps. My opinion is that security actors are not trained to this major evolution. They have to understand the technology and the user expectations to adapt the risk evaluation process.

Interested by feedbacks! 🙂



Philippe, yes, security is one of many important issues that should be addressed by disciplined agile teams. Whether a team needs a security expert will depend on the situation. In this case, from a DAD point of view, the person would be in the role of Specialist.


[…] The point is that there are several contributing factors to the lack of agreement within our industry as to what DevOps means in practice.  The implication is that when someone is giving you advice about DevOps that you need to understand the scope of what they’re actually discussing.   Another way to understand what DevOps is and how it may apply to your organization is to explore the various DevOps strategies and practices available to you, which we’re doing in other blog postings.  Please see our first post in that series which overviews General DevOps Strategies. […]

Leave a Reply

Your email address will not be published. Required fields are marked *