Solving Organizational Challenges Through Data Structures

Link: https://www.eatransformation.com/p/solving-organizational-challenges-through-data-structures

From Enterprise Architecture Transformation: A Practical Guide

This article is part of a short series where I describe real enterprise architecture assignments and what actually happens in them.

In this case, the starting point was a set of familiar data challenges.

The organization was dealing with issues such as:

the same data existing in multiple applications
information not moving smoothly between applications
data structures that had become increasingly complex over the years
difficulties in producing reliable information for management and customers
data quality issues affecting day-to-day operations

None of these challenges were particularly new. People in the organization were aware of them. What was missing was a clear understanding of how the organization’s core data actually fits together.

Management had recognized this gap and decided to approach the problem through a data architecture assignment.

The goal was to build a shared understanding of the organization’s current key information structures. At the same time, the assignment aimed to define a target state for the data architecture. The work was carried out at a more detailed level than typical enterprise architecture (EA) descriptions, focusing on the logical structure of the organization’s core information.

From an EA perspective, this was an interesting starting point. Many transformation initiatives begin with applications, processes, or individual projects. Here, the organization intentionally started with data architecture.

At the same time, process descriptions were produced in a separate assignment, which complemented the picture nicely.

Mapping the Current State

The current state model was built through interviews across the organization.

These discussions focused on questions such as:

what key information entities exist
how they relate to each other
which applications handle them
what kinds of challenges people face when working with the information

The work focused on building a logical-level data model of the organization’s core information. The model was expressed as a color-coded UML diagram, complemented with descriptions of entities, their key attributes, and the applications responsible for handling the data.

One thing that stood out positively was the atmosphere in the interviews. People were consistently constructive and willing to help. In architecture work this is not always guaranteed.

Regular follow-up discussions with the key participants proved essential. The model evolved through iterative validation, not through one round of workshops. Without that loop, the model would quickly drift away from reality.

Another practical factor helped a lot: the customer had a strong project manager who knew the organization well. She was able to identify the right people to involve and provided useful background material before the interviews.

Building the Target State

Constructing a logical target state model is not particularly difficult in theory, but the real difficulty is this: who can really say what the business and its information structures should look like five or ten years from now?

Any target model inevitably contains assumptions about the future. The goal is not to predict the exact structures, but to define something that can support the organization’s development without locking it too tightly into today’s situation. In practice, this means navigating between different expectations and perspectives across the organization.

At the same time, the model still needs to resonate with the organization. People inevitably compare the target state with the structures they know from their daily work.

There was also a personal challenge. I had only recently entered this particular organization. Building a meaningful data model in that situation requires some humility—and a lot of questions.

Another challenge was the level of abstraction. The target state needed to support the organization’s future growth and scalability, which meant the model could not be tied too tightly to the current structures.

At the same time, if the model becomes too generic, it quickly loses its practical value. The real task was to find a balance between concreteness and generality. This was also visible in the model itself. The target state ended up containing significantly fewer entities than the current state.

The modeling approach itself remained similar to the current state description. The entities and relationships were presented in a comparable visual structure, which made it easier for participants to follow the discussion. The key difference was that the target model was not tied to specific applications. Instead, it focused purely on the logical structure of the organization’s core information.

Enough time was reserved for both developing and validating the target state. Validation was done through concrete business situations: how the model would support actual operational scenarios. This approach made the discussions much more productive than abstract architecture debates.

An Interesting Side Effect

The modeling work itself was valuable, but the most interesting effects appeared elsewhere. Once the structures were visualized, several things started to happen.

First, describing the organization’s data also helped clarify the business itself. In many organizations, the underlying information structures reflect how the business actually operates. Once those structures became visible, it became easier to understand and discuss the business as a whole.

Second, the root causes of many data quality problems became easier to see. When the entities, relationships, and responsible applications were mapped out, some of the issues that had previously looked like isolated operational problems turned out to have structural causes.

Third, the model helped clarify how ongoing and planned projects affected the overall data landscape. Development initiatives that had previously been viewed separately could now be seen in relation to the same information structures.

But perhaps the most noticeable change was in the discussion itself. Once the structures were visible, people started discussing data across organizational silos. The diagrams made dependencies visible in a way that had not been obvious before.

The conversation also shifted in tone. Instead of general concerns about “data challenges,” discussions increasingly focused on specific structures, entities, and relationships.

The topic attracted notable interest from leadership. That alone is often a sign that the discussion has moved beyond technical details. When the structures of information become visible, they tend to raise questions that are directly relevant to how the organization operates and develops.

Often the value of architecture work is not in inventing something completely new. It is in making the existing structure visible. And once that happens, the conversation tends to change.

📘 New Book: The Architecture of Expert Compensation

I have recently written a short book called The Senior Expert Pay Playbook.

It continues the same structural perspective as The Senior Expert Career Playbook, but focuses specifically on how compensation actually forms inside organizations—in a way, the architecture behind how expert compensation develops over time.

The book will be published in early April, but it is already available in my Gumroad store.

A launch discount is available with the code PAYSTRUCTURE22 (for The Senior Expert Pay Playbook) and EXPERTMODEL22 (for the bundle including both books).

🔗 You May Also Like

Looking to dive deeper? Here are more enterprise architecture insights you might find useful:

👨‍💻 About the Author

Eetu Niemi is an enterprise architect, consultant, and author.

📬 Want More Practical Enterprise Architecture Content?

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