How to Start an Enterprise Architecture Practice From Scratch

Most enterprise architecture practices don’t begin with a mandate. They begin with a question nobody could answer. Somebody asks which systems touch customer data, or what breaks if the payments service goes away for an afternoon, and three people give three different answers.

Starting an enterprise architecture practice from zero means building the ability to answer those questions repeatably: a picture of what exists, a small group that owns it, and a cadence that keeps it current. Almost every guide on this treats it as a people-and-process problem, which is half right. The half they skip is the data problem, and it’s the half that stalls most first attempts.

This guide covers six steps that take a practice from nothing to useful, the domains it grows into, and the mistakes that kill it early. It’s written for engineers and architects standing one up for the first time, with no dedicated team and no budget for a year of modeling.

You Don’t Have an EA Practice. You Have a Backlog of Questions Nobody Can Answer.

The honest starting position for most teams is not “we have poor documentation.” It’s that the documentation describes a system that no longer exists, and nobody can say by how much.

That gap is hard to size directly, but two independent 2026 surveys show its shape. Flexera surveyed 512 IT professionals globally and found that complete IT visibility has dropped to 36%, down from 43% the year before, with only 31% reporting visibility into their AI software. Flexera attributes the drop to AI specifically: visibility into on-premises, SaaS and cloud is still improving, and AI has opened a new blind spot that pulls the overall number down.

Separately, BetterCloud surveyed 525 IT and security professionals at SaaS-first organizations and found that only 56% of the apps in use carry IT approval. It reads that as nearly half the software sitting outside IT’s line of sight.

The two surveys measure different populations and different things, and neither measures documentation accuracy. Together they show gaps in visibility and approval, not a shared measure of documentation accuracy or its change over time. So the first artifact of a new practice is not a framework, a target-state diagram, or a governance charter. It’s a list of what’s actually running.

Step 1: Get a Real Inventory Before You Plan Anything

Every guide to starting enterprise architecture agrees you need a current-state picture. Almost none say how to get one from nothing, and the default answer, a round of interviews and a spreadsheet, is where first attempts die. Interviews capture what people remember, and spreadsheets capture what was true on the day they were filled in.

The standard objection to putting inventory first is that you should set the goal first, so you know what to inventory. That’s correct when the inventory is expensive, and a hand-built one always is. Automated discovery can make a broad first pass practical, though scope still affects permissions, coverage, and effort. Doing it first can stop you from choosing a goal aimed at a system two teams already abandoned. The stronger form of the objection is that an inventory tells you what exists, not what matters. That’s true, and it’s exactly why Step 2 exists. The inventory is an input to choosing the goal, not a substitute for having one. If interviews are your only route to a current-state picture, invert these two steps.

Tools differ mostly in where the data comes from. Diagramming tools ask you to draw the estate; repository tools ask you to model it, and a smaller group derives it. We sit in the third group. We connect read-only to your AWS accounts, Kubernetes, and VPC flow logs, and build the model from what we find, with no manual modeling required. Component detail goes down to cloud-specific properties like instance type, region, and ARN. We work with architecture teams beyond AWS-only estates; the available integrations and evidence coverage need to be confirmed for your environment, and we are a decision and design layer rather than an observability tool.

Whatever you use, the test is the same. Ask whether the inventory updates itself when somebody deploys something new. If the answer is no, you’ve bought a snapshot, and you’ll run this exercise again next quarter. The enterprise architecture tools roundup covers the category against that criterion.

Infrastructure discovery alone won’t give you a complete SaaS and vendor inventory, which is where the unapproved-app problem lives. Pair it with a finance pull: every recurring software line item in the last twelve months of spend. This is the half of the inventory the goal-first objection is right about, since it costs real calendar time and depends on somebody else’s cooperation. If you already know the decision you’re serving, scope it to the vendors that decision touches.

Step 2: Pick One Sponsor and One Goal

A practice with two sponsors has none. Eetu Niemi addresses ownership in his second step and is direct about it: the work needs a named owner, with a C-level sponsor to keep it anchored, because without ownership EA becomes “a polite hobby.” Find the single executive currently being hurt by the thing you just inventoried, and make the practice serve their problem first.

The goal should be small enough to finish and specific enough to argue about. “Improve architectural alignment” is not a goal. “Decide by end of quarter whether we consolidate the three reporting databases” is. It has a decision at the end, a named owner, and a date, so the practice gets measured on something other than the completeness of a diagram.

This is also where you set expectations about what the practice will not do. It will not review every pull request, and it will not own delivery. Writing that down in the first month prevents the slide into being a review board, which is the most common way a promising practice becomes an obstacle.

Step 3: Build a Working Group Under 10 People, Not a Committee

Niemi’s sequence calls for a small, motivated team “well under ten people,” on the grounds that a group that size can still hold one conversation instead of a committee meeting. What matters as much as the size is that the group can decide rather than recommend, and that authority comes from the Step 2 sponsor explicitly, not from meeting regularly.

The structural question most first-timers skip is where the group sits. Writing for EDUCAUSE in 2020, Jim Phelps frames the choice as centralized, federated or feudal, and makes it contingent on culture. Centralized fits a top-down organization, federated fits one with genuinely distributed autonomy, and feudal fits independent business units. Decide it deliberately rather than discovering which one you’ve built eighteen months in, and pick the one that matches your org chart rather than the one that sounds collaborative.

Cover four perspectives in almost every discussion: infrastructure, applications, data, and what the business is trying to do next. That last seat is the one most often skipped and the one that most determines whether anybody outside engineering takes the output seriously.

Step 4: Ship Rough Models Fast, Not Perfect Ones

Niemi recommends producing early models quickly so the practice builds credibility before enthusiasm fades. First-time practices often aim for a complete model and produce nothing usable for six months.

