devopsy.kinsta.cloud

Tag: Bi-Modal IT

  • DevOpsDays London 2016: Making Happy

    DevOpsDaysLondon16logo

    We haven’t had a DevOpsDays event in London since 2013. The audience size was about the same at this year’s event, held April 19-20, as I remember from last time, but about 85 percent of the audience were attending a DevOpsDays event for the first time. It was great to see so many new faces, and I guess the high proportion of first-time visitors could be a sign of the maturing and proliferation of DevOps thinking.

    I’m delivering a webcast April 26 titled, “DevOps for Architects,” so on the way to the event I read this book in preparation. At Ranger4 we ask people a lot: “Are you having a good day?” or, “How do you know you are having a good day?” Something has always discomfited me slightly about this, in the same way that “What does good look like?” and, “Just good enough,” trouble me. Can’t we aim higher? What does “great” look like? In the book, the authors talk about “happy days,” and this makes me happy. And this was the theme I took away from the first day at DevOpsDays London 2016—DevOps makes happy.

    Here are a few reasons how:

    First up on the stage was Bridget Kromhout, a DevOpsDays organizer I last saw speak at the DevOpsDays five-year anniversary in Ghent in 2014. Her talk was titled, “Cloudy with a Chance of DevOps”—a succinct introduction to DevOps as it looks today with some key takeways:

    • “Automation is not everything.” Most people get this now, but we meet a lot of people who started with automation and realized they’d skipped to the end. Start with culture.
    • “DevOps is practiced, not purchased.” You might be surprised to find us supporting this, since we make a living out of selling DevOps. But we don’t. We believe that the best way to help organizations transform using DevOps principles is to partner with them—to coach, motivate, guide, challenge and help them move through their journey. This is what we do.
    • “It is not necessary to change. Survival is not mandatory.” This is a quote from the “Godfather of Lean,” Deming.

    Bridget was followed by Joanne Molesky, the co-author of “Lean Enterprise,” a frequently cited must-read for DevOps enthusiasts.

    Key messages from Joanne’s talk were her assertion that technology is no longer the bottleneck, particularly now that conventional business models are under attack. Joanne also cited quantum computing as the key disruptor she sees coming through in the near future. It was particularly interesting to think about what she said about Tesla disrupting not because the company has designed a better, more affordable electric car, but because it is changing the game in terms of how individuals will access the power grid.

    Following on from Bridget’s recognition that not all companies are any where near delivering on the velocity promise of DevOps and the subsequent happiness, key barriers Joanne identified include slow decision-making processes and conflicting goals embedded into many enterprises that have been around for a significant amount of time. She described “process madness” and how most enterprises “plan, do” and forget the “check, act” part of the PDCA cycle. She explained how many organizations have created walls of “no’s”—effectively, “Culture says no”; a sentiment shared by many individuals we spoke with after her session.

    A popular quote that was tweeted multiple times from Joanne was: “You only fail when you fail to learn.”

    Speaking with organizations that are moving to agile and DevOps, many of them talk about their difficulties moving from project-centric thinking to product-centric thinking, a point reiterated by Joanne. She recommended the three horizons framework as a useful tool to plan and enact change while managing the current state. She also had some very useful advice for organizations trying to tackle regulatory requirements: “Understand the intent.” Organizations have a habit of misconceiving and conflating what the regulations say.

    “The best code is that which you don’t write”—a bit like the advice to writers: “kill your darlings.” This is about being lean, planning properly and removing extraneous effort.

    Close to our own hearts, Joanne also emphasized the importance of measuring the things that matter. Similarly, she pointed out that organizations that have a classic “command and control” structure have no hope of being able to do DevOps. When organizations perform cultural change, they must amplify their feedback loops at all levels. By using principles like holacracy, organizations can understand who the sensors are in their business and learn to hear ideas, how to make the process madness sane and let ideas germinate and blossom.

    I frequently quote John Willis:

    “DevOps finally proves how IT can be a strategic advantage that allows a business to beat the pants off the competition. This is the moment we’ve all been waiting for.”

    For far too long IT has been seen as the guys in the dungeon, (ever seen the IT Crowd?) but as John said, these are exciting times for us in IT. As Joanne put it, we used to say IT supports the business, then we said IT is aligned to the business, now we say IT is integrated to the business or, even better IT is the business. This should make us all happy.

    Kris Saxton followed Joanne with a talk we were anticipating highly: “Bi-Modal IT and other snake oil.” We’ve been challenging this term recently, too, so I was happy to find more support that this is an oversimplification of the situation organizations are in and is counterproductive, undermining the type of culture we are trying to create by creating more silos, more “them and us-es.” Put succinctly, Kris said: “Bi-modal IT is poison.”

    As Jez Humble recently said:

    “Gartner’s model rests on a false assumption that is still pervasive in our industry: that we must trade off responsiveness against reliability… This assumption is wrong.”

    Kris said there is a “happy place” where we can have both responsiveness and reliability, velocity and quality, speed and stability. DevOps helps us do this by shifting left, having multi-disciplinary teams, a people-focused culture working to small, scalable scope—and more.

    The rest of day one was filled with slots from the many sponsors of the event, a demo from Pivotal, Ignites and Open Spaces. The last three thoughts I’ll leave you with though were:

    1. Sponsor ServerDensity used its pitch to highlight health and well-being in IT; #hugops. The company is setting up a MeetUp group in London for HumanOps, emphasizing that DevOps is not just automation and it’s here to make humans happy
    2. Microsoft’s Thiago Almeida shared stats on how DevOps initiatives at Microsoft have positively influenced employees’ work/life scores
    3. John Clapham spoke on how he set fire to his car and what this taught him about the currency of empathy and how this can be used to improve life at work

    Check back for coverage of Day 2 of DevOps London.

  • Multi-Speed IT versus Bimodal IT

    Multi-Speed IT versus Bimodal IT

    I wanted to continue our revue of the recent IBM InterConnect conference in Las Vegas last month. We kicked off the revue with the release of our first videos from the show on Monday. Since then we just updated the YouTube playlist of videos available with a new batch. We will be adding to these in the coming days. For this article I wanted to zero in on a topic that I find interesting and have explored before, namely Multi-Speed IT versus Bimodal IT.

    I know that Gartner has led the way in popularizing the term Bimodal IT. Many people have adopted the term to mean that some legacy parts of the IT organization will not be able to operate at the speed of some of the newer DevOps empowered parts of the org. can work at. So it is OK for the different parts to operate at different speeds. You have in essence more than bimodal, but almost bifurcated IT.

    My problem with this scenario starts with the Bi in Bimodal. Bi signifies two, as if there were just two parts in this equation. One moves at one speed and the other moves at another speed. In real life there are more than two parts to the organization moving at different speeds. So multi-speed is much more appropriate than Bimodal.

    My problem goes beyond just comparing two to many though. I have a problem with thinking legacy systems cannot benefit from DevOps, Agile, Lean, etc.  As we have seen, even Big Iron mainframes can be made faster with DevOps. So while different parts of the IT organization can move at different speeds and will naturally do so, it doesn’t mean that legacy systems of record for instance cannot be speeded up using DevOps.

    In my view of multi-speed IT the entire organization is more like the gears in a Swiss watch. Different gears of different sizes, moving at different speeds, but all of them orchestrated to mesh together like a fine timepiece.

    This brings me back to InterConnect. I had a chance to discuss this very issue with a few people who know a thing or two about mainframes and DevOps.  Below is my conversation with Hayden Lindsey, VP of DevOps for Enterprise Systems at IBM:

    As you can see Hayden shares many of my views on this subject, but probably even goes a bit further than me calling the premise of Bimodal IT “snake oil”.

    Hayden was not the only person I spoke to at InterConnect about this subject either. I had a great conversation with Rosalind Radcliffe, distinguished engineer, enterprise systems at IBM (and one of my favorite interview subjects).  Here is what Rosalind had to say:

    While this interview covered topics other than multi-speed IT, I have also interviewed Rosalind before on this subject. Rosalind and I actually did a podcast/DevOps chat on this subject as well.  You can listen and read along to that one here.

    The multi-speed IT versus bimodal IT isn’t just something that IBM sees though. While at InterConnect I also had a chance to sit down with Ralph Van Beek of Rabobank. A Netherlands based bank with operations throughout the world.

    Ralph tells us of Rabobank’s DevOps journey in which multi-speed IT plays a big role.

    If all of this multi-speed IT versus bimodal IT is not enough for you, we also did a good Google Hangout on this same issue prior to IBM InterConnect 2016. Finally, Sanjeev Sharma, author of DevOps for Dummies, wrote a good piece on this subject right here on devopsy.kinsta.cloud that you might find very useful if you are as interested in this subject as I am.

    So that should be enough on this subject to satisfy just about everyone. But if you have something to add to this topic please leave a comment or submit your own article to me here at editor@devops.com.

  • Bimodal IT and Remodeling Traditional IT for Greater Agility

    Bimodal IT and Remodeling Traditional IT for Greater Agility

    Bimodal IT is a Gartner concept created to help CIO’s understand that IT organizations need to support both traditional and agile modes of IT solution delivery and operation in order to make wise choices about infrastructure, process, people, and tools.  Much attention has been given and rightfully so to the disruptive and innovative “Mode 2” teams building on the practices established by web-scale giants like Amazon, and Google.  However, in enterprises there still exists a sprawling majority of “Mode 1”, traditional, industrialized applications run by teams that must focus on risk aversion, security and compliance.  While these will likely not match the innovative velocity of agile IT teams and applications, traditional IT teams are still under pressure to get faster, more agile, innovative, productive and cost-efficient.  Yet, the Mode 2 playbook can’t be applied wholesale to Mode 1 transformation work because it often assumes a greenfield situation—kind of like a new home construction.  By contrast, Mode 1 modernization is more like renovating an existing home that must proceed in steps that address the present realities of applications, legacy infrastructure, business mandates, organizational interactions, and technical skills.

    Understanding Bimodal IT

    The Bimodal IT concepts is meant to distinguish between applications and teams that are traditional in their focus, and those that are agile.  In her blog post on Bimodal IT, Gartner analyst Lydia Leong explains Bimodal IT thusly:

    “Traditional IT is focused on “doing IT right”, with a strong emphasis on efficiency and safety, approval-based governance and price-for-performance. Agile IT is focused on “doing IT fast”, supporting prototyping and iterative development, rapid delivery, continuous and process-based governance, and value to the business (being business-centric and close to the customer).”

    The reason that Gartner promotes the idea of Bimodal IT to CIO’s is to help them see that it can be dangerous trying to optimize processes, human resources, infrastructure, and tools to cover such different modes, and as a result, optimizing to neither.  Rather, the right move according Gartner is to allow agile teams room to develop a brand new set of capabilities that can then help transform the whole organization. Lydia continues in her blog:

    “We’ve found that organizations are most successful when they have two modes of IT — with different people, processes, and tools supporting each. You can make traditional IT more agile — but you cannot simply add a little agility to it to get full-on agile IT. Rather, that requires fundamental transformation. At some point in time, the agile IT mode becomes strategic and begins to modernize and transform the rest of IT, but it’s actually good to allow the agile-mode team to discover transformative new approaches without being burdened by the existing legacy.”

    The Contrast Between Agile and Traditional IT

    Traditional IT and Agile IT are different in a number of ways.  Perhaps an effective way to explain the difference is to picture what these applications and teams look like.

    The classic agile IT initiative in the enterprise is around a mobile, e-commerce or web-centric application that is aimed at moving into new markets, improving engagement with new customer segments, or disrupting a current market.  The application is fully virtualized, and the preferred infrastructure is a public cloud such as AWS.  The team is conceived as a unified, DevOps team of line of business product managers, developers, testers, and operations folks working collaboratively on an agile development methodology. Automation is built deeply into the process, with infrastructure as code tools used to manage public cloud virtual machines and related infrastructure components via well-documented RESTful API’s, plus other DevOps toolchain elements automating and managing most processes, including continuous integration, continuous delivery and continuous deployment of code into production.

    Traditional IT stands in pretty stark contrast.  Let’s consider an industrialized, mission-critical application that has evolved slowly for years.  The application (which is usually composed of anywhere from 5 to 10 or more components) is likely running on a mix of legacy (think RISC UNIX), dedicated (x86-based) and virtualized servers (VMWare and perhaps Hyper-V) running in a private or hosted private datacenter, using a mix of traditional and software-defined storage and connected by Ethernet and Fibrechannel switches.  The application components themselves may be legacy code, making them difficult to quickly port to more modern infrastructure.  For example, I was talking recently with a colleague who told me about his sister who still writes code in Fortran for a major bank.    With such a large, complex, long-lived and mission-critical application suite, the IT organization maintaining it and the developers creating updates and upgrades are highly concerned with quality, reliability and predictable performance.  The nature of the overall team working on an industrialized application is a far cry from the sort of “two pizza” DevOps teams on the agile IT side.  Rather, it’s more of a loose consortium of teams such as developers, testers, security and compliance, plus outsourced contractors and vendors.  The development process is waterfall-based, managed by an application lifecycle management (ALM) suite of some sort.   Automation is scant, and in particular it takes a long time to pull together infrastructure for those dev, test and other teams to perform their jobs.  Despite that, a production-like environment for testing, security, compliance, etc. is considered necessary to minimize downtime and other quality risks.  As a result, release cycles can stretch into many months.

    Modernizing Traditional IT

    When my wife and I remodeled our 1908 Craftsman-style house about 15 years ago, we discovered that an earlier renovation had actually cut out a third of a key supporting beam, leaving one part of the house literally hanging on a beam that was only attached to one side of the house.  Needless to say, we were a bit alarmed to find that out.  When dealing with mission-critical applications and infrastructure, you can’t be careless.  As mentioned earlier, simply taking the playbook for a greenfield, agile IT application and trying to apply wholesale it to a legacy, industrialized application usually won’t work.  Making traditional IT more agile requires a step-wise renovation—a risk-mitigated path that leads towards agile and DevOps practices, but without a great leap into the dark.  The steps need to establish the building blocks to agile/DevOps practice without disrupting the application, without introducing downtime, and while delivering solid returns along the way.  Successful legacy application and service ‘remodeling’ efforts observed in highly traditional organizations such as telecommunications and cable operators provides good ideas on how to take those steps:

    • Identify or Procure Automation Skills:  The initial steps to remodeling Traditional IT are about incrementally improving current practice with automation and at the same time making it ready for agile and DevOps.  This means that to be successful, you need to get some automation skills into the mix.  A team that can’t take hold of its own destiny in modernizing a Traditional IT application is not going to have a sustainable change, and that means identifying or procuring some automation expertise and protecting that person’s time to focus on the renovation rather than on firefighting.
    • Private Cloud IaaS:  One of the most serious obstacles to agility is the painful amount of time and effort it takes to allocate and provision infrastructure for developers, testers, etc. and the lack of standardized, consistent infrastructure environments, due to manual processes.  This is exactly the issue that drives some development teams to go shadow IT and start developing on AWS.  Often times, these development teams then discover that integrating that software into the production environment is plagued with translation issues.  Nonetheless, the first order of business then is for the infrastructure team to establish IaaS that can serve up full production-like infrastructure environments to devs, testers and other constituents.  This isn’t trivial when you’re dealing with a combination of legacy servers, bare metal x86, VMs, and perhaps networking, security and other devices.

    The IaaS delivers a number of key improvements.  First of all, it speeds up access because developers, security, compliance and other personnel can now get access to infrastructure in the space of minutes rather than the space of days or weeks.  More than just speed, IaaS enables asynchronous productivity by various teams to happen 24×7, so that quality progresses in an even fashion, unimpeded by office hours.  This is especially helpful if there are global teams, contractors or vendors involved.  IaaS also provides standardization and consistency across all efforts.  Finally, IaaS saves costs.  Significant amounts of operations personnel time that was devoted to painstaking manual infrastructure assembly can be repurposed to higher value activities, and infrastructure utilization rates can easily double or triple almost immediately, which reduces the need to purchase more capital equipment.

    A word here about GUI’s.  One of the key notes of dissonance that often occurs is when people hear developers say that they don’t want GUI’s, they want API’s.  That in my view is absolutely valid, but more so for Mode 2 Agile IT teams.  It turns out that IaaS GUI portals can be rather helpful in providing an easily understood reference point to multiple teams that may have highly varying understandings of the end-to-end picture of the application and its infrastructure.  For example, if an IaaS self-service portal provides a full visualization of the end-to-end infrastructure involved, a developer who might assume that latency is always near zero might become more aware that there is a WAN in the middle of the end-to-end infrastructure.

    • Test as a Service:  Many development and testing teams have taken some stab at test automation.  However, test automation tends to live and be maintained at the individual level.  The natural follow-on to IaaS is to build a standardized regression or certification of automated tests that can be offered from the IaaS portal—test as a service (TaaS).  This allows teams to access production like environments, do their development work, then easily launch a comprehensive certification test.  Tests naturally should report their results into the ALM tool so that individuals and teams can review results in near real-time to keep the process moving.  The benefits are similar to IaaS:  increased velocity, standardization, productivity and efficiency.
    • DevOps Evolution:  With a combination of IaaS and TaaS, the stage is now set to deploy a DevOps toolchain and start doing cross-functional technical collaboration, and agile methodologies.  For example, the IaaS and TaaS can be launched by a unified continuous integration server upon software development check-ins from any team.  Of course, DevOps doesn’t just mean tools and automation, but the process of coming around collaborative devtest infrastructure and common certification tests to build a common, agile development practice is one of the steps towards a more broadly responsive cycle.

    Conclusion:

    Traditional IT may not be the sexiest beast in the technology forest, but it’s often mission-critical.  Gartner’s Bimodal IT concept encourages CIO’s to let go and let Mode 2 Agile IT teams do their thing to create new culture and practices.  Translating that to Traditional IT requires a more step-wise approach.  Progressing from manual processes to IaaS to systematized, self-service test automation as the foundation for DevOps evolution is a sound way to proceed.  With these steps. Traditional IT can “do IT right” and do IT faster.

    About the Author/ Alex Henthorn-Iwane

    AlexAlex Henthorn-Iwane joined QualiSystems in February 2013 and is responsible for worldwide marketing and public relations. Prior to joining QualiSystems, Alex was vice president of marketing at Packet Design, Inc., a provider of network management software, and has 20+ years of experience in senior management, marketing, and technical roles at networking and security startups.

    Through his roles at QualiSystems, Packet Design, CoSine Communications, Corona Networks and Lucent Technologies he has acquired expertise in cloud computing and the opportunities presented through virtualization. He has written for Embedded Computing, Virtual Strategy Magazine, Datamation, SDN Central, Datacenter Knowledge and InformationWeek.

    Connect with him on LinkedIn, Twitter, or SlideShare.

  • DevOps and Bi-Modal IT

    DevOps and Bi-Modal IT

    Can a business have two competing approaches to delivery and operations of their information infrastructure and be successful? If you follow Gartner recommendations, it would seem that bi-modal IT is the way to go. Bi-modal IT has been explained many different ways, but, ultimately, comes down a failure in leadership; allowing a subset of IT to continue to operate in an non-optimal way because it’s too expensive and difficult to transform. This results in formation of a secondary subset of IT leveraging emerging trends that have demonstrated results to deliver modern information infrastructure faster with reliability.

    If we examine from the 50,000 foot view, bi-modal IT actually makes a lot of sense. Disruptions are happening everywhere and businesses need to respond quickly. For many of these businesses IT can barely keep the core systems afloat let alone bear the burden for handling creative exploitation of massive data growth, enhanced customer experience and transformation to new compute platforms. A nimble team with the right skills can facilitate forward movement in these areas with little disruption to the core business. Moreover, they can establish a framework and approach that enables the core business to adopt when ready.

    The issue is when we move down to 5,000 feet, this strategic viewpoint becomes a series of tactical actions that have the potential to spell long term disaster for the business. For example, the data that feeds many of the new digital applications is actually housed in systems being managed by the “traditional IT” group, which means that the “fast” team now is reliant upon the “traditional” team to enable access. Needless to say this is fraught with many hurdles; everything from heel-dragging due to animosity to lack of skills to lack of slack time needed to make the changes to support. While the stick might help with heel-dragging there’s little it can do to fix the lack of skills or slack time issue.

    Technical and operational debts are finally coming home to roost for many of these businesses. Lack of attention to automation, documentation, training and staffing are now creating a Sophie’s Choice for many IT and business executives.

    • Where do we invest?
    • Do we spend time and money making what we have work better before addressing the needs to compete in a digital economy?
    • If we do this, how far behind will we fall?
    • If we follow a bi-modal IT strategy, do we risk losing critical resources needed to support our existing systems?

    For years we’ve been telling the business that downsizing and budget cuts for IT is a mistake. The reduction in headcount and budget continued to squeeze existing resources to take on more responsibilities. As we now know through DevOps research the larger the quantity of work-in-progress being managed the more likely the increase in defects during the build process and the higher the likelihood of outages in production.

    If there is a possibility to escape this conundrum, it most certainly is not bi-modal IT. Leveraging a nimble team to meet the needs of digital economy is fine, but they must work cooperatively with the traditional IT teams. Prioritization of backlog and increased transparency with the business is critical for moving forward. The business has to accept they can’t do everything they want that’s new and keep all that’s running today. Specialization must be reduced through standardization to reduce complexity and bottlenecks. Increased automation efforts will reduce time spent on manual operations and afford time to support other key efforts. Visualization and communications of work-in-progress across teams will minimize conflict and foster faster prioritization of critical efforts. Finally, moving to fewer changes with increased number of releases will enable the business greater opportunity to prioritize efforts.

    In summary, one could say that the fix for IT isn’t going bi-modal, but adopting continuous delivery and lean IT approaches.