DevOps.com

  • Latest
    • Articles
    • Features
    • Most Read
    • News
    • News Releases
  • Topics
    • AI
    • Continuous Delivery
    • Continuous Testing
    • Cloud
    • Culture
    • DevSecOps
    • Enterprise DevOps
    • Leadership Suite
    • DevOps Practice
    • ROELBOB
    • DevOps Toolbox
    • IT as Code
  • Videos/Podcasts
    • DevOps Chats
    • DevOps Unbound
  • Webinars
    • Upcoming
    • On-Demand Webinars
  • Library
  • Events
    • Upcoming Events
    • On-Demand Events
  • Sponsored Communities
    • AWS Community Hub
    • CloudBees
    • IT as Code
    • Rocket on DevOps.com
    • Traceable on DevOps.com
    • Quali on DevOps.com
  • Related Sites
    • Techstrong Group
    • Container Journal
    • Security Boulevard
    • Techstrong Research
    • DevOps Chat
    • DevOps Dozen
    • DevOps TV
    • Digital Anarchist
  • Media Kit
  • About
  • AI
  • Cloud
  • Continuous Delivery
  • Continuous Testing
  • DevSecOps
  • Leadership Suite
  • Practices
  • ROELBOB
  • Low-Code/No-Code
  • IT as Code
  • More
    • Application Performance Management/Monitoring
    • Culture
    • Enterprise DevOps

Home » Blogs » Enterprise DevOps » The DevOps value stream is not SOP

The DevOps value stream is not SOP

By: Lori MacVittie on June 16, 2014 Leave a Comment

#devops #lean Don’t confuse doing something faster with greater efficiency.

Recent Posts By Lori MacVittie
  • The Definition of Faster in the Age of App Capital
  • Sharding for Scale: Architecture Matters
  • Automation: Critical Missing Pieces in the CD Puzzle
More from Lori MacVittie
Related Posts
  • The DevOps value stream is not SOP
  • Automation versus Orchestration
  • When DevOps-as-a-Service (DaaS) Meets Security
    Related Categories
  • Blogs
  • Enterprise DevOps
    Related Topics
  • automation
  • devops
  • enterprise
  • orchestration
Show more
Show less

Much of the focus on DevOps remains at the implementation level – on gaining efficiencies through automation of tasks and orchestration of processes. While this is not a bad thing, such a micro-focus on the moving parts can result in the loss of efficiencies to be gained at the macro-level.

DevOps Connect:DevSecOps @ RSAC 2022

One of the biggest inhibitors of a timely release cycle is not the moving parts, but rather the process in which those moving part are executed. It’s not necessarily the actual push into production that’s problematic, but the length of time it takes to accomplish certain tasks when they cross internal organizational boundaries.

For example, many years ago we began the process of pushing a new application into production – a web application. This required, perhaps obviously, changes to the corporate firewall. The “process” for accomplishing this change – essentially opening a port on the firewall for the intended public IP address – required no less than five different signatures across networking, security and architecture teams. There were only two security roles allowed to approve such a change, and the process was noted as taking up to 15 days to get a signature on a piece of paper and subsequently a rule change.

err is humanThis was not a task level problem. It was not implementation issues. It wasn’t even difficulty in making the change on the firewall. It was all about the process. Scheduling a release meant taking into consideration not only the readiness of the application itself, but its supporting services – including networking.

This is why DevOps should start with a review of the processes used to release an application into an environment (whether test, QA or production). Mapping out the process is the first step to finding where the bottlenecks might be that are causing delays in moving that application to the next phase of its lifecycle.

Simply automating an existing process may not provide the value expected or touted by DevOps supporters, because if the process is poor, you just end up doing something poorly much faster.

In other words, the value of DevOps is not necessarily in simply automating SOP (Standard Operating Procedure).

The initial Value Stream Map captures the current process as it exists.  This is known as the “As Is.”  It is the actual process flow and should be created through observation of the current flow and with participation of those who are in the process.  Do not make the mistake of pulling a process map from the procedural manual (SOP).  The best technique for mapping is to be the unit (the “thing”) coming through the process. For example, in the insurance industry it might be the policy.  In the auto industry, it may be the car.  In each instance, the Value Stream Map begins with the request for the unit i.e. insurance policy or car.  [emphasis mine]

http://www.goleansixsigma.com/how-to-visualize-a-process-with-a-value-stream-map/

