The Architecture Questions I Ask Before an Initiative Starts
How to reveal scope, dependencies, and impact before solution design moves too far
Enterprise architecture (EA) can be used in many different contexts. Supporting strategic planning, portfolio prioritization, operating model change, large-scale transformation or long-term platform decisions may sound more “strategic” than helping evaluate individual development needs.
Still, application development guidance and early assessment of development ideas are practical areas where EA can create real value. At least in my own work, I have ended up doing quite a lot of this. It is not always glamorous, and it does not usually look like high-level strategy work. But it can be impactful, because many expensive problems start as small, unclear, or underestimated change requests.
That is why the early stage of an initiative matters. Early on, there is still room to clarify assumptions, adjust scope, change sequencing, and choose a better path before decisions become expensive to revisit.
I use the word “initiative” broadly here. The same logic applies whether work is organized as a project, program, process or product development effort, continuous improvement item, or smaller change request.
What is known at that point may be quite rough: “we need a new application,” “we need better reporting,” “we need to automate this workflow,” “we need an integration,” or simply “we need this capability.” The initiative may already have a business owner, a preliminary scope, and even a preferred solution direction. That is useful, but not yet enough.
From an architecture perspective, the first question is usually not “what should the target solution look like?” That comes later. The earlier and often more important question is:
What does this change actually affect?
Before solution design moves too far, it is useful to understand the scope, dependencies, and likely impact of the change. Otherwise, the initiative may start making decisions with a narrower view than the situation deserves.
This does not require a massive architecture exercise. Often a few good questions and one simple diagram are enough.
What Is Actually Changing?
Initiative names can be misleading. A “CRM improvement” may actually change many processes and customer data ownership. A “reporting enhancement” may reveal unclear definitions and data quality problems across business units. A “small integration” may introduce a new dependency between two critical processes. A “workflow automation” may quietly change roles, responsibilities, and control points.
So the first architecture question is about the real object of change.
Is the initiative changing a capability, a process, an application, a data object, an integration, a user experience, cooperation with an external party, an operating model, or some combination of these?
That matters because the formal scope and the architectural impact of the initiative are not always the same thing. The scope may describe what the initiative is expected to deliver. The impact describes what the change touches.
Many problems in development start when something is treated as “out of scope” even though it is clearly not out of impact.
If it is difficult to identify what the change affects beyond a single architectural component, the change may not be very architectural in the first place. That is also a useful finding. Not every initiative needs deep architectural analysis. Sometimes a lightweight check is enough.
What Dependencies Are Already Visible?
The next question is about dependencies. What other applications, teams, processes, data sources, vendors, platforms, or ongoing initiatives does this change depend on? Which decisions cannot be made independently? Which parties need to be involved or at least informed? Which other changes could affect the timing or feasibility of this work?
Dependencies are often known by someone, but not necessarily visible to the initiative early enough.
This is where architecture work can create very practical value. It helps bring scattered knowledge into the same conversation before dependencies turn into delivery surprises.
The point is not to identify every possible relationship in the enterprise. That would be a fine way to turn a useful discussion into a small documentary series. The point is to identify the dependencies that can materially affect scope, sequencing, cost, risk, or design choices.
The earlier these are visible, the less they look like surprises later.
What Decisions Would Be Expensive to Reverse?
Not every decision deserves the same level of architectural attention.
Some choices are easy to change later. Others quietly become foundations for many future decisions.
Before an initiative starts moving too fast, it is useful to ask which decisions would be expensive to reverse. Examples include platform choices, integration patterns, data models, ownership boundaries, product or vendor selections, and decisions about where specific responsibilities should sit.
These choices may not look dramatic at the time. They may appear as practical delivery decisions. But once other applications, processes, teams, and contracts start building around them, they become harder to change.
Architecture helps by making these decisions visible before they harden. It does not need to slow everything down. It simply helps distinguish between choices that are local and reversible, and choices that may create long-term structural consequences.
What Should a Good Early Architecture Diagram Show?
Before an initiative starts, the most useful architecture view is often not a polished target architecture diagram. It is a simple picture of scope and dependencies.
If the high-level EA current state has already been described, this becomes much easier. Existing architecture elements and relationships can be used as a starting point instead of reconstructing the landscape from scratch. This is one of the practical reasons why maintaining a sufficiently current, high-level view of the organization is useful.
A good early architecture view should help people see what the initiative touches and what touches the initiative.
I usually recommend anchoring the view to one or a few types of functional elements, depending on what has already been described in current-state EA. Capabilities, processes, organizational units, and external stakeholder types are often useful anchors, because they connect the change to business activity and responsibility rather than only to applications or technical components.
From there, the view can show affected applications, data objects, integrations, and related initiatives. The point is not to model everything, but to show the relevant scope and dependencies clearly enough for early decisions.
The picture should help answer questions such as what is in scope, what is affected, where are the dependencies, and which areas require alignment before decisions are made?
In my EA book, I have emphasized simple views of scope and dependencies for exactly this reason. At the beginning of an initiative, clarity often matters more than modeling elegance. A rough but useful diagram is usually better than a beautiful diagram that arrives after the important decisions have already been made.
Closing Thought
Early architecture work does not need to solve everything. It does not need to define the full target state, design the complete solution, or produce a large architecture document before anyone is allowed to move. That would often be too much, too early.
But it should happen early enough. Ideally when the initial need is known, but before key decisions have been made.
In practice, this means bringing the architecture discussion into the forum where the initiative is shaped—or, at the latest, before it is approved to move into detailed planning. This may be portfolio prioritization, project intake, investment preparation, or another decision point where scope and assumptions are still open enough to influence.
The exact forum matters less than the timing. The result should not be just a diagram, but a clearer view of dependencies, stakeholders, decisions that require alignment, and assumptions that should be tested before solution design moves too far.
At that stage, the most useful architecture question is often simple:
What does this change affect?
That question helps prevent the initiative from starting with an unnecessarily narrow understanding of its own impact.
🔗 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.
Follow him elsewhere: Homepage | LinkedIn | Substack (consulting) | Medium (writing) | Homepage (FI) | Facebook | Instagram
Books: Enterprise Architecture | The Senior Expert Career Playbook | The Senior Expert Pay Playbook | Technology Consultant Fast Track | Successful Technology Consulting | Kokonaisarkkitehtuuri (FI) | Pohjoisen tie (FI) | Little Cthulhu’s Breakfast Time
Web resources: Enterprise Architecture Info Package (FI)
📬 Want More Practical Enterprise Architecture Content?
Subscribe to Enterprise Architecture Transformation for real-world advice on architecture that supports change, strategy, and delivery.
I like and use the idea of creating 'early' diagrams when an initiative begins and these artifacts can take the form of lists of things so they do not need to be visual. The core idea is that most stakeholders cannot see the whole picture and listing out elements that could be affected (processes, connection applications, strategies, business metrics, etc.) is a useful way to bring the teams together and 'hook' them into revealing other elements.