PowerDesigner and ER/Studio Consultancy and Training Specialist at a tech services company with 1-10 employees
Real User
Sep 2, 2020
I agree with Mark McGregor, you do need to present the vendor with your own use cases, and you also need to think about more than what you're capturing in the tool. I've been into a bank that had a process management tool, an enterprise architecture tool, and a data modelling tool. They were all purchased by different parts of the bank, the purchasers didn't consider anybody's requirements but their own, and it wasn't possible to pass information between the tools. This led to what I like to call a 'Metadata Archipelago'.
Director Product Marketing at a tech services company with 1,001-5,000 employees
Real User
Jul 23, 2020
Your prime question was, "What tips for choosing a suitable tool", which needs to be answered before considering what to ask a vendor. Vendors are very good at shaping your problem to fit their tools.
So, step one is to ask yourself "Why do you want a tool", "What will be the benefits of having a tool in place", "Are there other situations where the tool could add value".
With this information, you can start to build out your Use Cases, and quantify the value in real money terms. So not just "save a week", but "save $5,000 per quarter etc.) By summing up all these numbers you will get a better idea of the true value of a tool, and it will guide what budget might be available. Try to use a 7 or 10 to 1 ratio of cost vs benefit. This should make it easier to get budget allocated.
When speaking with vendors, ask them to demonstrate how to use the tool to address your use cases, not their examples. Ask them to show starting from a blank repository and with zero customizations - often the demos are done by slick presenters and lots of customizations that you won't get out of the box.
Lastly, focus on the outputs and reports more than the creation, and seek references to validate how long it takes to get those benefits.
Community Manager at a tech services company with 51-200 employees
Real User
Jul 26, 2020
@Mark McGregor Thanks, this is very useful. I agree that it's important to first define what problem you need to solve with the tool, which should then guide what you ask the vendor. Great tips :)
Find out what your peers are saying about SAP LeanIX, Quest Software, MEGA International and others in Enterprise Architecture Management. Updated: January 2026.
Enterprise Architecture Management (EAM) is a strategic discipline that outlines a comprehensive framework to manage and align an organization’s structure, processes, and information systems to achieve its goals and objectives efficiently.Enterprise Architecture Management provides organizations with the methodologies and tools necessary to effectively map out their current structures and future states. This discipline helps navigate the complexities of aligning IT strategies with business...
I agree with Mark McGregor, you do need to present the vendor with your own use cases, and you also need to think about more than what you're capturing in the tool. I've been into a bank that had a process management tool, an enterprise architecture tool, and a data modelling tool. They were all purchased by different parts of the bank, the purchasers didn't consider anybody's requirements but their own, and it wasn't possible to pass information between the tools. This led to what I like to call a 'Metadata Archipelago'.
I haven't compared or selected EA tools but I have done it for data modelling tools - there's a summary of basic tool requirements at https://metadatamatters.com/services-and-solutions/tool-evaluation/dm-tools/ - most of these would also apply to EA tools (the 'core modelling' would be different)
Your prime question was, "What tips for choosing a suitable tool", which needs to be answered before considering what to ask a vendor. Vendors are very good at shaping your problem to fit their tools.
So, step one is to ask yourself "Why do you want a tool", "What will be the benefits of having a tool in place", "Are there other situations where the tool could add value".
With this information, you can start to build out your Use Cases, and quantify the value in real money terms. So not just "save a week", but "save $5,000 per quarter etc.) By summing up all these numbers you will get a better idea of the true value of a tool, and it will guide what budget might be available. Try to use a 7 or 10 to 1 ratio of cost vs benefit. This should make it easier to get budget allocated.
When speaking with vendors, ask them to demonstrate how to use the tool to address your use cases, not their examples. Ask them to show starting from a blank repository and with zero customizations - often the demos are done by slick presenters and lots of customizations that you won't get out of the box.
Lastly, focus on the outputs and reports more than the creation, and seek references to validate how long it takes to get those benefits.
@Mark McGregor Thanks, this is very useful. I agree that it's important to first define what problem you need to solve with the tool, which should then guide what you ask the vendor. Great tips :)