An enterprise architecture practice is strong in technology architecture and weak in business and data architecture. What problems does that imbalance cause?

The problems

1. Technology decisions without business justification. Standards, platforms and consolidation programmes argued on technical grounds, which do not compete against a roadmap and are therefore either refused or imposed and resented.

2. Data ownership and duplication go unaddressed. Without data architecture, the same entity — customer, property, booking, price — is modelled differently in each application, and reconciliation becomes a permanent tax. This is usually the largest source of enterprise complexity and it is invisible in an application inventory.

3. Capability duplication is not detected. Business architecture is what reveals that the same capability is implemented several times by different units for historical reasons. Without it, rationalisation proposals are argued application by application, which is a much weaker position.

4. Integration is designed as point-to-point plumbing rather than as flows between capabilities that own their data, so the estate accumulates connections nobody can enumerate.

5. Regulatory and residency requirements land late, because they are data questions, and a technology-focused practice discovers them at review rather than at design.

Why the imbalance is common

Technology architecture is the most legible domain: it has artefacts, standards and clear artefacts of progress. Business architecture requires access to business leaders, and data architecture requires patient work with no visible output for months. Both are harder to staff and harder to demonstrate.

The rebalancing that matters most

Data architecture first, because it is where the compounding complexity is. Specifically:

• Ownership per entity. One system of record per business entity, with everything else consuming it. In most enterprises this is unclear for the most important entities.
• A published contract per shared entity, so consumers depend on an interface rather than on a table.
• Classification attached at source, propagating through derived datasets — the prerequisite for every privacy and residency answer.

Then business capability mapping to a useful depth, because it is what turns technology proposals into investment arguments.

The framing

Technology architecture answers "how"; business architecture answers "why and whether"; data architecture answers "what is true and who owns it". A practice strong in only the first can produce good designs for the wrong problems, and cannot argue for its own proposals in the language the business decides in.