How can organizations make sure applications are built quickly without sacrificing quality?
It probably comes as no surprise that development and operations teams don’t always see eye to eye. Though they both may be focused on delivering high quality apps and services that meet the demands and expectations of their customers, they often have different motivations. The challenge is getting everyone on the same page.
For example, “quality” means something different to developers than it does to operations teams. Quality for developers might be centered on code and defect densities. Quality for operations might be application performance. And each group might focus on one variable more than the other. One group might be optimizing for time. The other might be optimizing for quality. But in reality, application development and operations teams need to have a shared vision of each of the variables — time, cost, and quality — and make sure the main priority is delivering a top-notch customer experience.
The DevOps methodology is gaining in popularity in today’s tech-driven, highly competitive business environment. The idea is to break down barriers between developers and the operations teams so that IT can deliver sleek and functional apps in days, not months. But we can’t speed up the application release process at the cost of performance or perceived quality by internal and external customers. The resulting applications have to be enterprise-grade. They can’t crash and burn, they must deliver positive customer experiences, and the applications must perform exceptionally and consistently.
After all, there’s no reason to release 100 apps — or even one app — if the customer experience is horrible or the application performance is lousy or unpredictable.
How can organizations make sure applications are built quickly without sacrificing quality? Here are just a few ideas to start:
- IT leaders should establish shared goals — with regular assessments — for both the application development and operations teams to encourage communication.
- Conducting job exchanges lets an application developer see how the other half lives and vice versa, fostering collaboration.
- Assign one owner to an application that is responsible for it from beginning to end to manage its lifecycle — from development, through testing, and even beyond its launch into production. It doesn’t matter if the person is an application developer or systems administrator, the point is to ensure that the app isn’t just developed and thrown over the fence, but actually meets a business objective.
- Organizations should add more quantitative practices that exact measurable efficiencies and improvements in IT operations. Capacity planning and Service Assurance tools are a great start.
Let’s take a closer look at how capacity planning and Service Assurance tools can help make the DevOps methodology work in practice.
Capacity planning used to be a once-a-year exercise in which a PH.D. came out, Skittles and Mountain Dew in hand, with a really complicated Excel spreadsheet, to take a snapshot of all of the assets on the ground and forecast what infrastructure would be needed during the next year. Not so any more. Predictive modeling and other intelligence-driven methods can help organizations right-size their infrastructure rather than over-provision. But these tools shouldn’t just be for ops teams. Developers can model the capacity an app might require based on workload parameters and response time goals. Developers can use the tools to test what-if scenarios ahead of time and identify the capacity the app will need before it gets thrown over the fence to operations. If developers can model the capacity they’ll need, given the scenarios that they anticipate, they can share that model with operations. Better yet, developers can actually reserve capacity so when the app is ready, so is the infrastructure. There’s no point of rushing an application to production, if production doesn’t have the capacity to host it.
Service Assurance takes things one step further. Wise operations teams are talking in terms of business services and are taking an experience-centric approach. Rather than think about singular domain availability metrics, they’re thinking about systematic metrics around the experience of the customer. During each customer interaction, is the service available? Reliable? Accurate? And it can’t be just operations. Developers need to consider business service reliability.
Both development and ops teams have to think about the customer, and align their efforts around common software development goals of time, cost and quality (TCQ). And they have to relate all three variables to the overall customer service. Capacity planning and Service Assurance tools are a necessary start to getting both teams to focus on customer expectations.