Locking down that SLA – A VCDX Quest

One of the things that continued to haunt me during the preparation of my VCDX is the SLA (Service Level Agreement), I got grilled, squashed and eaten alive because of it during the mocks, it was like the minute they’d see the term SLA! Its forks and knives on the table ;-).

This blog post is compilation of my understanding of an SLA and how it impacts the design decisions. Hopefully, this will help those out there preparing. On a side note, folks don’t be intimidated by the fact that you might have not grasped the SLA part from the first couple of mocks, its normal and it builds up during the process.

Before delving more into this, don’t think about the SLA from a financial perspective, you need to think about the SLA as a pillar that drives the management of the customer expectations and your design outcome.

1. There might be a single SLA.
2. There might be multiple SLAs.

When dealing with a single SLA, I (you might not) find it harder to defend as most of the times it will drive you away from thinking about the rest of the enterprise construct (from an SLA perspective that it).

On the other hand, when dealing with multiple SLAs for the different enterprise constructs, then you’ll have more leverage and you’ll have more chance to show design skills and ultimately it will help you realize the track you’re defending.

That said, please do take into consideration that your SLA focus should touch on all of the enterprise constructs, but from your perspective you might not be responsible for them all and you just need to cater for the alignment of the SLAs so that yours won’t contradict others, for example, if you’re defending NV then your focus should be on the networking services and their constructs, yet you need to align with other constructs so that to make sure your networking SLA doesn’t violate the other SLAs.

Usually in an enterprise an SLA has a certain type of focus, when it comes to VCDX, aligning the SLA with AMPRS makes perfect sense, in such a way that, each SLA should be subject to:

As you will notice, I tried to look at an SLA from the different angels and I attempted to align those points with something relevant to the VCDX blueprint, obviously in a design/architecture not all of these pillars are important from an SLA definition point of view, but, they’re all there and they’re all impacted, yet when it boils down to your business cases then you will definitely have more focus on at least 2 out of the 5 (for example Availability+Performance or Security+Recoverability).

Probably I should have mentioned this as the beginning, but if your customer doesn’t have any SLA or doesn’t provide you with an SLA then don’t state in your design document that you did not have an SLA or neglect it (remember before, me eaten without salt and pepper ;-)). If that’s the case, this is the perfect timing to brush up on SLA’s and how they shape an enterprise and then think of a mold to shape your SLA and align it with your business requirements.

Now that you have you defined the SLA and the SLA’s focus, you will need to show how you’ve satisfied the SLA requirements, and this could be done for example via (either/or):

1. Functional testing.
2. Business written processes (this including business continuity plans, cold site recoverability procedures, etc.).
3. Change management processes.
4. IT Audit cycles.
5. Penetration testing cycles.

If your SLA is fictitious or not, the question stands still “HOW DID YOU SATISFY YOUR SLA?” and you’d better be ready to answer this question and you need to anticipate any question that might go around it, by doing so, you will save yourself a lot of time and you will get out of a rabbit hole smoothly and elegantly.

When thinking about the SLA, it’s a skill that you will also need in the design scenario. Maybe not much in depth or as thorough in comparison to the design defense, but as I said before don’t think about the SLA from a financial perspective, think about it from a design steering perspective and it can definitely be used as one of the points to discuss and lead with when conducting the design scenario discussion.

I am definitely continuing to learn more about the wonderful aspects of SLA’s and I’d like to thank Manny Sidhu, Chris Porter for provoking the need for such a blog post and Mateja Jovanovic for giving us the chance to mock with him to learn more and more throughout the process.

If you have links, ideas, books or any comments that can enrich this blog post, please let me know and I will update it and if you think I have misunderstood this please hit me up and we can have a conversation about it.

Thank you,
(Abdullah)^2