Overview
Understanding how applications work together to support organized processes is key.
To reach this goal, it is first needed (for each organized process) to create a diagram
showing the most critical data flows that are required during the end-to-end execution
of the activities. Once done, vital applications and flows are highlighted, and additional
information (such as Integration style and technology) are added to facilitate the linkage
between application and technology layers.
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 organizing any workshop.
Potential Inputs & Workshops
This step requires both a good knowledge of the organized process and a good knowledge of
applications. The typical inputs are:
- The organized process description and the list of supporting applications established during the step "Map Applications to Activities".
- Already existing Application Exchange Diagrams or Data Flow Diagrams, usually centered around critical applications.
- Existing data flow catalogs.
With these inputs at hand, it is then possible to organize a workshop with Business and IT
SMEs, such as Business Process Owners, Applications Managers and Functional/Application Architects.
Creating the End-to-End Application Data Flows Diagram
Here's a starting point to lead this workshop:
-
(Before the workshop) Prepare a (potentially slightly simplified) visual description
of the organized process. The process should be as linear as possible and run from left to right.
Put it on the top of the diagram. Put applications below the activities they support. Because an
application can (and usually will) support multiple activities, it can be added several times
to the same diagram.
-
(During the workshop) With the diagram shared on screen, ask SMEs to draw data
flows from applications to applications. The direction of the arrow indicates the direction of
information exchange, from the data producer to the data consumer. Take note of the information
exchanged on the name of these flows (usually the name of the data or dataset).
-
Challenge SMEs to identify potentially hidden applications. For example:
- Which applications are in charge of collecting the input data?
- Which data repositories are required?
- How are data exchanges managed? Do they rely on other applications such as an ESB[1] or an EAI[2]?
-
Keep track of the answers and update the diagram accordingly when needed.
Modeling Rules
- Flow labels should describe the information or data type exchanged, not the technical channel.
- Each flow should contain a property named
Integration Style set as either Unknown, Manual, File Transfer, Shared Database, RPC or Messaging.
- Each flow should contain a property named
Integration Technology referencing the integration technology used (e.g. CFT, SOAP, REST, MQ, Kafka).
- Applications and flows not needed for the worst-case scenario are greyed out.
- Active flows use specific colors based on integration style (e.g. Message, Rem. Proc. Invocation, Shared Database).
- Use color to highlight which applications and flows support the worst-case scenario.
- When using Archi, a label expression such as
${name}\n(${property:Integration Technology}) can be used.
Integration Styles and Technologies
Once the flows are identified, it is important to track how the information is exchanged.
The integration style and the integration technology per flow should be documented.
Unknown
Integration style is not yet identified. Temporary placeholder to be refined.
Manual
Human-driven data exchange (e.g. email, phone, manual data entry).
File Transfer
Batch file exchange via protocols such as CFT or SFTP.
Shared Database
Applications accessing a common database or data store directly.
RPC
Remote Procedure Call — synchronous request/response via SOAP or REST.
Messaging
Asynchronous message exchange via MQ, Kafka, or similar brokered technologies.
Example: End-to-End Application Flow — Outgoing
The following diagram illustrates the end-to-end application data flow for the
Cash Payments — Outgoing process, highlighting vital applications and flows.
End-to-End Application Flow — Outgoing
Example of an end-to-end data flow diagram for Cash Payments — Outgoing
Corporate Customers
Host-to-Host · Face-to-Face · Fax
→
SWIFT
INTERNAL SERVICE
SAG · AMH · FBM
→
Message (SWIFT)
Message (MTM)
Receive
Instruction
Coherence
Checks
Compliance /
AML Handling
Regulatory
Reporting
Financial /
Accounting
Payment
Release
→
Billing
→
Archiving
→
Client
Reporting
SWIFT INTERNAL
SERVICE
PLAZA64 · AMH · FBM · SAG
→
Clearing & Settlement
Mechanism (CSM)
EURO1 (EBA) · STEP2 (EBA) · TARGET2 (EBA)
Message (SWIFT)
Auto. File Transfer
Vital Application
Non-vital Application
Message
Auto. File Transfer
Non-vital flow
Customer Flow Map: Payment Instruction Management
The customer flow map shows the high-level steps of payment processing and which applications support each step.
Payment Instruction Management
Process steps mapped to supporting applications
1. Receive
Instruction
→
2. Instruction
Validation
→
3. Instruction
Enrichment
→
4. Instruction
Scheduling
→
5. Handling Bulk
Payments
→
6. Instruction
Internal Routing
Footnotes
- ESB — Enterprise Service Bus: a middleware architecture for integrating applications via messaging.
- EAI — Enterprise Application Integration: frameworks for integrating heterogeneous applications.
- Enterprise Integration Patterns reference: Integration Styles Introduction.
- When using Archi, a label expression such as
${name}\n(${property:Integration Technology}) can be used to display integration technology on flow labels.