devopsy.kinsta.cloud

Tag: DevOps processes

  • IBM Allies with ServiceNow to Bridge DevOps Divide with ITIL

    IBM Allies with ServiceNow to Bridge DevOps Divide with ITIL

    IBM and ServiceNow today announced an alliance under which IBM Global Technology Services (GTS) will collaborate with ServiceNow to make DevOps processes and events managed via the IBM Cloud Migration Factory visible to a cloud-based IT service management platform from ServiceNow based on the ITIL framework.

    Jim Comfort, general manager for cloud services at IBM GTS, said that from a governance and compliance perspective it has become clear IT organizations need more visibility in to DevOps processes. In general, enterprise IT organizations are increasingly adopting DevOps processes to accelerate application development and deployment, while still relying on ITIL to manage governance and compliance, he said.

    IBM GTS, via the alliance with ServiceNow, will be able to bridge that divide by integrating ServiceNow with a set of tools and services IBM provides across hybrid cloud computing environments that are based on DevOps process.

    The IBM Cloud Migration Factory is based on a methodology IBM developed to move applications to cloud. IBM Services claims it has completed more than 100,000 migrations. In addition to allying with ServiceNow, a new toolset is being added to IBM Cloud Migration Factory that employs algorithms based on the migrations IBM has completed that improve planning accuracy and uncover application dependencies. Included in that portfolio is cloud brokering software that IBM gained via the acquisition of Gravitant in 2015.

    Comfort said the alliance with ServiceNow will make it possible to have DevOps processes and events register automatically in the change management database (CMDB) provided by ServiceNow. That’s critical because it should allow IT organizations to maintain governance and compliance without having to impose an overhead that otherwise would slow down application development and deployment using DevOps processes, he said, adding there’s no need to impose an artificial construct on top of a DevOps process.

    As hybrid cloud computing continues to evolve, Comfort said IBM GTS expects IT organizations will be relying on a mix of ITIL and DevOps processes for the foreseeable future. In fact, he noted that while managing one to ten DevOps processes is relatively simple, keeping track of hundreds of DevOps processes requires a more static set of processes to maintain governance and compliance. The IBM approach is to create a unified approach to integrating DevOps and ITIL processes that doesn’t require organizations to integrate a variety of point products on their own.

    Proponents of DevOps processes have been making a case against ITIL processes that they tend to view as being too rigid to support agile application development. Comfort said the next iteration of the ITIL framework will incorporate many of the concepts advocated by DevOps proponents. But the two frameworks will remain distinct.

    The alliance between IBM and ServiceNow represents a clear signal that DevOps is going mainstream in enterprise IT environments. The challenge now is finding a way for organizations that have spent more than a decade adopting ITIL processes to embrace DevOps processes with a minimal amount of friction possible.

    — Mike Vizard

  • DOES18: Challenges and Enablers for DevOps Success

    DOES18: Challenges and Enablers for DevOps Success

    “What happens in Vegas, doesn”t stay in Vegas” … a great quote to end the recent DevOps Enterprise Summit 2018 (DOES18) in Las Vegas, urging attendees to take and share the new insights and knowledge gained. This article is an attempt at sharing my discoveries.

    This article contains a summary of the challenges that delegates told me about when visiting the GamingWorks stand at the summit. These closely match our global findings, with more than 400 teams having participated in the Phoenix Project business simulation workshop.

    This article also describes highlights from the sessions I had time to attend—highlights mostly in relation to the challenges mentioned above, and biased toward toward people, culture and behavior, as this to me is the No. 1 success or fail factor for the successful adoption of DevOps ways of working.

    Challenges

    I asked more than 100 people, “What is your top challenge or barrier for your adoption of DevOps ways of working?” I have ordered them based upon the number of times mentioned, highest first. Many of these I captured before the opening of the summit:

    Leadership:

    • Leaders applying the “pointy-fingered” approach. “You are now self-empowered. Make IT happen.‘
    • Lack of “empowerment” and not “walking-the-talk” to foster the right culture.
    • Not wanting to let go of a “command and control” management approach and fear of becoming less relevant.

    Product Management:

    • The need to shift from a “feature” focus to more “outcome” and “business value” focus.
    • Product owners “demand” but don”t share why.
    • Low focus on “technical debt” and “issues” versus “benefits.”
    • Need higher-level product management (business decision makers) to balance “innovation” with “risks” (e.g technical debt).

    Value Stream:

    • Poor end-to-end visibility (including business “before” and “after” activities).
    • A narrow focus on Dev and Ops, mostly a Dev “pipeline.”
    • No impediment backlog visible for the stream.
    • Too much local optimization.

    Value and Metrics:

    • Too much focus on internal, proxy metrics.
    • Need more “value” and “outcome” metrics to gain buy-in to scale up.

    End-to-End Communication and Team Collaboration:

    • “Them” and “Us” – lack of trust.
    • Poor listening and communication skills to explore and understand.
    • Lack of end-to-end understanding of the business impact and value we are all working toward.

    Poor Management of WIP:

    • Poor balance between types of work, feature vs technical debt, improvements, training and knowledge-sharing.
    • Engineer disconnect between “what you are working on and the business impact.”

    Continual Learning and Improvement:

    • Not enough WIP reserved.
    • Poor team ownership and ability to structure this.
    • No visible backlog of impediments/improvement.
    • No prioritization of improvements.

    Project to Product:

    • Projects claiming resources.
    • Product owner resource conflicts and challenges.
    • Flip-flopping, context switching work.

    Buy-in and Resistance:

    • Why should we change?
    • Fear, uncertainty, doubt.
    • Suspicion of intentions.
    • Managers not wanting to change and lose “power.”

    Certainly not a lot of CI/CD or technology stuff mentioned here!

    What were some of my highlights as they relate to these challenges?

    DOES18: Introduction and Opening

    In his introduction, Gene Kim revealed one of the goals of the summit was a need to “Elevate focus on spanning business/technology divide,” which clearly relates to a high-scoring challenge. Another topic in the intro was the need to “upskill,” announcing a new skills research project to be launched. The challenges above and the highlights from the sessions give a clear indication of some of the skills needed. Considering the challenges above, I sincerely hope the survey also focuses on business skills as well. In the “Lean Coffee” roundtable sessions, one of the announced topics was “Transformational Leadership,” clearly linking to the top scoring challenges mentioned. More about this topic in my closing.

    DOES18 Sessions

    In a session titled, “Product Management Meets DevOps” a key recommendation was to “build and run teams combined with service ownership,” stressing a need “to connect people to your strategy” and declaring “IT cannot be separate from the business,” and finishing with a need to “manage product value streams, not projects.”  (This was the only session in which I heard the word “service”). To me, these highlights clearly make a link back to the challenge teams have in understanding business impact and value. These recommendations will require a changing role for product management to ensure strategic priorities are embedded in the value stream, and a more engaged role of product owners in teams to ensure a shared understanding and focus on “outcomes” and “value” in relation to strategy, rather than on features.

    Benefit: Enabling the flow of strategic intent

    Mark Schwartz explained that almost all large enterprises are faced with “impediments” that are a barrier to DevOps success, and these are usually people and organizational issues, not technology. He introduced his new “War and Peace and IT” book, and explained an impediment faced by Napoleon in his Russian campaign—Napoleon had “long decision cycles.” By the time he got the right information to make a strategic decision, the fast-changing short decision cycles at the battlefield meant his decision-making was ineffective. The same applies to the way we currently manage IT: long decision-making cycles from idea to business case to program and project resourcing while DevOps teams operate at a fast, agile pace. Mark suggested a need to speed up the “entire lead time from idea to impact” (a topic also explored in Mark Smalley’s latest DASA whitepaper, “The Business Value of DevOps“).

    Benefit: Enabling the faster flow of strategic intent

    Schwartz went on to suggest three ways to build more agility into the end-to-end value stream and delegate decision-making to a lower level: the “product model,” decentralizing decision to the product team; the “budget model,” decentralizing budget to the team to manage both “innovation” and “keeping the lights on”; and the “objective model,” just give the team the key objectives to be achieved and let them decide how to make it happen anyway they can.

    This to me represents a considerable mindset shift from the hierarchical “command and control” management paradigm and requires transformational leadership. In my mind, whatever model is chosen needs to fit with the highlight from the previous session, “Connect people to your strategy.”

    Benefit: Enabling faster decision-making around strategic intent

    Anders Wallgren‘s session, “Measuring DevOps – The Key Metrics That Matter” was standing room only, with a packed audience taking pictures of all of the slides. I must admit to being surprised, as this is the fifth DOES conference and organizations have had five years to put metrics in place! I can only assume the vast majority were just starting their journey. I was pleased to see not just the traditional metrics often quoted such as “deployment frequency,” “lead time to change,” “mean time to recover (MTTR),” and “change failure rate,” but also business value metrics such as revenue growth; customer value metrics such as customer experience satisfaction; team culture metrics such as education and growth; and the pipeline metrics such as release velocity. This was one of the top-scoring challenges facing delegates who visited our table: “Fhifting from internal metrics to business value metrics.” This focus on business value metrics ties in again to the highlight from the first session above, “Connect people to the strategy,” and the important role product owners have in sharing the strategic intent.

    Benefit: Enabling measurement of strategic intent.

    Dr. Mik Kersten presented “Project to Product: How Value Steam Networks will transform IT and the Business,” suggesting that project management and traditional cost models are the wrong models, an idea supporting Mark Schwartz’s observations. He went on to add, “Fragmented value streams kill personal productivity,” as well as “impact employee satisfaction.” Silos and proxy metrics not related to business value will also destroy a DevOps transformation. He made some powerful arguments for a complete end-to-end value stream (Not just a DevOps value stream).

    These messages were further endorsed by Carmen De Ardo in his session, “Connecting IT to the Business at BMW Group,” during which he also stressed, “Flow time is not just code-to-commit but also, and more importantly, idea-to-value.” Carmen also stressed that the “flow to value” is not just the flow of “features” but also “defects,” “risks” and “debts,” which to me represents a need to manage “value optimization,” a balance of “value creation” and a reduction of “value leakage.”

    Benefit: Enabling value optimization of strategic intent.

    Damon Edwards, in his session “Operations: The Last Mile,” expanded on the theme of end-to-end value streams, with a powerful case about disruption, context switching, waiting, escalations, lack of trust and employee dissatisfaction—all this because of “four forces that undermine operations” that need to be addressed to empower operations:

    • Reduction of Toil—non-valued repetitive work that can be automated.
    • Queues, which disintegrate and obfuscate value streams.
    • Silos, causing disconnects and mismatches.
    • Low trust—the need for “psychological safety, the No. 1 predicate for success.”

    Benefit: Enabling the removal of behavioral flow barriers and waste.  

    Dominca Degrandis in her session, “Making Connections Visible: How to Defrag Your Value Stream,” stressed, “The hardest thing we do is communicate across teams,” making a call to make connections visible as well as “how the different types of work enters the system, where they enter and which tools are used.” This touched on a topic I discussed with DeArdo at itSMF Fusion: the information value stream.

    Benefit: Enabling the removal of end-to-end information and behavioral flow barriers and waste.

    One of the most powerful sessions for me was the presentation from Dr. Steve Spear: “Discovering Your Way to Greatness: How Finding and Fixing Faults is the Path to Perfection.” He suggested, “Design all work to SEE problems.” Make this part of a philosophy: “See, Solve, Spread (Share knowledge).” He suggested, don’t ask “How is it going?” Ask, “What is not working, and what can we do about it?” This ties in nicely with a finding from the latest State Of DevOps report: “Relentless improvement work leads to excellence and high performance.”

    Benefit: Enabling the relentless removal of barriers and waste and the optimization of strategic intent.

    DOES18: A Customer Case

    Mascha Boender  and Stefan Groot presented an ABN AMRO case, “Crossing the DevOps Chasm: From Taboo to Enterprise DevOps,” in which they discussed their bottom-up journey of experimentation. They designed their approaches to see problems. They admitted failure, demonstrating their learning and how they made iterative improvements. They stepped away from a maturity model to a capability model, recognizing that one size doesn’t fit all teams. They provided a “Moonshot workshop,” focusing on specific team goals and ambitions and how these aligned to business strategic goals. They provided a DevOps playbook (based on captured team best practices) to help new teams develop practices at their own pace. To develop team “soft skills” such as communication and collaboration, they used the Phoenix Project business simulation workshop. This was done also with more than 30 leaders to create a mindset shift and demonstrate the change of leadership behaviors required to empower the teams and foster an enterprisewide culture change.

    Benefit: Enabling bottom-up and top-down “skills” and “culture” and aligning team goals to strategic intent.

    The State Of DevOps

    Nicole Forsgren and Jez Humble presented, “The Data Behind DevOps: Becoming a High Performer,” in which they shared findings from the latest “State Of DevOps” report. I won’t go into detail. I suggest you read the report, then read it again. Suffice to say their key messaging echoed many of the other sessions above: “Focus on outcomes, not output,” the need to “identify constraints and continually improve,” and for me an important topic: “Influencing culture through leadership and autonomy.”

    The ABN case above was an example of how they gave teams autonomy to change and  how they helped change leadership behaviors.

    DOES18: Final Thoughts

    As I stated at the start, culture to me is the No. 1 success or fail factor. The “State of DevOps” report stressed the importance of leadership on culture. Leadership was the top challenge mentioned by delegates visiting our stand. I”d like to share with you an article on devopsy.kinsta.cloud on how to influence leadership behaviors: The article is written through the lens of “communication,” tying back to a comment from Dominica Degrandis: “The hardest thing we do is communicate across teams,” and tying in with the ABN AMRO case about developing communication and collaboration skills.

    And finally, getting back to the start of the summit and the need to “upskill,” with the announcement of a skills survey, I’d like to provide some input. Here is a DevOps Agile Skills Association (DASA) article, “DASA Provides Core Skills Key for DevOps Success,” which summarizes the “people and culture” elements from the “State of DevOps” report (this year and previous years) matching these with findings from more than 400 teams having participated in the Phoenix Project DevOps simulation. This I believe can provide input into the survey.

    — Paul Wilkinson

  • If DevOps is Required, Then It’s All About Change Management

    If DevOps is Required, Then It’s All About Change Management

    For more than two years, I have participated in a number of panel discussions at Boston DevOps, our local DevOps meetup.  Panels have been put together from several disciplines to address issues through the successful adoption of DevOps and reaching optimized use of this current methodology in software development.

    As relevant as the DevOps challenge is for every technology organization, it remains elusive. Many groups simply are not cracking the code and in some cases simply do not know how to effectively start the change. Check out SMART DevOps as a way to get started.

    A recent panel in which I participated was set up as an informal question-and-answer session, including questions from attendees viewing a live stream of the event. The introduction by one of the panel members laid out the complexity of issues required to optimize DevOps in an organization. It was clear from the audience questions, as well as those from the live stream, that there was discontent among representatives of all three groups who have been combined into a DevOps function–issues related to implementation and ongoing results. As I prepped for the panel, I came upon a Gartner Group article that had an extremely interesting quote in it: “The DevOps trend goes way beyond implementation and technology management and instead necessitates a deeper focus on how to effect positive organizational change. The DevOps philosophy therefore centers on people, process, technology and information. With respect to culture, DevOps seeks to change the dynamics in which operations and development teams interact.”

    One of the questions from the live stream was: “If DevOps is so great, why is everyone so unhappy?” Another question from the panel moderator very clearly and succinctly asked about the kinds of cultural change happening in organizations, separate from new tools and new practices. The commentary from some technology-oriented panel members precipitated the rapid disintegration of audience discussion into a heated debate about tools and technology.

    Observing that rapid switch away from very “soft” questions about culture to what tools will and will not support aspects of DevOps was enlightening and frightening at the same time. It was very apparent to me that this major shift in how information systems organizations were structured and managed was a throwaway in terms of organizational change. The Nike phrase “Just Do It” comes to mind.

    The issues were obvious to me. In no way had most organizations viewed the combination of three separate, virtually autonomous departments (one of which is adjacent to customers) each with a different culture, as an organizational change. And, by the way, a change to be accomplished while maintaining a 24-hour idea-to-delivery cycle, with each new idea coming within seconds of the last. The departments in question were not filled to the brim with sales and marketing extroverts. Rather, they were groups and individuals who were used to looking at the problem in front of them and solving it without having to resort to communicating with others. Like its close relative Agile, DevOps relies heavily on communication and conversation to be successful.

    The situation is a wake-up call to technology leaders and managers. If you are working in an organization that has embraced DevOps with the goal of providing customers with what they want almost immediately, check in with all of your technology teams. They may be floundering in what they did not perceive as an organizational change. If you are a technologist trying to implement DevOps successfully and suspect that there are underlying organizational issues, there are several things you can do to be effective and help your organization realize a successful implementation. Start the conversations that need to happen to have optimized DevOps, learn some of the principles of collaboration and consensus, and draw upon the expertise of outside resources who can facilitate you and your teams through the organizational complexities of a transition—“a philosophy, a cultural shift that merges operations with development and demands a linked toolchain of technologies to facilitate collaborative change.”

    This article was co-authored by Kevin Fisher

    — Callie Gargiulo McDowell

  • The 2 Best Ways to Automate Your TechOps

    The 2 Best Ways to Automate Your TechOps

    The DevOps community is rapidly building tools and processes to automate more of the DevOps workflow. One key is to put engineers on the front line who can find root causes of problems and automate more of the common tasks. Here are the two key areas to focus on when automating operations processes.

    Automate Your Most Expensive Tasks First

    The first step is to do some analysis on where the team spends most of their time. You will want to know if they’ve done a good job around the tickets and how many requests of what type have they gotten.

    After analysis, one company found it had more than 500 tickets a day for user access requests from users who were locked out of their account. This is a common problem, especially in midsize to large companies that are doing user management or account management and have very manual processes for onboarding and offboarding.

    There’s a ton of money that can be saved by automating these processes. And there’s a whole host of tools for everything from full orchestration systems to pipeline stripping to make it possible. But the first step is to analyze where time is being spent on the repetitive, easily duplicated tasks and automating those.

    Automating Monitoring and Self-Healing

    There are a lot of different tools out there, and the amount of data that’s coming together is enormous. With the emergence of big data and machine learning, we have the ability to put all the different points of monitoring into one system and bring all the data together to provide a single picture of how everything is performing.

    Data sources can include anything from systems monitoring tools to application performance monitoring tools to social media feeds such as Twitter and Instagram. In addition, it can and should include data from your IT service management (ITSM) tools. Once you’ve got that you can correlate your performance data with your incident data to actually predict when a problem is more likely to occur so you can fix the root cause or the underlying issue before it impacts your users.

    There’s some really neat stuff that can happen with automation, whether that’s just a simple script that can save you time and money or advanced machine learning to actually predict issues and address them in real time. Take the first step to make your organization more efficient and effective.

    — Sean Mack

  • Agile Development: The 3 Methods You Need to Master

    Agile Development: The 3 Methods You Need to Master

    As organizations embrace the age of Agile and digital transformation strategies, every brand is looking for a competitive advantage. To succeed, organizations need to focus on the user, offering services to users on their terms, on their devices and at their convenience. Even more, users expect these offerings to be visually appealing and fast. That’s a lot to keep track of!

    When selecting a digital transformation strategy, there are two key trade-offs organizations need to understand. First, getting features to market faster and increasing presence on users’ devices, and second, maintaining high application quality.  Acceleration can come in the form of adopting an agile process, i.e. highly independent dev teams who are responsible for one feature in the code, delivering incremental functionality from design to production. A proper quality methodology is as equally effective, ensuring a high-quality application at the end of each sprint. This can actually help the team accelerate.

    Continuous integration (CI), continuous delivery (CD) and continuous testing (CT) are the top three methods by which many development teams adopt an agile strategy. While each serves a slightly different objective, when combined, they can significantly help the team achieve velocity and quality, two of the most important goals of any development team. Let’s dive deeper into these three different components to understand the critical role they each play.

    Method 1: Continuous Integration

    CI is the most critical component to making an effectively agile development team. To help understand the important role CI plays, the image below depicts a team that has not installed a CI process. As you’ll notice, this team does not share their code with the rest of the development team until after the 60-day development period is over. As a result, by waiting to share key performance components, such as code, this team has unnecessarily extended the post-sprint stabilization phase, where developers test and redo integration points. With speed being such a sensitive KPI in situations such as app development, prolonging this phase can make a significant difference in the success of a project. What’s more, it can cause frustration among developers and testers across the software development life cycle (SDLC).

    For comparison, the image below depicts a team that has implemented a CI process. Using CI, the team integrated increments from the main tree continuously. In addition, by using test automation, they are able to ensure the integration actually works. By implementing a CI approach, the conclusion of each sprint is on time and within the defined quality expectation, resulting in a reduced stabilization phase. In some situations, it might be possible to get rid of this phase altogether. The ideal CI process yields a working product at the end of each sprint and each day.

    Method 2: Continuous Delivery

    CD is the practice is the practice of streamlining and automating all the processes leading up to deployment. There are a number of steps in CD, such as validating the quality of the build in the previous environment. When done manually, these steps can take significant effort and time; however, they can be automated using cloud technologies and proper orchestration.

    Teams should ensure they have a monitoring dashboard for their production environment in place to eliminate performance bottlenecks and respond fast to issues. This will complete an efficient CD process.

    Method 3: Continuous Testing

    CT, which can also be referred to as continuous quality, is the practice of embedding and automating test activities into every “commit.” CT helps developers use their time more efficiently when trying to fix a bug for code that was written years ago. To fix the bug, developers should first remind themselves of which code it was, undo any code that was written on top of the original code, and then retest the new code—not a short process. Testing that takes place every commit, every few hours, nightly and weekly not only increases confidence in the application quality, but it also drives team efficiency.

    Outlined below are various steps teams should take to achieve CT:

    • Confirm a stable test lab 24×7.
    • Arm the testing team with a suite of test and development tools that enable high productivity.
    • Leverage automation for only the high value and stable tests.
    • Properly size the platform and test coverage for all projects.
    • Enable fast feedback via frequent reporting and analytics.

    Summary

    One of the most popular misconceptions about adapting to today’s digital transformation and implementing an agile development process is that it hinders speed and quality. Incorporating the CI/CD/CT trifecta, in addition to an agile development methodology enables the velocity and quality needed for success in today’s rapidly transforming industry.

    — Amir Rozenberg

  • How to Get More Visibility Into Your Continuous Deployment Process

    How to Get More Visibility Into Your Continuous Deployment Process

    I know far too many developers who cringe at the thought of continuous deployment. Thoughts of broken code and an endless stream of customer support requests puts continuous deployment into the “nice to have, but not right now” pile.

    But, it might just be a case of clearing the fog on process so you get visibility into the deployment pipeline. If your team can get more visibility into releases, you will have more confidence your shipped code is quality. With more visibility, you’ll be deploying faster and earlier before you know it.

    What are the Results of an Effective Continuous Deployment Process?

    Shipping a big release is taxing on your QA and testing teams and the pressure to get every part of the build correct is huge. Continuous deployment allows you to deploy smaller chunks of code more frequently so you have more control over the release.

    Think “shipping responsibly.”

    With that in mind, it’s easy to see why a lack of visibility can hinder continuous deployment’s goal of shipping more code to a tight schedule.

    Why is Lack of Visibility a Problem?

    Best practices for your software development lifecycle (SDLC) demand that you know what’s going on in your code. And if you are responsible for your release process, you are probably held accountable for what customers receive.

    Production demands visibility into code quality; otherwise, you risk economic damage to your business in the form of bugs and crashes. With this in mind, understandably, many teams hesitate to continuously deploy thorough lack of confidence in the quality of shippable code through the build process. If more visibility means more confidence, let’s take a look at the stages in a build process and how to increase visibility at each stage.

    How to Get More Visibility Into Your Continuous Deployment Process

    Invest in modern architecture

    Continuous deployment will require resources and modern tooling initiated by your best people. Although budget often can be one of the biggest roadblocks to continuous deployment’s success, don’t withhold funds. Invest in the tools and people first, and the process will come. Modern tooling that is updated regularly will give you the best of what’s available, allowing you to effectively see what’s happening in each stage from source control to deployment and beyond.

    Allow for manual intervention

    You may not want your continuous deployment to be fully automatic. There are risks associated with continuous deployment, and to mitigate those risks you need a human to push the “deploy” button. It’s more about making your team feel accountable for their actions. The developer sees the change go live and is the first to test them.

    A viewable stage environment

    Do you have key stakeholders waiting for updates on feature releases? Rush boxes might be the answer. A rush box is a server used for work that is not ready for the QA process. This will give anyone to give feedback and authorize changes.

    Report

    Continuous deployment is certainly not without its risks. But, if you incorporate a culture of visibility into your processes, you can quickly identify where the gaps are so you can start to scale. Your toolkit will generate a huge amount of transactional data that will help to steer your company in the right direction.

    Monitor

    It amazes me how many companies still push out changes and rely on the end user to tell them whether the deployment was successful. Defects in production code have economic impacts on your company, and undiscovered bugs and errors can rack up into technical debt. But, you can’t change what you can’t see. Small changes are always going into production, so time for QA and regression tests naturally lessens. Therefore, you need to know what happened, and when, which is where a monitoring tool such as crash reporting can help. I’ve written before about the benefits of monitoring in continuous deployment, and it’s an integral step that is often missing. Monitoring can also help you make informed decisions about when to rollback a deployment.

    Rollbacks have an economic impact to your business, much in the way errors do. However, if a decision to roll back is data-driven, it’s an easy call for a senior developer to make.

    In Conclusion

    Don’t let the lack of visibility into your deployment pipeline affect your decision to implement a continuous deployment process. Invest in people and tooling first, and the process and scale will come.

    — Freyja Spaven

  • Overcoming the Awkward Teen Years of DevOps Adoption with Process-Centric IT

    Overcoming the Awkward Teen Years of DevOps Adoption with Process-Centric IT

    DevOps adoption is all over the map. Just last year, xMatters and Atlassian surveyed more than 1,000 companies on their DevOps maturity and found only 65 percent were getting the benefits from their DevOps initiative that they expected. Sixty-six percent described their maturity level at or below intermediate. And another 1,000 organizations were excluded from the survey because they didn’t have a DevOps initiative at all!

    With so much misalignment and insecurity, you might say that organizations are going through their awkward teen years. While many businesses recognize the importance of DevOps and agile methodologies, most are still struggling to truly embrace them, and therefore reap the real benefits. So what’s holding us up? The answer is people issues. Gartner recently surveyed organizations about their biggest barriers to DevOps adoption, and resistance to change was No. 1.

    Becoming Process-Centric

    It’s a complex challenge, but it does have a solution. The best way to enable continuous delivery while supporting legacy initiatives such as major incident and IT service management is to ensure your IT teams are process-centric. This entails mapping out the business processes required to achieve IT objectives and identifying the data, tools and people needed to optimize existing workflows while driving real change. If you’re not sure where to start, here’s how you can get started.

    Map Out Essential Processes

    IT teams frequently make the mistake of buying a checklist of tools they believe are necessary, but this can make it difficult to know where to start when evolving IT to support continuous delivery. Without a business process strategy in place, it’s virtually impossible to integrate your tools and optimize collaboration between teams.

    Enable IT to be a driver in achieving business goals by clearly defining your business objectives and the activities that directly support them, as well as managed entities and available response types. For instance, common business objectives include increasing the frequency of code releases, reducing the number and severity of major incidents, minimizing lead time for product updates and improving SLA standards of uptime.

    Identify and Connect Your Process Ecosystem

    After mapping out your business processes, you’ll need a connected ecosystem of data, tools, people and teams to drive them forward. This ecosystem is possible only if you understand the different types of contextual data you need for each managed process, from monitoring insights to system logs to stakeholder communications.

    Next, choose the tools to manage the processes and data flow. For instance, application performance monitoring and management, ChatOps and issue tracking are all common tool types. Then, pinpoint the people (or teams) that need to be involved in each type of process so that you can keep the right people informed—no more, no less.

    Finally, you should ensure that your teams within development, operations and support have an efficient and streamlined way to collaborate so that processes always advance to completion.

    Operationalize Steps for Collaboration and Resolution

    Now let’s get more specific. What are the steps required to facilitate collaboration and drive resolution? By defining these steps, you can optimize and effectively templatize processes that can be reused, thereby improving both consistency and efficiency each time a recognizable  incident comes into play.

    For each process, start by outlining the tasks necessary to resolve the issue, then detail the tools needed and the personnel or teams that should be involved. Repeat this for all of your processes to define the necessary technology investments.

    Automate and Curate Manual Work

    Operationalizing processes improves efficiency to a certain degree, but you can go a step further to really maximize the benefits. This is where you can leverage both automation and curation of manual work. For each managed process, drill down at the task level to determine whether you can either fully automate or, if human intervention is needed, efficiently curate work.

    For instance, routine tasks that have a defined set of triggers and can use software-driven logic to determine and execute on next steps can be fully automated, whereas tasks that have a defined set of triggers but require that human intervention determine which next steps should be curated. There are, of course, different levels of curation and automation based on associated triggers and response types, so you’ll need to gauge these and plan accordingly.

    Extract and Archive Contextual Information

    It’s important to maintain a repository of information on your business processes and how they are handled. This kind of data gives you complete visibility into issues as they progress, and ensure you’re taking consistent, proven responses to similar situations when they arise in the future. Some stakeholders will, of course, also need access to this information.

    The way to maintain this repository is to understand the unstructured data (such as FYI communications) versus structured data types (such as ChatOps) managed within each process. Once these are identified, you can map the unstructured data into structured data. The rule of thumb for aligning stakeholders is that the business and customers require data from structured sources; they’re looking for the information concerned with status and real business impact.

    In contrast, subject matter experts will often rely on unstructured data. They benefit more from the in-depth insights from system and application logs, performance metrics, and other essential data points to help them assess, resolve and manage situations.

    In Conclusion

    The journey to becoming process-centric may seem daunting, but there is a proven approach that can guide you toward the dream of becoming a mature DevOps organization. Figure out which processes you can automate, which require human intervention, and be sure to let your teams work within the systems they know and trust to ease the resistance to change.

    One persistent danger is that multiple systems can create silos of data that stand in the way of collaborative work. A process-centric IT organization with integrated systems can help move data to enable collaboration, more informed decisions and better outcomes. And nothing takes the awkwardness out of a teenager like better outcomes.

    — Kristin Apgar

  • A Definition of DevOps for the Masses

    A Definition of DevOps for the Masses

    If you asked the average person in the street, “What does DevOps mean to you?” you’d probably get a blank stare. And there are those who aren’t directly involved but are vaguely aware of DevOps as a concept. While a vague understanding is better than nothing, it leaves room for misconceptions and misinformation, which can be problematic in the long term. An accurate definition of DevOps is necessary.

    How can you provide an accurate definition of DevOps for a non-technical audience? Long-term DevOps practitioner Alex Honor echoed earlier agile software development principles when he coined the phrase, “People over process over tools.” This mantra provides a handy list of DevOps priorities, and as such offers a useful framework for an easily understandable definition of DevOps.

    Start with the People

    Everyone loves a good organizational chart, and discussing how DevOps teams organize themselves is a useful way to understand how DevOps should work in practice. DevOps is very much about bridging traditionally separate development and operations departments, but this involves more than simply increasing collaboration between teams.

    Related Content:

    5 Biggest Ways to Fail at DevOps

    DevOps Gets More Exciting in 2018

    In a traditional setup, developers build applications and fix them when necessary, while operations teams work to maintain, support and monitor those applications.

    In DevOps, the wall dividing these two worlds disappears. But it’s not just about getting dev and ops teams to work more closely—it’s about creating an environment where developers and engineers work alongside each other at every stage of a product’s life cycle. In other words, there should be no separation between dev and ops, just a unified DevOps team.

    By emphasizing the people factor and contrasting a DevOps team structure with more traditional arrangements, it’s easier to visualize DevOps playing out in the real world. This is a great place to start when it comes to demystifying DevOps for a less-technical audience.

    Move on to the Process

    When put into practice, DevOps is supposed to be faster, more efficient and more reliable than more traditional software engineering methodologies—once the organizational structure is in place, these benefits can be achieved via innovative DevOps processes.

    In traditional development and ops, manual tasks have a habit of slowing down processes, and getting in the way of high-frequency deployments. But in DevOps processes based on infrastructure as code (more on the tech later), teams can automate the provision and management of resources.

    Take the task of provisioning server resources, for example. In the past, the developer would email the infrastructure team and ask for a certain set of resources in a specific configuration. Then someone in the infrastructure team would look at a document and follow a checklist of tasks before finally deploying the server.

    In a DevOps process, not only are developers and infrastructure engineers working alongside each other in the same team, they’re also implementing processes through infrastructure as code (IAC).

    Within the context of IAC, the provisioning of IT resources is automated via code, so rather than provisioning servers manually, the developer simply clicks a button. The desired infrastructure then spins up automatically, accelerating the overall process and giving DevOps teams the means to deploy far more frequently and efficiently.

    By describing the automated processes made possible by IAC, the differences between DevOps and more traditional practices become much clearer. For less-tech-savvy employees, this explanation provides some much-needed context in terms of the day-to-day working of DevOps teams.

    Then Talk About the Tools

    Technology, and the benefits it brings in terms of automation and management, is a key driver of DevOps. The maturation of cloud computing and virtualization, and the emergence of infrastructure as a service (IaaS) in particular, provides the flexibility and speed demanded by DevOps.

    With IaaS, it’s possible to instantly provision computing resources for highly customized and constantly shifting IT requirements, without on-premises hardware or manual configuration. This in turn enables the infrastructure as code (IaC) processes detailed above, and the level of automation required for DevOps teams to function.

    So cloud computing, in the form of IaaS and by extension IAC, lays the technological foundations of DevOps. That’s the big-picture stuff, but what about those brand-name tools that non-technical people might have actually heard of? Docker, Kubernetes, GitHub, Jenkins, Travis CI … the list goes on, but how vital are these to the core concept of DevOps?

    Arguably, not very. While containerization, source control and continuous integration tools all can perform very important roles within a DevOps context, they’re hardly defining features of DevOps itself.

    Continuous configuration automation solutions such as Puppet and Chef come more directly under the IAC umbrella, enabling the automatic configuration and scaling of data center resources. But like the others, these tools would be equally at home in a more traditional setup.

    In this sense, there’s no such thing as a “DevOps tool,” just tools that can be used within a DevOps organization for DevOps processes. It’s how you use them that really counts.

    So when offering a definition of DevOps for a novice audience, don’t fall into the trap of simply reeling off a list of tools. DevOps is far more about people, organization and process. And while it’s very reliant on IaaS and IAC technologies, many of the tools utilized by DevOps teams are more or less incidental.

    And Finally, a Reminder that DevOps Works

    The ultimate goal of DevOps isn’t simply to unify development and operations, but to result in shorter dev cycles, more frequent deployments, higher-quality products and happier customers. More bluntly, the ultimate goal of DevOps isn’t just to say, “We do DevOps,” but to increase productivity and make the business more profitable.

    Just look at sprawling organizations such as Google and Amazon. The success of these companies hinges on their ability to deploy new software multiple times every day, or even every hour. Amazon and Google may not agree on a precise definition of the term, but what they do agree on is that DevOps, as a set of unified software engineering practices, is crucial to their profitability.

    With a consensus on the broad strokes of DevOps emerging over the last few years, lack of definition of DevOps will hopefully become less of an issue as its culture crystallizes. In the meantime, the good news is that the big ideas behind DevOps are also the most straightforward to explain to a non-technical audience.

    By breaking DevOps down into people first, process second and tools third, an accurate and relatively simple definition of DevOps is possible. DevOps is fundamentally about people, how developers and engineers organize themselves and work as a unified team to deliver better products faster. It’s on top of this structure that DevOps processes are built, with a heavy focus on automation and innovative tools—always within the context of the core DevOps principles and practices.

    — Neal Thoms

  • Break the Rules and Win at Digital Transformation

    Break the Rules and Win at Digital Transformation

    The rules of the game have changed.

    In today’s digital world, it’s not about the big eating the small. It’s the fast that beat the slow and the nimble that outmaneuver companies constrained by old systems and business models.

    What’s more, the finish line is always moving. The rapid pace of innovation and disruption means businesses must continuously transform themselves to stay ahead of competitors.

    The takeaway for CIOs: Speed and agility are the name of the game.

    IT must respond faster than ever to shifting business needs. To succeed at digital transformation, companies must rethink how they design, build, deploy and source enterprise applications. They must adopt new approaches that accelerate delivery and anticipate, even bake in, ongoing changes.

    It’s time to update the IT playbook. Here are five best practices from digital leaders that are breaking with the past to deliver a successful future.

    Accelerate and Iterate Software Delivery

    Digital leaders outpace their rivals by adopting methodologies and mindsets that shorten software delivery cycles. They’re also really, really good at rapid, iterative change.

    Shift to Speedier Methodologies

    Digital leaders rely on Agile development methods—short sprints, scrum teams and user feedback loops—to accelerate the design and development of new applications. With its emphasis on rapid iteration and continuous improvement, Agile methodologies are a proven way for companies to churn out new innovations quickly. Studies show Agile approaches average 50 percent faster time-to-market than waterfall ones.

    DevOps is also a catalyst for speed. Automation and tighter collaboration between development and operations make it easier to put new code into production. Led by such companies as Facebook, Google and Amazon, the world is moving away from “that 10-year-old solution everyone’s afraid to touch” to flexible platforms that are updated multiple times a day.

    Adopt an Agile Mindset

    Of course, being agile requires more than just new methodologies. It also demands a willingness to take risks, learn on the fly and adjust continuously. Digital leaders don’t just respond to change; they embrace and design for change.

    Digital leaders test and then invest. They fail fast and then swiftly course-correct. The most successful experiment rapidly and incrementally so if they do stumble, they fall from the first floor, not the 10th. Digital leaders also think big. They don’t just digitize current processes. They completely re-imagine business models and technology systems—as Pitney Bowes did with its transformation into a digital commerce powerhouse or as GE did with its launch of the Predix industrial IoT platform.

    Adopt New Application Architectures and Infrastructure

    Digital leaders are building in flexibility with new application architectures and deployment models. They’re leaving legacy systems behind as they take to the cloud with microservices-based solutions.

    Move to Microservices

    Monolithic applications are hard to change, costly to maintain and ill-suited to today’s dynamic business environment. That’s why digital leaders are moving to an agile, microservices-driven architecture. Converts include Netflix, eBay, Amazon, Twitter, Gilt, Liberty Mutual and the UK Government Digital Service, to name just a few.

    Assembling applications from small modular services—each a self-contained building block—allows digital leaders to transform quickly and at scale. They can mix and match services to fast-track new digital offerings and processes. They can tweak and scale services to adapt to changing business models and customer expectations. And they can push innovation across the enterprise by reusing services—all without adding armies of developers or getting locked into any one technology.

    Step Up Cloud Migration

    The cloud is increasingly the preferred foundation for digital transformation. Digital leaders gain speed and agility by plugging into on-demand services and computing resources. They short-circuit long design and procurement cycles; focus on innovation, not infrastructure; and deliver differentiated capabilities and customer experiences at a fraction of the time and cost.

    Digital leaders are betting big on the cloud. According to IDC, at least half of IT spending will be cloud-based by 2018, reaching 60 percent of IT infrastructure spending and 60 percent to 70 percent of software, services and technology spending by 2020. Organizations across industries—such as Nike, Xerox, General Mills, Liberty Mutual, and the U.S. federal government—have migrated mission-critical workloads to the cloud to support new, more digital ways of doing business.

    Use Novel, Unexpected Sources of Innovation

    Digital leaders rely on open-source innovators and third-party collaborators to shorten development cycles. They’ve also abandoned long RFPs in favor of shorter, more effective proofs of concept (POCs).

    Embrace Open Tech with Open Arms

    Open technologies—including open source, open standards and open APIs—dominate the digital landscape. According to a study by North Bridge and Black Duck, open source software makes up more than 50 percent of the typical enterprise and application stack. Digital leaders including Ticketmaster, Box, eBay and Goldman Sachs rely on open-source software to speed solution delivery and draft off the innovations of millions of developers worldwide.

    Digital leaders also innovate openly with others. They hold hackathons. They crowdsource. They co-create with customers and partners. They also contribute back to the community with projects such as Walmart Labs, Ericsson’s open-source hub and GE’s Industrial Dojo for the Cloud Foundry ecosystem.

    Say RIP to RFPs

    Digital leaders have pulled the plug on massive RFPs for complex, multiyear development projects. Instead, they favor faster, more flexible procurement processes that reward innovation and accelerate vendor selection. They conduct POC tests to evaluate alternative technologies. They use iterative prototyping to refine requirements and determine the best solution for the job. They keep their options open with shorter timelines and smaller deliverables.

    Digital success calls for a more collaborative relationship with technology providers. It’s the whiteboard sessions, technical conversations and joint problem-solving that yield breakthrough results. That’s why progressive companies now approach the RFP like a “request for partnership.”

    Integrate Data and Systems in Transformative Ways

    Digital leaders use open platforms and APIs to integrate information, people and processes across their extended value chain. These connections lay the foundation for faster business flows and new digital products and services.

    Connect Quickly with APIs

    APIs (application programming interfaces) enable diverse applications to connect and share data. Digital leaders use API-led integration to combine services and expose information in ways that deliver unprecedented customer and business value. Within days and without lots of coding, they can roll out service innovations, revamp internal processes, enliven customer interactions, extend their digital reach and enable entirely new business models.

    This year, 2017, has been dubbed the year of the API economy. ProgrammableWeb lists more than 17,700 APIs and hundreds of digital leaders are opening up their APIs so others can easily integrate and innovate with their technologies. API marketplaces from Mastercard, ADP, Ford and FedEx are just a few examples.

    Achieve Digital Flow

    Silos slow the flow of business. Disconnected processes, departmental barriers and gaps in information all impede speed and agility.

    Digital leaders excel at silo-busting. They integrate disparate systems. They connect processes from end to end, across all customer touchpoints and organizational boundaries. They use open platforms to ensure that information—structured data and unstructured content—flows to the right person, at the right time, in the right context.

    The seamless integration of information, people and processes allows digital leaders to be much more nimble and responsive. They can also leverage these connections to make huge improvements in customer experience—such as the bank that slashed loan origination steps by 70 percent or the insurer that processes claims 25 percent faster.

    Bring Business and IT Closer Together

    Digital leaders treat digital transformation as a partnership between business and IT, with a shared focus on meaningful outcomes and better experiences for customers and employees.

    Engage and Empower Users

    Digital leaders put people—customers, citizens, employees and partners—at center of their transformation efforts. They prioritize design thinking, a user-centric approach that shifts the focus from adding features to adding value. They take advantage of platform tooling to involve users in solution design and invest in dedicated UX teams to deliver better experiences faster. Capital One, for instance, regularly solicits customer input at its three innovation labs. Other proponents of design thinking include Citrix, Airbnb, BMW, DHL and Procter & Gamble.

    Another winning strategy is to empower users with self-service tools that add business agility. Examples include self-service analytics for rapid decision-making and process services that make it easy for users to modify workflows as business needs change.

    Take a More Strategic Role

    Now that every company is a software company, IT is increasingly strategic to the enterprise. Successful CIOs have seized this opportunity and are making the most of it.

    Forward-thinking IT leaders have recast IT in the role of business partner and change agent for digital transformation. They look for ways to drive growth, deepen customer engagement and shorten time to market. They help colleagues understand and realize the value of digital initiatives. They build bridges and buy-in by adopting a service mindset—what one CIO calls “ego-free IT.” The new measures of success aren’t IT-specific metrics; they’re meaningful business outcomes such as dollars saved, customers added and market share gained.

    Conclusion

    Every digital transformation is different. But the underlying challenge is the same. How can IT accelerate the pace of delivery and change simultaneously? By following the lead of digital trailblazers, any organization can gain the speed and agility needed to compete in a digital-first world—and win.

    About the Author / Chris Wiborg

    Chris Wiborg is Vice President of Product Marketing at Alfresco Software. In his role, Chris is responsible for setting and executing the go-to-market strategy for Alfresco’s Digital Business Platform. Connect with him on Twitter and Linkedin.