PowerDesigner and ER/Studio Consultancy and Training Specialist at a tech services company with 1-10 employees
Real User
2020-09-02T10:23:23Z
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
2020-07-23T11:17:18Z
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
Community Manager
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 :)
Enterprise Architecture Management (EAM) solutions are designed to help organizations effectively plan, design, and manage their enterprise architecture. These tools provide a comprehensive view of an organization's business processes, IT systems, and their relationships, enabling better decision-making and alignment between business and IT strategies.
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 :)