Vital Services
End-to-End Design Methodology

A structured 10-step approach to identify, document, and analyze vital services, their supporting applications, and worst-case scenarios for operational resilience.

Created by Jean Baptiste SARRODIE · Dec 17, 2024 · Updated Mar 12, 2025

About This Methodology

This methodology provides a comprehensive framework for documenting and analyzing vital services within an organization. It covers the full lifecycle from identifying critical services to creating deployment diagrams for worst-case scenarios. Each step builds upon the previous one, ensuring traceability and complete coverage of the service landscape.

Scope & Context

  • Domain: IT Group Architecture — Operational Resilience
  • Stakeholders: Service Owners, Enterprise/Functional Architects, Business Analysts, IT SMEs
  • Key Inputs: RISK Process Library, ServiceNow CMDB, RISK0449 Policy (MTDT)
  • Modeling Tool: ArchiMate (Archi tool)

Methodology Steps 10 steps

Each step includes detailed guidelines, modeling rules, and examples.

1

Identify Vital Services

Evaluate the criticality of business activities. Document vital services as ArchiMate Business Services with attributes: name, category, owner, and description. Create a single view listing all vital services.

Table 7 Vital Services
2

Map Vital Services to Processes

Map each vital service to RISK processes that realize them. Decompose generic processes into organized processes (2-5 per service). Service Owner accountable, relies on business and IT SMEs.

ArchiMate Diagram Modeling Rules
3

Detailed Process Modeling

Break down organized processes into activities modeled as Business Functions. Follow an 8-step workshop approach: define scope, identify start/end events, identify activities, assign actors, map applications, and define process flow.

8-Step Approach BPMN Diagram Modeling Rules
4

Map Applications to Activities

Identify applications used in each activity. Distinguish primary (critical) vs. supporting applications. Golden source: ServiceNow. Model as Application Components with AUID property. Color-code by criticality.

App Mapping Modeling Rules Criticality
5

Analyze Worst-Case Scenario

Define the worst-case scenario (Extreme Cyber Attack) and MTDT. Determine which activities are affected: performed as-is, done manually, deferred, or skipped. Classify impacted applications as "vital."

WC Diagram MTDT Impact Analysis
6

Document End-to-End Application Data Flows

Create diagrams showing critical data flows between applications. Follow a 4-step workshop method. Add integration style and technology to each flow. Vital flows highlighted for worst-case scenario.

4-Step Workshop Integration Styles Modeling Rules
7

Identify Dependencies Between Applications

Uncover hard dependencies like master data repositories. Create Application Exchange Diagrams with the vital application in the center. Show incoming flows on the left, outgoing on the right.

Exchange Diagram Modeling Rules Workshop
8

Document Application's Technical Architecture

Create Technical Architecture Diagrams focusing on components (databases, queues, schedulers) and call relationships with protocols. Distinct from Deployment Diagrams — no hosting nodes shown.

Tech Arch Diagram Naming Rules Calls vs Data Flows
9

Map Applications to Infrastructure Service

Optional step. Map applications to 7 categories of IT infrastructure services: Network, Security, Data, Collaborative, Operations, Compute, Communication. Identify critical vs. important services for WC scenario.

7 Categories Optional Modeling Rules
10

Create Deployment Diagram for Worst-case Scenario

Create a specialized deployment diagram focused on the worst-case scenario. Based on application exchange and technical architecture diagrams. Specific guidance out of scope for this version.

Out of Scope Deployment

Core Modeling Rules

Recurring conventions across all methodology steps.

Activity Operations

  • Manual — fully manual activity
  • Automated — supported by one or more applications
  • Deferred — postponed until normal operations resume (light grey)
  • Skipped — not performed at all (dark grey)
🔷

Application Criticality

  • Vital applications — dark blue
  • Non-vital applications — light blue / grey
  • Critical property on serving relationships (Yes/No)
  • An app can be critical for one activity but not another
🔗

Integration Styles

  • Unknown, Manual, File Transfer
  • Shared Database, RPC, Messaging
  • Technology examples: CFT, SOAP, REST, MQ, Kafka
  • Flows are functional, not technical
📐

Worst-Case Focus

  • Non-vital apps/flows → greyed out
  • Flows colored by integration style
  • Protocol-based coloring for technical diagrams
  • Call relationships use Protocol property