TOGAF for SMEs: Is It Really Made for You?

TOGAF for SMEs: Is It Really Made for You?

When enterprise architecture is mentioned in the context of small and medium-sized enterprises (SMEs), the reaction is often skepticism. Frameworks like TOGAF -- the Open Group Architecture Framework -- are widely perceived as heavyweight methodologies designed for large corporations with dedicated architecture teams and multi-year transformation programs.

This perception is not entirely wrong, but it is dangerously incomplete. The principles behind TOGAF are relevant to any organization that depends on technology to operate and grow. The challenge lies not in whether TOGAF applies to SMEs, but in how to adapt it pragmatically.

This article demystifies TOGAF for SME and mid-market decision-makers. We will explain what the framework actually is, walk through the ADM cycle in plain language, and provide an honest assessment of what to adopt, what to simplify, and what to skip entirely.

What Is TOGAF, Really?

TOGAF is a framework for developing, maintaining, and governing enterprise architectures. First published in 1995 and now in its 10th edition, it has become the most widely adopted enterprise architecture framework in the world, used by organizations in over 80 countries.

At its core, TOGAF provides:

A structured methodology (the Architecture Development Method, or ADM) for creating architectures
A set of reference models and standards for consistency
A governance framework for managing architecture over time
A common vocabulary that enables communication between business and technology stakeholders

It is important to understand what TOGAF is not:

It is not a prescriptive, step-by-step recipe that must be followed exactly
It is not software or a tool
It is not an all-or-nothing commitment
It is not exclusive to large enterprises

TOGAF explicitly states that it should be tailored to the specific needs of each organization. This tailoring is precisely where SMEs can extract value without being crushed by bureaucratic overhead.

The ADM Cycle: A Walkthrough in Plain Language

The Architecture Development Method (ADM) is the beating heart of TOGAF. It describes a cyclical process for developing enterprise architecture through a series of phases. Let us walk through each phase, explaining what it does and how an SME might approach it.

Preliminary Phase: Setting the Stage

What it does: Establishes the architecture capability within the organization. Defines principles, governance structures, and the scope of the architecture effort.

For SMEs: Keep this lightweight. You do not need an Architecture Board or a formal governance charter. What you do need is:

Agreement on why you are investing in architecture (e.g., preparing for growth, reducing IT costs, managing risk)
A clear understanding of who will be involved (even if it is a single person wearing multiple hats)
Basic principles that guide decisions (e.g., "prefer SaaS over custom development," "standardize on a single cloud provider")

This can be a one-page document or a 30-minute alignment meeting -- not a six-month initiative.

Phase A: Architecture Vision

What it does: Defines the scope, stakeholders, and high-level vision for the architecture effort. Creates a request for architecture work and secures management buy-in.

For SMEs: This phase translates to answering three questions:

What is the business problem we are solving? (e.g., "We are growing through acquisition and need to integrate three different IT environments.")
What does success look like? (e.g., "A unified view of all applications and their dependencies within six months.")
Who needs to be involved? (e.g., CTO, operations manager, finance director.)

The output can be a brief presentation or memo -- not a 50-page architecture vision document.

Phase B: Business Architecture

What it does: Develops the baseline (current state) and target (future state) business architecture, including processes, organizational structures, and business capabilities.

For SMEs: Map your core business processes and identify which ones are supported by IT and which ones are manual or ad hoc. You do not need to model every process in BPMN notation. A simple list of your top 10-15 business capabilities with their current maturity level provides immense value.

Key questions to answer:

Which business processes are most critical to revenue?
Which processes are the most fragile or dependent on specific individuals?
Where are the biggest gaps between what the business needs and what IT delivers?

Phase C: Information Systems Architecture

What it does: Develops the application architecture and data architecture, mapping the software landscape and data flows that support business processes.

For SMEs: This is often the highest-value phase for mid-market organizations. Building a clear picture of your application portfolio -- what you have, what it does, who uses it, and how it connects -- is transformative.

Focus on:

Creating an application inventory with ownership, cost, and criticality information
Mapping key integrations between applications (what talks to what?)
Identifying redundant applications that perform overlapping functions
Understanding data flows -- where does critical data originate, and where does it go?

This phase directly supports IT rationalization, cost reduction, and risk management.

Phase D: Technology Architecture

What it does: Maps the underlying technology infrastructure -- servers, networks, platforms, and cloud services -- that hosts the application landscape.

For SMEs: Document your infrastructure at a level of detail that supports decision-making:

