PagerDuty sponsored this post.
Over the last few decades, software certainly “ate the world.” Today, software is rebuilding and supporting enterprises during a time of uncertainty and change. The way we write, deploy and maintain software is changing — so technical operations teams need to change, too. Our research found that 80% of companies are experiencing increased demand for digital services, and more than half (53%) believe this pressure has reached unprecedented levels in the past 3-6 months. This places tremendous strain on IT and DevOps teams.
In this context, traditional operating models no longer keep pace with modern development processes, application stacks, and the rate of change required. Traditional, centralized management is failing as software, systems and teams increase in complexity. It is easy enough for fresh new startups building applications from scratch, but most of us have already invested and built skills in how software was built yesterday. This is difficult to change. Today’s enterprises are now undergoing digital transformation and a new approach is needed to ensure contemporary software stacks are always on and delivering maximum value.
This is where full-service ownership comes in. The idea is simple — today’s digital services are powered by microservices that are constantly changing. These microservices enable rapid development, deployment and flexibility. Behind those rapidly changing microservices are distributed technical teams who are building, testing, rolling out and maintaining what’s there independently. Full-service ownership brings these experts closer to their customers and the business outcomes driven by their software. But getting there takes time, change and the right tools.
There was a time when software development worked very differently. In the days before Agile and DevOps, developers wrote monolithic towers of code that went into production on static four or five-tier technology stacks. After deployment, they handed them over to multiple siloed teams. This process was consistent but was slow and inefficient. Software changed infrequently as a result.
Then software ate the world. Today’s businesses are laser-focused on driving innovation to meet customer expectations around convenience, speed and personalization through digital services. Consequently, application services changed significantly. Services today are built on hundreds of microservices, supported by multiple distributed technology teams. They update their part of the service when they want and as a result we see downstream implications — Amazon, for example, can drive thousands of distributed changes a day. It’s a next-generation challenge to manage and master complexity on that level.
This complexity, combined with a new pace of change, is causing problems — an estimated 80% of all incidents are caused by changes in the environment. Full-service ownership was designed to address this complexity.
By enabling decentralized teams to own the entire lifecycle of their services and dependencies to others, they can add value in new and unexpected ways. For one thing, your organization gets much better at shipping features quickly. The key is clarity of responsibility at real-time speeds, which is just as important as agility in this new era of business. Empowering engineering teams means they are engaged when something goes wrong — reducing hand-offs and mean-time-to-resolve (MTTR). In other words, no panic, no uncertainty and there’s minimal customer impact.
Full-service ownership means everyone in the business understands exactly what they’re working on and why, what the dependencies are, who relies on their services, and what the end goal is for delivery. It brings them much closer to the impact their software and services have. In turn, this crystalizes what’s needed to continue delivering value. With this knowledge, it becomes much easier for teams to solve unexpected problems while they try new things. Less guesswork, fewer interruptions and more innovation.
However, it’s not easy to make the transition to full-service ownership and it certainly starts with a DevOps mindset. Long-standing function-based silos are a feature of many existing IT organizations. They divide the process of developing code, quality assurance, owning the customer relationship, running software in production and so on across centralized teams.
The task of reworking team structures and technology for full-service ownership may seem overwhelming, but it doesn’t need to be. Starting small and taking things in stages is the key.
It’s important to understand what “business service” actually means. A business service is a critical function required to run a business or deliver your customer offering. Business services are powered by digital services, made up of microservices delivering a feature, component, shared piece of infrastructure or an internal tool.
Service ownership is about connecting humans to technologies and services. This includes an understanding of what and who delivers business services. What are the boundaries of a given service, what processes is it involved, what does it deliver, who is responsible for it and what does it impact at the business level? At any given instant (and even in dynamic environments) organizations need to be armed with this information — even the teams behind a particular service.
If you are at the beginning, demonstrating small gains can be a good way to win the executive buy-in needed to drive organizational change. Choose a non-critical production system or greenfield applications to start with and try to avoid technology debt. Initially, don’t set tight timelines. If this is new to your organization, it will take time to master the lifecycle. Agile methodologies will be useful in adapting to dynamic development requirements and unpredictable events while still focusing on long-term goals. Test-driven development and writing code in small batches is also a good idea that makes it easier to spot and address problems before and in production.
As you mature into production and a full-service ownership mentality, your teams should consider not only “build and deploy,” but also “run.” Adopt technology that comprehensively shows the entire infrastructure, leverage machine learning to reduce alerts and false alarms, and use automation to conserve team resources and reduce the impact of going “on-call” to support services in production.
Above all, remember that full-service ownership takes time and may require cultural change. Mistakes are inevitable — set your team free to learn new models and experiment without fear of failure. In the long term, adopting full-service ownership will result in greater agility, lower costs, happier engineers and better customer experiences.
Featured image via Pixabay.