EA Reflection: Start Small Enough to Learn

A useful first architecture version does not explain everything.

It makes the next executive decision clearer.

Start there.

It’s something I set expectations with from the beginning. The projects move faster when leaders stop asking for the perfect model and start testing the smallest useful one. That is where Enterprise Architecture earns trust: by making complexity visible before it becomes cost.

Enterprise Architects feel this pressure constantly. A new governance model, ERP roadmap, integration standard, or data strategy is expected to arrive fully formed. Leaders want certainty. Delivery teams want permission. Vendors want scope. The architect is often pushed to turn an early idea into a complete operating model before the organization has tested whether the model can survive real decisions.

The better move is often smaller and more disciplined.

A useful first version is not a weak version. It is a learning version. It names the business outcome, the decision rights, the constraints, and the first few tradeoffs that must be made visible. It does not pretend to solve every dependency. It creates enough structure for executives to see what the next decision will cost.

That matters because early architecture work changes behavior. When the first version is clear, sponsors start asking sharper questions. Product owners see where their local priorities collide with enterprise direction. Delivery leaders can separate urgent work from permanent design choices. Even disagreement becomes useful because it is attached to a model everyone can inspect.

That is where architecture earns trust. Not by producing a perfect artifact, but by reducing the risk of hidden complexity. When people, process, technology, data, vendors, and funding all appear simple on the surface, the Enterprise Architect has to show what is connected underneath. A small first version makes those connections discussable before they become expensive.

This is also where services such as ERP transformation assurance, architecture governance, and strategy-to-execution alignment matter. The value is not more documentation. The value is creating a repeatable way for leaders to learn before they lock themselves into a path.

For an EA, the practical question is simple: what is the smallest version of this architecture that can improve the next executive decision?

If the answer is clear, build that. Put it in front of the right people. Watch where the confusion appears. Then improve the model.

The first version is not the finish line. It is the instrument panel. It tells you what the organization can understand, where the operating model is fragile, and which decision needs stronger architecture before the next step is taken.

Start small enough to learn. Then scale only what proves useful.

Practice

Before the next roadmap, transformation, or architecture review, ask each sponsor to name one decision the current architecture must improve this month. Write the answers down, group overlaps, and choose the one decision with the highest cost of confusion. Use that as the focus for the next architecture model, governance discussion, or executive update.

Reflection

Where am I producing architecture that explains the enterprise, but does not improve a real decision?
What is one smaller, more practical architecture artifact or conversation that would help leaders choose, trade off, or act with more confidence this week?

Have you set the expectation consistently across you architecture team?

Darin Paton is the Owner of Cornerstone Consulting Inc., an Alberta-based enterprise architecture and SAP ERP transformation advisory firm serving organizations across complex business and technology change for over 15 years. 30+ years as an EA and using SAP.



Leave a Reply