Model migration so every squad sees the same map — a live gaming platform example
ArchiMate gets dismissed the same way TOGAF sometimes does: too theoretical, too many boxes, nobody reads it.
That is fair — when ArchiMate is used as wallpaper.
It becomes valuable when you are in the middle of a migration and six squads are drawing six different pictures of the monolith we are leaving and “the platform we are building.” Lobby thinks matchmaking is already separate. Transactions thinks money moved last quarter. Platform thinks RabbitMQ is “temporary.” Product thinks the cutover is next sprint.
At that moment, ArchiMate is not ceremony. It is a shared language for baseline, target, gaps, and plateaus – the same story ADM Phase F asks for, but visible to engineers, product, and the architecture board.
This article shows how to model a real migration on a live gaming platform: monolith → modular services (lobby, game, transactions) with a message broker on the money path and strangler increments — not every ArchiMate element, only the ones that stop migration arguments.
Why migration is the right ArchiMate proving ground
Migrations fail in predictable ways:
Invisible dependencies — “we extracted transactions” but the monolith still writes wallet state
Fake target states — microservices on a slide, monolith in production
Big-bang fantasy — no plateaus, no coexistence rules
Squad-local truth — each team’s diagram stops at its repo boundary
ArchiMate does not fix those by itself. It fixes them when you model what exists, what must exist, what changes between plateaus, and who delivers each slice.
If ArchiMate only works on greenfield data-center refresh decks, it is not Enterprise Architecture. Strangler migration on a live game platform is the stress test.
ArchiMate in one sentence (before we draw anything)
ArchiMate is a standard notation for describing enterprise architecture across business, application, and technology — and for showing how you move from today to tomorrow without pretending tomorrow arrives in one weekend.
You do not need every viewpoint. You need the right viewpoint for the decision in the room.
| Viewpoint | Use it when… |
|---|---|
| Layered | Explaining structure — what serves what |
| Implementation & Migration | Planning strangler moves, plateaus, work packages |
| Motivation | Linking business drivers to migration scope (optional but powerful in Phase A) |
ADM tells you to plan migration (Phase F). ArchiMate shows what you are migrating in which order.
The example: baseline monolith on a gaming platform
Baseline (Plateau 0): one application component does too much.
| ArchiMate element | Example on the platform |
|---|---|
| Business capability | Live gameplay, Player monetization |
| Business process | Join table → play hand → settle wallet |
| Application component | Monolith Game Server |
| Application service | Socket session, Table state, Wallet mutation (all in one deployable) |
| Data object | Player profile, Table state, Wallet ledger |
| Technology node | Single JVM / process fleet behind a load balancer |
| Artifact | game-server.jar (one binary, many responsibilities) |
The pain in EA language: gameplay hot path and money path share process, deployment, and failure domain. A spike in lobby traffic or a stuck wallet call can drag down live tables.
This is not a drawing exercise. It is the baseline plateau every squad must agree on before “we already migrated” conversations start.
Target: separate capabilities into application components with clear serving relationships — clients and other apps call services, not “the server.”
| Application component | Owns | Application services (examples) |
|---|---|---|
| Lobby Service | Matchmaking, presence | Find table, Seat player |
| Game Service | Live session, table state | Play event, Broadcast state |
| Transaction Service | Wallets, buy-in, payout | Authorize buy-in, Settle hand |
| Message Broker (infra) | Async handoff | Payment command queue |
Client pattern (from the real journey):
REST (or HTTP API) to Lobby — door: find and join a table
WebSocket to Game — room live play
Broker between Game and Transactions — money off the gameplay hot path
ArchiMate relationships to model explicitly:
| Relationship | Meaning in the migration |
|---|---|
| Serving | Lobby Service serves Find table to the mobile client |
| Flow | Game events move between client and Game Service |
| Triggering | Buy-in requested triggers a payment command |
| Access | Game Service accesses table state; Transaction Service accesses ledger |
| Realization | Game Service realizes Live gameplay capability |
The part people skip: plateaus and gaps
Migration is not binary. ArchiMate’s Implementation & Migration viewpoint exists because Plateau 1 is where production actually lives.
Plateau 0 — Monolith (baseline)
Everything in one component. Money and play in one failure domain.
Plateau 1 — Strangler: transactions extracted, monolith still plays
Work package: Extract transaction module; route wallet commands via broker.
| What changes | ArchiMate modeling note |
|---|---|
| New Transaction Service component appears | Target element in Plateau 1 |
| Monolith loses wallet mutation | Gap: retire in-process wallet behavior |
| RabbitMQ (or similar) as Technology service | New Flow between Game and Transactions |
| Coexistence rule | Monolith still owns lobby + game; transactions own ledger writes |
Gap (Plateau 0 → 1):
Duplicate wallet path — monolith code path must be decommissioned, not left “just in case”
Data ownership — one writer to ledger (record in model + ADR)
Operational owner ship — who runs the broker, queues, and DLQ
This is the increment ADM + Agile articles describe transactions module first, live tables keep running.
Plateau 2 — Lobby and game separated
Work package: Split lobby matchmaking from game session; REST door + WebSocket room.
| Gap | Why it matters |
|---|---|
| Session handoff | Lobby assigns table; Game owns socket room |
| Identity / session token | Model Flow of “seat confirmed → connect to game shard” |
| Scale independence | Lobby scales on browse traffic; game scales on seated players |
Plateau 3 — Shard game fleet, containerize (optional further plateau)
Aligns with the 200K concurrent journey: stateless game engines, externalized state, autoscale – another plateau, not a surprise Phase F slide.
EA rule:Model every plateau you will actually run in production — not only baseline and dream target.
What to put on the diagram (and what to leave off)
Model these for migration
Application components you will deploy separately
Application services other teams call
Flows that cross team boundaries (especially money)
Plateaus with dates or release trains
Gaps with named work packages and owners
Principles as constraints (one writer per ledger, money off hot path)
Do not model these (yet)
Every class or microservice repo
Every MQ topic name
Full cloud networking on day one
A perfect enterprise map that updates never
ArchiMate should be just detailed enough that a squad can answer: Does my sprint fit the current plateau?
Migration roadmap (Archi view 4)
The implementation & Migration viewpoint is where ArchiMate earns its keep: Plateaus, Gaps, and Work Packages on one diagram — not a second poster that ignores today.
| Element | In this model |
|---|---|
| Plateau 0 | Monolith baseline |
| Gap P0→P1 | Extract transactions; one ledger writer |
| Work Package 1 | Broker + Transaction Service; retire in-process wallet |
| Plateau 1 | Monolith (lobby+game) + Transaction Service |
| Gap P1→P2 | REST lobby + WebSocket game handoff |
| Work Package 2 | Split Lobby and Game services |
| Plateau 2 | Lobby + Game + Transactions (target modular) |
In Archi (or BiZZdesign, Sparx), attach deliverables, stakeholders, and ADR links to each work package. The notation is standard the discipline is yours.
ArchiMate × ADM × Agile (one line each)
| Method | Role in migration |
|---|---|
| ADM Phase F | Names migration planning as a first-class outcome |
| ArchiMate | Makes baseline / target / plateaus / gaps visible and debatable |
| Agile | Delivers one work package per increment with a demonstrable plateau |
Without ArchiMate (or an equivalent shared model), Agile ships features; with it, Agile ships plateau transitions the board can recognize.
Anti-patterns ArchiMate should kill in migration reviews
Target-state-only diagram — pretty future, lying about today
Component per developer — boxes follow org chart, not behavior
Missing broker — money path drawn as synchronous REST because it is easier to draw
No gap — “we’ll switch over Friday” with no coexistence rules
Plateau without owner — work package on a slide, nobody on-call
ArchiMate as PDF export — model not connected to backlog or ADRs
Rewriting the whole model every sprint — model plateaus, refine incrementally
Migration modeling checklist (use in architecture reviews)
1. Is baseline agreed? One monolith box is not enough — name services, data writers, and hot paths.
2. Is target a plateau or a fantasy? Target without Plateau 1 is a poster.
3. What is the next work package? One strangler slice — who owns it?
4. What gap closes when it ships? Name behavior you stop doing in the old component.
5. Where does money flow? If it is not on the diagram, it is still in the monolith.
6. What is coexistence? Two paths may run briefly — model duration and decommission rule.
7. Which capabilities are realized where? Gameplay vs monetization separation is strategic — show it.
8. Does the squad’s sprint map to a plateau element? If not, why are we building it?
If you can not answer these from the model, you are not ready to migrate. You are ready to argue in stand-up.
Wrapping up
ArchiMate is not a diagram contest. It is how Enterprise Architecture makes migration legible: baseline monolith, target modular platform, plateaus in between, gaps that close with real work packages.
On a live gaming platform, that looked like:
Plateau 0 — socket monolith: play, lobby, money in one place
Plateau 1 — transactions strangler via broker; one writer to the ledger
Plateau 2 — REST lobby + WebSocket game; money still off the hot path
Later plateaus — shard, containerize, autoscale — same model, new gaps
Use ArchiMate to stop six squads from drawing six truths. Use ADM to justify why migration is phased. Use Agile to land each plateau while players are still at the table.
That is EA doing its job: map over slogans, plateaus over big-bang, shared model over private diagrams.
Leave a Reply