Making the Invisible Visible: Applications and Data Flows in Enterprise Architecture

Why mapping data flows is the most practical way to deliver fast value in enterprise architecture

Enterprise architecture (EA) means different things to different people—strategy alignment, capability mapping, future state visions. But there’s one area I keep coming back to, one I never get tired of: mapping applications and the data flows between them.

Recently, I’ve worked on several focused assignments centered around this exact topic. In some cases, data flow mapping was the primary deliverable. In others, it served as a crucial building block within a broader EA initiative. Either way, the value is clear—and often, surprisingly fast to realize.

Why Focus on Data Flows?

Mapping data flows isn’t just a supporting activity in EA. It’s often the very foundation that makes meaningful architecture work possible. It’s not about drawing diagrams for their own sake, but about making the invisible visible: how information actually moves across applications, business units, and organizational boundaries.

Surprisingly often, even the most basic current-state documentation of data flows is missing. And yet, this is exactly the kind of view that becomes critical when planning change. Whether you're:

• evaluating the complexity of your IT landscape,

• preparing for new integrations,

• planning application upgrades or phaseouts, or

• simply trying to keep the current environment stable and secure,

a clear view of data flows helps you navigate the landscape with confidence.

And sometimes, the value is simpler—and more human—than that. Sometimes, just getting everyone to finally see the same picture is a breakthrough in itself.

I’ve seen architects and CIOs react with visible relief when we’ve managed to assemble the big picture. In one organization, a member of the IT operations team almost literally teared up after seeing the first complete overview of application data flows: “Now I finally know how things are actually connected.”

When done right, mapping data flows becomes more than just architecture work. It becomes a shared understanding—a platform for collaboration, prioritization, and smarter decision-making.

Best Practices for High-Level Flow Mapping

Let’s be clear: high-level data flow diagrams are not about APIs, protocols, or middleware details. Not at this level. On the EA level, your goal is to understand how information flows across the organization—who sends what to whom, what kind of data moves, and which applications depend on each other.

While the concept is simple—applications connected by directional data flows (see the example below)—some good practices can make the difference between a cluttered drawing and a truly useful model:

• Focus on what moves—not how. Highlight the content and direction of the data, not the technical implementation details.

• Keep it simple. Use only one relation type throughout the diagram (e.g., Flow in ArchiMate) to maintain clarity and consistency.

• Aggregate flows. If a source application has multiple integrations to a single target, combine them into one flow with a clear, high-level label.

• Indicate the primary direction of data transfer. Focus on where data meaningfully moves—typically in responses or updates. For example, if a frontend sends a request and receives customer data in return, only the response flow needs to be shown. This keeps the diagram clean and focused on what matters.

• Include external flows. Don’t just map internal applications—show which data exits the organization and where it goes. It’s essential for identifying risks, dependencies, and compliance impacts.

• Label clearly and consistently. Use short, descriptive labels, and when possible, reference existing data domains or groupings to make the flows easier to interpret.

• Use a logical layout. Place customer-facing applications at the top, internal applications in the center, and external ones at the edges or bottom. If focusing on a single application, consider showing data consumers above and producers below to clarify directionality at a glance.

• Avoid technical overload. If you need to include integration types (e.g., API, file transfer, manual input), keep it minimal—use a suffix or color coding sparingly, and only if it adds real value.

• Include known near-future changes. Even in a current-state view, it’s helpful to include upcoming or planned changes (e.g., new integrations or application replacements). Mark them clearly, for example with a “(to-be)” label.

• Use an EA tool. You can build flow maps in Visio or even Excel, but using a repository-based tool (like Archi or a commercial EA tool) makes it easier to manage, update, and analyze the model over time.

• Model consistently. Follow a consistent modeling approach aligned with your overall EA metamodel, especially if others will contribute or maintain the diagrams.

And above all: keep it at the right level. You’re not documenting every message or payload. You’re creating a shared understanding of how information flows—enough to support planning, alignment, and good decisions.

Applications and data flows (simplified example)

Ways of Working: How to Get Data Flow Mapping Done Efficiently

Data flow mapping doesn’t have to be a long or heavy effort. When done right, it can be completed in weeks, not months. The key is to work systematically, focus on what matters, and start with what you already have.

• Use existing documentation as a starting point. Application documentation, integration catalogs, and ITSM records often contain useful (even if incomplete) information about applications and data flows. These sources help you sketch an initial picture before talking to people.

• Interview application or product owners. Focused one-on-one sessions are the most efficient way to uncover real-life flow details. You can usually cover one application’s flows in less than an hour, especially when you come prepared with a draft based on existing documentation.

• Map one application at a time. This application-by-application approach helps manage scope and ensures consistency. Each new interview builds on the previous findings and allows you to validate and refine existing flows along the way.

• Validate continuously. As the model evolves, revisit and challenge it regularly. Confirm key flows, cross-check connections with multiple stakeholders, and ensure the view remains aligned with reality.

• Get formal validation and approval. Once the core flows are modeled, organize a review with relevant stakeholders. Having key people sign off on the model ensures shared understanding, builds trust in the content, and creates a solid baseline for development and planning.

As you progress, the model improves organically. Start with the most critical applications and expand from there. Add flows incrementally, clean up inconsistencies as they emerge, and don’t wait for perfect information—an evolving, “good enough” model delivers far more value than one that never gets finished.

To keep the effort on track, define light checkpoints for yourself or the team: for example, how many and which applications are mapped each week, which ones are still missing, and which content needs validation. A simple status list or Kanban board can help maintain momentum and make progress visible to stakeholders.

Final Thoughts: Owning the Landscape

A well-crafted data flow map is more than just a documentation artifact—it’s a tool for insight, alignment, and smarter decisions. And yes, sometimes it’s also a wake-up call. That ”scary picture” showing dozens (or hundreds) of integration lines crisscrossing the landscape? It’s not there to overwhelm—it’s there to say: this is what we’re really managing.

But just drawing the picture isn’t enough. To keep it useful, it needs to be maintained. Make sure there’s ownership, update routines, and integration into planning processes. A clear model that’s left to rot is not much better than no model at all.

When architecture helps people understand, act, and adapt—it’s doing its job.

That, to me, is good architecture.

---

☀️✈️ Taking a Summer Pause

That’s it for now—and actually, for a little while. I’m heading off for a month-long summer break, so there likely won’t be new posts during that time. I’ll be focusing on family, rest, some writing (offline!), and just a bit of aviation on the side.

See you in August—refreshed and with new ideas.

---

📬 Want More Practical Enterprise Architecture Content?

Subscribe to Enterprise Architecture Transformation for real-world advice on architecture that supports change, strategy, and delivery.