Design Before Implementing

In a recent project, the initial request was precise: connect the e-commerce platform with the ERP. A limited scope, at first glance. What we discovered during the assessment changed the diagnosis: product information lived in three different places at the same time. The e-commerce catalog, the pricing system, and the ERP maintained their own records, updated by different people, with no defined synchronization logic between them.

There was no way to integrate those two systems without solving something more fundamental: no one had defined where product information should live or who was responsible for keeping it consistent. These questions are not technical; they are design decisions that the company had never formulated because they had never seemed urgent. The integration project made them urgent.

The Ecosystem No One Designed

In the previous article I argued that digital evolution is not about adding software but about designing an ecosystem. This idea implies something worth making explicit: every company that has grown digitally already has an ecosystem, even if it was never consciously designed.

It is made up of accumulated decisions, tools incorporated to solve immediate problems, integrations built along the way, and processes that adapted as volume demanded it. Each decision was reasonable at the time. The problem is that the whole rarely builds a coherent structure.

When an organization adds a tool without defining how it relates to the others, that tool establishes default rules: where it stores data, how it structures it, what types of integrations it allows, which actions remain within its logic and which remain outside. Those rules do not disappear. They accumulate. Over time, the ecosystem takes the shape of the urgencies that assembled it, not of a strategic intention.

A 2024 study from the IBM Institute for Business Value illustrates the scale of the phenomenon: only 36% of technology executives say they manage their technology investments as integrated portfolios with a shared architecture. In the remaining 64%, the ecosystem grows in another way.

What Growth Reveals

While volume remains manageable, the seams of the system remain invisible. Teams learn to compensate for what the tools cannot solve on their own: intermediate spreadsheets, manual synchronization steps, processes that work because someone executes them from memory. Operations move forward, though with more effort than necessary.

When the business grows, that compensation becomes unsustainable. Adding a new channel implies duplicating processes that already existed. Modifying a commercial condition requires updating several systems separately. Scaling the team does not scale the operation, because the logic does not live in the system but in the people who learned how to navigate it.

The symptoms are operational, but the origin is structural. The system was not designed to grow, but to solve what needed to be solved at each moment, and growth simply amplifies that structure.

Four Questions Before Any Technology

Designing the ecosystem before implementing does not mean extending analysis times or postponing execution. It means answering, before choosing any technology, four questions that determine how the system will behave when it grows.

The first is where business logic resides: which rules belong to the organization and should not be tied to any vendor’s data model. The second is how information flows between areas: who produces it, who consumes it, and where it lives as the source of truth. The third is which parts of the system can change without affecting the rest, defining the real capacity to adapt to business or market changes. The fourth is who governs the core rules and by what criteria evolution decisions are made.

These are not technical questions. They are organizational design decisions with direct impact on the technology that is chosen and how it is configured. When they are not formulated in advance, technology answers them by default, according to its own logic.

Design Defines Where Control Resides

When an organization adopts a platform without having defined these questions, the platform answers them for the organization. Business logic becomes embedded in the vendor’s data model. Information flows adapt to what the system allows, not to what the business needs. The ability to change becomes subordinated to someone else’s roadmap.

This dynamic is not the result of isolated bad decisions. It is the natural consequence of not designing before implementing. Dependency is not explicitly chosen; it emerges when the organization fails to define in advance what must remain under its own control.

Control over the digital ecosystem is not a statement of intention. It is the result of structural decisions taken before any implementation: where business logic lives, which elements must remain under the organization’s direct control, and which can be externalized without compromising future autonomy.

When these questions are not formulated, the ecosystem designs itself by default, based on the rules of the systems that are gradually incorporated.

The next level of depth addresses this concretely: which specific questions must be answered before choosing any technology, and what each one reveals about the real state of the ecosystem.