13. June 2026

Thinking small with Enterprise Architecture

Applying EA frameworks and principles to smaller projects

Introduction

Enterprise Architecture (EA) is often associated with large, complex organisations and vast IT landscapes. However, its core principles are equally valuable when applied to smaller projects, helping to achieve a greater level of efficiency when designing and delivering the desired outcome.

I have been updating some EA frameworks and helping create processes for them and how they can be used on larger projects and the more I was creating the processes for the larger scale projects, the more I was able to tie in the frameworks and principles to smaller projects that I’ve been involved with in the past and how they could have made the projects run more efficiently. Added to this, the potential for on-going improvements for the clients and how adding the EA principles to the smaller projects helped plan these future engagements and help drive the clients forward.

Using the Zachman framework alongside TOGAF gives a better all-round view on how to apply EA principles and I’ve referred to both in this article. For more info, take a look at the following sites.

Comprehensive Guide to the TOGAF Architecture Development Method (ADM) - Visual Paradigm TOGAF

What is Zachman Framework?

Why Consider EA for Smaller Projects?

How did I come to this conclusion I hear you ask? (no, you at the back I thought you had your hand up?)

Even the traditionally smaller projects could all benefit from using aspects of both EA frameworks, from a more structured presales engagement to the design, deployment and then working on future improvements with the clients. The example I’ve given below is for a workload migration to Azure using the normal approach and tooling which will hopefully show how EA can be fully utilised.

Structured Approach:

Applying EA ensures every project has a clear roadmap, reducing ambiguity and risk.
Defined processes that can be utilised for each stage of the project
Determining the stages of the project and how the processes from each framework can apply to them

Strategic Focus:

Even small initiatives benefit from aligning with broader business goals, ensuring long-term value.
Asking more of the “right” questions at the presales stage and finding the business drivers, depts affected, current and target state etc

Scalability:

Starting with EA principles makes it easier to expand the project in future without costly redesigns.

Framework Examples: Zachman & TOGAF ADM

As I’ve already mentioned, I’ve based the findings in this article on the two main EA frameworks: the Zachman Framework and the TOGAF Architecture Development Method (ADM). These frameworks offer structured approaches to organising and managing architecture work, even on a modest scale.

Don’t worry, I’m not going to give full descriptions of these here (that comes later BWUAHAHAHAH! Sorry, I digress). I’ve added two brief paragraphs that give a very high-level overview. Anyone that wants to know more, theres mass amounts of information on both frameworks on the interwebs or if this article goes well I may just treat you lovely people to an article on it.

Zachman Framework Example

The Zachman Framework is a matrix that helps teams understand the different perspectives and artefacts required for a comprehensive architecture. It is organised into six rows (representing stakeholders such as Planner, Owner, Designer, etc.) and six columns (representing questions like What, How, Where, Who, When, and Why).

The following table is an incredibly basic example to show how it can be used.

This filled-in example shows how Zachman can structure thinking across stakeholder viewpoints when planning an Azure migration. Even a lightweight version like this gives clarity on ownership, scope and dependencies.

TOGAF ADM Framework Example

The TOGAF ADM (Architecture Development Method) is a step-by-step process for developing and managing enterprise architecture. It is depicted as a circular diagram, emphasising its iterative nature. Below is a simplified representation of the ADM cycle:

Both frameworks can be tailored to the scale and complexity of your project, providing a clear structure and a repeatable approach to managing architecture work. Even for small projects, leveraging these frameworks helps teams communicate, plan, and deliver more effectively.

Case Study Example

The example I’ll use to (hopefully) reinforce my point, is a bog-standard migration project that is relocating workloads from an on-premises environment to Azure. The approach I’ve taken below is as a project designed and delivered by an MSP but with some slight changes to the initial presales stages, this could be adapted to be used by an internal IT department.

The points below aren’t exhaustive but will hopefully provide enough examples on how the EA frameworks can be used.

Presales Engagements

Work with the client to detail the business drivers for the migration
Why migrate? Why now?
What are you looking to migrate? Why do you want to migrate those particular workloads?
Which areas of the business are affected by this move? Have they been properly consulted/informed about the moves and are they prepared?
Has the business planned for post migration?
The statement of work (SoW) can be created to serve the same purpose as the TOGAF vision document to show the above and be used as the source of truth for the project.

Design phase and migration

Use the principles of Architecture Building blocks and Solution Building blocks from TOGAF, determine the tooling and architecture to be used for the migration.
Architecture Domains can be used to determine the Business, Data, Application and Technology domains (BDAT principles from TOGAF).
These can be used to determine the migration phases/priorities, the underlying technology – Azure migrate, ASR, VNets, Resource Groups etc.
Using both the ADM and Zachman frameworks, the plan for the migrations and phases can be created. Aligning the correct stakeholders for the applications moves, server moves, required networking and access etc. The testing can be planned using these frameworks. Never skimp on the testing!

Project completion and follow on actions

Using the later phases of the ADM (Phases G and H) continuous improvement can be discussed and planned following the migration of the workloads.
App modernisation, IaaS to PaaS services etc

Conclusion

Enterprise Architecture doesn’t just have to be used for the longer term, larger projects. By using an EA approach and adapting the aspects of the framework that can add value, it can help with a more structured and focused planning phase where the right people can be involved from the start and the right priorities can be determined. Taking time with the planning phase and priorities will lead to a smoother deployment phase where the right outcome will be achieved and ensure long term success rather than just completing a project quickly and moving on to the next project.

In the example above, if the time is taken on the planning phase to determine why the workload needs migrating and who needs to be involved and when, this would mean that the migration would be efficient and bring the least disruption to the business. During the migration phase, the follow-on actions can be planned and help the client realise the value of using the phased and structured EA approach.

So the next time you’re planning a project, however small and seemingly mundane, give the EA approach a go and see how it can make a difference to your planning and execution of the project. Use the TOGAF and Zachman frameworks and take what you need from them. They aren’t meant to be followed in a linear approach, but there’ll be aspects within both that will make a big difference to the way your project goes.