When Architecture Becomes Discovery:

Why the Best Solutions Begin by Questioning Our First Assumptions

There are a handful of moments in every career that quietly change the way we think. At the time, they feel like just another project with another set of challenges. Only years later do we realize they fundamentally changed not only how we approach our profession, but how we approach problems themselves.

One of those moments for me came during an ERP implementation, years before I thought of myself as someone working in Master Data Management (MDM) and Data Governance. At the time, I believed I was learning the capabilities of a new software platform. Only later did I realize I was learning something much more valuable. I was learning that good architecture is not simply about designing solutions, it is about discovering them.

That lesson has remained remarkably consistent throughout my career. It has influenced how I approach MDM initiatives, Data Governance programs, ERP implementations, integration projects, and, more recently, conversations around AI. While the technologies have continued to evolve, one principle has remained constant: our first solution is often shaped as much by our assumptions as it is by the business problem we are trying to solve.

When the First Solution Becomes the Requirement

Most enterprise projects begin in a familiar way; the business identifies an opportunity, workshops are held, requirements are gathered, architects develop solution designs, and vendors demonstrate how their platforms support the proposed future state. Before long, everyone has a shared vision of what success should look like. That vision is important, but it is also the point where projects quietly become vulnerable.

Without realizing it, we often move from discussing the business problem to defending the first solution that emerges. A proposed implementation gradually becomes "the requirement." By the time configuration begins, everyone is working toward an architecture that may never have been challenged.

Eventually, every implementation reaches a familiar moment, someone says, "The software can't do that."

When Technology Exposes an Assumption

Early in my career, I interpreted that statement as the beginning of a technical problem. If the platform could not support the requirement, then the obvious next step was to identify the gap, design an extension, or customize the application until it behaved the way we expected.

Over time, I have come to hear that statement very differently.

Rather than immediately asking how we can overcome the limitation, I now find myself asking a different question: “Are we looking at a genuine technology gap, or has the technology simply exposed an assumption we never realized we were making?”

That simple question has influenced the way I have approached every implementation since.

Separating Business Outcomes from Implementation Decisions

One of the easiest places to see this is in the way organizations define requirements. It is common to see statements such as "the system must synchronize customer information in real time," "the approval process must mirror the existing application," or "the integration must work this way." They sound like business requirements, but they are often implementation decisions that have quietly become accepted as requirements.

When we step back and ask what the business is trying to achieve, the conversation often changes. Does the business truly require real time synchronization, or does it require trusted information within a defined period? Was an approval process introduced because it creates business value, or was it created years ago to compensate for limitations in a legacy application that modern platforms now address? Are we solving today's problem, or preserving yesterday's solution?

Those conversations usually produce stronger requirements because they separate business outcomes from implementation assumptions.

Understanding the Platform Before Redesigning It

Over time, I have developed a simple habit that has served me well. Before deciding how I think a platform should work, I spend time understanding the design principles behind it.

That may sound obvious, but it requires discipline. Enterprise software carries decades of engineering experience. Its capabilities, limitations, and architectural patterns rarely exist by accident. They reflect years of customer feedback and thousands of implementations across different industries, where product teams have continually refined their platforms to solve common business problems.

That does not mean the software is always right. Sometimes a platform genuinely lacks an important capability. Sometimes regulatory requirements demand customization. Occasionally an organization's competitive advantage depends on something no commercial product was ever designed to do. Those situations absolutely exist, and experienced architects encounter them regularly.

I did not realize it at the time, but those experiences taught me not to let technology dictate business process, while also reminding me not to dismiss a platform's design before understanding the thinking behind it.

One experience in particular changed how I approached that question.

A Lesson from Microsoft Dynamics 365

While working on a Microsoft Dynamics 365 Finance & Operations implementation, I encountered the distinction between ‘Products’ and ‘Released Products’, along with the concept of configurable product attributes. My initial reaction was one of skepticism. My background had taught me to value structured data models, clearly defined metadata, and strong Data Governance. Structured fields felt predictable, well governed, and easy to understand. Configurable attributes, by comparison, initially appeared to offer less structure and therefore less governance.

My instinct was to reshape the solution, so it aligned with the architecture I already trusted.

As the project progressed, I found myself doing what I have done countless times throughout my career when something did not quite make sense: I opened a SQL query window and started looking at the underlying data model.

I wanted to understand how the platform actually represented product information.

What the Data Model Revealed

The more I explored the tables, the relationships between them, and the way structured fields and configurable attributes were stored, the more I began to appreciate the intent behind the design. It became clear that configurable attributes were not intended to replace structured fields at all. They solved a different problem. The platform was not sacrificing structure; it was providing flexibility where flexibility created business value while preserving structure where consistency mattered most.

That realization did not come from another meeting or another product demonstration; it came from taking the time to understand how the platform had been engineered.

Looking back, I realized I had spent the first part of the project evaluating the technology against assumptions I had carried with me from previous systems. Once I understood the underlying design, I found myself questioning those assumptions instead.

I had opened SQL expecting to understand the software.

Instead, I came away with a better understanding of my own assumptions.

From Architecture to Master Data Management

I did not realize it at the time, but that project became one of several catalysts that eventually drew me into Master Data Management and Data Governance. More importantly, it fundamentally changed how I approached architecture. I became far less interested in proving that my first design was correct and much more interested in understanding why different technologies solve problems in different ways.

As my career progressed, I began seeing the same pattern repeated project after project.

One of the reasons I find Master Data Management so rewarding is that it sits at the intersection of business processes, ERP, CRM, integration, Data Governance, analytics, security, and increasingly AI.

Why Architecture Cannot Happen in Isolation

Every discipline approaches the problem from a different perspective. Business stakeholders understand operational realities. Vendors understand the strengths and intended design of their platforms. Integration specialists understand how information moves across the enterprise, while Data Governance practitioners focus on stewardship, ownership, and quality. Architects are expected to bring those perspectives together into something coherent.

That is precisely why no individual or team can be expected to design the best solution in isolation.

Looking back across those projects, a pattern begins to emerge. The successful implementations were not the ones where a single team produced the best design. They were the ones where every discipline was willing to challenge assumptions, including its own. The business developed a better appreciation for technology, while technology teams gained a deeper appreciation for the realities of the business. Together, they discovered solutions that none of them would likely have designed independently.

Challenging Assumptions in the Age of AI

That collaborative mindset feels even more important today because AI continues to accelerate the pace of technological change. As capabilities evolve more quickly, assumptions have a shorter shelf life than they once did.

Over the years, I have found myself thinking about architecture differently. I no longer see it simply as the process of translating requirements into systems. Increasingly, I see it as a process of discovery; discovery of the real business problem, discovery of what the technology is actually capable of, discovery of the assumptions we've carried with us from previous projects, and, perhaps most importantly, discovery of solutions that no single team would have arrived at on its own.

Architecture as a Process of Discovery

When someone now tells me that a platform cannot support a particular requirement, my first instinct is no longer to ask how we can customize the software. My first instinct is to understand the problem more deeply. Sometimes the right answer is still customization. Sometimes it is choosing a different platform. More often than not, it is neither. It is a conversation that leads the team to a solution none of us had considered when the project began.

Looking back over more than two decades of designing and implementing enterprise solutions, I have come to believe architecture is at its best when it becomes an exercise in discovery rather than confirmation.

The goal is not to defend our first solution. It is to remain curious long enough to discover a better one.

Sometimes the best solution begins the moment we are willing to question our first one.