What to Model First

Three views cover most of the questions a new practice gets asked.

• The application landscape: what systems exist, who owns each one, and what each is for. Coarse is fine. A list with owners beats a beautiful diagram with none.
• The dependency map: what talks to what. This answers the “what breaks if” questions, and a derived inventory gives it to you almost for free.
• A capability map: what the business is able to do, in its own language, mapped loosely to the systems supporting each one. Capabilities are not processes: a capability is stable and says what; a process says how and changes every quarter. A dozen or so at the top level is plenty for a first pass, and it’s the view that connects a technical change to the business strategy behind it.

Skip data groups, integration patterns, and technology standards for now. They matter, but they refine a picture you don’t have yet.

Where to Pull Source Material From

Use what already exists before writing anything new. Audit and compliance documentation is often more current than architecture documentation, because somebody was forced to keep it accurate for an auditor. Onboarding guides tell you what new engineers are told the system looks like. Incident postmortems are the best source of real dependency information, because they document connections nobody knew about until they broke.

Then reconcile the difference between what the documents claim and what the environment shows. Where a document and the running system disagree, the system is right, and the disagreement is your first finding.

Step 5: Put the Models to Work Immediately

Niemi recommends bringing models into project scoping and investment prioritization as soon as they are usable. A model that hasn’t informed a decision is decoration.

Take the goal from Step 2 and run it through the models you just built: scope a project, price a consolidation, answer the risk question somebody raised in a leadership meeting. Then say out loud, in that meeting, which model produced the answer. That isn’t self-promotion; it’s how the practice earns its next quarter.

People remember not the diagram; they remember the decision that got made faster because the diagram existed. Keeping the reasoning attached to that decision also lets you revisit it later, which is what enterprise architecture management covers once the practice is running.

Step 6: Keep It Alive With a Lightweight Cadence

Most practices die of maintenance cost, not opposition. A heavy governance model collapses under its own weight, usually before it has produced a decision anyone remembers.

A workable rhythm has three slots. The working group meets every two weeks with a short agenda of live decisions, and the models get reconciled against reality on a fixed monthly slot. One quarterly session asks whether the target state still makes sense. Add to that only when something breaks that the cadence did not catch, and add only the thing that would have caught it.

Protect the reconciliation slot. If the inventory is derived automatically, this is a review of what changed, not a rebuild. If it isn’t, this is where you find out how expensive manual modeling really is, and you’ll have the evidence to argue for changing it.

The Four Domains You’ll Eventually Need to Cover

None of the above requires adopting a framework on day one. But as the practice grows, the four architecture domains TOGAF describes, which most other frameworks map onto, are a useful checklist of what you haven’t covered yet.

• Business architecture: capabilities, processes, and the operating model. Business architecture covers how this layer is usually structured.
• Data architecture: what information exists, where it lives, and how it moves.
• Application architecture: the systems themselves, how they interact, and which business processes each one supports.
• Technology architecture: the infrastructure everything runs on.

Treat these as coverage gaps rather than a sequence. Most practices start deep in application and technology, then get pulled into data and business architecture the first time somebody asks something the technical layers can’t answer alone.

Common Mistakes When Starting an EA Practice

• Modeling for the sake of modeling: the number of diagrams produced is not a measure of progress. The number of decisions they inform is.
• Waiting for a complete picture: a practice that won’t answer a question until the model is finished will never answer a question.
• Running the framework as a project plan: frameworks are checklists of coverage, not sequences to execute in order. Treating one as a month-by-month schedule is how a first year disappears into methodology, which the FAQ below gets into.
• No named sponsor: without one, the practice is a volunteer effort competing with delivery work, and delivery work wins.
• Becoming a review board: the fastest way to lose the goodwill you built in the first quarter is to start adding two weeks to other people’s projects.
• Treating the inventory as a one-time project: if it’s built by hand, it’s decaying from the day it’s finished.

Conclusion

Starting an enterprise architecture practice is mostly a sequencing problem. The people-and-process advice in circulation is sound, but it assumes a current-state picture that teams starting from zero don’t have, and building that by hand is what turns a three-month start into a year.

Get the inventory from the systems, pick one sponsor and one decision, keep the group small, and put rough models in front of real questions inside the first month. If your bottleneck is the picture rather than the process, book a demo to see what a derived inventory looks like before you commit a quarter to building one manually.

Frequently Asked Questions

Is TOGAF still relevant?

Yes, though not in the way the question usually implies. The current version is the TOGAF Standard, 10th Edition, and it is built to be configured and tailored to the organization using it rather than run as shipped. Tailor the ADM to your organization rather than treating every activity as a fixed project schedule. As a checklist of what a mature practice eventually covers, it holds up well. As a project plan for month one, it will bury you.

How do I become an enterprise architect?

Most people arrive from a senior engineering, infrastructure, or solutions architecture role rather than from a certification. The transferable part is having owned a system end to end and been accountable for a decision that was expensive to reverse. Certifications help with hiring filters and give you shared vocabulary, but they don’t substitute for watching a real architecture decision play out over several years.

Does it take seven years to become an enterprise architect?

There’s no fixed number, and the range in practice is wide. What the timeline actually tracks is exposure rather than tenure: how many systems you’ve seen through a full lifecycle, including the ones that went badly. Someone who has run three migrations in five years is usually further along than someone who has maintained one stable system for ten.

What are the 5 components of enterprise architecture?

Answers vary because there’s no canonical list. The most common version is the four architecture domains: business, data, application, and technology, plus a governance or principles layer that keeps them consistent. If your organization has adopted a specific framework, use that framework’s own breakdown rather than a generic one, since the differences between them matter more than the count.