How should a small team choose an enterprise architecture tool?
So it’s just you. Or maybe you and two others. That’s it. You are the Enterprise Architecture team. The entire weight of the responsibility of the EA function falls to you.
I bet most of us have been there. That’s where I’ve spent most of my career: as the only person who actually wanted the title, the role, and the responsibility of being an Enterprise Architect. Most CIOs have no idea what an EA is supposed to be doing. They think of EA as a glorified solution architect. (Some well respected influencers agree with them, including the British Computer Society and the International Association of Software Architects).
Here’s the reality: Whatever you do will affect how your peers will perceive other Enterprise Architects for years to come. Just read the posts on Reddit. Post after post will put down all architects, but EAs most of all, as people out of touch with the field or losers who cannot write code. Your struggle is not yours alone. Every architect will be judged by your performance.
No pressure.
Another reality of the field: no one will allocate a budget of $50K for you to buy an EA tool and spend weeks or months installing it at the company. Why would they? There’s one user: You. Just use Excel, right?
Choosing a tool for a small EA team is a task that lives within some pretty tight constraints. First off, it has to be cheap. So cheap that you can afford to buy it yourself, or it fits within the tiny budget your department can afford. Carpenters own their tools. Contractors own their tools. Why are we so special?
On the other hand, life gets in the way. When I started as an EA, my children were small and I did not have the cash on hand to blow $1000 for my company to have a decent tool for me to use. That’s why I set the limit to $30 a month or $360 per year.
Secondly, that tiny budget has to cover the actual needs of the job. Otherwise, spending money on a tool is pointless. The tool has to be something you can actually use in your day-to-day work. Any tool that offers a stripped-down feature set as a “trial” version is not doing you any favors. If your tool makes you deliver half-assed results, how will your peers judge your output?
Affordable yet powerful. Believe it or not, there are still EA tools in this category. (see the other article on inexpensive EA tools to see a list). My goal here is to help you choose one.
1. YAGNI: Ya Ain’t Gonna Need It
If it was just a competition about who has the most features, this gets easy fast. The most expensive tools on the Internet have the longest list of features. They can draw diagrams, manage applications, plan your roadmap, communicate your standards, handle architectural decision records, and do your laundry.
I’ll borrow from agile development: YAGNI. You should only pay for the features that you are actually going to use to answer problems that you actually have to solve. This is where your maturity matters. A small team of Enterprise Architects cannot accomplish every function of EA. You don’t have the time, or the bandwidth, or the remit from management.
Here’s the first rule: start with the question you want answered. Seriously. Take pen and paper (remember those?) and write down the first three decisions your EA program needs to make. For example:
- Which applications should we invest in, replace, consolidate or retire?
- Which business capabilities need improvement to hit strategic goals?
- Which programs will need to change if we reprioritize our strategies?
- Which projects achieve or lack the business value to be funded?
- Which architecture records must be reused across several views?
- Could we use AI assistance for evaluating processes, capabilities, or application fitness?
Take the questions to your stakeholders. Ask them which questions matter. In addition to helping you scope the tools, this activity helps your stakeholders get a better idea of what you do.
This step is important. If the team, and your stakeholders, cannot pick a question to answer, don’t select a platform. If you pick more than three questions, you are not tightly scoped enough for a small team. Be thoughtful about this: A question is not an activity. “Create an enterprise architecture repository” is an activity; “Which applications should be retired?” is a question.
2. Decide whether you need drawings or information objects
This distinction eliminates many poor fits.
In a drawing tool, a box is primarily a visual object. The same application drawn on three pages may be three unrelated shapes, and updating one does not necessarily update the others.
In a structured modeling or repository tool, the application is an information object. Its name, owner, lifecycle and relationships can be reused in several views. Change the record once and the views can reflect the change. Buyers ask for this directly: one 2026 public tender for an EA tool required that a single definition of an application, data entity or capability can appear in multiple diagrams without duplication.
Choose drawing software when the artifact is temporary and the visualization itself is the deliverable. Choose structured software when the underlying facts must be maintained, queried, reused or governed.
3. Choose the category that matches the work
| Tool category | Use it when | Check carefully |
|---|---|---|
| Diagramming or presentation software | You need a workshop picture, presentation or occasional map | Reuse of objects, consistency between diagrams, ownership and ongoing maintenance |
| Standards-based modeler | ArchiMate, UML, BPMN or another formal notation is central to the work | Exact notation coverage, validation, exchange formats, collaboration and learning curve |
| Repository or portfolio platform | The same governed records must support repeated views, reports and decisions | Metamodel, permissions, audit, search, integrations, administration and data stewardship |
| Focused decision tool | You need a bounded outcome such as a capability priority, application disposition or benefits map | Scope boundaries, exportability and whether later work will require a broader shared repository |
No category is universally better. Many organizations reasonably use more than one: for example, a formal modeler for solution designs and a portfolio tool for application lifecycle decisions.
4. Test the data sources and maintenance burden, not only the demonstration
Ask who will keep each important data object up to date after the initial import. A polished demonstration often assumes complete data, dedicated administrators and reliable integrations. Your small team may not have the time or bandwidth to keep the data current.
Consider if the tool can load data in from Excel spreadsheets (Typically CSV format) so data can be imported from other tools. Also ask if the tool can export data in multiple formats as well, for integration, backup, or presentation. You do not want your data to become ensnared in a tool that doesn’t allow it back out.
For every proposed data object or relationship, identify:
- the source;
- the owner;
- how often it changes;
- how it will be reviewed;
- what decision becomes worse when it is stale; and
- whether “unknown” can be recorded honestly.
A small well-maintained model is more useful than a comprehensive repository nobody trusts.
5. Verify the complete cost of the qualifying edition
Compare the edition you can actually buy and whether that edition meets your team’s needs. Consider:
- monthly or annual price;
- whether the price is per editor, per named user or a flat organizational fee;
- minimum seat or spending commitments;
- viewer and contributor charges;
- required modules;
- staff training time;
- product documentation and support;
- multi-device support and accessibility;
- single sign-on capabilities; and
- data migration costs.
For those products that are multi-tenant solutions, consider:
- data security and SOC2 compliance;
- penetration testing;
- government regulations and internal policies on the location of enterprise data; and
- what happens to your data if the subscription ends.
For those products that are internally hosted, consider:
- hosting and backup costs;
- ease of deployment, updates, and maintenance patches; and
- activity of maintenance (especially for FOSS).
Free and low-license-cost software can still be expensive to operate. Conversely, a browser-based SaaS can be set up quickly and is often economical to use since it removes infrastructure and administration work.
For current products with an edition below US$395 per user per year, see our low-cost enterprise architecture tools comparison; for business architecture specifically, see our low-cost business architecture tools comparison. Useful EA publishes both comparisons and we try to keep them up to date.
6. Run a decision-shaped pilot
Do not test a tool by reproducing the vendor’s sample model. Use one real, bounded question and a representative slice of your own data.
For example, a small application-portfolio pilot could use 20 to 30 applications supporting one business area. Test whether the team can:
- import or enter the records without extensive cleanup;
- distinguish confirmed facts, estimates and unknowns;
- connect applications to the capabilities and dependencies needed for the decision;
- identify overlaps or risks without treating the tool’s output as proof;
- produce an artifact stakeholders can review; and
- export the records in a usable format.
Record the time required to prepare, maintain and explain the result. That is part of the cost. The application portfolio management starter guide describes the minimum data for a pilot like this.
7. Use a small-team selection scorecard
Score each candidate from 0 to 3, but keep hard requirements separate. A high total cannot compensate for a missing mandatory security, deployment or export requirement.
| Criterion | 0 | 1 | 2 | 3 |
|---|---|---|---|---|
| Supports the first decision | No | Indirectly | Mostly | Directly |
| Information can be maintained | Unrealistic | Heavy effort | Manageable | Clear ownership and workflow |
| Outputs work for stakeholders | Unusable | Major rework | Minor rework | Ready to use |
| Data can be imported and exported | Locked or manual | Limited | Adequate | Open and practical |
| Collaboration and governance fit | Missing | Workarounds | Adequate | Strong fit |
| Administration fits the team | Excessive | Difficult | Manageable | Light |
| Total cost is clear | Unknown | Material gaps | Mostly clear | Transparent |
Document the evidence behind each score. “Easy to use” and “AI-powered” are not evidence unless the pilot shows how they improve the team’s actual work.
Where does Useful EA fit?
While I built Useful EA and sell access through my company, CTO Resources LLC, I tried to make this buyer’s guide as neutral as I could. Useful EA is a set of focused browser tools: Capability Modeler, Application Portfolio Manager, Benefit Dependency Network, EA Maturity Assessment and a metamodel-neutral Architecture Repository. Useful EA is tailored to fit a small team, a consulting engagement, or a course that needs a straightforward architecture workflow without operating a large platform. Every tool exports to CSV. The other four tools also export to PowerPoint, and the Architecture Repository exports JSON. At the time of this writing the tools are in beta, and accounts are free during the beta; see pricing for details once we go live.
We do not assert any claim that the Useful EA tools are appropriate for every team and situation. Caveat Emptor.
A practical final rule
It may sound obvious but my advice is to choose the least complicated tool that can preserve the facts and relationships you need to answer your key questions, and that the team can keep current after the first enthusiastic month.
If a diagram is the deliverable, use a diagramming tool. If conformance to a notation is the work, use a formal modeler. If the same records must support repeated questions, use structured repository or portfolio software. Always test the tools against the outcome you need to produce.
Sources
Vendor documentation is cited as context for how the market describes these patterns, not as evidence about Useful EA.
- Business Architecture Guild: BIZBOK Guide v10 glossary (2021) — defines a business architecture tool as software that facilitates capturing, maintaining, communicating and sharing blueprint artifacts; an older source, used for a stable definition
- Trans-Caledon Tunnel Authority: Request for Bid 094/2025/EWSS/EATOOL/RFB, Enterprise Architecture Tool (issued 20 April 2026) — a public specification asking for a configurable metamodel, relationship mapping, role-based access control, capability mapping, application portfolio management and object-level reuse; one buyer, not the whole market
- Useful EA: Low-Cost Enterprise Architecture Tools Compared — product, category and price information as of a specific date