devopsy.kinsta.cloud

Tag: two-speed IT

  • What lane do you travel on the DevOps highway?

    What lane do you travel on the DevOps highway?

    Last week we kicked off our webinar series on Variable Speed DevOps. The discussion was lively and informative. For myself as moderator the webcast was as comfortable as an old pair of slippers. Two of the three panelists, Carme DeArdo of Nationwide and Sanjeev Sharma of IBM are both friends and people I have had the pleasure of appearing with before.  Additionally, Lee Reid, fit right into the discussion, not missing a beat.  You can listen to the recording or view the slides here.

    We discussed Variable Speed IT from many different aspects and how Nationwide has successfully merged onto the DevOps highway.  More than any of the other analogies we spoke about or I have heard, I really like the DevOps highway as a good way to explain Variable Speed IT and Variable Speed DevOps. The notion of multiple lanes with traffic moving at different rates in each lane is a good way to think about Variable Speed IT.

    Of course if only things were that easy. In the variable speed DevOps world the traffic in each lane is directly connected to the traffic in the other lanes.  This is where the expertise of Carmen and the rest of the panel comes into play.  In an organization such as Nationwide (see the first two slides of the deck to get an idea of Nationwide’s scope) coordinating Systems of Records with Systems of Engagements, multiple dev and ops teams and doing it all successfully is orchestration worthy of a maestro.

    Lee and Sanjeev in their positions at IBM have had the chance to work with several organizations like Nationwide so can take lessons learned across an even wider spectrum of experiences.

    All of this added up to a great webinar that I was lucky to be part of in some small way.

    Our deep dive into Variable Speed DevOps continues on May 19th with the Canada Mortgage Housing Corporation explaining how they were able to break down IT silos and in both their mainframe environments (yes even mainframes) and others. You can find out more about this one and register here: https://devopsy.kinsta.cloud/blogs/variable-speed-ibm2/?S_Tact=C34701GW.

    Variable Speed DevOps, 2-Speed IT, Bi-Modal IT – we are seeing lots of different terms to describe a common fact pattern.  We think this series of webinars will explore many of the facets of this subject.

    In them meantime we are off to a fantastic start with our first in this series. I really encourage you to go have a listen.  Many thanks to Carmen DeArdo, Sanjeev Sharma and Lee Reid for kicking us off with a great webinar.

  • Streamlining no matter how many speeds your IT operates at

    Streamlining no matter how many speeds your IT operates at

    IBM InterConnect 2015 took over the Mandalay Bay and MGM Grand conference centers this week with an estimated audience of more than 20,000 attendees. The event is filled with DevOps evangelists, hybrid cloud experts, and IBM customers converging to share information in presentations and panel discussions.

    On Monday I had an opportunity to attend one such panel discussion titled Mobile to Mainframe Experts: DevOps Best Practices for Systems of Engagement and Systems of Record. Yeah, the title doesn’t exactly “pop” but I didn’t let that dissuade me. The panel included a number of respected names in DevOps such as Carmen DeArdo from Nationwide Insurance, and Rosalind Radcliffe and Sanjeev Sharma from IBM.

    In spite of the title of the panel discussion most of the conversation revolved around the concept of two-speed IT. In any organization—no matter how streamlined—there are going to be different processes or teams that function at different speeds. Applying the Pareto Principle, even if the organization figured out a way to operate more efficiently there would still be 20 percent doing 80 percent of the work and 80 percent doing the other 20. It would just be a matter of degree.

    The problem is that if the speeds are too different problems arise. First, it’s just a waste of resources to have skilled workers sitting idle waiting for a different group or process to catch up. Second, those workers will often get antsy and go rogue—writing code and introducing features that weren’t part of the initial requirements and aren’t part of the planned testing. Now you’re just adding chaos that disrupts the workflow even further.

    According to the esteemed panel the goal is to find ways for those processes and teams to function at their own pace without it impeding the overall efficiency —hence two-speed IT. Rather than trying to force a square peg into a round hole, or getting frustrated that the square peg can’t just be round in the first place, you have to find ways to maximize efficiency with the teams and processes you have.

    Carmen DeArdo from Nationwide Insurance applies another term as well: variable-speed DevOps. In essence two-speed IT frames the challenge, and variable-speed DevOps is the set of processes and tools organizations can utilize to address the challenge. Removing some of the friction between different groups and enabling the organization to function more effectively is one of the primary benefits of DevOps.

    When I spoke to Rosalind a couple weeks ago she stressed repeatedly that the foundation of effective DevOps is breaking down silos and finding common ground. That doesn’t mean all the teams have to be restructured under one organizational unit, or even that everyone has to adopt the exact same tools and processes. It means figuring out how they’re different and how they’re alike, and determining ways to make the most effective use of the common ground where their similarities overlap. It provides a starting point to get the ball rolling, and then things can mature and evolve from there.

    In the session at IBM InterConnect Rosalind agreed that variable-speed DevOps is a great approach, but cautioned attendees regarding how it’s used. She told the audience that variable-speed IT should be driven by business needs, not by tools or processes. In other words, you have to stay focused on the business requirements and the need to achieve business goals and then find ways to do that. You can’t try to shrink or adapt the business requirements and goals to fit the processes and tools you already have.

    DevOps tools and processes can—and in most cases should—speed processes and teams up. One of the hallmarks of DevOps is speed. Even as organizations embrace DevOps and introduce more automation, there will still be different teams and processes functioning at different speeds—and a need to implement variable-speed DevOps to enable those different speeds to exist in harmony.

  • Variable Speed DevOps

    Variable Speed DevOps

    I was lucky enough to be the host of a Google Hangout last week with some very smart folks who will be speaking at IBM InterConnect 2015. One of the topics that we discussed was Two-speed IT or as Carmen DeArdo of Nationwide called it, variable speed DevOps.

    What is meant by this term is the realization of the fact that different parts of an organization, even different parts of an IT team move at different speeds. Rather than forcing everyone to move at one speed, how can you use DevOps to allow these different size gears to mesh into one smooth functioning machine?

    Constraints and bottlenecks pop up when one part of the process is allowed to proceed untethered only to either be constrained from a lack of resources or data from a pre-requisite or to be wasted as the output then has to sit and wait around for another part of the process to proceed.  It is almost right out of The Goal by Goldratt.

    How do we achieve a “just in time” method of IT? This is a problem that agile has tried to tackle in the development world, but what about the larger canvas of IT? That is variable speed DevOps.

    Perhaps nowhere is this variable speed issue as visible then when talking about legacy mainframe systems working with modern cloud architectures. Yes IBM’s z/system team has numerous examples of exactly this taking place.  But don’t be fooled into thinking that this is about making old stuff work with new stuff, for it is not.

    I have discussed this with Sanjeev Sharma of IBM as well regarding a follow on panel on this subject that both he, Carmen and Rosalind Radcliffe will be participating in this month at the InterConnect 2015 event in Las Vegas (Mobile to Mainframe Experts: DevOps Best Practices for Systems of Engagement and Systems of Record, Session DEM-4399, Monday 2PM).

    The real key to a successful DevOps implementation is recognizing the variable speeds of the different parts of the organization operate at. Yes automate, yes do more faster, yes, yes, yes. But at the end of the day some processes move like Cheetahs, others like Sloths.  A Sloth is never going to be a Cheetah. The trick is making sure the Cheetah is not wasted behind the Sloth.

    To be successful in DevOps, you cannot focus on one process or part of the story without a keen understanding of the big picture, the whole story. That is part of what I like about DevOps. It is a big picture, big goal game. While it is easy for any one of you to focus in on one piece or gear of the machine, it is the machine that counts.  Machines have big gears and little gears, slow gears and fast gears. Getting them to function like clockwork is the key.

    I think too many people try to get all of these gears to function at the same speed. In most cases this is a strategy destined to fail. Understanding the variable speeds of the people and parts of the process is necessary to cook the perfect dish.

    So next time someone tells you that DevOps is about getting things done faster, remind them that we all can’t be the Cheetah. Sometimes speed kills. In real life we all move at variable speeds. So do different parts of the IT stack. Orchestrating them to be most efficient is really where DevOps wins.