The DevOps approach to software development and delivery requires trust and collaboration among parties inside and outside of core IT. In adopting DevOps so that it works for all concerns across the enterprise, one of your early goals should be to restore trust among the IT tribes that must work together for faster product deployments and higher customer satisfaction.
Hewlett Packard Enterprise created an enterprise-level DevOps manifesto, rooted in principles created and adopted by HPE’s IT organization, as a way to establish that trust. Here are the seven principles in our manifesto, each of which describes how we work to create great software.
HPE's 7 principles of DevOps
1. Optimized - We are more about accomplishing the goal, rather than being prescriptive of how we achieve it. The variables for optimization (cost vs speed) is driven by the goal.
2. Inner source - All of our code is inner source, by default. Team members work together as a community of interest, so the whole team is greater than the sum of its parts.
3. Scientific - We formulate hypotheses, and validate them with experience and data to take the guess work out of decision-making.
4. APIs - Resources are controlled by APIs. Everything is code, and everything exposes its API.
5. Pipelines - We have all changes go through our continuous delivery pipelines: application, compute, storage, database, network, and operating system. Our pipeline continuously improves the service families vertically, but also horizontally, as developers compose digital products and traditional applications.
6. Teams - Our teams are integrated, empowered, and self-organizing. Communities of interest form naturally to advance the organization, and drive agility and speed.
7. Trust - We value trust and responsibility. We are driven by a culture that rewards horizontal inclusion, trust, and collaboration.
HPE’s principles for DevOps are based on decades of IT experience, on trial and error, and an accumulated sense of what creates a great culture for software development, security, and operations. If you want to understand why we selected these seven elements for our DevOps manifesto, read on.
Following are two binary concepts that explain our sense of tribal identity, which supports this manifesto, and the thinking behind each of the seven principles.
What defines tribal identity?
Consider a large enterprise that employs tens of thousands of people, with an IT organization that consists of 3,000 to 5,000 employees. Within the IT shop, you find engineers and subject matter experts grouped by technology, function, and capability domains. The organization resembles a collection of tribes: the compute tribe, the network tribe, the DBA tribe, and so on. It includes a collection of developer tribes: the SAP (for example) tribe, with factions inside it, the developers for marketing and finance, as well as the cloud developers.
Each tribe has its own language, execution processes, tools, and rituals—in other words, its own culture. Tribal identity in IT is a natural outgrowth over decades of real work experience and adjustments to changes on the technology and business landscape. Expertise within each domain led to silos of capability, with limited trust between one domain and the next. And lack of trust, as Steven M.R. Covey has observed, is what slows businesses down more than anything else.
Two binary ideas are central to understanding tribal identity and the reasons for HPE’s DevOps manifesto:
- Command/control vs. collaboration/inclusion; and
- Systems of record vs. systems of engagement
Command and control vs. collaboration and inclusion
The rationale that made waterfall development popular for so many years was a prevalent lack of trust among IT tribes. This was the world that your management information systems or computer science diploma anticipated for you.
When you got your first IT gig, your IT shop imposed a very methodical, prescriptive, deliberate approach to its deliverables that was dictated by risk, complexity, and cost. You were indoctrinated with the principle that change is bad. Because too much change means you can’t close the books, or you can’t pay employees, or worse, your company is on the front page of a national newspaper, portrayed in a negative light. This is why traditional IT tends to be very guarded and risk averse.
Tribal identity in IT is a natural outgrowth over decades of real work experience and adjustments to changes on the technology and business landscape.
Today’s digital business world is different. More business professionals are tech-savvy, often empowered to do whatever it takes to run their business. Digital business is not about using technology to automate business processes, but rather technology as business products. Today’s software engineers wear business badges, and they don’t have the time or inclination to follow the seemingly burdensome rules and regulations to which their IT counterparts are forced to comply. The apps they produce can be directly correlated with business value, which represents a huge difference from the world in which I grew up.
DevOps originated in green field companies, unencumbered with the traditional IT approach and systems. In smaller companies, they can’t afford (nor do they don’t see value in) an IT department. If they have one, it’s typically small, and in charge of operating the environments and interacting with the infrastructure providers. Developers wear multiple hats, with trust and collaboration built in.
Systems of record vs. systems of engagement
There are two business models at work in the modern enterprise: traditional and digital. Systems of record live in the traditional space, where processes are rote, technologically speaking, and where SAP, for example, serves as the dominant platform. Sure, you might move to a faster, cheaper, better model based on cloud services and technology (e.g.., Salesforce or private cloud), but that’s not revolutionary or transformational.
DevOps originated in green field companies... they can’t afford (nor do they don’t see value in) an IT department.
What’s transformational are the newer systems of engagement, apps that live in the digital space. The digital business model is about interacting with customers, partners, and providers in new ways. The older systems of record are still important, but those systems are not on the front lines of business growth today.
The thinking behind HPE's DevOps manifesto
A central goal of enterprise DevOps is to bridge the divide between the control and collaboration, as well as the gap between traditional and digital systems. For years, these behaviors have divided old thinking from new, fear and experimentation, even dev from ops, for decades.
Here’s what’s behind each of the seven principles in the HPE manifesto, which I believe can serve many organizations, not just ours.
1. Optimized
There are two distinctive qualities: cost versus speed, and what you optimize for depends on your goal. If the goal is to produce, say, a digital banking product, then your chief concern will be getting there fast, and being flexible. Speed and agility are key to getting out there, and competing with your digital banking product. But in the traditional world, it’s all about driving down cost. Speed is less important.
Is the goal a digital product, or automating a traditional process? That answer will dictate the approach—i.e., the how, the way you attack this problem. Speed and agility are two capabilities that must coexist, of course. You still have to close the books, hire and fire, and those systems of record move at a much slower pace, and changes are much more restrictive, with pipelines that are more institutional, compared to the digital world, where speed and flexibility trump cost.
The reality is, speed and agility most coexist in a modern development shop, but they can’t usually be applied at equal levels to the same project.
A central goal of enterprise DevOps must be to bridge the divide between control and collaboration, as well as the gap between traditional and digital systems.
2. Inner source
This refers to the adoption of open source development practices within a team or organization. The inner source principle naturally runs together with the principle of teams (see below). Inner source techniques allow team members to work together as a community of interest, so the whole team is greater than the sum of its parts. When you view things horizontally, rather than vertically, it expands the power of your capability.
Because open source principles and technologies are accepted in the enterprise, it means we simply plug everything into Git, and allow people to reuse code created by others. Inner source is both a technology and a culture, so it lies at the heart of DevOps. It’s collaborative by default, and it breaks down tribal barriers. Regardless of tooling or the culture in each tribe, the cross sharing is valuable, because it contributes to speed, lowers cost of operation, and ensures security.
3. Scientific
Another way of saying “scientific” is “data-driven.” I noted earlier that traditional ops teams tend to be risk averse. But big data techniques, for example, can take much of the guess work out of IT decision making. We now have the ability to ingest volumes of data from multiple sources, whether systems are produced, or human, or machine. And we can develop the optimum algorithms to manipulate that data, to tell you what to do.
In the traditional world, those who scream the loudest get the funding. In the modern world, data drives those investment decisions.
Game Show Network (now known as GSN Games) uses its data to understand what games are winning or losing ,and what their customers want or are willing to tolerate (wait times, etc.). They don’t have to ask for requirements, they don’t have to spin up projects to create outcomes. They can instantly reshape the product to meet customer need.
In the traditional world, those who scream the loudest or make up the best story get the funding. In the modern world, data drives those investment decisions. So data-driven, quantified—i.e., scientific—analysis replaces emotion-based speculation about what works. After all, evidence is the heart of scientific reasoning.
4. APIs
The world revolves around services. The sooner you can rely on APIs, the sooner you’ll be freed from making all those requests of your ops team. If ops teams can package up an identity management service or a tax service, and expose that as an API or microservice, developers get speed, and they can interact programmatically. They can subscribe to a service within an app they’re creating, or other digital property, and compose the rest of the app by way of a service system.
We don’t know what data centers they reside in. We only know they offer an advertised warranty on the services being exposed.
For example, digital banking is a core service offered by many banks. But the rest of the application is based on services that are prepackaged, and exposed as APIs through some sort of engagement experience, such as a catalog. We can subscribe to those services on behalf of our application.
As we gain access to these services, and weave together a service system that produces digital banking outcomes for our customers, we don’t know or care where the security services, or hosting or network services are. We don’t know what data centers they reside in. We only know that they offer an advertised warranty on the services being exposed, and that’s the value of this fourth principle. Its’ all about speed and flexibility.
5. Pipelines
This is all about the improvement and continuous advancement of both the services and applications that those services drive. But continuously releasing an application won’t work if application development is the sole focus. The services on which you’re dependent need to be continuously advancing as well. The ops team and the engineers that sit behind those services must be continuously improving, and releasing what developers need.
Teams need a pipeline that continuously improves the service families vertically, but also horizontally, as developers compose those digital products and traditional applications.
The services you’re dependent on need to be continuously advancing.
For example, if I’m going to create an application hosting service, I depend on network, compute, and storage tribes to deliver services that I value. And because I want developers to come back to me regularly, I’m going to continually improve my hosting service, and I will regularly package it up to make it easily consumable. For that service, I may have workloads in my data center, or workloads at Amazon or Rackspace. But the developer doesn’t care. He or she just wants the workload hosted. So I’m going to continuously improve that application hosting service and have a pipeline for that.
I can also create value-add services, such as a developer workbench that provides all the approved APIs, engineering tool chains, embedded security scanning for code, etc. That will be more attractive to developers because they don’t have to assemble these things themselves.
6. Teams
First of all, what do we mean by “self-organizing?” It’s a holdover from the Agile Manifesto that needs a little examination. Obviously, no manager wants to walk in on a Monday morning to find that his team has “self-organized” themselves out of his organization. What we want are communities of interest that form naturally to advance the organization and drive agility and speed. We want to reorient our thinking from being vertically integrated to being horizontally integrated .
Consider the network tribe in most IT shops. Everything revolves around the network, and they’re going to engineer the best LAN, WAN, SAN on the planet. These are their deliverables. That’s the way the world works for the network tribe. But the modern business is more horizontal in its thinking: “I want to be able to use that access control service in different digital products.”
Organization based on DevOps leads to teams thinking horizontally, rather than vertically.
The point is to accomplish the goal, which is either to drive the cost out of a process (the more traditional goal of IT management), or to drive speed and agility into a digital product (which is the more typical goal for systems of engagement). Both goals are valid, and they are necessary inside a modern organization. To get there, you need to see the world horizontally, and package up more services horizontally by composing ,as opposed to developing stuff.
The point is to accomplish the goal—either to drive the cost out of a process, or to drive speed and agility into a digital product.
Composing is about knitting together reusable components to create a capability. It connects to the inner source concept: There are many reusable components, and as time passes, more and more of them are created.
So at the end of the day, I compose a hosting service with a database service with a web page rendering service; and I include a Google search service, a YouTube microservice, and six other microservices to create my app. Then I provide small amounts of code to fill in the gaps. Here you have a composite app that can run anywhere. In fact, I can put all of this into a container, to achieve not only composability but portability—both of which are ultimate goals.
7. Trust
Do devs ever need to ever wear ops hats? In a small shop, DevOps means “if you build it, you run it.” You’re held accountable for what you built, and for keeping it working. But at enterprise scale, you probably need a different approach. There’s an operations team that's charged with running everything. But we need to improve on our former benevolent dictatorship by bringing the dev and ops teams closer together. If DevOps can build a culture of horizontal inclusion, trust, and collaboration, that’s a good thing.
Operations wants to trust that developers aren’t going to break production with things like open loop code, memory leaks, and security holes. Developers want to trust that ops will not block their path, that they will monitor and manage in real-time, not IT-time. They want to trust that when they make a request for an IT service, it will be provisioned in minutes, not weeks or months.
A starting point for DevOps
If you do a Google search on the phrase “DevOps manifesto,” you’ll find plenty of arguments both for and against having such a thing. But when it comes to scaling DevOps capability to the needs of an agile organization, one whose experience and confidence appears right for moving toward enterprise-level DevOps, writing things down seems like a natural best practice.
This is what made sense to HPE; it’s at least a starting point for improving our company-wide capability in DevOps.
HPE's manifesto may change over time. Drop a comment below and let us know how you might improve on the ideas here, or how your own experiences map to ours.
Image credit: Flickr
Keep learning
Take a deep dive into the state of quality with TechBeacon's Guide. Plus: Download the free World Quality Report 2022-23.
Put performance engineering into practice with these top 10 performance engineering techniques that work.
Find to tools you need with TechBeacon's Buyer's Guide for Selecting Software Test Automation Tools.
Discover best practices for reducing software defects with TechBeacon's Guide.
- Take your testing career to the next level. TechBeacon's Careers Topic Center provides expert advice to prepare you for your next move.
