As a TOGAF practitioner, I hear the same complaint often TOGAF is too theoretical.
That is only half true.
TOGAF looks heavy when you study it as a framework. When you apply it the right way, especially through the Architecture Development Method (ADM), it becomes surprisingly simple and practical. Whenever a complex business problem lands on your desk, try following ADM. It does not give you magic answers it gives you a clear picture what matters, who owns it, what to build, what to govern, and what to change next.
In this article, I map a real-time fraud engine we built for high-scale gaming and payments onto ADM not as a certification exercise, but as a working method.
TOGAF ADM applied to a real-time fraud engine Preliminary through Phase H with requirements at the center signal → detect → decide → case → learn contrast of without ADM vs with ADM.
Why a real-time fraud engine is a good ADM proving ground
High-scale gaming and payments are a bad place for vague architecture.
Business risk is immediate (loss, chargebacks, regulatory heat, player trust).
Stakeholders disagree on “success” (risk wants catch-rate product wants low false positives; ops wants explainability finance wants cost).
Decisions sit on hot paths game and wallet flows cannot wait for a leisurely batch job.
Data is everywhere (events, payments, device, behavior, cases) and late or wrong data becomes wrong blocks.
Buy vs build vs reuse shows up hard (vendor fraud suites vs in-house rules/ML vs shared event platforms).
Change never stops (new abuse patterns weekly). Phase H is not optional poetry.
If ADM only works on calm greenfield HR portals, it is not Enterprise Architecture. A real-time fraud engine is the stress test.
ADM in one sentence (before we use it)
ADM is an iterative method to move from “why are we changing?” to “what must be true in business, data, applications, and technology?” to “how do we deliver and govern without lying to ourselves?”
You do not need every artifact. You need every phase question answered well enough to decide.
Preliminary Phase — get permission to architect, not just to code
ADM question: Are we allowed to run architecture as a controlled change, with principles and scope?
For a real-time fraud engine, Preliminary is where enterprises usually skip and later regret.
What we fixed here:
Architecture principles the engine must obey (examples prefer explainable decisions on player-facing blocks no silent irreversible wallet actions without audit reuse enterprise event sources before inventing parallel telemetryprotect PII in case files protect hot-path latency budgets).
Org touchpoints:Risk, Payments, Customer Support, Legal/Compliance, Game/Product, Data Platform, Security.
Repository / decision log: fraud architecture decisions are recorded, not trapped in Slack.
Scope fence: this cycle is “real-time fraud decisioning and case workflow for online play and payments” — not “boil the ocean AML + KYC + every analytics dashboard.”
Without Preliminary, every squad invents private fraud truth. ADM starts by making the fraud engine an enterprise concern.
Phase A — Architecture Vision name the pain and the target state in business language
ADM question: What problem are we solving, for whom, and what does success look like?
Fraud conversations love tools. Phase A refuses tools first.
Drivers we made explicit
Abuse and payment fraud leaking into loss and support load
Real-time game and wallet paths needing decisions in tight latency budgets
Investigators needing a case trail, not only a model score
High-scale concurrency peak play and payment bursts, not demo traffic
Management wanting to avoid unbounded third-party fraud-platform cost where an in-house + selective-buy mix is defensible
Vision statement (shape we aligned on)
A real-time fraud engine that consumes trusted enterprise events, decides with rules and models under clear SLAs on gaming and payment hot paths, opens explainable cases, and improves continuously without a second shadow data estate.
Stakeholders and concerns
| Stakeholder | Concern |
|---|---|
| Risk / Fraud ops | Catch rate, case quality, tooling |
| Product / Game | False positives, player friction |
| Payments | Auth/capture risk, chargebacks |
| Support | Clear reasons, override path |
| Platform / EA | Reuse events, avoid duplicate stacks |
| Finance | Loss vs platform TCO |
Phase A outputs a vision stakeholders can argue with. If they only argue about vendor logos, you are still in sales mode, not ADM.
Phase B — Business Architecture how fraud work actually runs
ADM question:What business capabilities, value streams, and processes must change?
For a real-time fraud engine, Business Architecture is the difference between a model demo and an operating model.
Capabilities we mapped
Signal intake- player, session, payment, device, bonus, gameplay events
Detection — rules, velocity, graph/collusion signals, ML scores
Decisioning — allow / challenge / hold / block / step-up (sync on hot paths)
Case management — queue, investigate, evidence, disposition
Feedback — confirmed fraud / false positive back into rules and training
Reporting — loss, funnel, SLA, auditor views
Value streams (simplified)
1. Live play / payment → real-time risk check → decision → continue or friction
2. Post-event review → enrichment → case → action
3. Analyst improvement → pattern found → rule/model change → governed release
Baseline vs target (business)
Baseline: fragmented checks in payment and game services tribal knowledge weak case continuity vendor tools overlapping enterprise data
Target: shared real-time fraud capability clear RACI between risk ops and engineering decision SLAs by channel feedback loop owned
If Phase B is skipped, “fraud AI” projects optimize the wrong verbs.
Phase C — Information Systems Architecture (Data + Applications)
ADM question: What data and applications realize those capabilities?
Data Architecture
Canonical risk events aligned to enterprise event models (game + payment + identity signals)
Feature / profile for real-time attributes (velocity, device reputation, linked accounts)
Decision and reason codes as first-class data (not log line archaeology)
Case and evidence store with retention and access control
Label / outcome data for model and rule learning
ADM forces a hard line: the fraud engine does not get a private parallel universe of “almost the same” player events. Reuse enterprise data products build fraud-specific semantics on top.
Application Architecture
Application Architecture building blocks: Decision API, detection workers, rules and policy, model scoring, case management, admin/simulation, and integration adapters.
| Application building block | Responsibility |
|---|---|
| Fraud Gateway / Decision API | Real-time sync decisions on hot paths |
| Detection workers / stream jobs | Async scoring and pattern detection |
| Rules & policy service | Versioned, testable rules |
| Model scoring service | ML inference with fallback |
| Case Management app | Investigator UX and workflow |
| Admin / simulation | Shadow rules, backtests |
| Integration adapters | Game, payments, wallet, support, notifications |
Baseline often shows rules hard-coded inside payment or game services. Target separates decisioning from channel apps so high-scale gaming and payments call one fraud engine instead of each inventing one.
Phase D — Technology Architecture make non-functionals boringly explicit
ADM question: What technology standards and patterns meet the SLAs?
For a real-time fraud engine, NFRs are the architecture:
Latency — hot-path decision budget on game and payment calls
Availability— fail-open vs fail-closed policy by transaction type (a conscious business choice)
Throughput — peak concurrent games and payment bursts
Auditability— every material decision replayable
Security— least privilege on cases; encryption; secrets
Observability — decision metrics, drift, queue age, false-positive rate
Technology patterns that fit this class of engine:
Event backbone already in the enterprise
Low-latency decision service horizontally scaled
Stream/nearline enrichment without blocking the sync path
Datastores fit to access patterns (profiles vs cases vs features)
Isolation of model runtime from rule runtime so one failure mode does not blind both
Phase D is where buy/reuse/build returns vendor case tools might be buy event bus reuse decision service build. ADM does not mandate build. It mandates fit.
Phase E — Opportunities & Solutions packages, not wishlists
ADM question: What solution building blocks and work packages close the gap?
We grouped work so delivery could breathe:
1. Foundation — decision API, reason codes, audit log, adapters (payment + one game path)
2. Detection depth — velocity rules, device/link signals, model score integration
3. Case ops — investigator workflow, evidence attach, disposition codes
4. Intelligence loop— features, backtest harness, governed rule/model release
5. Decommission— retire duplicate checks and overlapping vendor modules
Each package has dependencies and a business outcome. “Big bang fraud rewrite” is not a Phase E output. It is a resignation letter.
Phase F — Migration Planning sequence risk reduction
ADM question:In what order do we move, with what transitional architectures?
Real-time fraud migration is dual-run friendly if you design it
Shadow mode: new engine scores beside old checks compare
Dark launch: decide but do not enforce on selected cohorts
Enforce on lower-blast-radius payment types first
Expand to hotter game paths when false-positive SLAs hold
Keep break-glass override with support/risk RACI
Roadmap is calendar + risk, not only story points. ADM Phase F makes that respectable in front of finance and risk leadership.
Phase G — Implementation Governance architecture is a gate, not a spectator
ADM question: Are delivery teams implementing the architecture we agreed?
Governance checks that mattered for our engine
New channel cannot embed local fraud ifs — must call the Decision API
Reason codes required for player-facing friction
Fail-open/closed matches policy matrix
Hot-path latency budgets are measured, not assumed
PII in cases classified and retained correctly
Model/rule changes go through simulation evidence
Without G, ADM becomes a kickoff deck. With G, ADM becomes how the enterprise stays honest.
Phase H — Architecture Change Management: fraud never sits still
ADM question: How do we respond when the enemy changes tactics?
Fraud is adversarial. Phase H is continuous:
Monitoring abuse pattern shifts and model drift
Intake for new typologies from investigators
Architecture runway for new signals (new payment rail, new game type)
Re-entry to earlier ADM phases when the vision or capability map breaks
If your TOGAF practice has no Phase H operating rhythm, you certified a museum.
Requirements Management — the center that a fraud engine will flood
Every phase dumps requirements into a managed set latency, explainability, retention, jurisdictions, payment-scheme rules, player-experience limits, audit.
ADM’s center is not bureaucracy. It is how you stop a single loud incident from silently rewriting enterprise principles.
What applying ADM changed
What applying ADM changed: without ADM versus with ADM on the real-time fraud engine.
| Without ADM | With ADM on the real-time fraud engine |
|---|---|
| Vendor demo drives scope | Vision and capabilities drive scope |
| Engineers argue tools first | Business architecture names the work |
| Shadow data copies appear | Data architecture reuses enterprise events |
| Hot path latency is a surprise | NFRs are Phase D contracts |
| Big-bang cutover fantasy | Migration with shadow and dark launch |
| Architecture finishes at design review | Governance and change management continue |
TOGAF did not give us the fraud engine. ADM gave us a way to decide and sequence one for high-scale gaming and payments.
How to steal this for your next Architecture Board
1. Pick a real problem with enemies, regulators, or revenue on the line.
2. Walk A→H as questions, not as mandatory 40-deliverable cosplay.
3. Write principles in Preliminary before tool shortlists.
4. Force Business Architecture before ML heroics.
5. Make fail-open/closed latency, and explainability explicit in Technology Architecture.
6. Package E/F so risk shrinks every release.
7. Keep G/H alive or admit you only did waterfall with extra shapes.
Whenever a complex business problem lands on your desk, try following ADM. It will not hand you magic answers. It will hand you a clear picture.
Wrapping-Up
TOGAF looks heavy when you study it as a framework. It becomes simple when you apply ADM to something that can hurt the business.
For us, that something was a real-time fraud engine for high-scale gaming and payments. Stakeholders, capabilities, data, applications, technology, migration, governance, and change under adversarial load.
Theory becomes useful the day you stop redrawing the ADM crop circle and start answering its questions against a working method.