In ops, we often have other internal groups that we either work with or support. It's often useful to view these groups as a customer, then you use the same policies, perhaps with a few exceptions in some cases, to manage the relationship. Typically we call this the OLA, the operating level agreement. I can only speak for my own experience, but operations groups I've been part of that don't have this concept of the operating level agreement typically suffer various types of damage to reputation. This is because there are no rules around how internal groups assess accountability, and therefore by having the terms of the OLA, you have the ability to defend your position as long as you stayed within the terms of the OLA. For example when we started building VAData data centers all over the world for Amazon, by having an OLA, we were able to push back on groups that claimed we were not holding up our end of the agreement.
I work in machine learning, where my team’s ML web services are typically requested by other in-house teams to provide features for their business logic, and so our SLAs are also agreements with other in-house teams.
What I’ve found is that product managers and business people are typically extremely resistant to traditional concepts of software requirements or feature planning, because they want flexibility to change requirements late in development without any negative repurcussion to them.
But somehow the language of SLAs magically clicks and they are more receptive to defining a service agreement. Then you ask them, from a business point of view, how much uptime does it need, what sort of throughput does it have to support, is the budget for outages or failures distributed equally across all features or more important for some features than others?
This practically leads directly to the same scoping and requirements discussion you would have had in traditional software planning, but for some reason the language of SLAs is more palatable, so I’ve found it is an effective way to get around some non-tech person in the loop who might be fighting against detailing a proper spec or documenting priority delivery among features.
