Overview
To manage the resiliency of "Vital Services," one must understand both functional and
technical aspects. Identifying technical architecture helps determine which vital
infrastructure services an application relies on. This documentation serves as input
for creating "worst-case scenario" diagrams.
As for all dependency mapping steps of the methodology, the Service Owner is accountable for this activity
and relies on business and IT SMEs. It is thus mandatory for architects to first get in touch with the
Service Owner and the Operational Resilience Manager prior organising any workshop.
Technical Architecture vs Deployment Diagram
It is important to distinguish between two types of diagrams to clarify what should be documented in this step:
| Aspect | Technical Architecture Diagram | Deployment Diagram |
|---|
| Focus |
Internal components (databases, message queues, scheduling agents) and their relationships |
Physical infrastructure (hosting nodes, networks, network flows) |
| Hosting |
Does not show servers, clusters, or hosting nodes |
Shows servers, clusters, and physical infrastructure |
| Audience |
Software architects and developers |
IT Operations and Technology Architects |
Calls, Not Data Flows
This step shifts the focus from tracking data flows to tracking technical "calls"
from a caller to a callee. The direction of a call represents the technical initiation of an action
(e.g., a request), which is often the same as the network flow but different from the direction of
data retrieval.
Examples of Technical Calls
- Calling a REST API via HTTPS to get master data
- Sending a file via CFT
- Calling a database via SQL to store/retrieve information
- Sending mail via SMTP
- Reading messages from a Kafka topic
It is also recommended to model business users or personas to show which applications or
components they interact with.
Inputs & Workshops
Technical information must be collected before creating diagrams.
Mandatory Inputs
- Existing Application Deployment Diagrams created by Technology Architects or IT Operations
- Diagrams of application artifacts (frontend, backend) and technical components (RDBMS, messaging services, network storage)
Use these inputs to prepare diagrams and organise workshops with Subject Matter Experts (SMEs)
such as Application Managers, Product Owners, and Technical Leads.
4-Step Workshop Approach
Phase 1: Before the Workshop (Preparation)
- Identify and nest technical modules (GUI, frontend, backend) inside the application
- Identify business actors (users) and technical components (Queue Managers, Scheduling Agents)
- Identify external but related components (databases, network storage) and managed services (SSO, Mail servers)
- Map call relationships and their associated protocols
Phase 2: During the Workshop (Collaboration)
- Share the draft diagram on-screen
- Ask SMEs to identify missing artifacts or technology components
Phase 3: Challenging the SMEs (Validation)
- Probe for "hidden" components like middleware (ESB or EAI)
- Ensure the list of databases and managed services is exhaustive
- Verify that all data flows involving vital applications are explained and mapped
Phase 4: Finalisation
- Keep track of answers and update the diagram accordingly
- Application components must follow the pattern
[app_short_name] module_name (e.g., [MTM] Web Front-end) to avoid generic names like "Frontend"
- Technical components are modelled as Technology Services using the pattern
[app_short_name] provided_behavior (technology) (e.g., [MTM] Messaging Service (MQ))
- Managed services are modelled as Technology Services using the pattern
provided_behavior (common_name) (e.g., Single Sign On Service (WebSSO))
- Call relationships must reflect the purpose of the call using a verb (e.g., "stores files") and must include a Protocol property (HTTPS, SQL, MQ, etc.)
- Components and triggers not needed for the worst-case scenario should be greyed out
Example: Technical Architecture Diagram
The following diagram illustrates the technical architecture for the MTM Application (AP08414).
MTM — Technical Architecture Diagram
Example of a SATS (Schéma d'Architecture Technique & Sécurité)
MTM Users
[HTTPS]
Single Sign-On Service (WebSSO)
[HTTPS]
Email Sending Service (SMTP)
→
MTM (AP08414)
[MTM] Web Front-end
[MTM] Workflow Engine (QuickFlow)
[MTM] RDBMS Service (Oracle)
[MTM] Messaging Service (MQ)
[MTM] Batch Scheduling Service (Autosys)
[MTM] File Storage Service (NAS)
[MTM] File Transfer Service (CFT)
→
Web Front-end
stores & retrieves
[SQL]
Workflow Engine
watches changes
[SQL]
Messaging Service
sends messages
[MQ]
File Exchange Service (XFB Gateway)
[CFT]
WTX (AP07529)
→
FREE (AP28005)
→
AceTP (AP02807)
→
Actimize (AP24134)
FOX (AP02871)
→
ARPE FUSION (AP00510)
→
ARPE BF25 (AP02811)
→
GRODE (AP02876)
→
RDI (AP02922)
→
MIDAS (AP02901)
Business Users
Vital Application / Service
Non-vital Service
External Service
File Transfer (CFT, SFTP)
Database Access (SQL)
Messaging (MQ, Kafka)
HTTP / HTTPS
Other RPC Protocols
Footnotes
- Archi tip: Use label expressions like
${name}\n(${property:Protocol}) to automate the display of component names and their associated protocols.