How can any organization launch products, services and solutions without focusing on the three “P”s – People, Processes and Products?
You need the right people, following appropriate processes using the proper technology or products to accomplish a task or solve a problem. How is this related to DevOps you might ask?
DevOps is about these three most important assets in any organization: People, Processes, and Products. They are the Three Musketeers of DevOps (Tous pour un, un pour tous).
Last week I introduced the DevOps blog series starting with what DevOps means to IT Pros. . Bookmark this site and follow me on Twitter at @volkerw as my team digs deeper into the role of IT Pros within DevOps. If you’re interested in the underlying technology roadmaps and products available from Microsoft and 3rd parties, a new series will start in May at DevOps in the Cloud.
Is DevOps a role or function?
Before we go any further, let’s get this out of the way. What’s this DevOps all about? There’s as many opinions about what DevOps is as there are people in IT – at least. I’m going to rely on an excellent phrase coined by Adam Jacob, founder of Chef and OpsCode:
It is a broad initiative involving most anyone in IT. It is a way of doing work or more narrowly a new way of increasing agility and shortening cycles between application development (Dev) and operationalizing the new application within the business (Ops). Other than the term DevOps might indicate, this movements goes well beyond the Dev and Ops teams. It requires involvement throughout the entire application lifecycle management (ALM) from inception of the idea throughout development, test, and finally deployment, management, and monitoring. But in reality, no one can tell you what DevOps means in your situation. You have to figure it out. Besides all guidance and smart tips, it depends on you and your very specific situation what DevOps means for you. Or to paraphrase a senior leader from a large enterprise who just spoke at ChefConf 2014: “If someone tells you this how to do DevOps, or here is the roadmap, they are full of s**t.” Paraphrasing of course. J
At times it helps looking at what something is not. Let’s look at what DevOps is not. Below my favorites, derived from the Twelve DevOps Anti-Pattern:
- Just Devs and Ops
- A person
- A product
- Just automation
- DevOps is equal to developers managing production
Neither is DevOps just a person or role nor a new process of doing things. You cannot “do DevOps” just by using a new set of products and tools. DevOps is about collaboration across functional boundaries, involves experimentation and the ability to act fast on feedback. And for any DevOps work to be successful it better creates business value along the whole product lifecycle, from cradle to grave.
Enterprise IT is no different but some
Driven by an ever changing business and its requirements to create new and better products and services with a competitive advantage, more and more pressure is put on all groups inside companies. Operations, developers, tester, QA, operations teams, security and networking groups alike, to name a few, feel this urgent need by the business to be not just better than the competition but also faster. Most likely developers experience this first. New features must be delivered faster than ever and with less bugs. If bugs are discovered, hopefully during the testing phase and not by the consumer, fixes must be deployed within hours rather than with a next major update in a few months.
Startups may have a leading edge as they for one do not maintain a large base of legacy code. And with a strong tendency to use Microsoft Azure and other off-premise cloud based services for their core infrastructure and service delivery, there is way less investment in traditional on premise operations, allowing for greater agility. More often than not a startup displays a different culture than traditional enterprises. The whole company is just 10-20 people strong. Everyone may even work on the same floor, in the same room and close collaboration is their lifeblood. And every step that can be automated saves precious time and resources.
On the other hand, larger and more mature organizations may have unique sets of requirements, restrictions, and regulations. Large enterprises in particular. Not to mention the boatloads of legacy code that no startup has to deal with. Other parameters like big geographically distributed teams or regulatory restriction pose challenges unknown to most startups. And in cases we see a natural resistance to change in the existing staff.
Within even large enterprises, however, there might be net-new projects which could easily operate like a startup. Or the next iteration of a service or feature can serve as a greenfield project to try DevOps.
DevOps is for everyone, large and small, startup as well as well-established enterprises. It is just that there is not one size that fits all.. While following DevOps practices should be in the future of companies of any size, careful introduction and thoughtful selection of the approach is key to its success. All enterprises are different from another, posing different sets of challenges for the teams involved.
Microsoft believes DevOps can only be effectively implemented with the help of all of the Three Musketeers: People, Process, and Product. Following ideal DevOps practices requires taking on those three in the order listed.
Over the course of the next few posts we will peek at each of the three musketeers of DevOps and their relevance when embarking on the enterprise journey to DevOps to save the day.
To get you further started, here are a few additional resources to get you into the right mood for the next post.
– Have fun.
*Photo by Flicker user pasukaru76