Last year I helped a mid-size pharma company build their first real application landscape. They had one EA lead, no dedicated budget, and a CTO who wanted something useful in 90 days.

We got a working application landscape — 40 applications, accurate metadata, usable diagrams — in one week. Not perfect. Not complete. But accurate enough that people trusted it and actually used it.

Here's exactly how we did it.

Day One: Get Your Source Documents

Don't start by asking people to fill out surveys. Start by finding the documents that already exist.

Ask your IT team for:

• CMDB export or service catalog
• Active directory export (shows applications users have access to)
• Network diagram or documentation
• Any existing system inventories

Ask your validation team for:

• GxP system inventory
• Validated systems list
• CSV/FDA submission system list

Most companies have this information somewhere. It's usually scattered, sometimes outdated, but it exists. Find it before you ask anyone to do extra work.

What you'll likely find: Three different spreadsheets with partially overlapping information, none of which is completely accurate. That's fine. You're getting a starting point, not a final answer.

Day Two: Import and Clean

Take those documents and get them into your EA tool. If you're using something with AI import, this might mean uploading exports and letting the AI suggest classifications. If you're doing it manually, it means copying rows from spreadsheets into your repository.

Either way: clean as you go, but don't try to be perfect.

Your job today is to get the list of applications in one place with basic metadata. For each application, you want:

• Application name
• What it does (one sentence)
• Owner team or person
• Key integrations (what it connects to)

Don't worry about nice diagrams today. Just get the list in and make sure it's accurate enough to be useful.

Day Three: Draw the First Diagram

Pick your five most important applications — the ones that are central to how your business operates. Draw them in a single diagram.

Don't try to show every application. Just show these five and how they connect to each other.

The first diagram rules:

• Only show applications, not processes or capabilities
• Show connections between them (API calls, data flows, integrations)
• Use simple shapes — boxes and arrows is fine
• Include the application name on each box

The goal today is to have one diagram that shows something true about your organization. When someone looks at it, they should recognize something they know.

Day Four: Validate With the People Who Know

This is the step most teams skip, and it's the reason their EA repositories don't get used.

Find the person who owns or uses each of your five applications. Show them the diagram. Ask them:

• Is this accurate?
• What's missing?
• What's wrong?
• What would make this more useful for you?

Take notes. Fix the diagram. Not the whole repository — just the one diagram you've built.

The conversation is more valuable than the diagram. People who feel consulted about the architecture will use it. People who feel imposed upon won't.

Day Five: Add Five More and Connect

Expand your diagram. Add the next five most important applications. Connect them to the existing ones.

Your landscape now has ten applications — roughly 10-20% of most organizations' total. That's enough to be useful.

Show the expanded diagram to your CTO or whoever requested the EA initiative. Tell them what you have and what it cost to build it. Ask what questions they most need answered from the architecture.

That's your roadmap for expansion.

What you have at end of week one:

• 10 applications documented with basic metadata
• One diagram showing how those applications connect
• Validated accuracy on at least 5 applications
• Input on what to expand to next

That's a working application landscape. It might not cover everything. But it's accurate, it's being used, and it's expanding based on actual priorities.

What Happens After Week One

Most teams make the mistake of trying to build everything at once. The right approach is to keep the momentum going but stay focused:

Week two: Add five more applications. Get those validated.
Week three: Start adding metadata beyond the basics — compliance classification, business criticality, data sensitivity.
Week four: Connect to business capabilities. Show not just what systems exist but what business functions they support.

By the end of month one, you have a real repository that people trust because they've seen it validated. That's the foundation everything else gets built on.

The worst thing you can do is spend six months building a comprehensive model that nobody uses because it's too big to maintain. Start small. Start accurate. Expand from there.