What an Old Methodology Taught Me About Modern Data Architecture — DMBOK Stories

While reading the second edition of DMBOK, I came across something I did not expect to find: Business Systems Planning (BSP).

BSP is not new. It was introduced decades ago to help organizations align business strategy, processes, information, and systems. At first glance, it may look outdated in a world of lakehouses, streaming systems, and cloud-native platforms.

But after reading more about it, I realized many of its ideas are still highly relevant to data architecture.

A Familiar Challenge from Consulting Projects

Across different roles in data engineering and consulting projects, I repeatedly encountered similar conversations before any architecture discussions even started:

How do you want to use the data?

Not:

“Which database should we choose?” Not:

“Which ETL tool should we use?”

The harder questions were usually have to ask:

• What problem are we solving?
• How will the business consume this information?
• Which systems will change in the future?
• What migration scope should be defined?
• Which tools support future scalability rather than current constraints?

Across several migration and transformation projects, I experienced how teams explored different approaches before aligning on architecture boundaries, migration scope, ownership, and technology decisions.

While reading DMBOK, I realized BSP provides a structured approach for many of these conversations that often happen informally during consulting engagements.

The Problem Many Data Architectures Still Have

Many organizations still design data platforms starting from technology decisions:

• Which warehouse should we use?
• Which ETL tool should we choose?
• Should we use batch or streaming?
• Should we move to a lakehouse?

These are important questions, but they often come too early.

A common reason data architectures fail is that teams build around systems before understanding information needs.

What BSP Does Differently

BSP starts from a different direction:

Business Strategy → Business Processes → Information Needs → Data → Systems

This sequence changes how architecture decisions are made.

Instead of asking:

“What platform should we build?”

BSP encourages asking:

• What business functions exist?
• What information supports those functions?
• Which data entities are shared across departments?
• Who owns the data?
• Where should information originate?

These questions are architectural questions, not only business questions.

Why This Matters for Data Architecture

Enterprise Data Modeling

BSP helps identify common entities across the organization.

Instead of:

• Sales Customer
• Marketing Customer
• Support Customer

You move toward:

Enterprise Customer

This reduces duplication and conflicting definitions.

Better Migration Planning

One connection I found particularly interesting was migration work.

Migration projects are rarely only technical exercises.

Understanding business processes, information dependencies, and shared data assets often determines:

• Migration scope
• Prioritization
• Dependency management
• Future-state architecture decisions

BSP provides structure for this.

Governance and Ownership

BSP naturally introduces:

• Data ownership
• Shared definitions
• Information dependencies
• Cross-functional alignment

These are still major challenges in modern architectures.

Final Thought

Reading DMBOK reminded me that architecture is not only about platforms and tools.

Older methodologies like BSP remain useful because they focus on a question many teams still struggle with:

What information does the business actually need before we build systems around it?

Technology changes quickly.

Information architecture principles change much more slowly.