In enterprise architecture, what does the acronym BDAT stand for, and what does each of the four layers describe?

## The four layers BDAT slices everything an enterprise architect looks at into four horizontal layers, each answering a different question about the organization. - **Business architecture** answers "what does the business do and how is it organized?" — strategy, capabilities ("process a claim," "onboard a customer"), organizational units, roles, and the processes that turn capabilities into outcomes. - **Data (or information) architecture** answers "what information exists, what does it mean, and who owns it?" — conceptual and logical data models (a canonical definition of "Customer" or "Policy"), data ownership/stewardship, data flows between systems, and information lifecycle — deliberately independent of which database physically stores the data. - **Application architecture** answers "what software implements the capabilities and manages the data?" — the portfolio of applications/services, their boundaries and responsibilities, the interfaces between them, and how they map onto business capabilities and data domains. - **Technology architecture** answers "what does it all run on?" — servers, networks, cloud platforms, middleware, storage — the substrate applications execute on. ## Why the split exists The split exists because each layer changes at a different pace and is owned by different stakeholders, and conflating them causes decisions to be made by the wrong people for the wrong reasons. | Layer | Pace and ownership | |---|---| | **Business processes** | Relatively stable and owned by process owners; they should rarely change just because a database was swapped. | | **Data definitions** | Semi-stable and owned by governance/stewardship; the meaning of "Customer" shouldn't change because a new CRM was purchased. | | **Applications** | Turn over faster — vendors get replaced, monoliths get decomposed — owned by engineering/product. | | **Technology** | Turns over fastest — servers get replaced, regions migrated. | Separating the layers lets you change technology without touching application logic, change applications without redefining what data means, and reorganize data flows without rewriting business process, as long as the interfaces between layers are respected. This is EA's version of separation of concerns. ## What modeling all four layers costs and buys Modeling all four layers fully is expensive: it requires cataloguing capabilities, data entities, application services, and infrastructure components, then mapping cross-layer traceability (which application supports which capability, which technology hosts which application). The payoff is impact analysis — when the business changes (entering a new market), you can trace which data, applications, and infrastructure are affected before committing budget. The cost is real ongoing governance overhead; many organizations let the artifacts rot until the model says one thing and production says another, making the models actively misleading rather than merely incomplete. A common compromise is doing full BDAT modeling only for capabilities under active change (a merger, a platform migration) rather than the entire enterprise up front. ## Failure modes 1. The most common failure mode is **layer collapse**: teams design "data architecture" as literally one application's physical schema, so the same business concept ends up with several incompatible definitions across several applications with no one able to say which is canonical — a data-architecture failure caused by skipping the layer's real job of system-independent meaning. 2. Another failure is **technology-driven business change**: a team migrates to a new platform and, because application/data layers weren't respected, business processes silently break — the org discovers the coupling only when the outage happens. 3. A third is **stakeholder mismatch**: business decisions get made by an infrastructure team, or infrastructure decisions get made without cost/scalability context, because layer ownership was never made explicit. ## How TOGAF's ADM operationalizes it TOGAF's Architecture Development Method operationalizes BDAT directly: Phase B is Business Architecture, Phase C is Information Systems Architecture (split into a data sub-phase and an application sub-phase, run somewhat independently because they have different stakeholders and change cadences), and Phase D is Technology Architecture. Concretely: a retailer decides (Phase B) to launch a unified loyalty program across e-commerce and in-store channels. - **Phase C's data sub-phase** defines a canonical "Member" and "Reward" model independent of any system. - **Phase C's application sub-phase** then decides whether an existing CRM, a new loyalty platform, or both jointly implement that model, and how e-commerce and point-of-sale applications integrate with it. - **Phase D** decides where the loyalty platform is hosted and what throughput/latency the in-store network needs for real-time reward calculation at checkout. Each phase constrains the next, and a limitation discovered late in Phase D (the network can't sustain required latency) forces revisiting the application-layer design — showing why the layers, while distinct, stay tightly interdependent.