“The biggest mistake in data architecture is not choosing the wrong technology. It is choosing technology before understanding the problem.”
A Familiar Story in Data Strategy
Picture this. A leadership team sits down to discuss data strategy. Someone suggests adopting a data lake. Another recommends a lakehouse. The IT lead agrees. A vendor is called. Budget is approved. Six months later, nothing has changed. Reports still don’t reconcile. Dashboards still conflict. Teams continue to debate numbers that should have been aligned long ago. This is not a technology failure. It is a sequencing failure.
The Question Most Organizations Get Wrong
Most organizations begin with the question: “What technology should we use?” But the better question is: “What problem are we trying to solve?”
A data architecture should never be chosen first. It must be derived from the business problem, the operating model, the ERP environment, and the organisation’s integration and governance needs.
This principle is central to established enterprise architecture methods. The Open Group Architecture Framework (TOGAF®) Standard, 10th Edition, explicitly requires that architecture decisions begin with business needs before any information systems or technology design is considered 1.
Start With the Business Problem
Before any architecture is discussed, the problem must be clearly defined in business terms. Common problem categories include fragmented reporting, disconnected ERP and source systems, delayed operational visibility, advanced analytics or AI requirements, and governance gaps with unclear data ownership. Each of these points to a different architecture direction. When the problem is clearly defined, the direction begins to emerge naturally.
Why ERP Shapes Your Architecture
The ERP system is one of the most important, yet often overlooked, factors in architecture design. It determines how data can be accessed, how frequently it can be extracted, and whether real-time integration is possible. For example, SAP S/4HANA supports API and event-based integration through SAP Integration Suite 2, Oracle Fusion Cloud ERP exposes REST-based APIs and ERP Business Events for outbound integration 3, and Microsoft Dynamics 365 supports both synchronous and asynchronous patterns, including BYOD export to Azure SQL for analytical workloads 4. Ignoring ERP realities often leads to designs that look good on paper but fail in practice.
Understanding the Core Building Blocks
Before selecting any architecture pattern, organisations must assess the core building blocks of their data environment: business processes and decision use-cases, analytics requirements and latency needs, source system and ERP integration profiles, data quality and domain ownership, storage and processing design, semantic and consumption layers, and governance and security requirements. These building blocks ensure that architecture decisions are grounded in reality rather than assumptions.
Choosing the Right Architecture Pattern
Once the groundwork is complete, selecting an architecture becomes much clearer. For structured reporting and consistent KPIs, a data warehouse with a semantic layer is often the right choice. For flexibility and advanced analytics, a lakehouse built on a medallion pattern—progressively refining data through bronze, silver, and gold layers—provides a more scalable solution 5. Where speed is critical, event-driven architectures using platforms such as Apache Kafka or Azure Event Hubs enable real-time responsiveness. In many cases, hybrid approaches balance operational and strategic needs.
Maintaining consistent business metric definitions across these layers is further supported by governed semantic models. Tools such as the dbt Semantic Layer allow organisations to centralise KPI definitions and reduce inconsistency in downstream reporting 6.
Technology Comes Last
Technology selection should always follow architecture design. Tools such as Snowflake, Databricks, Microsoft Fabric, or Azure Data Factory are powerful, but their effectiveness depends entirely on how well they align with the architecture. Databricks and Microsoft Fabric both document medallion-style lakehouse implementations as a standard approach for progressive data refinement 5. The right tool in the wrong design will fail. The right tool in the right design will create lasting value.
What This Looks Like in Practice
Consider a distribution company where ERP manages core operations, while sales data comes from multiple external systems. Reports are inconsistent and visibility is delayed. By applying a structured approach, the organisation identifies the need for unified reporting and near real-time insights. A lakehouse architecture with a semantic layer and operational data capabilities becomes the logical solution. The technology follows this design—not the other way around.
Final Thought
Data architecture is not just a technical design. It is a strategic capability that shapes how an organisation understands its performance and makes decisions.
The sequence is simple but powerful:
Problem → ERP → Building Blocks → Architecture → Technology
When this approach is followed, data becomes a source of clarity, not confusion—and that is where real value is created.
References
- The Open Group. (2022). TOGAF® Standard, 10th Edition. The Open Group. https://pubs.opengroup.org/togaf-standard/
- SAP SE. (2025). SAP Integration Suite: Feature scope description. SAP Help Portal. https://help.sap.com/docs/integration-suite
- Oracle Corporation. (2025). REST API for Oracle Fusion Cloud Financials (Release 25D). Oracle Help Center. https://docs.oracle.com/en/cloud/saas/financials/25d/farfa/
- Microsoft Corporation. (2025). Integration between finance and operations apps and third-party services. Microsoft Learn. https://learn.microsoft.com/en-us/dynamics365/fin-ops-core/dev-itpro/data-entities/integration-overview
- Databricks. (2025). What is the medallion architecture? Databricks Documentation. https://docs.databricks.com/en/lakehouse/medallion.html
- dbt Labs. (2025). dbt Semantic Layer. dbt Developer Hub. https://docs.getdbt.com/docs/use-dbt-semantic-layer/dbt-sl
