Author: JP Morgenthal

  • Lean versus the bandwagon, lean wins

    Lean versus the bandwagon, lean wins

    I’ve just finished reading “The Phoenix Project,” by Kim, Behr and Spafford. To be honest, it was on my reading list but had I not picked up a copy at Camp DevOps I don’t know that I would have ever read the book. My main issue with books of this ilk, such as “Who Moved My Cheese” and “The Energy Bus,” is that the story is often contrived for purposes of delivering the learning points. So, I was surprised by how much I was able to relate to the issues in Phoenix giving it an air of reality I was not expecting.

    Phoenix follows the life of a new VP of IT Operations through his early weeks on the job. Plucked from obscurity as the Director of Mid-range Computing after his management chain was seemingly asked to depart the company, Bill’s eyes are opened to a world of heroics and chaos that surrounds him in IT and has had detrimental impact on the company’s financial and competitive performance. For anyone who has logically questioned, “how can that happen?” in their own companies, the authors do a great job of illustrating the paths that lead to the unimaginable outcomes we see every day in our own IT world.

    That said (spoiler coming), I ask the authors, did we really need to make Bill’s dad an alcoholic? Sorry, completely tangential point, but interestingly, one of the few times where I thought the authors had reached into their “drama box” for reasons that are still unclear. Nonetheless, after reading this book, I reflected upon the content that is being created around DevOps movements and realize that there is a polarization effect occurring.

    Camp 1 I categorize as the “lean camp”. This camp represents those that believe DevOps should be the application of lean manufacturing principles on IT. In this perspective IT is represented as a critical hub through which business is enabled and transacted. In accordance with this perspective, work enters the hub through multiple endpoints and must be prioritized and coordinated in order to ensure that a) critical IT resources are sourced appropriately and with maximum value to the business and b) constraints and bottlenecks are minimized, thus allowing work-in-progress to complete successfully. Anyone who has studied any aspect of logistics, manufacturing or supply-chain management understands the number of variables involved in this type of scheduling, but applying this to IT is significantly more challenging since it requires the cooperation at both the 30,000 foot view and the 10 foot view, with the latter required to understand the impact of scheduling conflict and help foster collision avoidance that could lead to outages.

    Camp 2 I categorize as the “bandwagon camp”. This camp represents individuals that are using DevOps as a lever for their careers. Certainly, DevOps is the hot topic of the day and having it on the resume is certainly good for a few extra brownie points and higher salaries. Ask these individuals what DevOps is about and you hear answers, such as, “it’s about changing the culture in IT,” “it’s about getting development and operations to cooperate more effectively,” or my personal favorite, “it’s about automation.” The truth is that DevOps needs aspects of all of these factors but driven under an umbrella of work described in the Camp 1 description above. Acted on independently under the guise of DevOps and we will see DevOps nose dive into Gartner’s trough of disillusionment very quickly.

    Will things get fixed in Camp 2? Probably. Certainly implementing controls around who can make changes and when they can occur may help many businesses limit the unplanned work that is crippling their ability to address other work efforts. However, since this is not the focus of the DevOps effort, unplanned work will continue to come from other areas, it’s just the nature of the beast and without correcting the actions that foster unplanned work, it will continually have a negative impact on the business.

    The authors of Phoenix have done a fantastic job of providing IT leaders with a goal for their DevOps programs. If they are wise, they will rapidly adopt the principles defined therein and make sure that all other so-called DevOps efforts in the company are aligned for purposes of reigning in the chaos and free-wheeling efforts of rogue IT employees. I recently met with a VP of IT for one of the major food distribution companies. I was awed by how effectively his IT organization operates, but now I realize, that his company is primarily a logistics and supply-chain company that happens to move food. It only makes sense that the principles they use to run their business would be adopted for IT as well; especially with their IT leaders coming from other parts of the business. In combination with Phoenix, the meeting locked it for me that the lean principles are key to positioning IT as the business enabler needed to be competitive in the current era.

  • The DevOps master process: design

    The DevOps master process: design

    In speaking, counseling and talking to people with regard to DevOps, I often frame the discussion in terms of the DevOps master process. While all of the parts of the master process are important, one aspect very often is overlooked. I call this often overlooked aspect the design stage.  The design stage includes the gathering and visualization of requirements. If we assume that our goal is to deliver higher quality and more consistent and resilient deployments, then we must include expectations for how the software should operate and perform.

    When we are able to streamline and optimize the DevOps master process we ensure maximum velocity and agility for delivery of IT services to the business. The importance of the master process is that it applies for both businesses that develop their own software as well as those that operate using only Commercial-Off-The-Shelf (COTS) and Software-as-a-Service (SaaS) products. Before discussing what is involved with design in more detail, let me take a moment to better define what I mean by the DevOps master process:

    1. Design

    2. Build

    3. Test

    4. Stage

    5. Deploy

    6. Operate

    In future articles I will explore each of these elements in greater depth. For this article I wanted to focus in on the design element specifically.

    To ignore the design aspect of the master process means that we have no linkage for what we are building or testing during the Dev phase and no concern for performance and service levels in the Ops phase. Simply because there are no tools that help to automate this aspect of master process, does not mean that it is not an important aspect to fulfilling our DevOps mission; it simply means that we need human intervention to ensure that our requirements are met at each stage of the process.

    However, this is not all a one-way street with requirements only dictating to operations. In the past, traditional requirements gathering often focused on function with very little thought given to performance or consumption. Through our new DevOps collaboration, we introduce operations into the requirements gathering phase, which means that we can capture critical elements, such as service levels and usage models, ensuring all work across the master process leads to meeting these operational requirements. This will, hopefully, limit the spike in support calls operations needs to respond to immediately after deploying new software into production.

    Perhaps the reason we don’t yet hear about the importance of this is because it’s difficult and the tools for requirements gathering and automation around testing against the requirements traceability matrices just don’t exist in the current popular DevOps tool chains. Dare I say, these have been completely ignored by the open source community? It would be understandable since open source communities grow out of interest more so than need and developers are more inclined to work tools and technologies that are interesting to their own efforts. Perhaps we will see better integration of automation of testing not only features but also service levels, from the enterprise DevOps software providers, such as IBM who are applying their Rational suite of tools toward DevOps initiatives.

    Regardless, to achieve optimal benefits from DevOps, we need to automate around the entire master process. This means that we must translate requirements into automatable tasks by linking them to specific unit tests and load stress testing and ensuring that the requirement is only satisfied once these tests have passed.

  • Services As A Model For DevOps Communications

    Services As A Model For DevOps Communications

    DevOps is an interesting movement. As with any effort of this magnitude, there will be many opinions on what is entailed in adoption and implementation. The issue is that businesses are so diverse and varied in culture that no single method for adoption is guaranteed to fit all businesses. In large IT organizations, this issue is additionally hampered by the fact that multiple cultures and dominions exist.

    Thus, I am not a believer that DevOps adoption comes from the approach that the business commits to adopting DevOps. The business has committed to many initiatives over time that have not panned out. This is not necessarily failure, but perhaps just shifting priorities, shifting political landscape, lack of training or simply a lack of desire to change. “The best laid plans of mice and men ….” and all.

    If commitment is not hampered by people, then there’s a good chance that DevOps adoption may be hampered by silos. This does not make silos our enemy. Silos help to compartmentalize and provide focus. Still, silos limit the ability to orchestrate process without involvement and participation from each of the silos.

    Regardless of the reason, the challenge stands, how to align a process without the use of force. The answer is protocol. With protocol, an individual or group does not need to buy into the entire process, but just needs to understand their role. Short of incompetence or insubordination, or even both, which will eventually result in the removal of these particular types of hurdles, following protocol ensures that every role in an activity will complete their action and, thereby, facilitate the whole with roughly an 80% success rate.

    I posit that the service is the means for defining protocol and of communicating that protocol into an IT organization, such that DevOps is the natural activity and outcome. A proper service entails defining a number attributes, for example:

    • Metered
    • Valued (priced)
    • Advertised / Catalogued
    • Governed
    • Monitored
    • Supported
    • Documented
    • Quality
    • Available
    • Intuitive

    It is up to each area of IT participating in the DevOps process—Design, Develop, Test, Stage, Deploy, Operate—to contribute to defining and providing their completed artifacts that pertain to formulation of the service. The service will guide the development in the understanding of operational characteristics and will allow operations to ensure they can deliver and support the service to the level of expectations of the consumer. Moreover, in those cases where the service is not meeting appropriate levels, it will allow them to provide development with the appropriate data and metrics to take corrective action, thus leading to fewer and shorter outages and failures.

  • DevOps Is Free? Sure I’ll Support It

    DevOps Is Free? Sure I’ll Support It

    One of the biggest misnomers about DevOps is that since it’s all about process and communications there aren’t any costs associated with adoption. Sure, you can probably gain some improvement by simply modifying your current methods for delivering IT services in your organization, however, DevOps is about more than just modest improvements.

    Let’s explore why organizations that are succeeding with DevOps are succeeding over traditional IT approaches. From the article, “Fresh Stats Comparing Traditional IT and DevOps-Oriented Productivity,” also on devopsy.kinsta.cloud, we see that DevOps is driving down time spent on tasks where there is no value being added to the business, such as support, deploying changes, communication and firefighting. Time spent on these tasks reduce opportunities from innovation and responding to business needs, leading the business to view IT in an unfavorable manner unable to help them meet current business demands.

    Where DevOps-oriented teams do spend time is on automating repetitive tasks so that they don’t continually consume time, self-improvement and innovation. Instead of treating IT like assembly line workers capable of only completing the task at their station, which causes friction and increases turnover, DevOps-oriented organizations foster an environment where workers are rewarded for ensuring quality and reducing overhead.

    image-for-devops-com-byline

    So, where are the costs associated with becoming a DevOps-oriented organization?

    • Training / Education – DevOps transformational activities takes funds and requires outside training and, possibly, consulting. For businesses that desire to move forward but are stuck in the Catch-22 that is keeping the bus rolling while trying to paint it, it can be daunting to make the necessary changes. Getting past this point often requires groups trained in helping businesses make these types of transformations.
    • Tooling – There’s some great Open Source tools that can help drive continuous integration, automation and orchestration. However, the worst thing that can happen is that getting these tools to work the way you need them to ends up consuming resources and time that you’re trying to give back to driving business value. The supported versions of these tools will provide software support and deliver tested versions, which will minimize unnecessary disruptions.
    • Updates / Refresh – Older versions of some infrastructure components or software packages may not support automation efforts. Since this is a key element of DevOps, it may be a requirement to do a technical refresh or software update.
    • Platform Changes – Alas, the big kahuna, the platform change may be a necessary action to enable your IT team to become more agile and alleviate some operational challenges. The cloud is a perfect example of a platform change that supports DevOps. A platform change can be very expensive, but the long-term benefits need to be weighed; especially if it speeds transformation of your IT team into one that is agile and more quickly addressing the needs of the business.

    So, can you do DevOps without any financial outlay? Probably so, but the benefit received will be nominal, your team will most likely feel shorted and look to work for a business that has fully committed to a DevOps approach and the real time consuming sinks in your business will continue to exist eating your IT budget like a bear eating salmon in preparation for winter hibernation.