Data Flow Mapping for the entire data architecture in an application development project

Excellent and relevant question, Achmad.
In well-structured organizations, the responsibility for data flow mapping depends on the maturity of the enterprise architecture and the defined governance model.

Here’s a useful way to think about it:

- Business Architecture defines what the business needs - processes, functions, and value streams.

Data Architecture defines what data supports those business needs - entities, relationships, data lifecycle, and flows.

Application Architecture defines how those data elements are implemented and interact through systems and APIs.

In practice:

The Data Architecture or Data Management unit usually leads the data flow mapping activity, ensuring consistency, integrity, and compliance with standards.

The Application Development team collaborates closely, detailing technical flows and integrations.

The Operational or Business units validate that the flows reflect real processes and business rules.

So, it’s not a matter of one unit alone, but of collaborative alignment across the three architectures, ideally coordinated through an Enterprise Architecture function or a Solution Architect role who bridges the domains.

Data flow mapping becomes most effective when it’s treated as a shared responsibility anchored in a single, integrated architectural vision.

Excellent question, Achmad. In most organizations, data flow mapping is a shared responsibility, but the Data Management or Enterprise Architecture unit typically leads the effort. They ensure consistency across business, data, and application architectures. The Application Development team contributes by detailing process-level data movements, while Operations validates practical feasibility. Ideally, the mapping is co-created, data architects define structure, developers handle implementation logic, and operations ensure alignment with real-world workflows.