Using Archi for Technical Architecture Diagrams (TADs): How We Standardized Modeling in a Financial Institution

Introduction: Formalizing Architecture with TADs

In many financial institutions, architecture decisions are not just collaborative — they are governed. One of the most powerful tools in that governance is the Technical Architecture Diagram (TAD) — a standardized, layered model that shows how applications, infrastructure, and data interact.

In this article, we share how we helped a major bank define and enforce TAD standards using Archi for decentralized modeling and Sparx EA for traceability and governance. The result: a repeatable, reviewable architecture pipeline — from idea to approved deployment.

What Is a TAD?

A Technical Architecture Diagram (TAD) is a structured visual model showing:

Infrastructure and hosting topology
Application components and integration interfaces
Data flows, classifications, and systems of record

In the financial institution we worked with, no project could proceed without an approved TAD . This made TADs the backbone of architecture communication and compliance.

Why Use Archi to Model TADs?

✅ Standard ArchiMate Language

Supports layered modeling: Business, Application, Technology
Semantics and connectors already aligned with EA governance

✅ Lightweight Tooling for Architects

Open source — easy to deploy across teams
Modelers can work independently and commit to Git

✅ Easy to Enforce Visual Standards

Shared TAD templates for layout and mandatory elements
Embedded metadata via properties and views

Our Custom TAD Design

We defined a TAD reference layout used by all project teams. Key rules included:

Bottom Layer = Hosting and Infrastructure (Servers, Cloud Zones, Firewalls)
Middle Layer = Application Components, Interfaces, APIs
Top Layer = Data Objects, Classifications, Owners

Required Properties for Each Element:

Owner
Environment (e.g., DEV, TEST, PROD)
DataSensitivity (e.g., PII, PCI, Confidential)
AvailabilityTier , RecoveryTime

Connection Table Usage:

Application ↔ Data Object → for risk review
Application ↔ Interface → for integration analysis
Application ↔ Node → for deployment traceability

Review and Approval Process

Once created in Archi, each TAD was submitted as part of a formal Architecture Office Review :

Architect pushes Archi model to Git
Architecture board reviews in standard template
Checklist includes:
- Deployment alignment
- Data classification present?
- Resilience and integration visible?
Approval status is recorded (Approved / Revision Needed)

Linking with Sparx EA

All approved TADs were exported to Open Exchange Format (XML) and imported into Sparx EA. Benefits:

Preserved relationships, metadata, and layout
Linked to existing business capabilities, requirements, and programs
Used in dashboards (Prolaborate) and audits

EA became the integration layer — merging TAD insights with operational data and compliance needs.

Why This Approach Worked

✅ Distributed modeling in Archi reduced bottlenecks
✅ Consistent TAD design accelerated review time
✅ Centralized repository in EA ensured traceability
✅ All stakeholders — from architects to auditors — had a single point of truth

Conclusion: TADs as Architecture Contracts

For regulated industries like banking, architecture is not just design — it’s contract. By standardizing TAD diagrams in Archi and managing them via Sparx EA, this client achieved scale, speed, and control over architectural decisions.

The TAD format — simple, structured, and approved — was the keystone. If you want modeling that’s both agile and auditable, this approach might just work for your organization too.