​

ServiceNow Service Design

​

Command

arckit servicenow "<project ID or service>"

​

Description

​

Arguments

• Project ID or service: Project identifier or service name (e.g., ‘001’, ‘IT Asset Management’)

​

When to Use

• After architecture design (HLD/DLD)
• Before implementation begins
• For operational readiness planning
• ITSM integration preparation
• Service transition planning

​

Required Context

• Requirements (ARC--REQ-.md) - MANDATORY
• Architecture Diagrams (ARC--DIAG-.md) - MANDATORY
• Architecture Principles (PRIN) - Recommended
• Data Model (ARC--DATA-.md) - Recommended
• HLD/DLD (vendors//hld-v.md, dld-v*.md) - Recommended

​

Features

​

1. Requirements to SLA Mapping

• NFR-Availability → SLA availability targets
• NFR-Performance → Response time SLAs
• NFR-Security → Change control requirements
• INT-xxx → CMDB dependencies
• DR-xxx → CMDB attributes

• Critical requirement → Tier 1 service → 99.95% SLA
• Important requirement → Tier 2 service → 99.9% SLA
• Standard requirement → Tier 3 service → 99.5% SLA

​

2. Diagram Components to CMDB CIs

• External System (context diagram) → Service CI (dependency)
• Container (web app, API, database) → Application CI
• Deployment node (EC2, RDS, Lambda) → Infrastructure CI
• Data flow arrow → CMDB relationship

​

3. Service Tier Determination

​

Document Sections

​

Section 1: Service Overview

• Service name and description
• Service owner and stakeholders
• Business justification
• Dependencies from context diagram

​

Section 2: Service Catalog Entry

• Display name
• Request process workflow (Mermaid diagram)
• Approval chain
• Fulfillment workflow

​

Section 3: CMDB Design

• Mermaid tree from architecture diagrams
• Every component from container/deployment diagrams

| CI Name | Type | Technology | Owner | Status |
|---------|------|------------|-------|--------|
| Payment API | Application | Node.js | Team A | Active |
| PostgreSQL DB | Database | PostgreSQL | Team A | Active |

• Technology stack
• Cloud provider
• Repository URLs
• Health check URLs

• Parent-child (hosted on)
• Dependencies (depends on)
• Connections (connected to)

​

Section 4: Change Management Plan

• Standard (low risk, pre-approved)
• Normal (medium risk, CAB approval)
• Emergency (high impact, ECAB)
• Major (significant change, board approval)

• From Wardley evolution if available
• Default risk matrix otherwise

• Default: Sunday 02:00-06:00 UTC
• Customizable per service tier

​

Section 5: Incident Management Design

| Priority | Response | Resolution | SLA |
|----------|----------|------------|-----|
| P1 - Critical | 15 min | 4 hours | 99.95% |
| P2 - High | 1 hour | 8 hours | 99.9% |
| P3 - Medium | 4 hours | 24 hours | 99.5% |
| P4 - Low | 1 day | 5 days | 99% |

• One category per major component
• From container diagram

• Format: [ProjectName]-[ComponentName]-L2
• Example: “PaymentGateway-API-L2”

1. Detection → Alert received
2. Response → On-call engaged
3. Diagnosis → Health checks, logs
4. Mitigation → Rollback or hotfix
5. Resolution → Root cause, prevention

​

Section 6: SLA Definitions

• From NFR-Availability (e.g., “99.9% uptime”)
• Downtime allowed (e.g., 43.8 min/month)

• From NFR-Performance (e.g., “<500ms p95”)

• Based on service tier
• P1/P2/P3 response and resolution times

• 24/7 for Tier 1/2
• Business hours for Tier 3

​

Section 7: Monitoring & Alerting

• From sequence diagrams or default /health
• GET endpoint, expect HTTP 200

• CPU, memory, disk, error rate, response time

• P1/P2 → PagerDuty (immediate)
• P3 → Slack (15-minute delay)
• P4 → ServiceNow only (email digest)

• Operational (real-time)
• Business (daily aggregates)

​

Section 8: Knowledge Management

• Getting Started Guide
• Troubleshooting Guide
• API Documentation
• Runbooks (P1, P2, P3)

1. Purpose
2. Prerequisites
3. Steps
4. Verification
5. Rollback

​

Section 9: Service Transition Plan

• ✅ ServiceNow CIs created
• ✅ SLAs configured
• ✅ Assignment groups created
• ✅ Monitoring configured
• ✅ Runbooks documented
• ✅ Support team trained

• Pre-cutover (T-1 week)
• Cutover window (6 hours)
• Post-cutover (T+1 week)

​

Section 10: Traceability

• Requirement ID → ServiceNow element
• NFR-xxx → SLA definition
• Component → CMDB CI

​

Section 11: UK Government Compliance

• GDS Service Standard compliance
• ITIL v4 practices implemented
• Digital Marketplace requirements
• Annual technology spend reporting

​

Output

• Service tier
• Number of CMDB CIs
• Key SLA targets
• Incident response times
• Support coverage hours

​

Example

arckit servicenow "DWP Benefits Chatbot - Tier 1 critical service"

• NFR: 99.95% availability → Tier 1
• NFR: <500ms response → Performance SLA
• 4 components → 4 CMDB CIs
• 2 external deps → 2 Service CIs

• Service tier: Tier 1 (99.95% SLA)
• Support: 24/7 via PagerDuty
• 6 CMDB CIs
• P1 response: 15 minutes
• Change approval: CAB required

​

Validation Checklist

• ✅ Every NFR has SLA
• ✅ Every component has CMDB CI
• ✅ Every CI has owner
• ✅ Every incident category has assignment group
• ✅ Health check endpoints defined
• ✅ P1 runbook complete

• ✅ SLA targets match NFRs
• ✅ CMDB hierarchy matches diagrams
• ✅ Support hours match tier
• ✅ Technology stack matches HLD

​

Related Commands

• arckit devops - DevOps strategy with CI/CD
• arckit diagram - Source architecture diagrams
• arckit requirements - Source NFRs for SLAs

​

Next Steps

1. Review SLA targets with service owner
2. Create CMDB CIs in Pre-Production
3. Configure incident categories
4. Set up monitoring and alerting
5. Train support team with runbooks
6. Schedule service transition workshop

​

Important Notes

• Every ServiceNow element must trace to architecture
• SLA targets MUST match NFRs exactly
• Don’t promise unrealistic SLAs
• Design must be implementable by ServiceNow admin
• Include actual URLs, commands, not placeholders