#enterprisearchitecture

Most cloud cost problems aren't infrastructure problems.

They're workload placement problems.

I've seen teams spend months planning migrations when a single analytics workload move delivered the biggest savings.

Shared a real example on LinkedIn that sparked some interesting discussions.

Framework selection paralyzes more enterprise architecture programs than almost anything else. TOGAF, Zachman, FEAF, a homegrown hybrid, teams spend months debating the choice as if picking the "right" framework will make everything else fall into place.

It won't.

And that belief is often the real problem.

Start with the Right Mental Model

A framework is a tool, like a wrench.

The wrench doesn't fix the engine. The mechanic does.

The most rigorous framework in the world, in untrained hands, produces an expensive binder full of diagrams that nobody uses. A modest framework in skilled hands can deliver meaningful business results.

That perspective takes the pressure off framework selection and shifts attention to the factors that actually determine success.

Three Questions That Actually Matter

Instead of asking, "Which framework is best?", ask:

1. What problem are we trying to solve?

Portfolio rationalization, AI readiness, merger integration and governance modernization are different challenges. Start with the business problem, not the framework brand.

2. Who needs to use the output?

If stakeholders won't read or act on the artifacts, additional rigor creates little value. Match the framework approach to the audience and decision-makers.

3. Do we have people who can successfully execute it?

This is the question organizations skip most often.

A framework only creates value when practitioners know how to apply it effectively. Without the right skills, even the best methodology becomes shelfware.

A Practical Example

Consider a 200-person software company trying to rationalize an application portfolio that has grown through acquisitions.

They may not need the most comprehensive or process-heavy framework available. They need a capability-based approach that they can realistically execute with their existing team and resources.

In this situation, a lightweight, fit-for-purpose framework paired with a skilled architect will typically outperform a sophisticated enterprise methodology that nobody internally can sustain.

By contrast, a federal agency operating under strict governance requirements may benefit from a more formal architecture framework.

Same question. Different answer.

Because the answer depends on the problem, the stakeholders and the organization's maturity, not on which framework has the strongest marketing.

Think Beyond the Framework

Successful architects view frameworks as scaffolding: useful, valuable and necessary in many situations, but not the building itself.

They remain tool-agnostic and focus on developing the capabilities required to model, analyze, govern and deliver change effectively.

Framework knowledge matters.

Practitioner capability matters more.

Key Takeaway

Choose a framework that aligns with your business objectives, stakeholder needs and organizational maturity.

Then stop optimizing the wrench and start training the mechanic.

The framework is the starting point.

The practice is what produces results.

EACOE helps architects develop practical, implementation-focused skills that work across TOGAF, FEAF, Zachman and hybrid enterprise architecture approaches. The goal is not framework loyalty. The goal is delivering measurable business outcomes and helping organizations Succeed Fast.

The Zachman Framework's six questions are often presented as part of a complex-looking grid. That can make the framework seem intimidating. In reality, the foundation is surprisingly simple.

At its core, the Zachman Framework is built around six questions that journalists, investigators, and business leaders ask every day. Understand those questions, and you understand the backbone of enterprise architecture.

The Six Questions

The Zachman Framework's six questions organize everything needed to describe an enterprise:

WhatThe data and things the enterprise cares about, such as customers, products, orders, and invoices.

HowThe processes, functions, and activities the enterprise performs.

WhereThe locations, networks, and operating environments across which the enterprise functions.

WhoThe people, teams, stakeholders, and organizational roles are involved.

WhenThe timing, events, schedules, business cycles, and triggers that drive activity.

WhyThe motivations, goals, business rules, strategies, and objectives behind everything the enterprise does.

Answer these six questions thoroughly and you've described the essential elements of the enterprise. Few aspects of an organization fall outside these categories.

The Clever Part: Perspectives

The six questions are only half of the framework.

The Zachman Framework also organizes information across multiple perspectives, from the executive view at the top, through business and system perspectives, down to the technology and implementation levels.

The same six questions are asked from every perspective. Each level adds detail without contradicting the levels above it.

This structure helps create a complete and consistent architectural description. Each architectural artifact is intended to have a unique place within the framework, reducing redundancy and confusion while improving traceability across the enterprise.

A Simple Use Case

Imagine you're trying to improve a broken order-to-cash process.

Using the Zachman Framework, you would ask:

What data is involved? (Orders, invoices, customers, payments)

How does the process flow?

Where does the process occur across systems and locations?

Who owns or performs each step?

When do key events occur?

Why does the process exist and what business objective does it support?