Where are your applications hosted? (On-premises, cloud, hybrid?)
What are your critical infrastructure dependencies?
Are there single points of failure?
What is the age and supportability of key infrastructure components?

You do not need a detailed network diagram of every switch and router. Focus on the decisions that matter: cloud migration candidates, end-of-life systems, and capacity constraints.

Phase E: Opportunities and Solutions

What it does: Identifies the major projects and initiatives needed to move from the baseline to the target architecture. Prioritizes and sequences the work.

For SMEs: This is where architecture becomes actionable. Based on the gaps identified in Phases B through D, create a prioritized list of initiatives:

Which quick wins can deliver value in under three months?
Which strategic projects require planning and investment?
What dependencies exist between initiatives?
What is the realistic capacity for change given your team size?

A simple prioritized roadmap -- even in spreadsheet form -- is vastly better than no roadmap at all.

Phase F: Migration Planning

What it does: Creates a detailed migration plan with timelines, resources, and risk mitigation strategies.

For SMEs: For most mid-market organizations, this phase merges naturally with Phase E. Your migration plan is your project portfolio -- the sequenced list of initiatives with owners, timelines, and dependencies. Keep it practical and update it regularly.

Phase G: Implementation Governance

What it does: Ensures that implementation projects conform to the target architecture.

For SMEs: This translates to a simple discipline: before approving any new technology purchase or development project, check it against your architecture. Does it align with your principles? Does it fit into your target landscape? Does it create new dependencies or risks?

This does not require a formal Architecture Review Board. It requires the habit of asking the right questions.

Phase H: Architecture Change Management

What it does: Monitors the architecture for needed changes, driven by business changes, technology changes, or lessons learned.

For SMEs: Architecture is not a one-time project. Set a regular cadence -- quarterly is sufficient for most SMEs -- to review your architecture, update your application inventory, and reassess priorities. The business evolves, and your architecture understanding must evolve with it.

Requirements Management (Central)

What it does: A continuous process that manages architecture requirements throughout all ADM phases.

For SMEs: Maintain a simple, living list of requirements -- business needs, constraints, and non-negotiable standards -- that informs every phase. This can be a shared document that is reviewed and updated at each architecture review.

What to Adopt, Simplify, and Skip

Here is an honest assessment for SME leaders:

Adopt fully:

The concept of baseline and target architectures (where are we now, where do we want to be?)
Application portfolio management with ownership, cost, and criticality data
A roadmap connecting architecture to actionable initiatives
Basic architecture principles that guide technology decisions

Simplify heavily:

The ADM cycle -- treat it as a thinking framework, not a rigid process
Governance -- replace formal boards with regular check-ins and review habits
Documentation -- one good diagram is worth a hundred pages of text
Stakeholder management -- in an SME, the relevant stakeholders fit around a single table

Skip (for now):

Formal architecture certifications for team members
The TOGAF Technical Reference Model (TRM) and Standards Information Base (SIB)
Detailed metamodel compliance
Architecture repositories in the TOGAF-prescribed format

Common Objections and Honest Answers

"We do not have an enterprise architect."

You do not need one. TOGAF principles can be applied by a CTO, IT manager, or even a technically minded operations leader. What matters is the discipline of thinking architecturally, not the job title.

"We are too small for this."

If you have more than 10 applications and more than 20 employees, you have enough complexity to benefit from architectural thinking. The question is not size -- it is whether you can afford to make technology decisions blindly.

"It will slow us down."

Badly implemented architecture slows organizations down. Well-implemented architecture accelerates decision-making by providing clarity. The goal is not more process -- it is better information.

"We tried it and it was too bureaucratic."

That is a tailoring failure, not a TOGAF failure. If your architecture practice generates more documents than decisions, it needs to be simplified.

Making TOGAF Work for Your Organization

The organizations that extract the most value from TOGAF are those that treat it as a toolbox, not a rulebook. Take the concepts that address your specific challenges, adapt them to your size and culture, and ruthlessly discard anything that does not contribute to better decisions.

For SMEs, the highest-impact starting point is almost always Phase C -- Information Systems Architecture. Building a clear, shared, up-to-date picture of your application landscape and its dependencies unlocks value across every other phase of the ADM.

UrbaHive is designed to make this starting point accessible and collaborative. By providing an intuitive platform for mapping your information systems, managing your application portfolio, and visualizing dependencies, UrbaHive gives SMEs the architectural visibility that TOGAF prescribes -- without the heavyweight process. Start building your architecture practice today at urbahive.com.