DevOps or DIE
July 26, 2017
Show all

Dev/Ops Enablement Now- Flexible Definition and Moving at Light Speed
At IGNW, I am continually learning every day on the front lines of technology. If you want to be the expert in everything- this is NOT the place to be…IGNW is a learning culture and I get humbled on a daily basis by my clients, partners and employees who are usually quicker, smarter, and more creative than I will ever be. But then this is why I do what I do- because what I learn, I try to use to help my clients, associates and employees improve their business. This brings me to the subject of Dev/Ops….

Our “Chief of Software and Dev/Ops” Phil Taylor and his rockstar team are true industry experts in the ways of Dev/Ops. Phil keeps reminding me that “Dev/Ops is a CULTURE not a product”. “But I help companies consume technologies that create great business outcomes, not cultures”, I say. And he says- “Culture is the best possible business outcome you can have, because all success relies on great culture” and I then say… “ You’re right- as usual”…and I walk away humbled, thinking about Dev/Ops defined…and how much I need to learn in order to help my clients succeed…and how glad I am that we have a smart team!

But then I think more about that conversation… In order to create a great outcome as a consultant, I need to be flexible and adopt vernacular that will allow me to level set with our clients. So instead of being a purist in CULTURE and trying to explain that to clients, “Dev/Ops” becomes a set of solutions, services, tools and processes that ENABLE the CULTURE of automation and continuous delivery – or as close as we can possibly get to that for our clients. Recently we have been working with many enterprise clients and even Dev/Ops technology companies in our practice who have been asking for “Dev/Ops teams”, and “Dev/Ops engineers”- along with “ Dev/Ops toolsets”, “Dev/Ops processes” and whats for lunch? “DEV/OPS of course”… They ask IGNW for this because we are Dev/Ops enablement experts- adept at helping clients with their CI/CD initiatives, up and down the stack. All of this really started me thinking about how to describe our Dev/Ops business in a more accurate way…Positioning Dev/Ops as a mindset should permeate the entire organization in order to create a truly agile and automated approach that can really help our clients.

There are so many definitions of Dev/Ops but the most interesting definition I have seen out there comes from a smart guy at Microsoft Azure: “Dev/Ops is a union of people, process and tools to enable continuous delivery of value to the end user”. If this is the case, and you believe that Dev/Ops is a culture, then Dev/Ops defined this way expands well beyond the IT organization and certainly past the ‘Dev and Ops” teams. To be a true Dev/Ops culture, the entire value chain must adopt principals of AGILE delivery of value and understand the competitive advantages of continuous delivery. So how would this work?

WHAT TO DO
First, we need to understand some of the organizational goals and WHY Dev/Ops. If the culture is going to actually change, this conversation really must happen all the way to the top of the organization, and the C suite should be aligned to the Continuous Delivery mission as a differentiator. What is the differentiator? Today you might be delivering business value in large releases a couple times a year or once a month. Dev/Ops enables you to move as fast as you feel is right for your customers and has been successfully used by organizations to ship value up to 300 times in a single day. Wow. Talk about providing continuous value…. even one release per day is dramatically faster than most organizations go today. So to get to something reasonable, goals should work backwards from the business like this- Competitive Advantage>Faster Time to Market>Dev/Ops Culture>Continuous Delivery>Speed of release>Lower failure rate>Faster recovery times>Rational tools>Next generation technology>Agile processes>Next generation engineers.

Once we have our competitive advantage defined and agreed upon, then we should think about how different pieces work in the Dev/Ops culture with People, Processes and Tools, the opportunities and also where some of the pitfalls are…

DEVOPS PEOPLE
People are obviously key to the Dev/Ops culture. When a client asks us for a Dev/Ops engineer, we usually default to the latest and greatest automation and orchestration tools and technologies- but an additional question might be to seek ATTRIBUTES of a “Dev/Ops” engineer to make sure that they are a cultural fit. Dev/Ops principles demand people with strong communication skills and people that know how to work in a team environment. In Principal, a “ Dev/Ops engineer” could be a coder, a software developer, an infrastructure automation and orchestration expert, or operations folks like network, storage, systems and security engineers. Regardless of which type of engineer, it is critical that these folks understand and align with the goal of continuous delivery. Whats also interesting is that EVERYONE in the culture can have a role in Dev/Ops. From the CEO to HR, Project managers to line engineers, CFO to help-desk and support, and its important for the business partners in the organization to understand the desire for the Dev/Ops mindset.

DEV/OPS PROCESS
Dev/Ops is similar philosophically to Agile- in fact some say it is a derivative of Agile and the next step in a progression of Agile. AGILE focuses on an iterative process to deliver a project, DevOps places additional and equally important emphasis on implementing organizational change to achieve its goals. Culture must adapt because DEVOPS creates the speed of continuous releases, so single project management approach like Agile is not enough for DEVOPS. While both DEVOPS culture and Agile methods seek to release more reliable applications, Agile does this a project at a time and Dev/Ops seeks to continually release application and iterations with high frequency. SO the Dev/Ops process can look like Agile, but it really needs to be defined in each organization specifically depending on the mission. A good Dev/Ops consultant can help with this (hi).

DEVOPS TOOLS
In order to achieve continuous delivery and release, toolsets have evolved that enable Dev/Ops. Tools such as Docker (containerization), Jenkins (continuous integration), Terraform and Puppet (Infrastructure as Code), Vagrant (virtualization platform) and Consul (service discovery)—these few are among dozens of others that we work with and that are used to help enable an organization and its people achieve the Dev/Ops culture. One of the major risks with all of these great new tools are that sprawl can and does happen quite regularly without a good strategy to manage continuous release. When the tool sprawl happens, if the organization is not careful, OPS can start to get confounded by the volume of “needs” of the DEV shop and progress can actually slow down dramatically because managing tools becomes more paramount to the IT organization. What happens if OPS doesn’t believe that the container strategy is secure, or that the existent management tools cannot support the new environments, or that AWS spend spirals out of control because of all the great “free” tools. These issues cause rifts between DEV and OPS if not carefully considered. A good consultant with a “full stack” DEVOPS tools capability can really help cut the clutter and align the tools to the results needed. (hi again).

CONCLUSION- FOR NOW…
When delivering a “Dev/Ops” project or a Dev/Ops engineer or tool- its important to not lose sight of the “why”. If a client is asking us for one of the pieces or parts, the most important thing is to clarify whether there is a more strategic objective or if the request is tactical in nature. Clients need to be asking themselves how a certain tool or person or capability will not just impact “automation” at the IT level, but how this will eventually impact the value chain, or even customer of the client. IGNW can help any sized organization with “The Why” of Dev/Ops as well as “The How” for the tools, processes and people. We can even implement environments NOW that can help to actually CREATE a Dev/Ops culture by enabling smooth working mechanisms between DEV, OPS and anyone else in the entire release cycle.

Leave a Reply

Your email address will not be published. Required fields are marked *