By answering all six questions at the appropriate level of detail, you gain a complete picture of the process and can identify gaps, bottlenecks, ownership issues, or system failures.

What the Diagrams Won't Tell You

Here's the important part.

The Zachman Framework is a classification scheme (taxonomy), not a methodology. It helps organize architectural descriptions, but it does not prescribe a step-by-step process for creating them.

Knowing the framework is easy. Producing accurate, useful answers about a real organization is where the real work begins.

That skill comes from experience, practice, mentoring, and continuous feedback, not from memorizing rows and columns.

Key Takeaway

The Zachman Framework's six questions provide a structured way to ensure nothing important is overlooked when describing an enterprise.

By asking What, How, Where, Who, When, and Why across multiple perspectives, organizations can build a complete, consistent, and non-redundant understanding of how the enterprise operates.

The challenge isn't memorizing the framework. The challenge is answering the questions accurately.

EACOE's connection to the Zachman tradition is particularly strong through our Managing Director, Sam Holcman, who serves as President of the Zachman Institute (ZIFA). Our approach focuses on helping practitioners learn how to model real enterprises through hands-on application, mentoring, and practical experience so they can truly Succeed Fast.

Ask ten people what an enterprise architect does and you’ll probably get ten different answers and at least a few confused looks. The title sounds abstract, like someone who spends all day drawing diagrams no one reads.

The reality is far more practical and far more valuable than most people realize.

The Simple Explanation

An enterprise architect helps an organization keep its business goals, processes, applications, data and technology moving in the same direction so the company can grow and change without creating chaos.

The important word there is enterprise.

This is not just an IT role hidden inside the technology department. Enterprise architecture connects strategy, operations, technology and decision-making across the entire organization.

That’s what makes the role difficult and why it matters so much.

What Enterprise Architects Actually Do

When you remove the jargon, the job becomes surprisingly concrete.

1. Understand the Current State

Enterprise architects create a realistic picture of how the organization actually operates today, not how the org chart says it operates.

That means understanding:

systems

workflows

business processes

data flows

dependencies

operational bottlenecks

Most organizations are far more complicated than leadership realizes.

2. Design the Future State

Once business goals are clear, enterprise architects help design how the organization should evolve to support those goals.

This includes:

technology modernization

process improvement

system integration

scalability planning

organizational alignment

The goal is not “more technology.”

The goal is better business outcomes.

3. Drive Better Decisions

A good enterprise architect helps leadership see trade-offs before expensive decisions are made.

For example:

identifying overlapping systems

reducing technical debt

exposing implementation risk

preventing redundant investments

aligning projects with business priorities

Their job is to help organizations avoid expensive mistakes before they happen.

4. Translate Between Business and Technology

One of the most valuable EA skills has nothing to do with frameworks.

Enterprise architects constantly translate between:

executives focused on business strategy

technical teams focused on implementation

That communication gap quietly destroys a surprising number of projects.

Strong architects bridge it.

A Real-World Example

Imagine a company preparing to purchase a new CRM platform.

Leadership is excited. Vendors are making promises. Budgets are moving quickly.

The enterprise architect is the person who says:

“We already own multiple systems covering most of these capabilities and the new platform will require a costly integration with our billing environment.”

That single insight can prevent a massive financial mistake.

That’s enterprise architecture in practice: seeing the entire business landscape before decisions become expensive.

Why the Role Is Commonly Misunderstood

The word “architect” makes people think the value is in diagrams and documentation.

It isn’t.

The diagrams are tools.

The real value comes from:

judgment

systems thinking

business understanding

communication

planning

decision support

Many people can memorize frameworks.

Far fewer can walk into a real stakeholder meeting, navigate competing priorities and guide practical decisions under pressure.

That is the actual job.

Key Takeaway

An enterprise architect is part strategist, part analyst, part communicator and part problem-solver.

They connect business goals to technical reality and help organizations make decisions that scale instead of collapsing under complexity.

If an “enterprise architect” only produces documentation, you probably do not have an architect. You have someone documenting systems.

That gap is exactly why practitioner-based enterprise architecture training matters. Real enterprise architecture is learned through implementation, decision-making and hands-on execution, not just passing an exam.

Scaling AI across an organization requires more than deploying models. MCP helps organize how AI connects with tools, systems, and business logic. SDH builds MCP ecosystems focused on sustainability and performance.

In 2026, enterprises are re-architecting software as intelligent systems rather than isolated applications. AI-native design, cloud-first operating models, and modular architectures enable systems that adapt, evolve, and scale with business priorities.

The full perspective is explored on our website.