IT Service Planning and Design
What this domain tests
Service planning and design converts strategy into service definitions that can be operated, measured, charged and recovered. Expect questions on the service catalogue, service level agreements and their supporting agreements, the service design package, and the design of capacity, availability, continuity and security.
Core rules
- Catalogue versus pipeline. The catalogue holds live, orderable services with descriptions, owners, service level targets and prices; the pipeline holds services in design or transition.
- Three agreement layers. An SLA is with the customer and states outcomes; an OLA is internal, between support groups; an underpinning contract is with an external supplier. Every SLA obligation must trace to an OLA or underpinning contract that is at least as strict.
- Design covers five aspects: service solutions, management information systems and tools, technology architecture, processes, and measurement methods and metrics.
- Availability arithmetic: agreed availability is measured over an agreed service window. 99.9% of a 30-day month (43,200 minutes) permits 43.2 minutes of unavailability.
- Continuity: a business impact analysis sets RTO (how quickly service must return) and RPO (how much data loss is tolerable); recovery design must meet both and must be tested, not just documented.
Worked example
A customer demands 99.9% monthly availability for an order system, measured 07:00–23:00 daily. Service window = 16 h × 30 = 480 h = 28,800 minutes, so 0.1% allows 28.8 minutes of downtime per month. The internal database team signs an OLA at 99.95%, and the hosting provider's contract must be stricter still; otherwise the SLA cannot be honoured. Because the window excludes 23:00–07:00, planned patching done outside it does not consume the availability credit - a detail exam items test repeatedly.
Traps that cost marks
- Writing an OLA looser than the SLA it supports.
- Measuring availability over 24/7 when the SLA defines a narrower window.
- Swapping RTO and RPO, or designing recovery without testing it.
- Sizing capacity to average demand instead of peak demand plus headroom.
- Publishing a catalogue the customer cannot actually order from, or omitting ownership and pricing.
- Designing only the technical solution and forgetting metrics, process and supplier arrangements.