Welcome!

@DevOpsSummit Authors: Destiny Bertucci, Pat Romanski, Yeshim Deniz, Dalibor Siroky, Liz McMillan

Related Topics: @DevOpsSummit, Linux Containers, Apache

@DevOpsSummit: Blog Post

Enterprise DevOps Governance Gates By @Plutora | @DevOpsSummit [#DevOps]

Which side of the wall of confusion are your governance gates on?

Which side of the wall of confusion are your governance gates on?

Whenever people discuss DevOps they always speak of a "Wall of Confusion" between development and operations, and while there is certainly a barrier to understanding it's more than just a "wall."  I see it more as a "canyon of distrust" or a "gulf of miscommunication."

The Canyon of Distrust

These are all just creative ways of identifying that there is misalignment between development-focused and operation-focused parts of the IT department.  On a very simple level development tends to focus on revenue growth while operations focuses on revenue protection.  One side is resistant to change and risk and the other exists only to introduce change and risk - bridging these two worldviews is the constant promise of DevOps.Here's how I model this disconnect: as a series of roles distributed along a spectrum of development and operations.  The farther apart two job roles are on this spectrum the more difficult it is for individuals to communicate about software risk management and releases.

Plutora Governance Gates1 A DevOps architect might work closely with a release engineer.  The two might be in completely different departments, yet they are both responsible for supporting similar processes.  A DevOps architect and a release engineer are in agreement about release management and risk.On the other hand getting a software developer on the phone with a infrastructure support engineer focused on disk arrays is to get two people on the phone who likely won't be able to understand each other's work at all.  If there's an issue during a release that involves these two individuals collaborating it will likely involve miscommunication.

The majority of interactions between these two groups tend to happen in the middle of these two areas and they often happen around a release with senior developers interacting operations support and site operations.  If an organization doesn't provide the proper support from the proper roles you have a recipe for misalignment. If you expect your network engineers to hop on the phone with your senior architects every time something goes wrong then you'll have inefficient, unpredictable releases. The goal of release management is to make sure that interactions and governance gates are happening at the right point in the spectrum at different times during the process.

Where to place your release governance gates?

I recently saw an announcement from a popular cloud infrastructure provider about a Continuous Integration system that is able to double as a deployment tool providing the ability to add "governance gates" to a release process.  This sounds great until you start to think about what this means for an organization.The idea of putting a release governance gate so strongly on the development side of this equation might be compelling for an organization that is driven by development, but for larger organizations with more prominent operations departments the idea of placing governance gates right next to your continuous integration system is far too simplistic.

When you are evaluating the risk of a release and approving a release it is important that you include both development and operations roles into the decision making process.  Release governance isn't just about putting everything into an ITSM tool like BMC Remedy and filling out forms and it certainly isn't something that can be wholly automated in a DevOps-focused Jenkins CI server.Release governance is a shared responsibility and if you do it right you are including roles across the spectrum of IT bridging differences and making sure that incompatible views of software risk are aligned to achieve larger goals.

Your release governance process should act as a bridge over this "Canyon of Distrust" and it should assure both development and operations that the right people have assessed a project's risk and have agreed that a release has met a series of conditions.Release governance, when done right, is a shared responsibility. So, the right answer to "Which side of the wall of confusion are your governance gates on?" is "both."

With Plutora we offer the tool that gives you the ability to bridge this gap and provide the right information to the right roles to assess Go/No-Go decisions across a broad section of the IT department.

More Stories By Plutora Blog

Plutora provides Enterprise Release and Test Environment Management SaaS solutions aligning process, technology, and information to solve release orchestration challenges for the enterprise.

Plutora’s SaaS solution enables organizations to model release management and test environment management activities as a bridge between agile project teams and an enterprise’s ITSM initiatives. Using Plutora, you can orchestrate parallel releases from several independent DevOps groups all while giving your executives as well as change management specialists insight into overall risk.

Supporting the largest releases for the largest organizations throughout North America, EMEA, and Asia Pacific, Plutora provides proof that large companies can adopt DevOps while managing the risks that come with wider adoption of self-service and agile software development in the enterprise. Aligning process, technology, and information to solve increasingly complex release orchestration challenges, this Gartner “Cool Vendor in IT DevOps” upgrades the enterprise release management from spreadsheets, meetings, and email to an integrated dashboard giving release managers insight and control over large software releases.

Comments (0)

Share your thoughts on this story.

Add your comment
You must be signed in to add a comment. Sign-in | Register

In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.


@DevOpsSummit Stories
ChatOps is an emerging topic that has led to the wide availability of integrations between group chat and various other tools/platforms. Currently, HipChat is an extremely powerful collaboration platform due to the various ChatOps integrations that are available. However, DevOps automation can involve orchestration and complex workflows. In his session at @DevOpsSummit at 20th Cloud Expo, Himanshu Chhetri, CTO at Addteq, will cover practical examples and use cases such as self-provisioning infrastructure/applications, self-remediation workflows, integrating monitoring and complimenting integrations between Atlassian tools and other top tools in the industry.
A strange thing is happening along the way to the Internet of Things, namely far too many devices to work with and manage. It has become clear that we'll need much higher efficiency user experiences that can allow us to more easily and scalably work with the thousands of devices that will soon be in each of our lives. Enter the conversational interface revolution, combining bots we can literally talk with, gesture to, and even direct with our thoughts, with embedded artificial intelligence, which can process our conversational commands and orchestrate the outcomes we request across our personal and professional realm of connected devices.
The need for greater agility and scalability necessitated the digital transformation in the form of following equation: monolithic to microservices to serverless architecture (FaaS). To keep up with the cut-throat competition, the organisations need to update their technology stack to make software development their differentiating factor. Thus microservices architecture emerged as a potential method to provide development teams with greater flexibility and other advantages, such as the ability to deliver applications at warp speed using infrastructure as a service (IaaS) and platform as a service (PaaS) environments.
The use of containers by developers -- and now increasingly IT operators -- has grown from infatuation to deep and abiding love. But as with any long-term affair, the honeymoon soon leads to needing to live well together ... and maybe even getting some relationship help along the way. And so it goes with container orchestration and automation solutions, which are rapidly emerging as the means to maintain the bliss between rapid container adoption and broad container use among multiple cloud hosts. This BriefingsDirect cloud services maturity discussion focuses on new ways to gain container orchestration, to better use serverless computing models, and employ inclusive management to keep the container love alive.
While some developers care passionately about how data centers and clouds are architected, for most, it is only the end result that matters. To the majority of companies, technology exists to solve a business problem, and only delivers value when it is solving that problem. 2017 brings the mainstream adoption of containers for production workloads. In his session at 21st Cloud Expo, Ben McCormack, VP of Operations at Evernote, discussed how data centers of the future will be managed, how the public cloud best suits your organization, and what the future holds for operations and infrastructure engineers in a post-container world. Is a serverless world inevitable?