Designing a Vendor-Agnostic Enterprise Architecture
Every established enterprise carries the same weight: decades of accumulated systems, production workflows that cannot stop, and vendor contracts woven so deeply into the architecture that “switching” feels like open-heart surgery on a marathon runner. The goal is not avoiding vendors — it’s ensuring no vendor ever owns your domain logic, your data model, or your operational muscle memory. Let me show you how, using a fictional institution: the Bank of Atlantis, an underwater bank modernizing off a 30-year-old core. (Legacy pressure is intense down there.)
Principle 1: Your domains are the architecture. Vendors are implementation details.
We start with Domain-Driven Design, an approach that organizes software around business domains rather than technologies, because those domains — not products — are the stable unit of an enterprise. Atlantis maps eight of them:
- Customer & Identity — onboarding, identity verification and anti-money-laundering checks, consent.
- Accounts & Core Ledger — the immutable, double-entry heart of the bank.
- Payments & Transfers — real-time rails and standardized payment messaging.
- Lending & Credit — origination, decisioning, servicing.
- Cards — issuing, authorization, disputes.
- Fraud & Risk — real-time scoring and case management.
- Treasury & Liquidity — positions and funding.
- Compliance & Reporting — audit trails, screening, regulatory filings.
Each domain owns its data and exposes capabilities only through versioned interfaces and published events — never by reaching into another domain’s database. When boundaries are clean, a vendor swap is a local event, not a systemic one.
Principle 2: Depend on contracts, not products
Every domain follows the ports-and-adapters (hexagonal) pattern: business logic talks to abstractions like PaymentRailPort or DocumentStorePort, and thin adapters translate to whatever vendor sits behind them today. In front of legacy systems sits an anti-corruption layer — a translation boundary that keeps old models from leaking into new ones — so the old core can be retired capability by capability (the strangler-fig pattern), and a vendor exit becomes “write a new adapter and rerun the contract tests.”
The corollary: standardize on open protocols, not proprietary interfaces. SQL for relational data. The S3 interface (the de facto object-storage standard) for files. The Kafka protocol for event streaming. OpenSearch interfaces for search. OpenTelemetry for telemetry. OpenID Connect for identity. Kubernetes and infrastructure-as-code for runtime and provisioning. Any cloud can host this; no cloud can hold it hostage.
Principle 3: Pick the database for the access pattern
“One database to rule them all” is how lock-in starts. Atlantis deliberately runs several, each behind a port:
- Relational transactional database (PostgreSQL-compatible) for the ledger and payments — anywhere correctness demands strict transactional guarantees and strong consistency. The ledger is also event-sourced: an append-only record of every change, beloved by regulators and by future migration teams.
- Document database for customer profiles and product catalogs, where schemas evolve weekly and reads dominate.
- In-memory cache (Redis-compatible) — only where it earns its place: session state, hot reference data, duplicate-request keys for safe payment retries, and rate limiting. Give entries an expiry time and treat the cache as disposable. If losing it causes an incident, it isn’t a cache — it’s an unreplicated database.
- Search engine (OpenSearch-compatible) for what relational engines do badly: full-text transaction search, fraud investigations across billions of events, fuzzy name screening, and centralized log analytics.
- Object storage for statements and identity documents — immutable, versioned, with write-once retention locks for compliance.
- Analytics lakehouse on open table formats (Apache Iceberg), fed by change-data-capture and the event stream, so any query engine — and any future vendor — can read it.
An event backbone with a schema registry ties it together: domains publish facts (PaymentSettled, CustomerVerified), consumers project what they need, and the same stream powers dual-run cutovers during migrations.
Principle 4: Security and operations are architecture, not afterthoughts
Atlantis assumes zero trust: services authenticate with short-lived identities over mutually authenticated, encrypted connections; humans use open identity standards with strong multi-factor authentication; authorization rules are code, versioned in Git. Encryption keys live in tamper-resistant hardware under a bring-your-own-key model, so cryptographic control never transfers to a provider.
Operationally: everything is declarative code, deployed through Git-driven automation with canary releases and automatic rollback. OpenTelemetry carries traces, metrics, and logs end to end, making the analysis backend swappable by configuration. Teams own service-level objectives; error budgets gate releases; disaster-recovery runbooks are executed quarterly, not laminated.
The payoff
At Atlantis, a vendor swap is now a contained project: new adapter, contract tests, dual-run behind a flag, cutover. That’s what vendor-agnostic means — not zero vendors, but zero vendors with veto power over your roadmap.
Legacy is not the enemy. Coupling is.