Much of the interest and growth in DevOps comes from the world of startup and fast growing digital companies, such as Netflix or Etsy. These companies typically need to deliver new functionality onto an existing platform with hundreds of thousands of users in a way that is frictionless. That means minimal (if any) downtime, no loss of critical functionality and continuity of experience. But surely that’s as important to them as it is to most companies.
We tend to think of DevOps in the context of younger digital companies as they are often already in the spotlight for what they are offering anyway. We know about them more because of their market leading offerings (e.g., streaming media across multiple platforms at massive scale, for Netflix) more than we know about what’s happening under the hood, so to speak.
It’s when these companies do amazing things at scale that we start to wonder how we can learn and apply the same lessons within our own organizations. It is this course correction, and the complexity of the different moving parts, that makes any significant change (whether the move to cloud services or adopting agile) difficult and sometimes daunting.
Not just for startups
Startups have the benefit of being able to look around and see what’s working well. They can then take these patterns, practices and cultural behaviors and bake them into their own ways of working early on. A large organization that has grown organically over decades often has solutions that do not readily allow for quick changes in how they function. For example, it is unlikely that they were ever designed with automation and integration at the forefront of their functionality when they were conceived.
However, more and more companies are adopting an API transaction based way of developing. For some, this can be in the form of microservices for new developments. For others, it is through the establishment of an integration layer that connects existing systems. This move towards creating integrated systems, with a longer-term view to opening up data transactions, provides a possible opportunity to incorporate DevOps tooling, culture, and practices into an organization.
In his latest book, “Starting and Scaling DevOps in the Enterprise,” renowned DevOps expert Gary Gruver provides a quick, user-friendly guide that’s a must-read for any large organization needing to understand how to start and succeed with DevOps.
We’re not a software company. Does DevOps still apply to us?
Arguably all companies with any significant IT investment need to operate like software vendors. You might not consider your organization in this way. After all, your business focus might be on selling luxury clothing or improving your clients’ brand recognition but take a minute to reconsider.
How do customers and partners engage with you digitally – do you have a storefront, a mobile application or a website? Do you have a system for providing service support, with tracking? Do you record all client interactions, spend and pipeline activities? Is there another system that carries out marketing and notification to raise awareness or increase spend? How about internal communication – do you use email, intranets or other notification services? Is your organizational data stored and backed up somewhere? How about internal systems, such as finance, HR, and payroll?
While you might not think of your organization as a software company, there are very few companies of any size that don’t have IT as the blood that keeps the system functioning.
The cultural thinking that drives DevOps at an IT level is likely to drive investment at a company level. For example, instead of manually entering data from one system to another (perhaps taking the customer relationship record and creating a spreadsheet for the targeted emails), integrating the systems once provides much greater benefit in terms of data integrity and overall productivity. Similarly, integrating an order for products and services against the corresponding customer record and updating the inventory accordingly, brings additional benefits in terms of timely information for various stakeholders.
This desire to automate where appropriate for improved benefits is a key cultural part of what DevOps brings to the technology delivery and operations part of the business. Where people used to spend days testing the new release manually to see if anything broke, that testing can be written as scripts and included with each new build.
In this way, when a new release is ready to go out, the tests are run against this code to ensure that everything functions as expected. Ultimately the results might be the same, but the cost savings in terms of time and productivity can be sizeable.
The challenge at large enterprise scale
At enterprise scale, automation is not a trivial exercise, but then again, at enterprise scale very few changes are trivial. One area where you might consider introducing DevOps thinking, tooling and practices is in the implementation of a common integration hub.
For complex systems where point-to-point integration has taken place across many different systems based on various business changes and innovation, the first task might be one of simplifying all the ‘spaghetti.’ If this is then put through a common integration platform, you can write tests that ensure that, for each updated connection, the output is as expected.
As the overall solution is decoupled, you get the benefits associated with this architectural change, while also getting the advantages of scalability and quality control that DevOps offers. The organization starts to reduce the amount of duplication that naturally occurs when point-to-point integration is the default pattern. This in turn provides the ability to step back and consider if there are newer, better components that can improve the overall system. This action of continually looking for better ways to deliver services, improve productivity and reduce costs are again part of the DevOps way of thinking.
Alternatively, there could be a new project that is self-contained enough to allow the enterprise to look at introducing new ways of working without impacting the larger portfolio of systems. This type of opportunity can be ideal to build knowledge and confidence in DevOps delivery. Assuming this is successful, you then have a very tangible example of what has worked within the organization to sponsor further efforts with real in-house experience to support your thinking.
For these large enterprise environments, it is all about finding a place to start. Looked at as a whole, the enterprise environment can seem daunting, however, finding some project or component that needs replacing, updating or refactoring provides the opportunity to start bringing DevOps into the organization.