The demos all blurred together.

Another week, another vendor pitch. Slide after slide promised a “single source of truth,” “360degree visibility,” and “seamless collaboration across the enterprise.” The names changed. The interfaces changed. But to the enterprise architecture leader in the room, it all felt like the same story with a different logo on the last slide. 

Six tools made the shortlist. All six scored well on the RFP checklist — every box ticked, every feature accounted for. And that was the problem. The EA lead sat down to brief the CIO on which tool to recommend and realized she couldn’t articulate why any one of them was better than the others. Hundreds of features compared. Zero clarity gained. 

That’s when she changed the questions. 

Instead of asking, “What features does this tool have?” the EA lead flipped it: “What functions does our architecture practice actually need to perform — and which of these matter most right now?” 

If it sounds like a subtle shift, it isn’t. Features are the long, exhausting checklists in RFPs — useful, but noisy, easy for vendors to inflate, and hard for EA leaders to compare. Functions are different. They’re the higher-level capabilities that help architects understand today, design tomorrow, and safely move from one to the other. Features tell you what a tool can do. Functions tell you what your practice must do. 

When the EA lead started talking in terms of functions instead of features, the maze began to look more like a map. 

Core Functions: The Work Your Architecture Practice Runs On

First, the EA leader and team defined the core functions their EA tools must support (i.e., the work that absolutely has to happen for architecture to stay credible and relevant).

They asked questions like:

  • Can we reliably model our architecture layers so that everyone sees the same current state?
  • Can we design and compare target states that tie directly to business outcomes?
  • Can we connect the dots between data, applications, infrastructure, and business capabilities to understand the impact of change before it happens?

After all, these are the everyday tasks that architects, solution designers, and technical leaders struggled with across projects and portfolios. By grouping related capabilities into clear core functions, the team could finally answer a simple, powerful question: “Which of the presented EA tool truly deliver on these core functions and which only claim to?”

Extended Functions: The Capabilities That Change The Game

Once the essentials were clear, the conversation shifted to extended functions (i.e., the capabilities that don’t define an EA tool category but do shape how far a practice can go).

They looked at capabilities like smarter risk management and cost analysis, better management of technical and architectural debt, and design of AI enabled ecosystems. These weren’t universally required to qualify as an EA tool, but they made a real difference in how fast and how confidently the organization could change.

Consider architectural debt. Your organization carries years of accumulated technical debt across legacy platforms, and the CIO wants a clear, quantified view of remediation costs before approving a modernization roadmap. One tool gives you a debt register with manual tagging. Another surfaces debt automatically by analyzing dependency maps and flagging obsolescence risk across your portfolio. Same core modeling. Vastly different strategic utility.

Or take AI-enabled ecosystem design — an increasingly critical capability as organizations embed AI into products, operations, and customer experiences. An EA tool that merely catalogs AI initiatives is table stakes. One that models data flows, inference pipelines, and governance boundaries across your AI ecosystem gives architects real influence over how AI scales.

By naming and standardizing both core and extended functions, the team created a shared language that made sense to architects, CIOs, C-levels, and procurement alike.

Start with functions, not features

Here’s what to do next. Before your team opens another RFP spreadsheet or sits through another vendor demo, take one hour to define the core functions your architecture practice must perform not the features you think you need. Map those functions to the real work your architects do every week. Then ask which extended functions would change the game for your organization’s specific transformation priorities.

That exercise alone will eliminate half your shortlist and sharpen the conversations that remain.

In our latest research on the technical functions of enterprise architecture management suites, we break down the standard set of core and extended functions, show how they map to real-world use cases, and outline a practical path to evaluate your current vendors before you look elsewhere. Dive into the full report and use the function-first lens to redraw your map.