Through the years in my career, I have spent a fair amount of my time advising customers on Agile software development. Having practiced various Agile methodologies since the late 1990s, I've witnessed many implementations of Agile, both successful and not so successful. In more recent years, the notion of Agile has expanded across organizational boundaries and given way to a newer concept known as DevOps. While these two topics dovetail nicely and my years of past experience are relevant here, interesting questions always arise. Consider the following question that I received recently:
Question
What are the migration milestones in building out a DevOps group?
I suggest that this question be reframed a bit. For an organization to enter the world of DevOps means that one must adopt a mindset that is focused on agility in the processes and the methods used to execute those processes. It is very important that you identify the best way of carrying out that mindset across your organization and that it include not only software engineering, but also the customer, the business folks, quality engineering, test automation, release management, security, operations, system administration, etc. DevOps is about a fundamental reorientation to provide software in a more effective manner beginning with design and going all the way to production deployment.
Remember SOA?
I will draw an analogy here to a recent trend in software architecture. The concept of a service-oriented architecture (SOA) embodies a set of principles for designing and developing software. It's the 'why', not the 'how' of software architecture (i.e., SOA is a means to an end, not an end in itself). Numerous vendors took the SOA term and twisted this notion into a wrong-headed marketing message that basically said, 'Buy our software and you will be doing SOA'. I spent a lot of time dispelling this myth over the last several years, encountering much resistance along the way. But make no mistake, SOA is not a technology problem.
If someone asked me about forming a SOA group inside their company, I would tell them that they already have one and it encompasses the customer, the software architects, the software engineers, the quality engineers, the release engineers, the security experts, and the operations folks. There is no need to assemble a brand new group. Would you advocate the formation of an Agile group inside a company? I certainly would not because interpreting a methodology in such a literal fashion seems to me like you are already driving the car into the ditch and through the corn field. When I was a kid I learned a term for stuff like this, an Arkansas screwdriver (also known as a hammer). Just because you can doesn't mean you should.
Over the years, I have worked with many companies to get them on the road toward designing applications by using SOA. When I do this, I lead the customer toward the identification of folks across the organization who can participate in this effort. I was certainly not alone in this effort and this style as there are many others doing the same/similar thing. Although we operated on the idea that we were coaching customers to develop apps using SOA via Agile methodologies, I now realize that we were also already leaning toward DevOps. (Based on my research, this is really how the DevOps movement came to be what it is today.)
A Perfect Match
Getting back to the original question, I would not approach DevOps any differently than I have approached the coaching of customers into the use of Agile methods. Continue to coach customers in this manner and you will be successful. Only now, we have even more information and wisdom telling us that this is not just for software engineers. This is a fundamental change for an organization and should be broken down as described on the
Agile Admin blog like so:
- Agile principles: The core values that form the Agile movement (see the Agile Manifesto)
- Agile methods: Methodologies for running an Agile approach including Kanban, Lean, SCRUM, XP, etc.
- Agile practices: Procedures for executing an Agile methodology including Acceptance Testing, BDD, TDD, User Stories, Continuous Integration, Continuous Deployment, Daily Meetings (aka Standup Meetings), etc. etc.
I tend to think about DevOps in the same way that I think about Agile or even SOA, but with a bit more reach across the organization. That is,
DevOps is a set of principles for designing, developing, testing, deploying and supporting software. Each role will utilize different tools but they will all be involved in the overall software development lifecycle. DevOps is also a means to an end, not an end in itself. Some of it's main differences are that it cuts across an organization even further to include many roles and people, and it considers software development as a full lifecycle instead of only focusing on the software until its a teenager and then throwing it over the wall to operations and hoping it survives.
The Value of DevOps to the Business
Finally, the value of DevOps to the business is often misunderstood or not understood at all. Historically, the business side has treated software development as someone else's problem. The perception has often been that the propeller heads down the hall are responsible for the software, not the business side. This has always struck me as terribly short-sighted, especially for a company that would not make money without its software.
Consider another analogy here to depict this situation appropriately. Businesses love to equate themselves to sports teams and I've heard this one before, so I'll use the idea of a pro cycling race team (please forgive my cycling fever during this Tour de France season). A pro cycling team operates in a smooth, fluid manner handling anomalies as they arise without disruption. Like any good team it has the following characteristics:
- A clear direction with clear support and resources from the business side
- Team members have a good relationship with one another and with supporting companies or organizations
- The team monitors many external factors that effect their performance and their success
Although a pro cycling team has its recognizable personalities in the riders, there are many more people behind the scenes who make them successful. Without the entire team working as one they will not be successful or will be less successful than they planned. The team sponsors, the directors, the managers, the mechanics, the masseuses, the assistants, the domestiques, and the recognized riders all must be in tune and ready for success. They each have well-defined roles and operate in tandem across organizational gaps to be the very best at everything in pro cycling. I don't believe that these teams would be successful if they did not include everyone in the orchestration. There's also certainly a lot of luck that needs to be on their side to be successful, quite like the business world.
A company that relies on its software to make money is very much the same. Consider the following comparisons:
- Just as a pro cycling team has a clearly defined direction, so should a company that relies upon software. This message needs to be tuned appropriately to fit different areas of the business, but the overarching message remains – create a machine to make money.
- Just as a pro cycling team has clear support from the business side to stay on top of the technology in its field, so should a company that relies upon software. This means that time must be dedicated to the craft of building software, continued education where necessary, the purchase of materials (books, publications, etc.) and tools, etc. Do you want excellent, highly talented mechanics, masseuses and domestiques or just mediocre ones?
- Just as a pro cycling team forms close relationships between team members, so should a company that relies upon software. This doesn't just apply to folks who work in the same department. The most important relationships are those that span boundaries and break down barriers between departments within an organization.
- Just as a pro cycling team learns to execute flawlessly together, so should a company that relies upon software. Consider that the software a business relies upon to make money is the bike and the rider that a pro cycling team chooses. Do you think that the pro cycling team just arbitrarily decides how to prepare and train for events? Or do you think the pro cycling team has a strict, regimented formula to its training and preparation? A business that relies upon software to make money should also have a strict, regimented formula for crafting, testing, deploying and supporting it's software. Without this level of capability, the ability of the business to make money on a consistent basis is hamstrung by its own processes or lack thereof.
Conclusion
The bottom line is this: A business that deems its software to be critical needs the ability to get that software to market in a consistent, repeatable manner every time. Period. How can this be achieved without involving all of the parties who touch that software in some way?
Today I was trying to figure out how to quickly change the JAVA_HOME environment variable from the terminal using the /usr/libexec/java_home command-line utility. I looked at /usr/libexec/java_home --help but didn't pay close attention to the usages because I was in on the phone. As my friend Martijn Dashorts pointed out, there's a manpage for this utility. I am embarrassed to admit that I didn't even think to check for a manpage! My idiot moment for the day, I guess. Here are the two aliases I created:
