Thinking today about Internal Service Level Agreements (SLAs) or, as the Dev Lead might say when approached on the subject, “the what now? You mean, my employment contract, right?” The answer to that is, “Technically… okay, no.”

An internal SLA is the commitment between the provider and the consumer, as with an SLA between a vendor and a customer. Methods of collecting metrics, specifically what is being monitored, may differ somewhat since the information is used internally only. All jokes about the NSA and Big Brother aside, keystroke tracking may be required, depending on the industry (financial services; government work), in order to provide the level of security detailed in the SLA.

The Internal SLA has the same components of How, What, When, Where, Who, and Why. The penalties for failing to provide complete, accurate, timely, and cost-efficient service will differ significantly, especially personal ramifications for the Dev Lead who tried to duck my question. Ahem. To answer the Dev Lead’s joking-and-therefore-completely-serious question:

• Focus attention where it’s needed
  • The Internal SLA allows for continued monitoring of a delivered service. Ideally the Dev team isn’t working on maintenance constantly. Bug fixing in live/production systems of course comes up over time, as do other maintenance issues such as upgrading firmware or service OSes. Understanding the clients’ expectations allows Ops to plan downtime without violating the Internal SLA and, if break-fix maintenance is required, how to approach that and what the ramifications of that is, as well.

Structure communication for clarity, brevity, and speed

• The Internal SLA details the expected uptime and the required communication from service provider to service consumer/user/client about expected, and more importantly unexpected, downtime. Additionally the Internal SLA can more precisely detail the users’ required level of detail when reporting issues. For example, if the user is calling in to Help Desk, Help Desk will likely have a system-specific script of questions to ask, to get the required information to the Tech or Dev person who will look into the issue. Preventing repeated calls shortens time to resolution.

• Allll of the metrics
  • As mentioned above, collecting metrics internally should be a breeze, with greater data normalization possible.
• Feed metrics into new projects
  • Deeper lessons can be learned from the metrics collected because of the data normalization possible; we can be sure we’re comparing apples to apples.
  • Future project for similar efforts can potentially be structured in a way to minimize the need for maintenance/Dev’s deliverables detailed in the SLA. That’s cost savings over time.

More Reading….

• [Article] How to overcome internal SLA misconceptions, Valeh Nazemoff, CIO.com