Overview
In addition to already identified vital applications, there might be some unseen hard dependencies
(for example a vital application might rely on a master data repository which has to be available
because data are not replicated nor cached). Documenting the surrounding ecosystem for each vital
application will help clarify these data dependencies and evaluate their criticality.
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 an in-depth knowledge of applications. The typical inputs are:
- 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 workshops (usually one per vital application)
with IT SMEs, such as Applications Managers, Product Owner, and Functional/Application Architects.
Creating the Application Exchange Diagrams
Here's a starting point to lead these workshops:
-
(Before the workshop) Initiate the Application Exchange Diagram: the vital application
sits in the middle and known flows are imported together with their related source/target applications.
It is advised to put incoming flows on the left and outgoing flows on the right
as this can usually help visualize dependencies. Try to be as exhaustive as possible, leveraging the
model content but also existing data flow catalogs.
-
(During the workshop) With the diagram shared on screen, ask SMEs to identify missing
key dependencies, and add them to the diagram.
-
Challenge SMEs to identify potentially hidden applications. For example:
- If a source/target application is a middleware, what are the real business applications connected to it? Which data are sent/received?
- Which data repositories are required?
- How are data exchanges managed? Do they rely on other applications such as an ESB or an EAI?
-
Keep track of the answers and update the diagram accordingly when needed.
Modeling Rules
- There's one single Application Exchange Diagram per vital application.
- If an application belongs to another Vital Service, it is shown nested (i.e. aggregated) into a Grouping whose name reflects the Vital Service. Even though such Grouping can be reused multiple times on a diagram (and across diagrams), there must be only one Grouping per Vital Service inside the model.
- Each flow should contain properties named
Integration Style and Integration Technology.
- Arrow denotes data flows from producer to consumer, independently of the integration pattern used.
- When using Archi, a label expression such as
${name}\n(${property:Integration Technology}) can be used to display integration technology on flow labels.
Example: MTM Application Exchange Diagram
The following diagram shows the Application Exchange Diagram for the MTM vital application,
with incoming flows on the left and outgoing flows on the right.
MTM — Application Exchange Diagram
Example of a diagram identifying data dependencies between applications
Freemind
Outgoing Payment Instruction
through WTX
→
FREE
Outgoing Credit Transfer
through WTX
→
AceTP
Confirmation of Credit
through WTX
→
ARPE BP2S
Payment Instruction (Incoming)
through WTX
→
ARPE FUSION
Payment Instruction (Incoming)
through WTX
→
ACCOUNTING SYSTEMS
MIDAS · Cord · Olympic
Client account info · through WTX
→
→
Billing · through WTX
EBR
→
Regulatory reporting · through WTX
RRR / Clide
→
Post Act Fraud Control · through WTX
MIS
→
Payment Instruction
FREE
→
Fraud checks request · through WTX
Actimize (Fraud)
→
Exchange Rate · through WTX
FOX
→
Payment Instruction (outgoing)
ARPE FUSION
→
Payment Instruction (outgoing)
ARPE BP2S
→
Treasury Announcements · through WTX
GEODE
→
Booking & Billing
ACCOUNTING SYSTEMS
MIDAS · Cord · Olympic
Vital Application
Non-vital Application
Grouping (other Vital Service)
Message (WTX)
File Transfer (CFT)
Shared Database
Rem. Proc. Invocation
Manual
Other or Undefined
Arrow denotes dataflows from producer to consumer independently of the integration pattern used.
Footnotes
- 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.