In the BDAT model, in what order do the four layers typically drive each other, and what goes wrong when a team settles on technology architecture before business and data architecture are understood?

## The default dependency chain The default dependency chain in BDAT runs top-down. 1. **Business architecture** defines capabilities and processes ("approve a loan," "fulfill an order"). 2. Those processes imply what information must exist and flow, which **data architecture** formalizes into entities, definitions, and ownership ("Loan," "Applicant," "Order"). 3. Those data needs imply what software must create, store, and expose that data, which **application architecture** designs as systems and services. 4. Those applications imply what infrastructure must host them at the required scale, latency, and cost, which **technology architecture** provisions. Concretely, if a business decides to offer same-day loan approval (business layer), that implies data architecture must support real-time applicant and credit data rather than nightly batch feeds, which implies application architecture needs a synchronous decisioning service rather than a batch job, which implies technology architecture needs low-latency infrastructure and possibly a real-time credit-bureau integration rather than a nightly file transfer. ## Why the sequencing exists This sequencing exists because it keeps decisions traceable to actual business need rather than to whatever tool happens to be available or fashionable. It also reflects who is best positioned to make each call: - **business stakeholders** know what outcome is needed - **data stewards** know what information that requires and what it should mean - **application architects** know how to structure software to deliver it - **infrastructure engineers** know how to run that software reliably and cost-effectively When the order is respected, each layer's decisions are justified by the layer above it, and an auditor or new hire can trace "why do we have this database schema" all the way back to a business capability. TOGAF's Architecture Development Method formalizes this but is explicitly iterative, not a strict waterfall: a central requirements-management activity sits alongside the business, data, application, and technology phases, feeding discoveries back upward so that a constraint found late (say, in technology) can revise an earlier decision (in data or business) rather than being silently absorbed. ## The trade-off: speed versus traceability The trade-off is speed versus traceability. Insisting on fully settling business and data architecture before any technology decision is made can stall delivery for real, urgent needs, and some technology constraints are legitimate and known in advance: - a regulatory mandate to use a certified platform - an existing enterprise contract - a hard budget ceiling The healthy middle ground treats these as explicit, documented constraints that bound the design space, rather than letting technology preferences silently substitute for business/data analysis. The unhealthy version is treating "we already bought platform X" as a substitute for asking what the business and data actually need. ## The common failure mode The common failure mode is **technology-first design**: a team selects a SaaS platform or standardizes on a vendor before business and data needs are scoped, then discovers the tool's default data model doesn't match the business's terminology or the business process needs a capability the tool doesn't support (for example, only allowing one discount per order when the business process requires stacking multiple promotions). Rather than fixing the mismatch at the right layer, teams often paper over it with manual workarounds — staff re-entering data differently than the tool intends, or spreadsheets tracking what the system can't — which is a visible symptom that technology was chosen ahead of business/data understanding. Another symptom is a data model that closely mirrors a vendor's out-of-the-box schema rather than the business's own vocabulary; that's a sign the data layer was never really designed, just inherited from whatever tool was picked first. ## What it looks like in practice A concrete scenario: a mid-sized retailer standardizes on a new customer relationship management platform (a technology/application decision) before finance and marketing agree on what "active customer" means or how promotions should combine (a data/business decision). Three months after go-live, marketing discovers the platform can only apply one promotional discount per transaction, while the business process — agreed on well before the platform purchase — requires stacking a loyalty discount with a seasonal promotion. Because the technology decision preceded the data/business analysis, the company faces an expensive choice: - change the hard-won business process to fit the tool - pay for a costly platform customization - or replace the platform All of which would likely have been caught, and avoided, by scoping business and data needs before locking in the technology.