For application deployment, the “thing” is … an application, and the process should be mapped based on what’s actually happening. Only when you have the process mapped can you evaluate it for bottlenecks and understand the steps of the process at which each group adds value. Value is defined as any step that moves the thing (the application” toward the end goal. Efficiency is then measured as a percentage; specifically it’s the value added time as a percentage of the total time it takes to complete the process (the cycle time).

Don’t confuse doing something faster with greater efficiency. If every step of the cycle is automated, the actual process efficiency hasn’t changed. The ultimate goal of DevOps should be about improving the efficiency of these processes, not just doing what’s always been done faster.

Some of the opportunities for improvement in efficiency that will surface is certainly interfaces with other organizational groups. Perhaps it’s that a process step might not take as long if you had relevant data or information up front. If you’re wasting time waiting for some piece of information, that’s not value added time. It’s just cycle time. More cycle time reduces the efficiency of the overall process by overloading it with wasted time. Better information gathering up front can help reduce the wait time and immediately provide greater efficiency of the process.

It is these opportunities for improvement that will be particularly helpful in the enterprise arena, where the issue is not so much attempting to hit ten deploys a day, but rather the predictability and efficiency of the processes that enable teams to hit a specified change window as desired.

DevOps is not about the tools, or the automation of manual tasks. It’s about the big picture, and that means gaining greater efficiencies through process re-engineering and orchestration as well as automation. Focusing on the micro aspects of DevOps will only ensure that if you’re doing it wrong, you’re doing it wrong faster. Step back and look at the big picture, and find those process steps that are really causing inefficiencies in your organization.

Filed Under: Blogs, Enterprise DevOps Tagged With: automation, devops, enterprise, orchestration

Sponsored Content
Featured eBook
The Automated Enterprise

The Automated Enterprise

“The Automated Enterprise” e-book shows the important role IT automation plays in business today. Optimize resources and speed development with Red Hat® management solutions, powered by Red Hat Ansible® Automation. IT automation helps your business better serve your customers, so you can be successful as you: Optimize resources by automating ... Read More
« Five Top Tips for Cloud and DevOps Automation
The web-scale avalanche »

TechStrong TV – Live

Click full-screen to enable volume control
Watch latest episodes and shows

Upcoming Webinars

Continuous Deployment
Monday, July 11, 2022 - 1:00 pm EDT
Using External Tables to Store and Query Data on MinIO With SQL Server 2022
Tuesday, July 12, 2022 - 11:00 am EDT
Goldilocks and the 3 Levels of Cardinality: Getting it Just Right
Tuesday, July 12, 2022 - 1:00 pm EDT

Latest from DevOps.com

Rust in Linux 5.20 | Deepfake Hiring Fraud | IBM WFH ‘New Normal’
June 30, 2022 | Richi Jennings
Moving From Lift-and-Shift to Cloud-Native
June 30, 2022 | Alexander Gallagher
The Two Types of Code Vulnerabilities
June 30, 2022 | Casey Bisson
Common RDS Misconfigurations DevSecOps Teams Should Know
June 29, 2022 | Gad Rosenthal
Quick! Define DevSecOps: Let’s Call it Development Security
June 29, 2022 | Don Macvittie

Get The Top Stories of the Week

  • View DevOps.com Privacy Policy
  • This field is for validation purposes and should be left unchanged.

Download Free eBook

The 101 of Continuous Software Delivery
New call-to-action

Most Read on DevOps.com

What Is User Acceptance Testing and Why Is it so Important?
June 27, 2022 | Ron Stefanski
Chip-to-Cloud IoT: A Step Toward Web3
June 28, 2022 | Nahla Davies
DevOps Connect: DevSecOps — Building a Modern Cybersecurity ...
June 27, 2022 | Veronica Haggar
Rust in Linux 5.20 | Deepfake Hiring Fraud | IBM WFH ‘New No...
June 30, 2022 | Richi Jennings
Common RDS Misconfigurations DevSecOps Teams Should Know
June 29, 2022 | Gad Rosenthal

On-Demand Webinars

DevOps.com Webinar ReplaysDevOps.com Webinar Replays
  • Home
  • About DevOps.com
  • Meet our Authors
  • Write for DevOps.com
  • Media Kit
  • Sponsor Info
  • Copyright
  • TOS
  • Privacy Policy

Powered by Techstrong Group, Inc.

© 2022 ·Techstrong Group, Inc.All rights reserved.