The Critical Role of Data Architecture

Why emphasize Data Architecture? Because it is the foundation on which applications deliver. It defines:

• What data you need to support products, operations, and compliance
• Where that data originates in your business activity and application portfolio
• How data security is enforced
• How data quality enabled as data is created, edited, and transformed
• How that data flows through your business activities and applications

All this leads to data governance. You must know source, flow, transformation, and need to enable governance.

Without this foundation, applications can only offer fragmented views of the business. Data silos emerge. Worse the lineage of critical information becomes a challenge.

Better decision making is nice. However, a focus on data lineage can save a couple of million hours of labor per year. You heard me, a couple of million hours.

A construction client pursuing a digital transformation spent millions of hours on procure-to-pay. They spent millions of manual hours on procure-to-pay processes: double-checking requisitions, validating purchase orders, confirming goods receipt, and approving invoices—all paper-based and scattered.

All over the place—my favorite goods receipt site was a forest clearing where a helicopter dropped construction material.

Their digital transformation initiative had a solid process model showing differentiation and automation. We needed to protect the secret sauce and put the computers to do the work. The CFO wanted procure-to-pay completely automated. Not just a 4-way match on an invoice. He wanted end-to-end automation. If everything matched approving a requisition would approve the invoice.

This was their second ERP customization, requiring deep understanding of data needs and data flow. The OOTB ERP wouldn’t auto-approve without manual clicks—it forced a person to click ‘ok’, blocking full automation.

The other part was data flow! We needed a smooth end-to-end data flow. Consistent commodity codes. Populated attributes. The system had to consistently distinguish quality attributes.

For the data flow, we needed to push the commodity codes to to the bidding system. That let the bidding system pass the bill-of-material to the project system. It used the schedule to look ahead and create requisitions. Requisitions, turned into purchase orders, which gave rise to good receipt. Finally invoices. At every state the system automatically processed the matches. It reserved the discrepancies for the staff.

We managed two very cool things. First, we got the system to do-the-work, rather than just record-the-work. Second we saved several million hours of labor annually. Time spent shuffling paper, that could have been spent managing the project and delighting customers.

I'm always amazed how much work we put into systems that only record-the-work.

I’m appalled at how much work we put into systems whose structure harms data flow and data management.

Understanding the Relationship Between Application and Data Architecture

Applications manage data, applications move data, applications provide data. Some even use data to do work. Data Architecture defines what data is needed. Let's pause and reflect, what data is needed.

Data architecture defines where it comes from, and how it must be managed. Applications mediate the sources and usage of data, but it’s the underlying data architecture that ensures data availability, quality, and security across business processes.

Balancing these domains is one of the architect’s toughest challenges. The normal focus on applications seems to always create brittle, siloed systems with inconsistent data. Conversely, focusing only on data structures without considering data flow often results in abstract models and the common refrain ‘we need data governance’ without practical solutions.

Why This Series Focuses on Data Architecture

Over the next few weeks, this series will dive exclusively into Data Architecture — a domain too critical to be an afterthought.

We’ll explore:

• Core concepts of Data Architecture
• Understanding data sources, flow, controls, and value creation
• Aligning data management with business strategy and measuring contribution
• Practical approaches to describing and modeling data architecture in your enterprise

As always, each message will blend practical insights, framework guidance, and stories from real practice — helping you deepen your mastery and increase your impact.

The Architect’s Role: Bridging Functionality and Data

As architects, our role is to bridge the “what” (business needs and functionality) and the “how” (data and applications that enable those needs). This involves:

• Clarify data needs
• Defining data models, flows, and the resulting architecture specifications
• Ensuring application architectures reflect and support data reality

This is hard work—but it’s what separates effective enterprise architecture from fragmented project work.

Reflecting on Your Current Practice

Before we dive in, I encourage you to pause and reflect on your own enterprise architecture work:

• How well do you understand your enterprise’s data landscape?
• Do you know the data flows embedded in your process and application design?
• How effectively does your data architecture support business outcomes today? Where do you see gaps or risks?

Your answers will shape what you take away from this series and help pinpoint where to focus your efforts.

What to Expect Next

In the next email, we’ll start with the fundamentals: What is Data Architecture? We’ll define it clearly, position it within Information Systems Architecture, and introduce the core components you need to master.

I’m looking forward to taking this journey with you.

As always, Let me know your thoughts.

Have a great day!

Regards,
Dave Hornford
Conexiam

P.S. If you are interested in getting ahead, our Enterprise Architecture with TOGAF and Navigate course covers portfolio governance and architectural support for critical decisions. It’s being refreshed this fall. Use coupon Special40 for 40% off ($479.40) on the current version and access to the new release.

---

Going Further

Next time someone suggests better decision making think about MIT Sloane's Is Decision-Based Evidence Making Necessarily Bad?