devopsy.kinsta.cloud

Tag: devops adoption

  • Executive Buy-in May Be Preventing DevOps Success

    Executive Buy-in May Be Preventing DevOps Success

    A common misconception in the executive suite is that an organization can reap all the benefits of DevOps without fully embracing the change necessary. That’s understandable, given that a DevOps transformation is a lengthy, costly disruption for companies of all sizes. DevOps requires businesses to transform, from team organization to culture to development processes. This shift often sparks reallocation of power and influence, which sometimes can make high-level executives uncomfortable. While most companies have begun to recognize the overall business benefits of DevOps, few are fully committing to such a large undertaking. As a result, a hesitant executive suite holds an organization back from realizing the full potential of DevOps.

    The key to successful DevOps implementation has four facets. Executing against one element just isn’t enough—an organization must combine all of them to realize the benefits of DevOps:

    • Training: Once executives have educated themselves on the importance of DevOps and accepted the disruption that comes with it, they must make sure the individuals are properly trained. Everyone involved needs to be open to learning new skills and new ways of functioning. A big part of DevOps is breaking down team silos, so individual contributors need to be willing to work across functional boundaries.
    • Tools: DevOps adoption can be viewed as a cultural and methodological change, and therefore teams also need the right tools that help them work together to create scalable and secure applications efficiently. The executive suite should invest in platforms that support automation and collaboration.
    • Support and determination: To provide support and guidance throughout the shift to DevOps, organizations should consider hiring a DevOps expert or bringing in a third-party consultant. This person can help the executive suite map out a DevOps strategy and help train the teams involved. Lack of expertise is one of the reasons businesses often fail to complete a DevOps transition.
    • Cross functional and accountable teams: A DevOps team should have all of the resources necessary to implement and deliver functionality to the customer. They should also be accountable for operating and supporting it.

    Another important consideration is security. The CISO and security team are responsible for security in most organizations, but developers need to understand the critical role they play in creating secure applications. They need to be accountable for the security of the software they write. It’s up to the security team to train and nurture them until they are self-sufficient. The development organization as a whole must be willing to make security part of the annual goal-setting process and to report on progress transparently at each level of management.

    Every DevOps implementation begins with education, from management to the individual contributor. Educational resources increasingly are available as DevOps continues to gain momentum in the industry. If faced with a hesitant executive suite, teams should leverage proof points from other companies that have successfully implemented DevOps. Leadership should be ready to measure, experiment, iterate and, most importantly, stick with it. When armed with the right training, tools and support, organizations can gain a competitive edge with DevOps.

    — Pete Chestna

  • Quality Culture, DevOps Forge Better Connections Between IT, Lines of Business

    Quality Culture, DevOps Forge Better Connections Between IT, Lines of Business

    The automation of software development does not obviate the need for a collaboration between IT and the lines of business, or the development of a culture of quality on the part of the development team. Achieving that quality culture requires more than a change in mindset as developers seek to align quality with the speed and automation goals of DevOps.

    There are five items required for a quality-driven DevOps environment:

    1. Understanding the proper role of “minimum viable product”
    2. Collaboration between IT and lines of business
    3. Having metrics in place
    4. Across-the-board buy-in

    “Quality culture is characterized by employees who are motivated to consistently strive for the highest level of quality,” said Al Riles, principal consultant at Tunnell Consulting, a firm providing solutions to the complex problems faced by life sciences and biopharma companies. “That’s one key component of it, as well as the ongoing process of continuous improvement.”

    Minimum Viable Product and Continuous Quality

    Aligning quality with the speed and automation goals of DevOps is critical to success, and part of this is gaining a deeper understanding of the role of “minimum viable product” and understanding when that approach contributes to the development process.

    “The concept of ‘minimum viable product’ does not, as its name would suggest, contribute to a substandard product,” said C.R. Venkatesh, CEO of Dot Com Infoway, a CMMI Level 3 IT company. “Quite the contrary, the concept is the basis of continuous and iterative improvement, and encourages the use of user feedback, which often results in insights that might be missed by the in-house team.”

    The concept of quality culture and MVP are not mutually exclusive in a DevOps environment, so long as continuous improvement is part of the equation.

    Collaboration Between IT and Lines of Business

    The collaboration that is a key part of DevOps is also a key part of quality culture. “You have a culture in place where everyone embraces that fabric that includes the right type of behaviors and the right values, including communication, reward and recognition, as well as clarity on roles and responsibilities,” said Riles. “That working fabric gets well-defined, because everyone is functioning around the same key elements that constitute that strong corporate culture.”

    “Collaboration has always been important in a DevOps environment,” said Venkatesh. “But we need to define precisely where that collaboration exists. In an internal environment, that collaboration is between IT and lines of business. Increasingly though, IT and development is an outsourced function, and in such cases, that collaboration must be preserved. What this means is that it exists not just within the confines of the outsourcing provider, but also between the provider and the client. The developer must seek out alliances not only with the client’s sourcing manager, but also with other internal stakeholders in the project.”

    If You Don’t Measure, it Doesn’t Exist

    Quality initiatives require an active role in changing the mindset of all stakeholders, but mindset alone won’t get the job done. Metrics must be in place and tied to those quality initiatives. “Even in the smallest of development projects, defined quality metrics must be set ahead of time, with clearly defined outcomes,” said Venkatesh. “By asking what we hope to accomplish with a development project, clearly defining the goals and adhering to a set of predefined quality standards, developers—whether in-house or third-party—are able to accurately predict what the outcome will be.”

    Riles’ process involves a quality management maturity grid, which identifies multiple dashboards. “It allows the organization to become familiar with what a quality organization consists of, and then you can use this maturity grid to measure where the organization is once you embrace this initiative. Then, you can implement the initiative, and come back and re-evaluate yourself to see the progress you’ve made,” said Riles.

    Everybody Has a Seat at the Table

    Incentivizing all stakeholders, throughout every level of the company, is paramount and, according to Riles, “It has to do with communicating what the vision is, and having a clear quality message that’s coming from leadership. Then, there has to be a shared quality mindset among all staff.” Riles notes that the quality mindset is shared by everyone in terms of understanding the organization’s objectives, policies and procedures and their roles in hoping to achieve them.

    This is reinforced by leadership at all levels, who are actively engaged in supporting the development of a quality culture, and they engage and motivate others to do the same. For it to be sustainable, we realize that success is based on the sum of all parts of the organization. They must be continuously monitored and fine-tuned as the organization grows, and this includes communication, reward and recognition, and engagement.

    About the Author / Dan Blacharski

    Dan Blacharski is a thought leader, advisor, industry observer and PR counsel to several Internet startups, and author of the book “Born in the Cloud Marketing: Transformative Strategies for the Next Generation of Cloud-Based Businesses.” He has been widely published on diverse subjects relating to cloud computing and technology, and he is editor of BoozeHub.com. He lives in South Bend, Indiana with his wife Charoenkwan and their Boston Terrier, Ling Ba.

  • Overcoming the People, Culture Barriers to DevOps Adoption

    Overcoming the People, Culture Barriers to DevOps Adoption

    The fact you’re reading this article on devopsy.kinsta.cloud suggests you’re already a DevOps fan. Or maybe you’re visiting this site because you’re considering moving to DevOps in your organization, or you’ve been told you must move to DevOps and are figuring out how on earth to do it.

    Whatever your view on DevOps, let’s get my position clear from the outset: I am a big believer in the power of DevOps to deliver continual innovation to an organization. I advocate DevOps in every project I do because I believe those organizations that innovate and change the fastest become the leaders in their sector, and since almost every business innovation relies on a technology innovation first (“every company is becoming a technology company,” after all), DevOps is the best way for an organization to adapt to, and benefit from, new technologies and gain a lead in the market.

    However, as anyone who has managed the transition from waterfall to DevOps will know—or, in fact, anyone who has overseen any change management project will know—the transition is rarely a smooth one. So, what is behind this reluctance to innovate and work in new ways?

    First, the Technical Arguments

    At some point, most organizations have been burned due to a lack of quality control in technology, whether a security breach, bugs or implementations/changes that went horribly wrong. We all know stories like these. They can have an immediate and catastrophic effect on the organization’s ability to do business. Therefore, there has been a tendency to inhibit change in favor of “stability” and known entities, and to adopt a “Better the devil you know,” strategy.

    DevOps has rocked this view of the world, and teams are reticent to move away from tried and tested approaches and processes because they are held responsible for operational stability. In addition, those people in a quality-control role believe their very purpose and job is under threat. There is also a view that DevOps is system- or application-centric, and can introduce risk to an interconnected IT estate.

    While these are all valid concerns, it is worth bearing in mind they are all technical arguments against DevOps, and they have all been countered before. Implemented correctly, DevOps does not jeopardize stability or undermine quality (in fact, many would argue it does the exact opposite), and it does not undermine a person’s role in development or operations, but rather liberates them from their silos.

    Culture is the Real Reason

    From my experience, innovation of any kind cannot be held back by technicalities alone. While the technical arguments are certainly valid, in most instances, the reluctance to adopt DevOps comes from something much more basic: the organizational culture borne from natural human behavior. Most people are simply risk-averse and resistant to change, so the resistance to DevOps is just a manifestation of human nature.

    The only way for DevOps to succeed is to change the organizational culture to be more open to change and to adopt an “innovation mindset.” The change must also encompass the whole organization. If you only bring half of the business with you, the innovators will become frustrated and find ways to circumvent processes and policy, resulting in additional operational risk and shadow IT.

    The influence that senior managers can have in facilitating—or undermining—the move to an innovation mindset must also be factored in. It is common for senior management to inadvertently foster a hero culture, where those individuals who get things back on track after a catastrophic event are rewarded, yet the well-structured and “stable” DevOps deployments are not given the same weight or focus. Again, it is human nature to be drawn to the dramatic event than the non-event. But you must ask yourself: As exciting as firefighting is, is it a sustainable way to run a business?

    Instilling a new mindset into a business is the same as any other transformation project. It requires you to tackle the four elements of process, organization, technology and information to bring about meaningful and sustainable change. To bring DevOps into your organization you must:

    • Align operational teams with development teams, embedding where possible for early involvement of Ops.
    • Ensure that operational/non-functional requirements have the same weight and priority as functional requirements—no user story is complete without a stable and secure operational environment.
    • Automate where possible to reduce human error and increase the speed of delivery.
    • Improve knowledge management to reduce “hero culture” or bottlenecks where knowledge is concentrated across a few people or one team. Never make exceptions for “heroes”; you need their support more than anyone else because they hold the biggest sway over the rest of the team.
    • Have accurate and comprehensive configuration information. Having a good understanding of the IT estate (including interconnectivity) can help move an organization from a one-size-fits-all governance model to a tailored risk assessment approach through better understanding of the impact of changes.

    DevOps often fails when people can revert to their default behavior. Only by actively identifying and supporting a project in a DevOps manner (considering process, organization, technology and information as previously explained) will you be able to change to a new “business-as-usual” innovation mindset and behavior. But this needs strong sponsorship, guidance and patience.

    DevOps must become the culture of the organization, driven from the top as well as the engineering teams, and people need to understand the implications for their role and responsibilities. CEOs and leaders need to actively support and drive the change, while providing the necessary working environments (tools and training) for those people who will be held accountable for operational stability. It is no good investing in technology and training for engineering to innovate if your ITSM functions are not brought along with the change, for example. But if you bring everyone with you, and address all concerns along the way, you will soon be reaping the rewards of the DevOps approach.

    About the Author / Romy Hughes

    Romy Hughes is director at Brightman. Romy is a business change specialist with expertise in service integration and management (SIAM) for managed services, business transformation and IT service management (ITSM and ITIL). Connect with her on LinkedIn.

  • Top 5 Issues Curtailing DevOps Adoption

    Top 5 Issues Curtailing DevOps Adoption

    DevOps may seem simple and logical on the surface, yet most of the companies we talk to are struggling in one aspect or another. This is no surprise: Successful DevOps initiatives require putting together a full toolset and simultaneously creating a smart team of developers, testers and project managers who are well-versed in cloud and agile technologies.

    Those tasks alone can take many months of trial and error until you are ready to start DevOps in earnest. After a period of experimentation, it’s time to refine and optimize. Focus shifts to more mature issues such as creating a fully integrated tools stack, supporting a rich test data environment that doesn’t undermine privacy and security, and determining the best DevOps infrastructure strategy for your company.

    Regardless of your DevOps maturity, we’ve outlined some top issues to consider and mitigate, as your DevOps practice evolves.

    Integrating Tools

    As the practice of DevOps matures, we have seen an explosion of tools, both open-source and commercial. These tools serve every discrete need in the process: requirements management, test management, defect tracking, agile planning, source code management, build, deployment, monitoring and more. We calculate there are at least 1,500 such tools available today.

    So, while developers, testers, project managers and business analysts have many sophisticated capabilities to streamline DevOps, those tools must work together. It’s imperative that tools and groups don’t work in silos, but are part of an integrated pipeline. This allows the code to flow seamlessly according to business objectives, from requirements definition to test and dev, production and deployment. Organizations may choose to create these integrations themselves—although that gets costly fast, both at the onset and with ongoing maintenance. Some vendors offer out-of-box integrations with popular tools, although you must consider if these will fit your workflows and needs. A few vendors now offer the best of both worlds—connectors that are simple to set up and with the ability to easily customize the integration when needed.

    Configuration as Code

    A common problem in DevOps is the need to align the environment configuration present when/where the code is written with the environment configuration used in production. By adopting configuration as code (consisting of tools and processes), you can store all configuration data as a file alongside the code. This is valuable because if there are bugs or UI issues, your staff can quickly locate the version of the configuration that matches the code/feature in question and load it into that environment quickly. If we are confident that the environment configuration is accurate, we can narrow down the app failure being most likely due to the code itself.

    Having both code and the configuration setup information in one place is also useful for testing purposes, as infrastructure configurations sometimes differ between development and testing worlds.

    Fast is Not Free

    Software teams have always wrestled with the need to balance speed with quality and cost. You can’t get the best of everything, so teams should figure out where they can compromise and where they can’t. In DevOps, however, the emphasis is almost always on speed. Once you reach maturity, you usually go fast and achieve high-quality results, yet this requires investing in tools, process and people.

    Working smartly can go a long way toward moving faster without sacrificing quality. If your team can figure out how to be efficient and precise, with clear objectives, then you won’t have to do much rework, which adds cost and time. Many people will flaunt the benefits of full automation to work faster. In many cases, however, automation ends up being a more expensive solution to the problem. Automation adds additional maintenance and overhead that needs to be outweighed with saved effort; you will have more tools and integrations to maintain, and more pieces that will break.

    Justify how much automation you need and acquire only the tools necessary to meet your goals. Ideally, organizations should determine the need for speed based on business requirements. Many industries are not driven by speed to market and benefit more by working in a steady, iterative fashion. Make sure you have a sound business reason for working faster and releasing faster, and that you can effectively manage the automation and staff needed to work at that pace.

    Acquiring Test Data

    For high-stakes applications, such as a new e-commerce site or mobile customer app, there is a great deal of risk in launching an app that hasn’t been tested on representative data. Accumulating enough high-quality test data to find bugs and optimize all the key features and scenarios before going live can be a monumental task given today’s big data initiatives, fragmented DB technologies and data privacy/security concerns. Specifically, when companies are dealing with sensitive data, such as customer information and credit card numbers, this is a tricky endeavor.

    One common option is to use real customer data and “scrub” it to remove identifying characteristics. If the cleansing process is not thorough, however, you’re creating tremendous security risks for customers. Another basic option is to create fake data that’s representative of production data. However, that data might not be accurate in all key scenarios, nor comprehensive enough to meet your QA objectives.

    Our analysis is that test data is a complex problem that no one tool can solve, and should be handled with importance as a cross-functional initiative. It’s not unusual to see security, compliance, testing, development and business personnel involved in test data management activities, especially for companies handling sensitive data.

    Internal vs. External Hosting

    DevOps environments seem to run optimally in the cloud. Cloud infrastructure gives organizations the optimal scale, flexibility and speed to run more builds and test faster through highly automated services. Top providers including AWS and Azure offer a full range of DevOps-oriented services to manage infrastructure for you, such as load balancing, log and instance monitoring and automatic backup/failover. With many DevOps vendors hosting their products and services in the cloud as well, it’s logical to host the entire environment there.

    However, this isn’t possible for many organizations with strict security and compliance requirements. Running a DevOps infrastructure internally requires a great deal of configuration, maintenance and software, not to mention staff to maintain it all. Automated testing often can be time-intensive when limited machines are available in the internal network for testing. Running those tests may require waiting for the weekend to free up resources, given the many hours required to complete those jobs. This, in turn, causes significant delays in testing and code quality feedback.

    One solution to this problem is using containers to scale the internal DevOps infrastructure. This allows more tests to run at once and reduces the overall build process time. Companies strictly doing web development can use open-source tools to do this. Conversely, large enterprises with apps on multiple platforms will need to build out a great deal of their own infrastructure.

    It’s a Process

    All of this might seem overwhelming to organizations just getting started with DevOps. But remember that DevOps is a journey taken over time; it is more than just new tools and skills. DevOps is a dramatic and evolving way to develop software and services that meet the frequently changing demands of customers. DevOps is the only way organizations can truly become data-driven operations, supporting new revenue streams and product innovation. When viewing it through this lens, we know that change will be gradual. Celebrate the small wins with low-risk projects first, and work to drive efficiency wherever possible.

    About the Author / Kevin Dunne

    Kevin Dunne pic

    Kevin Dunne is vice president of strategy and business development at QASymphony. Prior to joining QASymphony, Dunne was a business technology analyst at Deloitte. He can be found online at Twitter and LinkedIn.

     

     

  • Spurring the DevOps Adoption Journey

    Spurring the DevOps Adoption Journey

    Every few years, the IT canvas is splashed with a new initiative that sparks enthusiasm among businesses and technologists alike. DevOps is one such philosophy gaining significant momentum in today’s digital transformation landscape. At the same time, the concept remains misunderstood and adoption is slow.

    DevOps embodies Development plus Operations within software development. Traditionally, these two parts of an organization have operated siloed from one another with marked differences in both ethos and approach. The result: delays in launching products and releases to the market. The fundamental principles of DevOps are to reduce barriers between Development and Operations; increase Development autonomy; and to automate Development and Operations activities to reduce wait time (and waste from a customer’s perspective), thus enabling faster time to market—all while keeping the end customer at the center.

    Planning the Adoption Journey

    Here are four different aspects an organization should consider before starting the DevOps adoption journey:

    Conduct an as-is continuous delivery assessment on product development practices and processes within the organization

    This will best determine an organization’s current maturity level across several different parameters, including:

    • Culture and organization
    • Build management and continuous integration
    • Environments and deployments
    • Release management
    • Testing and verification
    • Data management
    • Design and architecture
    • Information and reporting

    This process also includes identifying current automation levels and opportunities to automate, inclusiveness of tools and environments supporting continuous delivery, and an assessment of existing product design to determine if it lends itself to frequent and fast deployments.

    Map the journey of a piece of code from a developer’s desk all the way to when the consumers use it

    Utilizing a development pipeline assessment to study the life cycle of a piece of code through its journey from a developer’s desk to production will best identify “waste” during the life cycle. This assessment should bring out critical information, including the number of environment hops, test pyramid maturity and level of continuous testing, level of provisioning and deployment autonomy and its automation.

    Establish a culture of inclusiveness, autonomy and a sense of a ‘common goal’ within the organization

    Product management, development and operations teams should have a common mission and goal for the product, sprint or release they are working on. The definition here should be the value delivered to the customer as opposed to the value of code, test results, or individual deployment steps. Including operations roles within a close-working scrum team benefits this cause by:

    • Bringing in common views on what a product, release or sprint is intended to deliver.
    • Creating an opportunity to bring forward and address operations needs during the development cycle.
    • Creating a better understanding of mutual expectations and empathy for delivering outcomes that meet customer expectations.

    Measure and track

    Finally, determine parameters the organization would like to establish to track progress towards a successful adoption. The key here is to have a few, simple metrics that truly reflect “value to the end customer.” Here are a few commonly considered metrics:

    • Production deployment frequency: The number of product releases within a specified time.
    • Average lead time for a production change: The typical amount of time it takes for a piece of code to traverse from a developer’s desk through production.
    • Average production recover time: The time taken to bring back production systems after an incident involving a release, release rollback or system outage.
    • Change failure rate in production: The number of releases that did not stick in the live environment and needed either a rollback or an immediate emergency fix.

    The goal and a true measure of successful adoption would be an improvement of all these parameters over time. Internally, they would require strong engineering rigor and cultural realignment to be able to improve these customer-facing metrics.

    Navigating DevOps adoption successfully is neither easy nor fast for a number of reasons. DevOps encompasses different parts of the organization, which historically may have operated in silos and with different ethos. DevOps also questions the status quo regarding engineering roles and practices, and focuses on automation and reskilling, all of which need both upfront time and effort investment. Finally, DevOps believes in and propagates continuous learning and improvement, whereas many organizations may have more stepwise-based programs in place.

    For a midsized IT organization, it could take anywhere from 18 to 24 months or more to be able to reach a reasonable steady state. That’s why it is important to carefully craft a charter that encompasses the above parameters before embarking on this DevOps adoption journey.

    About the Author / Amit Gupta

    Amit Gupta is leader of Ness Digital Engineering’s DevOps practice. He has several years of software delivery background. He has keen interest and has developed deep expertise in establishing practical software development processes especially for globally distributed teams. Amit currently leads Ness Digital Engineering’s DevOps practice, and engages with several customers on such areas as improving engineering effectiveness, engineering tools and process transformation. Connect with him on LinkedIn.

  • DevOps is a Lifeline to Connected Mainframe ROI

    DevOps is a Lifeline to Connected Mainframe ROI

    A new IDC white paper sponsored by IBM and CA Technologies reveals the adoption of DevOps is a hallmark of those organizations that are actively modernizing and integrating legacy systems such as a mainframe to support digital transformation.

    Early adopters are blazing a path for faster innovation and greater ROI.

    DevOps Delivers Mainframe Modernization and Integration

    I’m encouraged to see DevOps recognized as an important element in realizing a “connected mainframe” vision. Respondents demonstrated a continued commitment to modernizing their mainframe environment.

    The IDC study confirmed that leveraging Java on the mainframe was one of the most popular approaches. In fact, I’m constantly surprised at how few managers realize that these days, Java and Git can be used by developers in such a way that allows them to completely separate themselves from the mainframe “green screen” environment when coding or maintaining applications.

    DevOps automation has also helped organizations overcome many of the cultural and operational challenges to a fully end-to-end enterprise by aligning application development tools and orchestration chains across multiple platforms and teams.

    Adopt a Business-First Approach

    Customers I’ve spoken with are experimenting with DevOps for mainframe tools and practices, with many piloting new approaches across the life cycle. They’re immediately becoming more agile, realizing shortened development cycles, improved collaboration between distributed and mainframe teams and faster MTTR that maximizes availability. In all, these early adopters have benefited from increased speed to market, improved business agility and better platform economics.

    The IDC study concurs, identifying more effective delivery of applications and services as a powerful cost-saver, with savings of $58,900 per application achieved through increased developer productivity and day-to-day support efficiencies. By helping mainframe organizations to realize improvements at every stage of the application life cycle—from build through test, deploy and operate—DevOps delivers compelling benefits; for example, from our recent study Accelerating Velocity and Customer Value with Agile and DevOps:

    • Advanced DevOps users reduce the time taken to develop, test and release new applications by 42 percent.
    • Advanced agile users reduce their time to decide and act on new opportunities by 40 percent.
    • Advanced agile users accelerate the time to develop, test and release new apps by 36 percent.1

    Excited? I encourage you to catch up on the full IDC White Paper here.

    — Aline Gerew

  • CD 101 Podcast: The What, How and Future of Continuous Delivery

    CD 101 Podcast: The What, How and Future of Continuous Delivery

    Now that we’ve arrived at Episode 4 of our CD 101 Podcast, let’s address some basic concepts—like the what and how of it all and the future.

    Wait … perhaps we could—or should—have touched on these key topics earlier. Or not. At least not the future part? Anyway …

    While this (mostly) backwards-looking orientation may seem a bit odd, I’d argue that we’re actually navigating the conversation on precisely the correct path. Let’s rewind for a moment to look at where we’ve come from.

    Episode 1: We highlighted many of the fundamentals of this thing called CD, yet we did so from more of a conceptual and best-practices standpoint. While the ideas and processes involved do resonate in the real world, the topics we cover in this episode are bit closer to the water-cooler conversations we’re hearing about CD as it grows in practical adoption.

    In Episode 2: We covered the whole how do you “realize agility” piece of the conversation. This is important and a precursor to some of these other basic questions. The entire process of digital transformation begins with getting agile and you can’t truly adopt continuous delivery without doing so; therefore, this was another good place to feed today’s discussion.

    In Episode 3: We looked at the prospect of re-inventing the “Modern Software Factory” with agile development and continuous delivery. OK, so, perhaps we were getting a bit ahead of the basics here, but I’d maintain that this is an important piece to consider upfront that builds on these other building blocks. As with the topics covered in Episode 2, it is critical to understand the big picture challenges and benefits before you begin to get your hands dirty.

    And now for some nitty gritty.

    In Episode 4, we hear from Shamim Ahmed, CTO of Continuous Delivery Solutions at CA Technologies, as he answers the nine burning questions he most often hears in speaking to enterprise practitioners as they look to employ DevOps and Continuous Delivery practices in the real world.

    So, while these previous conversations were material, this is a crucial set of topics to consider as you invoke your own strategy, including:

    1. What is the difference between DevOps and continuous delivery?
    2. What are the key impediments/obstacles to achieving speed/quality in CD?
    3. How do we overcome these obstacles?
    4. How do we get started on the CD journey?
    5. What are the key top-level metrics you want to track in a CD program?
    6. What org changes do we need to make to implement CD?
    7. What the key capabilities we need to implement?
    8. How do we integrate all the different tools we have in our environment?
    9. How will the future of continuous delivery evolve?

    OK, that last part is a bit more postulation on our part—though we like to think on the practical side, based on the answers to all these other important real-world adoption dynamics.

    Tune in and hopefully learn a good deal about where your approach stacks up, and needs to evolve.

    As always, you can find said Episode 4 of the Continuous Delivery 101 Podcast by:

    • Listening to it on your computer on YouTube
    • Downloading it from iTunes store
    • Downloading it via the Podcast App by searching for “Continuous Delivery 101 podcast”

    Enjoy!

    — Scott Edwards

  • DevOps Chat: ‘The DevOps Adoption Playbook’ by Sanjeev Sharma

    DevOps Chat: ‘The DevOps Adoption Playbook’ by Sanjeev Sharma

    Before the recent IBM InterConnect conference I had a chance to sit down and chat with Sanjeev Sharma, CTO of DevOps Adoption at IBM. I have spoken to Sanjeev many times and he is a contributor to devopsy.kinsta.cloud, as well as the author of “DevOps for Dummies.” Sanjeev has a new book out called “The DevOps Adoption Playbook.”

    With no disrespect toward the “DevOps for Dummies” book, the playbook is on a whole different level. This book represents the culmination of years of learning by not only Sanjeev, but by IBM in general, as well as some of the leading names in DevOps that he learned from during this time.

    “The DevOps Adoption Playbook” lays out a clear “how to” for DevOps including topics such as value-stream mapping, how to lead the transformation of culture and scaling DevOps to the enterprise. As Sanjeev himself says, the book started from a power point of best practices that he had started that tried to take in everything he had learned.

    Sanjeev also stays true to the “playbook” paradigm. He makes references to cricket, soccer and other sports throughout. It is a good read and well-organized. As I told Sanjeev, in a field full of “what is,” “The DevOps Adoption Playbook” is a “how to.” I highly recommend it.

    As usual, the streaming audio of our conversation is below, with the transcript of our conversation below it.

    Alan Shimel: Hi, everyone. Alan Shimel, devopsy.kinsta.cloud, here for another DevOps Chat. Today’s guest on DevOps Chat is Sanjeev Sharma, a DevOps author and IBM CTO DevOps. Sanjeev, welcome.

    Sharma: Thanks, Alan. Good to talk to you again and I’m glad to be on this DevOps Chat

    Shimel: Absolutely. Sanjeev, you are of course CTO DevOps Solutions at IBM, correct?

    Sharma: The exact title, not that it matters as much—it’s just nomenclature—is CTO DevOps Adoption. I am client-facing and work with customers around the world, helping them adopt DevOps, primarily focused of course on IBM solutions.

    Shimel: In addition to that, Sanjeev, of course you are the author of both editions of the “DevOps for Dummies” books, which were very successful in introducing DevOps concepts to the world at a time when DevOps wasn’t quite as well-known as it is now. Correct?

    Sharma: Right, yes. It’s hard to believe that that book has been around for multiple years now. We’ve had tremendous success. Bernie Coyne coauthored the second edition with me. We updated it and it’s been very successful. The book came out at a time when people were mostly asking the question, “What is DevOps and what does it mean to me?” That’s what that book is targeted towards. It’s a very short book. You can read it in an hour, an hour and a half. It’s like a dummified version, so pretty short and to the point.

    Shimel: Yes. But really, Sanjeev, I wanted to talk to you about the new book that you just came out with through Wiley and IBM Press and its called “The DevOps Adoption Playbook: A Guide to Adopting DevOps in a Multi-Speed IT Enterprise.” Sanjeev, I’ve read the book and to me this sort of represents the culmination of all of the lessons and the knowledge that you have accumulated over these last few years, in helping organizations around the world with their DevOps. Is that fair to say?

    Sharma: Absolutely, but I would go one step further and say it’s just not my knowledge and my experiences, which are fairly extensive. I’m sure I worked with dozens of customers around the world. I haven’t counted, but some of them very intimately through their multi-year DevOps adoption journey.

    But as you will see in the acknowledgement section of the book, it was also knowledge I gained talking to my colleagues here at IBM, talking to people like you and other business partners, our followers and colleagues in the DevOps industry, and also of course from our customers, because I wasn’t with them 24/7 carrying the tools of the trade and implementing DevOps and fighting the technology and the political and the business battles. They were doing it, and I was learning by observing them succeed or, in some cases, stumble and then figuring out with them how to go around the hurdles they were facing. So I owe a lot to all the people I worked with over these years, including our customers, in putting together what has come in this book.

    Shimel: Absolutely. Sanjeev, you’re being humble. You have worked with dozens of DevOps people. But in that role, as you say, you’ve interacted with many of the thought leaders, if we can call them that, within the DevOps movement.

    More than that though, when you look at the book, what I’ve said about the book and I’m writing a review of it, is that in a world full of books that are “what is” your book is a “how-to.” I think that’s an important reminder. We read too many books around DevOps that are trying to define what DevOps is, trying to put your finger on that slippery fish of, “This is DevOps,” where you spend some time on that right in Chapter 1. We give a little review of DevOps, but you spend a lot more time on good practical how-to DevOps advice.

    Was that your idea with this book? What drove you to write this book?

    Sharma: Absolutely, Alan. If you read this as a “how-to” book and not a “what” book, then I have succeeded in getting my message across. Quite frankly, it’s how this book came together. As I was working with our clients maybe two years, 18 months ago, the questions started changing. People no longer were asking us, “What is DevOps?” They were asking us, “How do I adopt DevOps? What are you seeing other people do? What can I learn from your experiences when you go with that bank over there or that health care company or that telco, that retailer? What are you observing when you’re out there in the trenches?”

    I started actually putting together a PowerPoint deck. This is where this book started, as a PowerPoint deck of best practices as part of the success. In fact, last year at InterConnect, myself and my colleague, Lee Reid, who is actually the technical editor of the book, we did that presentation and we called it “The DevOps Adoption Playbook,” and that’s what I intended this to be, this book to be a playbook which somebody reading it can have or they can learn all about it and then, based on the situation they are facing, pick a play, just like a coach or a captain does or a quarterback does in American football. He can do a read and get an idea of, “Okay. We need to run this play because that’s what’s needed here.”

    So it’s definitely a how-to book. There are certain, of course, strategic areas in the book on how to convince the business that the DevOps is in order to make a business case. Like its name suggests, it’s a playbook on how to go and get in the trenches and adopt DevOps in a large organization.

    Shimel: Sanjeev, first of all, the book is available on Amazon and other sort of traditional bookseller sites. Correct?

    Sharma: Absolutely. This is my first retail book. The first book that you mentioned, “DevOps for Dummies,” was a free book we were giving away, sponsored by IBM. So to me as an author, when the book came out and I knew it would be available, the first thing I did was drive to the nearest Barnes & Noble, which actually is 15 miles from my house, just to go see the book on the shelf. So yes, it is available at all major booksellers, both as a physical book and as an e-book.

    Shimel: Let me ask, and I think I probably know the answer. Did you take a picture, a selfie of yourself with the book on the shelf behind you?

    Sharma: I wanted to do that, but the book was placed at a very awkward angle, so I couldn’t get myself into it. So I just took a picture of the book sitting there with the other books. And, you know, it’s not a selfie if you give the camera to somebody else. This was in the middle of the day. They were letting nobody in the bookstore. It was pretty hilarious. I wish I had videoed the whole thing.

    Shimel: Very cool. Sanjeev, people can get the book. They can see you for themselves. Also, I will mention that it’s the kind of book where if there’s something specific you’re looking to hone in on, a particular issue, problem, topic you’d like to delve into, the table of contents and the way it’s laid out makes it very easy to do so. So you could use it to kind of pinpoint in the kind of thing you’re looking for, or you can take it as an overview around the whole book. Either way it’s pretty good.

    Sharma: Thank you.

    Shimel: But, Sanjeev, there are a couple of terms in the book that I’d like to – one of the things is you talk about this concept of fast waterfall. It was mentioned in there a few times and I’ve seen others mention it.

    Sharma: Sorry. [Audio breaks up]

    Shimel: Did I break up there? I apologize.

    Sharma: Could you repeat that?

    Shimel: Sure.

    Sharma: I’m sorry.

    Shimel: Sanjeev, you talk about this concept of fast waterfall. Did you hear that?

    Sharma: Yes, I did. Thank you for repeating that. We were seeing a very broad spectrum of maturity levels and a spectrum of business needs, and we go with clients and see how they adopt DevOps. So when I go into an organization, no organization is monolithic. No organization is homogenous. You see one part of the organization where nothing is broken, things are going fine, but they’re using a very old-school waterfall approach to delivering systems.                           

    So the question that arises is: What do you do there? Do you disrupt something that is working during maintenance, more to try to introduce agile principles or try to introduce continuous delivery? Or do you just make what they are delivering more efficient?

    My thesis in the book is that you focus on optimization. You look at the delivery pipeline. You do what we call a value-stream mapping, and look at where the waste is, where the bottlenecks are, and look towards eliminating or mitigating those, without necessarily needing an end-to-end sea change to say, “No, you have to stop what’s working for you. Your business doesn’t need you to go any faster. Your business doesn’t need you to be more innovative because this is an application in

    – but you have to disrupt it.”

    That all or nothing approach does not work. It is also very expensive. So how do we make it more efficient? I don’t like the term “fast waterfall.” I would like to call it “optimized waterfall”. You focus on optimization. Yes, eventually your goal should be to move to full Agile. You goal should be to move to continuous delivery, but you cannot do that day one. You cannot do it across every project, every system and every application at the same time, but you can do some things to start everybody on that optimization journey.

    That is to me what I am referring to in the book. Get started. Get started where you are. Understand your end goal. But you don’t have to get there at light speed. You don’t have to get there yesterday and you don’t have to get there all together. You have to make that business decision of how much change to introduce, how much change you can consume, and how much change you can afford at this time. Maybe not today, maybe you can only do it next year. So that’s summarizing some of the thinking behind what you’re really getting ready to do.

    Shimel: Understood. Sanjeev, you mentioned value-stream mapping. That’s a workshop that I’ve seen you perform over the years and it’s great. If anyone ever gets a chance to sit in on one of your value-stream workshops they absolutely should. Can you give us just a little bit of an idea of what’s involved with that?

    Sharma: Sure. Value-stream mapping, I would add, as an exercise is nothing new. It’s been in there in the Lean movement since the last century, probably since the 1950s. It’s a technique by which you look at processes and you try to figure out where there might be some waste, and then do a root cause analysis to determine why the waste is there and make a plan to mitigate it.

    So in DevOps, if you look at your delivery pipeline as a value stream, that requirements are coming in at one end and code running and production being used by a user, getting business value at the other end, we do a value-stream mapping to look at where the waste is. So we look at artifacts going through that delivery pipeline.

    What are those artifacts? Who are the stakeholders who touch those artifacts and perform actions on them, who do processes on them? How does the transition happen from one stakeholder to the other? How does the artifact get transformed as it goes from one stakeholder to the next? What environment or tool or repository does the artifact live in and is it consumable?

    There’s a concept in Lean called percent complete and usable, which tells me: when I get an artifact, can I use it as _____ to consume it? Are the requirements coming from the business usable by developers? Is the code coming from developers usable by the testers or whatever? Are there manual tasks which are causing waste? Are there tasks people are doing which add no value to the product? They don’t add any business value, like status reports. They have some value, but are the status reports really being used to progress the product or are they really being used because some needs a view, and they have to spend time creating those reports rather than having a real-time dashboard somebody can just look at?

    So a value-stream mapping exercise and what you’ve seen is a half-day version of a workshop we do with clients, where we go in and take one project of theirs and do a value-stream mapping to get an idea of where the waste is. Many times, actually more often than not, we do it at a division or a program or a line of business level and look at for that line of business: What does the value stream look like and where are the bottlenecks? Where is the waste?

    Then we spend some time doing root cause analysis on each bottleneck we identify. Then we go away and come back with a recommended adoption plan of what DevOps practices and capabilities and tooling, and organization change also, would we recommend to help mitigate those bottlenecks. So it’s a very powerful exercise we do.

    I have an entire section dedicated to it in my book. And on YouTube, if you Google, search for DevOps Whiteboard, you will find me doing a mock value-stream mapping also. There’s a 30-minute video of me doing it with one of my colleagues. So it’s something we’ve had a lot of success with and I think it’s something every organization should do.

    Shimel: I agree with you and I have seen the video. Sanjeev, we’re almost out of time. I wanted to just pivot from the book for a moment and talk a little bit about InterConnect. IBM’s InterConnect this year is coming up in about two weeks. I know you’ll be appearing there and I would imagine the book is involved in what you’re talking about. Yes?

    Sharma: Absolutely. IBM Press was the publisher of the book along with Wiley. On Wednesday afternoon we will do a book signing. They’ll set one up. So if you have a book, if one of your listeners has the book, they can bring it there. I’ll be more than happy to sign it and have a chat with them. They will also be selling the books there at the IBM Press store.

    And I am told—I don’t know if I’m even supposed to tell this, but if you come to a DevOps session, a track in the DevOps session, in some of the sessions we’ll be doing some surprise giveaways of books also. But don’t tell anybody that.

    Shimel: No, of course I wouldn’t.

    Sharma: It’s one big secret. No, no, no. Personally, I am doing three sessions, one of which is a panel with customers, and there are two other sessions related. Both of them are topics I picked out of the books, individual chapters from the books. One is on building a business case for DevOps, and the other one is a risk-based model to adopting DevOps.

    Then the third is a panel, and the fourth is a workshop I’m doing on driving innovation. So it’s kind of broader than DevOps. That’s going to be an hour-and-a-half workshop. So it’s going to be a fun few days and I look forward to meeting your listeners there.

    Shimel: Absolutely. You know what? We’ll try to get some links to these in the transcript and notes on this podcast.

    But for now, I think we’ll call it a wrap on this DevOps Chat. Sanjeev, congratulations on a great book here. I mean “DevOps for Dummies” was certainly a great read, but this is a book. Kudos to you and the team. You put together a really nice how-to here. I’m looking forward to hearing and seeing you at InterConnect. Of course we run into each other quite a bit during the year and I’m sure we’ll continue to do so.

    Sanjeev Sharma –

    Sharma: Absolutely, Alan. Thanks a lot for having me and I looking forward to chatting again soon.

    Shimel: Absolutely. Sanjeev Sharma, “The DevOps Adoption Playbook,” a new book out, definitely pick it up, by Wiley Press and IBM Press. Sanjeev, thanks for being on DevOps Chat today and we’ll speak to you soon.

    Sharma: Thank you for having me, Alan. I’ll speak to you soon.

    Shimel: Okay. This is Alan Shimel for devopsy.kinsta.cloud and we’ll see you soon on the next DevOps Chat.

    — Alan Shimel

  • DevOps in Legacy Systems: A Mission Impossible?

    DevOps in Legacy Systems: A Mission Impossible?

    The word “legacy” evokes mixed reactions from the IT and business crowds alike. For those who depend on legacy systems such as the zSeries and iSeries platforms, it is a way to deliver stable and reliable applications into production. Business stakeholders who may not know the intricacies of the technology often take a view of, “Why fix it when it ain’t broken?”

    mainframe

    On the other hand, for those who haven’t experienced the joys and pains of legacy systems , legacy world will continue to defy their logic and assumptions because their view of the world is shaped by the open system world which has completely different characteristics: being more malleable to change and easy to maintain etc. Hence there is this great divide between the legacy and new worlds. Add Agile and DevOps to the equation with the lofty goals of increased release frequency and reduced lead times, we end up with a divide that is too far to bridge.

    cobol code

    The likes of Gartner have come up with constructs such as two-speed delivery to help deal with this legacy challenge. In my view, there is a problem with the idea of dual-speed because it is based on a wrong analogy to start with — that of allowing vehicles to move at different speeds depending on whether you are on the motorway or a city road. That analogy works well for traffic management scenarios but not for complex IT architectures we see in the enterprise. The dependencies across the systems in the enterprise landscape are just too intricate and too tightly coupled to be defined using such a binary logic. In my experience, I find that many Agile and DevOps transformations hit the roadblock and never achieve the desired levels of productivity and effectiveness because of an oversimplified view of these complex dependencies across legacy and open systems.

    The three biggest challenges that prevent a legacy DevOps transformation are mindset problems, architectural constraints and tooling limitations.

    The Mindset Problem

    “There are no legacy systems, just legacy thinking.” That’s a great quote I heard recently from an engineer in a large organization trying to adopt DevOps at enterprise scale. The initial resistance from teams to move into DevOps ways is due to reluctance to change, emerging from an inertia of doing things a certain way for years if not decades. The mindset problem is as much a problem for those outside the legacy world as those inside. The “outsiders”—typically leadership, management team and consultants—tend to oversimplify the problem and, too often, rely on examples from the open systems world. This just alienates the incumbent legacy teams and makes them even more skeptical of DevOps driven change. The outsiders need to have a genuine appreciation of the challenges with legacy architecture and need to work in collaboration with the legacy teams if they really want to transform their organization.

    Architectural Constraints

    Legacy systems have certain characteristics such as being static, tightly coupled and monolithic blocks of procedural code. These systems were not built for the modern Agile workflows that focus on incremental and iterative deliveries. A significant majority of these systems are written to operate in batch mode.Testing the systems requires cycling through multiple business days, which simply limits the level of agility you want to introduce in the organization. I am currently working with a legacy engineering team in the financial services space where you have to cycle through a minimum of 20 business days to simulate even 70 percent of the test scenarios. However, there are a number of solution options to overcome the architectural challenges; they range from killing applications to migrating to modern platforms or re-engineering legacy code. Not surprisingly, the right approach depends very much on your context.

    Tooling

    Tooling in the legacy world to support a DevOps ways of delivery has always been a challenge. But it is fast changing now, thanks to a number of startups and even old-school IT product companies investing in this space. If you consider zSeries as an example, there are better IDEs (integrated development environments) such as RDz that can replace traditional code editors typically based on “green screens.” These IDEs provide great features such as better navigation, debugging, split views and searches on the legacy code. One of the CIOs I worked with made it clear to his team that he wanted to get rid of “green” screens from the IT floor. There are tools such as SmartBear Collaborator that support a great peer review experience and help bring one of the original XP practice of pair programming to the legacy world. There are tools such as endeavor from CA that promise automated build and deployments in the z-series world. Similarly, there are tools that support test automation of mainframe applications and tools for code coverage and code quality checks on legacy programming languages like COBOL. XATester looks like a promising tool for unit test automation from a Danish startup called Xact.

    While this write-up is not intended to be a compendium of all DevOps and engineering tools, the central message is that there are a number of DevOps tools emerging on the legacy landscape which can help your legacy delivery teams get on to the DevOps and Agile journey.

    What is more important is for organizations to realize that many of these legacy systems will remain part of their IT landscape for the next foreseeable future and it is time to invest in these core systems. They may not look as appealing as the digital platforms, but they are fundamental for businesses and you cannot ignore them on your DevOps journey. DevOps in the legacy world is not going to be smooth, but it is certainly not a mission impossible!

    — Aditya Vadaganadam

  • CD 101 Podcast: How to Build the Modern Software Factory with Agile Development and Continuous Delivery

    CD 101 Podcast: How to Build the Modern Software Factory with Agile Development and Continuous Delivery

    And now, for Episode 3 … you decide if it beats “Star Wars – Revenge of the Sith.”

    I think we accidentally just set the bar pretty low, but …

    … here we go. Let’s begin with a prerequisite pithy quote from an objective industry observer:

    “If agile software development was the opening act to a great performance, continuous delivery is the headliner,” according to Kurt Bittner of Forrester Research.

    Kurt explains this concept further by saying, “The pace at which consumers expect change is causing a crisis in application development and delivery … agile was a good start, but it wasn’t sufficient to drive better business results; continuous delivery forges the broken link in the value chain, connecting business strategy with business results.”

    So there, you have it.  At least according to Forrester, continuous delivery (CD) is one of the most important evolutions of agile methodology within the modern software factory. But, there’s more.

    Andrew Binstock from Dr. Dobbs fairly well echoes this sentiment, saying: “It’s becoming clear that agile alone is no longer sufficient to keep up with the demands of the present day … software complexity and the need for constant updates are making it difficult for leading edge organizations to keep up without moving beyond agile and embracing continuous delivery.”

    Episode 3 of our podcast series discusses the importance of Agile Transformation along WITH Continuous Delivery to automated some of the development, test, and release efforts to remove some of the bottlenecks downstream in the software development life cycle in the build, test and release phases.

    Lean Agile + CD can create these 1+1=3 types of results.

    Episode 3 of the Continuous Delivery 101 Podcast can be found by:

    • Listening to it on your computer on YouTube
    • Downloading it from iTunes store
    • Downloading the podcast from your Podcast App by searching for “Continuous Delivery 101 podcast”

    Thanks for listening!

    — Scott Edwards