devopsy.kinsta.cloud

Tag: agile

  • DevOps Debates: Monoliths or Microservices

    DevOps Debates: Monoliths or Microservices

    From the time software came into existence, application software has been booming to leverage the benefit of the computing paradigm. During this cycle, it has transformed decades of design and architectural thinking, and has crossed all aspects of application development and management needs, be it configurability, reusability, maintainability, scalability or security (a good list is of these “ilities” is here).

    While many have been addressed, one “ility” that has turned a lot of eyes and attention in the last few years is deployability. More than that, it is the ability to do so continuously. This requirement has changed the thinking of building software for two main reasons: (a) Businesses have started asking to release software faster than ever, even in verticals unheard of before; and (b) Cloud and infrastructure as code has made faster deployment a easier possibility. When you look at application design with deployability in mind, given the need to be agile, what you end up getting is a microservice.

    Most applications of old style addressed most “ilities” in an architecture but did not consider “continuous deployability” as a core need as well. I call these monolith from a deployment perspective. They are tightly coupled, and for any small change a complete build of the application was necessary.

    Now the question is, Should you really look at microservice as a silver bullet to deploy all software? Should you consider that as the de facto standard to deliver any application functionality? Will applications cease to exist the way we know? Here are my thoughts. As usual, feel free to add yours or write to me personally, as some of you do as well.

    Applications as monoliths will stay as they are

    1. Monoliths have evolved over generations of design and architecture tests and stood the test of time. The focus on modular development is, in fact, a way of creating modules, which are built with separation of concerns in mind.
    2. Monoliths were built to run for a long time. It had addressed some of the “ilities” well before they became considerations.
    3. Applications will remain easier to debug, as most of the debuggable areas are in developer’s hand, instead of having to work with a team.
    4. Applications will perform better, as they can share data in memory; they don’t have to do out-of-process calls to get one task executed.
    5. Applications will be more secure, as they will be a black box from an end user perspective or even a hacker perspective, with little coming out from the system.

    Microservices will be a monolith-killer all the way

    1. Deploy, deploy and deploy to correct your problems away. Fail fast and fix faster is the mantra that you can practice.
    2. It helps bundle two-pizza teams owning microservices and hence embrace better ownership and faster response.
    3. The overall architecture to deliver an end-to-end use-case may become complex, but each piece of the jigsaw puzzle can be handled faster.
    4. In the faster-moving world, business wants to try a concept rather thinking through all the “ilities” ahead of time, and progressively make everything better. Microservices helps abstract all complexities much better.
    5. Microservices will help developers think out of box from day one, while helping business deliver smaller chunks, without having to make the system a “big ball of mud.”

    At the end of the day, irrespective of the approaches, the key is to ensure the applications are managed well, changes are refactored well, the code that is written is readable and maintainable, and significant test assets are created to regress the entire system quickly. So whether it is a large system or microservices, you are able to make any necessary changes quickly and can deploy fast.

    While microservices surely will help this new faster-deployment thinking, I—and I am sure you all—have also seen large monolithic systems that are making delivery at an astounding pace.

    Thoughts?

  • Are databases part of Agile? The new partnership between Redgate and DevOpsGuys points the way

    Cambridge UK, 7 March 2016 – DevOpsGuys, the Cardiff-based company that builds, deploys, and manages enterprise-scale web applications for blue-chip companies and the public sector, has become Redgate Software’s first Certified Partner in the UK. The move brings advantages for both businesses, with DevOpsGuys given the support and expertise to enable them to include the database in Agile processes like continuous delivery.

    With a growing roster of clients including ASOS, BAE Systems, the Government, and Fitness First, DevOpsGuys is gaining a reputation for delivering practical engineering solutions which revolutionize the way businesses work. Typically called on to improve software delivery processes, speed deployments, and reduce both cost and risk, DevOpsGuys are experts in improving IT performance using DevOps practices.

    Redgate, meanwhile, makes the world’s most trusted tools for shipping changes to enterprise databases. The tools are technically challenging to make, but intuitive to use – a philosophy Redgate calls ingeniously simple. As a direct result, the company has more than 650,000 users worldwide and 91% of the Fortune 100 use Redgate software.

    DevOpsGuys joins other noted software consultancies like Northwest Cadence in the USA and GDS Business Intelligence in Germany in becoming a Redgate Certified Partner.

    Certified Partners are given inside knowledge of Redgate’s products, training in advanced deployments, and expert advice and support so that they can offer a premium service to their own clients. As James Smith, CEO of DevOpsGuys, says: “We’re on the inside track, if you like. We can talk directly to the people creating the software we’re recommending to clients. It’s a big advantage because if we have an issue, we can resolve it with one phone call.”

    The relationship works for clients as well. DevOpsGuys were recently shortlisted by private gym chain, Fitness First, to introduce a standardized IT infrastructure to make software delivery faster, reduce errors, and cut costs. As Smith continues: “Our close working relationship with a key vendor like Redgate demonstrated our capability far better than a PowerPoint slide. It was evidence of our commitment to industry-leading standards and helped us win the business.”

    Redgate’s Database Lifecycle Management (DLM) products were included in the solution to source control database development and automate database deployments for Fitness First. As a direct result, it is now quick and simple for the gym chain to copy databases into new environments – something that was extremely difficult and time-consuming before.

    DevOpsGuys are now organizing a series of training workshops in London UK to teach developers and DBAs best practice for database source control, database continuous integration, and automated database deployment using Redgate tools.

    As Smith concludes: “Redgate have a portfolio of world-leading database products that make continuous delivery for the database a reality. The big thing for clients is understanding how they can work alongside tools for application development, and what new Agile processes need to be adopted to make it possible. That’s where we come in.”

    As part of Redgate’s ongoing commitment to DLM and continuous delivery for databases, DevOpsGuys will be joined in the future by further Certified Partners in the UK as well as America, Europe, and Australasia.

    – ENDS –

    Further information from:
    Michaela Murray
    Regional Partner Manager, Partner Program
    Redgate Software
    michaela.murray@red-gate.com

    About Redgate Software
    Redgate Software makes ingeniously simple software used by 650,000 IT professionals who work with SQL Server, .NET, and Oracle. More than 100,000 companies use Redgate products, including 91% of the Fortune 100. Redgate’s philosophy is to design highly usable, reliable tools which elegantly solve the problems that developers and DBAs face every day.

    About DevOpsGuys
    DevOpsGuys deliver DevOps-as-a-foundation to underpin digital transformation, achieving greater customer enablement and unlocking new revenue streams. Their DevOps Education, Automation, and Transformation solutions make enterprise organizations agile, scalable, and responsive to rapidly changing business requirements.

     

  • Building a Foundation for Big Room Planning

    Building a Foundation for Big Room Planning

    When people think of agile, the first thing that comes to mind is a software development team. But agile is much more than that now, as every DevOps practitioner knows. Nearly a decade and a half of practice has shown us that high-performing agile software development teams are critical, but not sufficient on their own. When they operate in a silo, software development teams can easily become disconnected from the business and from other teams. To truly achieve the higher business goals, those development teams need alignment, or else they risk delivering the wrong things or the right things but at the wrong time. That is where Big Room Planning comes in.

    Big Room Planning is the secret sauce for effective agile planning and execution because it brings together all the people in an organization responsible for delivering software value to market—from development and test to program management and the business—to plan collaboratively. When I say bring them together, I don’t mean that figuratively: The key is to bring them together quite literally, assembling all of the stakeholders together in the same room in real time. That can feel quite shocking because it represents such a significant commitment by the company, but that is the point. Making agile work requires a commitment across every level of a company.

    Before the Big Room

    So do you just have everyone roll into a large space somewhere in a hotel’s conference area and hit a home run? Clearly, no. Setting up an effective agile delivery group takes time, and is far more complicated than spinning up agile development teams because of all the roles involved and how each team and individual will approach their part of the work. Most importantly, establishing the leadership changes required to truly change the way an organization works must also take place. Bottom line: Establishing an agile mindset throughout the organization is critical to have a foundation for success.

    There are three distinct phases of preparation required when standing up an agile delivery group (Agile Release Train, in SAFe parlance), which we call:

    • The Ready phase
    • The Sync phase
    • Rhe Go phase

    Each are vitally important, and without success in the earlier phases, your delivery will get bogged down in the latter stages.

    Get Ready

    The Ready phase is probably the most critical, and it establishes the right leadership, organizational mindset, and right group of people required for agile value delivery. Three key steps include:

    • Enterprise value stream mapping
    • Agile organization design
    • Leadership development

    Without these key steps, supported by leadership at every level, you simply cannot instill the cultural and mindset changes required to stick.

    Get Synched

    In the Sync phase, agile practices are instilled first. Agile practices specific to each role requires training and coaching to set in, and we advocate for a four-to-12-week period to ensure everyone understands their role, the ceremonies they will use to ensure collaboration and what artifacts they will use to plan and execute their part of the overall work.

    Once everyone in the delivery group gets it, it’s time to set up a first Big Room Planning event. This typically takes one month of preparation—without which your event is likely to fail.

    Preparing for Big Room Planning should focus on the inputs for the event. First among these is the business vision and context—the domain of executives, line of business leaders, etc. This is essentially the “why” behind what the teams will work on. Key initiatives for the delivery group, with clear outcomes defined (often supported by a lightweight business case), must be communicated effectively to inspire the group. It takes time to put this together.

    Next, develop a feature backlog that represents what the delivery group will be planning out during Big Room Planning. Doing this well is a more rigorous process than meets the eye. Features are the crucial ingredient because they represent the value being built to both the business and the customer, and they represent the key deliverables teams will produce.

    Product managers typically own this step, and if they are not well-prepared, they run the risk of either asking for too much or  asking for the wrong things that won’t have the desired impact on business results. At CA, our product managers go through several iterations of backlog preparation involving stakeholders throughout to company to make sure the priorities are clear.

    Even with a well-formed and prioritized backlog, effective Big Room Planning requires an understanding of the capacity of the organization to build what’s needed. This requires good estimation and a good understanding of the each team’s velocity. Estimation and a team’s velocity are big parts of what we learn during the Sync phase: Over a few iterations, the amount of work (a.k.a. story points) a team can deliver outcomes and provides an understanding of roughly the right capacity needed for effective planning. Doing this well ensures teams will be asked to plan not only the right features during Big Room Planning, but the right amount of features so that detailed planning can take place with enough time to design stories, resolve dependencies and address risks that emerge.

    Then Go

    The Go phase actually kicks off with the Big Room Planning event. The event itself occurs over a two-day period, which marks the starting point for agile execution. If formed well, the right people will be in the room to build value fast. With upfront preparation, the group members will understand what they will be building and why it’s important, and will be set up to create a plan that best delivers the value needed.

    Planning collaboratively ensures that the plan is well-designed across the group. Most importantly, because everyone has a part in building the plan—with the opportunity to work together across teams and across roles, with the ability to challenge and even veto decisions as they form—everyone ultimately feels a strong sense of ownership and commitment to the final plan. A successful outcome almost always ensues, and the group only gets better from there are they learn to prepare, plan and execute together as a cohesive “team of teams.”

    About the Author/Steve Wolfe

    Steve Wolfe photoSteve Wolfe is Senior Principal, Product Marketing for CA Agile Solutions. He has worked for more than 20 years on software products in both hardware and software companies. His experience spans 10+ years in both software engineering management and product management, including 7+ years on agile teams and delivery groups. Steve’s passions include helping organizations learn how to build the right things fast and reliably by applying agile and DevOps practices at scale.  He is a certified SAFe Program Consultant.

  • Why Financial Companies Should Embrace Automated Testing

    Why Financial Companies Should Embrace Automated Testing

    The drive to deliver new functionality to customers faster is being felt across every industry, and especially so for financial markets that are under pressure from new market entrants. Adopting agile development and continuous delivery can help financial institutions gain an edge and beat competitors to market, but it’s vital that quality is not forgotten.

    Financial institutions are accelerating to update software and release new products in days or weeks instead of months. That means software must be tested rigorously and quickly. Manual testing simply cannot compete with automated testing when it comes to speed, accuracy and the ability to perform functions repeatedly over time. However, it can be challenging to implement successfully. 

    The Customer is Always Right

    Customer power is forcing banks to improve customer experience. Accustomed to slick, efficient website experiences from such leaders as Amazon and Google, customers now are demanding similar experiences from their banks and credit card companies. Millennials expect easier access to banking, precipitating a shift to self-service, which presents all kinds of new IT challenges for banks.

    When customers don’t like their online banking experience, they will simply choose another provider. A full 18 percent of millennials switched their primary bank in the last 12 months, according to a recent Accenture survey. When failed or flawed software gets into the customer domain, the fallout can be very damaging and expensive. Think: lost sales, disgruntled customers, bad PR and a massive price tag to fix the problems.

    Test Automation a Solid Foundation

    Introducing test automation isn’t just about finding defects more quickly and efficiently, though it will do that. It’s also about shifting the burden of regression testing and freeing manual testers to focus on issues such as exploratory testing, usability and penetration testing, where they can add the most value.

    To implement automated testing successfully, financial institutions must devise a long-term plan that dovetails with their business objectives. Having a plan—and sticking to it—outweighs the importance of getting C-level support and winning a huge budget for automated testing. Without a plan, the most well-intentioned objectives can get rejected by senior management, stalled by other forces and, ultimately, forgotten.

    Automated Testing Misconceptions

    The plan should include a robust dismissal of two popular misconceptions about automated testing. The first—and bigger—one is that automated testing will produce instant cost savings, as fewer resources (mainly of the personnel kind) will be needed to perform testing.

    Over time, automation will cut costs. But cost should never be the main factor when considering automated testing. Applying test automation greatly outweighs all the negatives of manual testing (time-consuming), but it also opens new doors for more sophisticated testing and, hence, the competitive advantage.

    The second misconception is that automated testing is a one-time only exercise. Reality proves that automation is always going to be an ongoing process. Automated testing should be treated as (yet) another development activity: You write the production software and you write the software that tests the production software.

    Overcoming the Challenges

    Financial institutions face a threat from newcomers to the market, unencumbered by legacy system baggage and physical branches. They are offering disruptive products and new business models. How can existing financial institutions compete?

    It obviously makes sense to include the business and marketing teams in the development process to develop new solutions for customers. Extend the DevOps mindset to break down those silos. A united team that includes test and marketing alongside developers can ensure that automated tests are well-designed and focused on business aims.

    Pulling together to design and test new ideas can enable financial institutions to reinvent themselves and innovate. Embedding test automation in everything mitigates risk and increases velocity and quality. It can deliver the data businesses need to make the right next move.

    Long-Term Vision, Short-Term Plans

    Fast feedback is paramount to make the right business decisions, but financial institutions must cater to existing legacy systems and integrate new software deliveries from a range of vendors. Without test automation in place, it’s simply not possible to integrate deliveries, test them and reject them as quickly as possible if they are wrong.

    The reality is that organizations must be able to quickly introduce new tools and technologies, because agility and innovation go hand in hand, but the impact on legacy systems must be repeatedly gauged. Test management tooling should be fluid and extensible to cater to this diversity. To accurately measure quality and risk in real time, test automation must be dynamic and flexible.

    Failure to embrace automated testing will leave traditional financial institutions exposed and in danger of being swept away by the new wave of lean, agile, IT-focused competitors.

    About the Author/Viktor Clerc

    viktorViktor Clerc is product manager for testing applications at XebiaLabs, a provider of automation software for DevOps and Continuous Delivery helping companies to accelerate the delivery of new software. You may reach him at vclerc@xebia.com.

  • Murphy’s DevOps: Is Security Causing Things to Go Wrong?

    Murphy’s DevOps: Is Security Causing Things to Go Wrong?

    “Rugged DevOps,” “DevSecOps”—am I missing any? About the only thing more abundant than the volume of terms emerging to describe different facets of how security supports DevOps are the number of vendors now claiming to provide products and services that “solve” related security problems.

    There have been some interesting offerings we’ve seen emerge at this point and most of them probably have merit, in that they likely can accomplish the job they claim to do. Regardless of whether that “job” is actually something that needs to be done to solve a DevOps-related security issue, that is something for the professionals in the developer, operations and security worlds to determine—and hopefully something they will be interested in discussing here.

    This new column’s point is to go looking for problems and solutions. Specifically, it’s focused on how and if DevOps is causing things to go wrong in security (and from time to time in other spots) and what DevOps-focused organizations are doing to correct course.

    Security Questions to Ponder

    Is it true that security can’t keep pace with “continuous?” Will “agile” and security always be oil and water? Will DevOps and security never achieve a harmonious “peanut butter and chocolate”-like relationship? Or, is the talk about how DevOps is the best thing that has ever happened to security and a great opportunity, actually the new reality?

    Another great question this column seeks to answer is whether any of the “so-called” security problems DevOps is creating are anything new, or if they are the same old challenges that have existed since the first bit of sensitive data was exposed to the Internet decades ago.

    There are times when I may mention specific vendor solutions in this column, but only if an actual end user or practitioner is attached to the reference. If that happens, I will always point out if any are clients of mine at my day job.

    It’s no coincidence that this column is being launched just ahead of RSA 2016, as DevOps Connect: Rugged DevOps @ RSA Conference is a major part of the big show, and, that is where the world will be talking DevOps and security after all. Here’s hoping the event will expose problems and provide solutions.

  • TechWell Announces Agile Dev, Better Software & DevOps West in Las Vegas

    Over One Hundred Learning and Networking Sessions To Be Held Over Six Days

    Jacksonville, FL (PRWEB) February 15, 2016

    Agile Dev, Better Software & DevOps West will be held June 5–10, 2016, in Las Vegas, Nevada at the iconic Caesars Palace. The conference offers access to more than one hundred learning and networking sessions over six days, details of which are now available to view online.

    “We are excited to announce the full 2016 Agile Dev, Better Software and DevOps West schedule. This year’s event offers speakers from companies including Spotify, Whole Foods, ThoughtWorks, Autodesk, DirectTV, Electronic Arts, Microsoft, Agile Institute, and others.”, said Stasi Richmond, Director of Marketing for TechWell.

    At Agile Dev West, discover the latest in agile methods, technologies, tools, and leadership principles. Better Software West explores what is needed to build better software now; and, at DevOps West, learn from industry experts how your organization can apply DevOps concepts to improve deployment frequency and time to market, reduce lead time, and more successfully deliver stable new features.

    This year’s keynotes presentation lineup will feature industry experts like Jez Humble on DevOps and the Culture of High-Performing Software Organizations and Linda Rising on The Power of an Agile Mindset—plus other internationally-known speakers. Concurrent sessions offer attendees the flexibility to customize their learning experience by following a specific track or explore various track topics throughout the week. Session Tracks include, but are not limited to:

    ● Agile Leadership

    ● Agile Techniques

    ● DevOps

    ● Going Mobile

    ● Internet of Things (IoT)

    ● Projects & Teams

    ● Software Quality

    ● Test & QA

    Finally, attendees can take part in the Agile Leadership Summit at Agile Dev West. Participants in the Agile Leadership Summit work with and learn from experienced agile leaders that have led lasting change and produced a thriving agile culture. Learn ways to challenge personal leadership growth and lead in your organizational challenges including communication interpretation, anti-fragile approaches, visual data information radiators, and more.

    For more information and to access the full conference program, visit https://bscwest.techwell.com.

    About TechWell Corporation:

    TechWell—through its conferences, training, consulting, community websites, and online resources—helps people and organizations develop and deliver great software. For more information, visithttp://www.techwell.com.

    ###

    For the original version on PRWeb visit:http://www.prweb.com/releases/2016/02/prweb13217021.htm

  • DevOps Brings IT Out of the Shadows

    DevOps Brings IT Out of the Shadows

    One of the biggest threats to organizations today is shadow IT—unsanctioned and unknown technologies and applications being employed by maverick users. Shadow IT represents a security risk for your company—the IT department can’t defend and protect technologies and assets it doesn’t know about—and should be eliminated. One of the best defenses against shadow IT is DevOps.

    When I worked in the trenches as a one-man IT department—part network admin, part tech support—there always were one or two individuals who knew enough to be dangerous. As frustrating as it was to deal with completely clueless users who didn’t know the difference between the computer and the monitor and weren’t even really sure where the power button was, those who knew enough to go rogue and reconfigure their devices or introduce new applications and services were a more existential problem for the organization. In today’s era of BYOD and cloud services, shadow IT is a scourge significantly greater than what I faced.

    Don’t get me wrong—I’ve also been on the other side of that equation and I understand the motivation that drives shadow IT. Users just want to get their jobs done, and the people in the trenches know better than anyone what the hurdles are and how to fix them. Requesting new technologies or capabilities from IT is a cumbersome and tedious process at many organizations, so in the name of expediency users just do what they need to do on their own.

    DevOps can help solve the shadow IT problem in a better and more sustainable way, though. There are two benefits that DevOps brings to the table that minimize the potential for shadow IT: More rapid development and empowering individuals.

    First, an IT organization that has embraced DevOps will be quicker to respond to requests from users. Replacing the traditional software development life cycle with a more agile and continuous pace of development means that feature requests can be incorporated much faster.

    Second, one of the cornerstones of DevOps is the underlying culture—the breaking down of silos and removal of barriers and bureaucratic nonsense that get in the way of efficient progress. Essentially, those rogue technologies and applications that comprise shadow IT in other organizations are simply a part of the larger DevOps whole in an organization that has embraced DevOps. There is even a term ascribed to users outside of traditional IT/developer roles who develop solutions: “citizen developers.”

    The 2015 State of Citizen Development Report explains in more detail what a citizen developer is: “Citizen Developers are empowered problem-solvers from the various lines of business who have the drive and determination to engage in app development even though they lack traditional coding skills.”

    That isn’t to suggest that in a DevOps world everyone can just go set up virtual servers, or store data on personal cloud services and that it’s OK. It just means that when users are given the tools and freedom to develop solutions that have the blessing of IT and the rest of the organization, they don’t need to function in the shadows.

    Embracing DevOps and the citizen developer movement enables IT to work in harmony with users to develop solutions that work rather than fighting against each other and ending up with shadow IT servers, applications and cloud services that IT isn’t even aware of. Organizations that are concerned about the impact of shadow IT should look at ways to harness the power rather than just trying to ban shadow IT completely.

  • Are You Ready for Your DevOps Transformation?

    Are You Ready for Your DevOps Transformation?

    You’re done with missed release deadlines, long release cycles and risky releases. If your objectives are continuous application delivery to achieve fast feedback loops and reduced waste, DevOps practices provide the means to reach them.

    DevOps is all about agile transformation, which reaches beyond agile development into production to achieve continuous delivery. DevOps practices provide help for the necessary next step after agile development to leverage the full potential of agile and avoid massive post-delivery changes through the development teams, but before they are ready to go into production.

    The challenge is to navigate that DevOps transformation—and make it happen faster and at less risk. The speed and direction of that transformation depends on individual circumstances—for example, the type of technology you have deployed, the shape of your organization structure and processes, and what your overriding business and IT requirements are.

    Beginning the Transformation Journey

    Only once you have assessed your organization’s current DevOps maturity and orientation can you begin to scale your DevOps implementation—and move faster on the transformative journey toward continuous delivery. In other words, to know where you’re going, you need to know where you are now.

    transformationBy measuring your status across each of these dimensions on a scale of Level 0 and Level 4 (see diagram), you can benchmark where you are today and derive recommendations and measures for future improvements.

    Culture and Strategy: DevOps requires a strong vision and strategy and its success will depend on the awareness, knowledge, skills and motivation of your employees. This pillar addresses the effectiveness and alignment of your awareness-building and enablement programs as well as your incentivation system with regard to agility in all involved units, dev and ops. It also includes a snapshot of the sentiment and motivation of people to make such a change reality.

    Automation: This pillar addresses the maturity of your organization in terms of IT automation as an important prerequisite for continuous delivery. Both the application architecture and the DevOps automation tool chain are assessed. Relevant automation capabilities in application configuration, provisioning, deployment, test, infrastructure and application monitoring are included in the assessment. The maturity is assessed across the tree layers infrastructure, platform and application, and by technology stack—for example, your SAP platform, .NET or Java stacks—and then combined into a single level.

    Structure and Processes: The current organizational structure and methodologies and processes in use within all involved units are assessed with regard to their effectiveness for continuous delivery. This focuses on their agile fit and maturity. Governance and how agile teams and processes are embedded into the broader organization are part of the assessment scope as well.

    Collaboration and Sharing: Collaboration and sharing between development, operations, infrastructure and middleware teams are crucial to accelerate the delivery process and make it leaner. The assessment looks at particular sharing vs. redundancy of tools (e.g., tools used for deployment), information (e.g., the status of a package in the delivery pipeline), processes (e.g., an ITIL release process and a development release process) and functions (e.g., a release engineer in development and a deployment expert in production).

    Now you have the facts at your fingertips. The DevOps Maturity Assessment Service presents all of this as documented findings, to include a series of recommendations on how you can scale and mature your DevOps activity.

  • You Say You’re Doing DevOps, But What Does That Mean?

    You Say You’re Doing DevOps, But What Does That Mean?

    From recent conversations I have been having, it is clear that DevOps is top of mind for many. Out of the 40 or so customers I have spoken with recently, the overwhelming majority brought up DevOps during our conversation. They believe they ought to do DevOps, but they wanted me to help them define it and point the best way to get started.

    From my experience, many claim to be “doing DevOps,” but when you drill in, you’ll find wildly varying degrees of what this means. If a team is doing anything at all within the larger DevOps value chain, such as testing their software, they often believe they’re doing DevOps.

    Our latest survey on the implementation of DevOps points out how easy it is for companies to say they’re doing DevOps but how difficult it is to do DevOps effectively. There’s widespread agreement among the respondents on all the different things that should get done, but very few people are making significant progress in most of them. If you ask about specific DevOps success factors, very few people are doing them.

    Understanding, Then Doing DevOps

    Why is DevOps so hard? In general:

    1. companies don’t know how to do it
    2. companies aren’t sure what it is
    3. it’s too hard given the existing organization and/or culture
    4. too many jobs and people identify with existing tools and technologies
    5. there may be regulatory issues
    6. there’s a lack of leadership on what needs to get accomplished and the direct impact on users/customers

    The biggest issue usually is the organizational structure. People within IT are working in roles that have institutionalized the separation of dev and ops for 20 or 30 years, and suddenly this must change. Ops, in particular, has a process that is somewhat opaque, but now it has to be transparent, ops teams have to coordinate closely with the development teams, and they are being measured on totally different things. That’s a huge shift.

    Going back to the results of the survey, if you told me 20 percent of companies are doing some element of DevOps exceptionally well, I would agree with that. If you tell me 20 percent of companies are doing DevOps end-to-end the way I think it ought to be done, I would say that number is probably closer to 5 percent.

    The definition of DevOps makes all the difference. To me, DevOps focuses on the distance between the idea and the customer, whether that idea is a feature, an application or a business model. The purpose of DevOps is to optimize that distance.

    I use the word “optimize” for a very particular reason, because there are several different dimensions beyond speed that we need to think about. We also need to optimize for reliability, or perhaps it is appropriate to think of that as quality. Efficiency is another dimension: How much does it cost to run that pipeline? Finally, agility: If I have to make a change based on the customer feedback or the market conditions, how rapidly can I change?

    Based on your customers and what you’re trying to achieve in your business, you might optimize for those four dimensions differently than some other company. In some cases, a company might choose to emphasize speed, rolling out a new release every single day. In other cases, reliability, efficiency or agility might be given more weight.

    The purpose of DevOps is to make speed, reliability, efficiency and agility a given so companies can focus on digital disruption and serving their customers better—we can see that in the survey results. If we also look at the 20 percent that are farthest along in implementing DevOps, we see their most important metrics are customer-facing metrics. In other words, it is clear that with the emergence of companies focused on business insight analytics, more organizations want to know if their application is meeting the needs of the customers as it was intended.

    This is where the cultural and organizational challenges of DevOps come into play. If the ops team owns ops-related metrics, and the dev team owns dev-related metrics, then the organization is probably losing its focus on the customers. Those internal, traditional metrics are not going to get organizations to the Promised Land. You may have developed a bunch of code faster because you’re agile—and that’s great—but it’s only the first step. Instead, if we turn this around and say, “We expect this application to generate a million dollars of new revenue every four hours,” that’s a totally different mindset, and you have a much better chance of DevOps success. The app is either generating the revenue or not, and it’s the feedback you get based on the usage of the application that tells you what else you need to do.

    ING is a great example of a company that has a group of people who are focused on metrics that track the distance between the idea and the customers, and they wake up every day with a focus on how to optimize that distance. The rest of the company is then organized and culturally aligned to deliver against that.

    When you talk to most companies, you’ll find that there are elements of agile development, code pipelining or release automation that they do very well. These companies are taking a vertical or functional slice—such as test automation or release automation—and concentrating on optimizing there. That just gets us back to where we started our discussion, with everybody saying they are doing DevOps but no one doing it successfully. A better way would be to take an application and optimize all of the delivery metrics around that application. Take it all the way, end-to-end, and focus on solving a customer problem. Once that end-to-end distance is optimized, then you can apply what you’ve learned to other applications.

  • The Big DevOps Question: How Do We Get Started?

    The Big DevOps Question: How Do We Get Started?

    Every conversation I have with clients regarding DevOps eventually reaches a point where the client wants to know my recommendations for getting started with a DevOps program. Some have already embarked on a DevOps program, but want me to critique their approach against what I see others doing. Others simply don’t have a clue how to make the necessary changes in their organization.

    Ultimately, I sense in all these conversations a lack of confidence that their intended outcome is achievable and that they’re on the right path.

    The first questions I ask clients are, “What are you looking to accomplish, and what are your business drivers?” Interestingly, 90 percent of the time clients are unclear why they want to embark on this journey. Sure, DevOps makes sense academically, but if you don’t have a clear understanding of your expectations for improvement most likely you’ll end up with more questions.

    Sometimes it helps if I give prompts:

    • Are you looking to improve quality in your production releases?
    • Do you need to release updates and patches into production more quickly?
    • What metrics are you currently looking at, and what makes you believe these are not optimal for your business?

    This last question is really important. Quite often data represents invalid perspectives. Other industries’ and services’ metric of how often they deploy to production or how long it takes execute a release cycle might not be right for your business or industry. I hope medical device and airplane equipment manufacturers take a lot longer to bring something to production and test it more robustly than Netflix does its website.

    In an earlier post I wrote that the need for DevOps is effectively the admittance of a problem; to wit, the cure is continuous delivery. Hence, I often tell clients that a very realistic place to start is not with the actual work, but with the communications methods and pathways that will affect implementing continuous delivery within the organization.

    So many clients want to start their DevOps journey in application development and talk about what they’ve done with continuous build. That’s fantastic, but it has more to do with Agile software development than it does DevOps. If all that work creates bottlenecks in testing, you’ve accomplished very little. Now you must fix the flow to balance out development and testing. Trying to achieve continuous development through serial analysis and correction will take a long time and show little progress along the way—and often leads to abandonment.

    However, if all the leaders of all the various areas involved in the continuous delivery cycle discuss how their efforts are impacted by what the other leaders’ groups do, everyone can see the bottlenecks and constraints and they can prioritize changes. Management often fosters much of the cultural impairment, as these changes can impact everything from workload to bonuses. Getting everyone involved in working together to eliminate the bottlenecks often buys credibility for the program and minimizes some of the individual adoption issues.

    Don’t jump into the deep end of the DevOps pool just because everyone else is. Before embarking on your DevOps journey, do a deep analysis of your organization’s goals and baseline your current levels of performance. Discuss what needs to change based on real business goals and drivers (e.g., it takes us too long to issue regulatory changes to the system). Identify bottlenecks and constraints that exist in the current environment today and put together a plan to eliminate as many as possible.