Bring it home: EA on your AI platform¶
This guide taught you to build the pieces — calling an LLM, RAG, voice, image and video, guardrails, observability, cost. Enterprise architecture is how you see them as one platform and decide what to build, in what order, and how it's governed.
The rest of this section taught the technique on a bicycle manufacturer,
Cadence Cycles, because a neutral example keeps the method in
focus. This page runs the same technique on the platform this guide is
actually about — a cloud-agnostic AI platform. Everything below is a real
Archi export from a committed model (archi/ai-seed.ajs), regenerated exactly
like the Cadence diagrams.
What you'll get out of this page
- A capability map of an AI platform, each tile linked to the pillar of this guide that builds it.
- One layered view — a single RAG feature traced from a boardroom goal down to the cloud primitives it runs on — with the application and technology layers mapped to concrete Azure / GCP / AWS services.
- A "what to stand up first" ordering, scored the way the capability heat-map page scores investment.
The platform as one capability map¶
Left to itself, "we're doing AI" becomes a pile of disconnected demos. The capability map is the antidote: a stable inventory of what the platform can do, grouped into areas, agreed once and reused as the frame for every later decision. Here is that map for an AI platform — and every capability on it is a pillar of this guide.
The AI-platform capability map — an authentic Archi export. Fill colour is the ArchiMate Strategy layer; grouping shows the three areas. Each capability is an ability, not a team or a tool — which is exactly why it maps cleanly onto a pillar of this guide.
| Capability | What it is | Build it in |
|---|---|---|
| LLM Access | One gateway in front of every model, so callers are cloud- and vendor-neutral | Call an LLM |
| Retrieval-Augmented Generation | Ground answers in your own data | RAG |
| Voice | Speech-to-text → LLM → text-to-speech | Voice |
| Image & Video Generation | Generate and edit pixels and frames | Image · Video |
| Multimodal | Reason over image + text together | Multimodal |
| Guardrails & Safety | Input/output checks that fail closed | Guardrails |
| Observability | Traces, evals, prompt logging done safely | Observability |
| Cost / FinOps | Token accounting and per-feature unit cost | Cost |
| Identity & Trust | Passwordless service identity, attributed writes | Trust & attribution |
| Delivery (IaC + iterative) | Terraform + Helm baseline, shipped iteratively | Delivery & practice · Foundations baseline |
The value of drawing it as a map rather than a checklist is that it is stable. Models, SDKs and even clouds will churn underneath you; "we need an LLM-access capability and it must be guardrailed and observable" does not. That stability is what lets an architecture govern change instead of chasing it.
One feature, top to bottom¶
A capability map says what exists; it does not show a single feature working end to end. For that you need a layered view: one coherent thread traced through the ArchiMate layers so you can follow a single line of sight from why down to what it runs on. Here is that view for one RAG feature.
One RAG feature across the layers. The goal is realised two ways — by the Add RAG course of action (served by the RAG capability, which serves the Ship an AI feature value stream) and by the AI feature to end users service that the software actually delivers. Realisation is a dashed line with a hollow triangle; serving is a solid open arrow; each box carries its layer colour.
Read it downward:
- Motivation — the why. Ship trustworthy AI features fast, on any cloud. Two forces sharpen it into requirements: the business wants features, and you want to avoid lock-in. That second driver is why the layers below stay deliberately cloud-neutral.
- Strategy — the how. The RAG capability, configured by an Add RAG course of action, is what realises the goal. It feeds the Ship an AI feature value stream (Frame → Prototype → Harden → Deploy → Observe → Cost-tune) — the repeatable path every feature takes, and the reason each pillar of this guide has a place to plug in.
- Business — what users get. The AI feature to end users service is the customer-visible end of the goal.
- Application — the software. A Retrieval Service does the retrieve step and calls a Model Gateway for generation. Keeping the gateway a separate component is the single most valuable structural decision on the diagram: it is where portability, guardrails, cost accounting and observability all attach once.
- Technology — cloud-neutral. Each application component is served by a primitive that every major cloud offers: a vector DB, a model endpoint, and a Kubernetes cluster (or serverless) to run on.
The application + technology layers, per cloud¶
The layered view is drawn cloud-neutral on purpose — that is the whole point of the Avoid cloud lock-in driver. But when you build it, each neutral box lands on a concrete service. Here is the mapping for the RAG thread above.
| Layer box | Azure service |
|---|---|
| Model Gateway (app) | Your service on Azure Container Apps / AKS, calling Azure OpenAI |
| Retrieval Service (app) | Your service on the same compute |
| Model Endpoint (tech) | Azure OpenAI deployment |
| Vector DB (tech) | Azure Database for PostgreSQL + pgvector, or Azure AI Search |
| Kubernetes / Serverless (tech) | AKS / Azure Container Apps / Functions |
| Object Store (tech) | Azure Blob Storage |
| Managed Identity (tech) | Microsoft Entra managed identity |
See Trust → passwordless to services for wiring the managed identity, and RAG → store (pgvector).
| Layer box | GCP service |
|---|---|
| Model Gateway (app) | Your service on Cloud Run / GKE, calling Vertex AI |
| Retrieval Service (app) | Your service on the same compute |
| Model Endpoint (tech) | Vertex AI (Gemini) |
| Vector DB (tech) | Cloud SQL / AlloyDB + pgvector, or Vertex AI Vector Search |
| Kubernetes / Serverless (tech) | GKE / Cloud Run / Cloud Functions |
| Object Store (tech) | Cloud Storage |
| Managed Identity (tech) | Service account + Workload Identity |
See RAG → store (native) for Vertex Vector Search.
| Layer box | AWS service |
|---|---|
| Model Gateway (app) | Your service on ECS/Fargate / EKS, calling Bedrock |
| Retrieval Service (app) | Your service on the same compute |
| Model Endpoint (tech) | Amazon Bedrock |
| Vector DB (tech) | RDS/Aurora PostgreSQL + pgvector, or OpenSearch / Bedrock Knowledge Bases |
| Kubernetes / Serverless (tech) | EKS / App Runner / Lambda |
| Object Store (tech) | Amazon S3 |
| Managed Identity (tech) | IAM role (IRSA on EKS) |
Because the gateway isolates the model call, swapping the Model Endpoint row — Azure OpenAI for Bedrock, say — is a configuration change at one component, not a rewrite. That is the architecture earning the "on any cloud" goal, not just asserting it.
What to stand up first¶
You cannot build ten capabilities at once, and you should not try. The capability heat-map page turns "where do we invest?" into an analysis: score each capability by strategic importance against your maturity gap, and let the hot tiles set the order. For a platform starting from zero, the scoring lands in a predictable sequence.
| Order | Stand up | Why first |
|---|---|---|
| 1 | LLM Access (model gateway) | Nothing else has a model to call until this exists; it is also where every later concern attaches. Highest importance, largest gap. |
| 2 | Guardrails & Safety + Observability | The moment a real user hits the gateway you need it to fail closed and to be traceable. Cheap now, expensive to retrofit. |
| 3 | Retrieval-Augmented Generation | The first capability that makes answers yours; it depends on the gateway already being there. |
| 4 | Cost / FinOps, then Voice / Image / Multimodal | Once traffic is real, meter it; then broaden the modalities as demand appears. |
Two rules keep that order honest. Delivery (Terraform + Helm, shipped iteratively) and Identity & Trust (passwordless service identity) are not a phase — they are how every row above is built, so they are in from row 1. And the order is a roadmap, not a waterfall: each capability ships thin and grows, which is exactly what the Ship an AI feature value stream is for.
The one-sentence version
Stand up a guardrailed, observable model gateway first; add RAG next; meter cost as soon as traffic is real; broaden modalities on demand — and do all of it on cloud-neutral primitives so the platform, not any one vendor, owns your line of sight from goal to cloud.
Where to go next¶
- The technique in full, on a neutral example: Enterprise Architecture overview and the worked example.
- The scoring behind the ordering above: Capability heat-maps.
- The pillars that build each capability: Call an LLM · RAG · Guardrails · Observability · Cost · Trust · Delivery & practice.