erwin Data Modeler by Quest Reviews

The use cases are for our enterprise data warehouse where we have an enterprise model being maintained and we have about 11 business-capability models being maintained. Examples of business capabilities would be finance, human resources, supply-chain, sales and marketing, and procurement. We maintain business domain models in addition to the enterprise model.

We're on-premise, a virtualized data center. We're running this as client-server, the client being PC-driven and the back-end for the erwin Mart is virtualized Windows Servers.

Collaboration is very important because it's important to have an enterprise-view of data, as opposed to a project-specific view of data. Using the business capability models, we're able to augment those models based on a project-by-project implementation. And each of those implementations goes through a review process before those business capability models are finalized. That adds a lot of value in data consistency and data replication when it comes to the models. We can discover where there is duplication and inconsistency. It also helps with the data descriptions, the metadata, about the purpose of using certain designs and certain descriptions for tables and patterns, for the data elements. It helps enforce the data standards that we've adopted.

Each data modeler has their own way of designing the models, but no modeler is starting from a blank sheet of paper. By reverse-engineering models, and by creating models that are based off of popular packages — for example SAP or JD Edwards or Workday — you're able to construct your own data model and leverage the metadata that comes along with the application models. You are able to integrate the data based on these models.

These modeling tasks deal with applications, and some of the applications are mission-critical and some are not. Most of the applications are not; it's more an analytical/reporting nature that these models represent. The models are key for data discovery of where things are, which makes it more transparent to the user.

The solution's code generation pretty much ensures accurate engineering of data sources. If you're reverse-engineering a data source, it's good to have the script for examination, but it's valuable in that it describes data elements. So you get accurate data types from those. It cuts down on the integration development time. The mapping process of source-to-target is a lot easier once you know what the source model is and what your target mapping is.

The most valuable features are being able to visualize the data in the diagrams and transform those diagrams into physical database deployments. These features help, specifically, to integrate the data. When the source data is accumulated and modeled, the target model is in erwin and it helps resolve the data integration patterns that are required to map the data to accommodate a model.

Also, collaboration around maintenance and usage is associated with data model development and expertise coming from a review process, before the data is actually deployed on a platform. So the data models are reviewed and the data sources are discovered and profiled, allowing them to be mapped to the business capability models.

The modeling product itself is far and above anything else that I've seen on the market. There are certain inconsistencies when it comes to keeping up with other platforms' databases in the reverse-engineering process. It should also support more database platforms.

There should also be improvements to capture erwin models in third-party products, for example, data catalogs and things of that nature, where the vendors have to be more aware of the different releases of product and what they support during that type of interaction. Instead of being three or four releases behind from one product to another, the products should become more aligned with each other. So if you're using an Erwin model in a data catalog, you should be able to scan that model based on the level of the Erwin model. If the old model is a certain release, the capture of that should be at the same release.

I've been using erwin Data Modeler since 2014.

There haven't been too many problems with stability so we're pretty pleased with the stability of it. Once in a while things may go awry but then we open up a request.

We haven't had any issues with scalability. Licensing is very supportive of the scalability because of the type of license we use, which is concurrent. We don't anticipate any issues with scalability: not in terms of the number of users and not in terms of the scalability of some of the models. 

Some of the models are quite large and therefore our data modeling framework helps us because we're able to have multiple models that are loosely coupled and make up our enterprise model. So we're not maintaining one model for all the changes. We're maintaining several models, which makes it a lot easier to distribute the scalability of those models and the number of objects in those models.

Technical support has been pretty good. We've had licensing issues. There have also been some bugs that have been repaired and there have been some issues with installation. But all in all, it's been pretty good.

We did not have a previous solution.

The initial setup was pretty straightforward. 

The only thing that we would like to see improved would be having the product support a silent install. If we were able to deploy the product from a predefined script, as opposed to a native installation, such as on a Windows platform, that would help. We are such a large company that we would prefer to package the erwin installation in one of our custom scripts so we could put it in our application store. It's much along the lines of thinking of an iPhone or an Android application in an application store where you're able to have it scripted for deployment, as opposed to installing it natively.

Our deployment took just a few months. We constantly go through deployments as new people come onboard, especially consultants. Usually, with a consultant engagement using a data modeler, you have to be able to deploy the software to them. Anything that helps them out in that process is good.

Our deployment plan was to test the product in a development environment, and have people trained through either self-service video instruction or through on-the-job-training. We were then able to be productive in a production environment.

ROI is hard to measure. If we did measure it, it would be more of a productivity jump of around 10 percent and would also be seen in data standardization. All of these numbers are intangible. There is more of an intangible benefit than a tangible benefit. It's hard to really put a dollar on some of the data governance processes that erwin supports.

Standardization is very difficult to put a price tag on or to estimate its return on investment. But we do have data standards; we are using standard names and abbreviations and we do have some standards domains and data types. Those things, in themselves, have contributed to consistency, but I don't know how you measure the consistency. When it comes to enterprise-data warehousing, it's a lot easier for end-users to understand the context of data by having these standards in place. That way, the people who use the data know what they're looking at and where it is. If they need to look at how it's designed, then they can get into the product a little deeper and are able to visualize the designs of some of this data.

The accuracy and speed of the solution in transforming complex designs into well-aligned data sources absolutely make the cost of the tool worth it. erwin supports the Agile methodology, which tends to stabilize your data before you start your sprints and before application development runs its course.

We pay on a one-year subscription basis.

The biggest lesson that I've learned in using this solution is to have a data governance process in place that allows you to use erwin more easily, as opposed to it being optional. There are times when people like to do design without erwin, but that design is not architected. It pays to have some sort of model governance or data governance process in place, so models can be inspected and approved and deployed on database platforms.

We use it primarily for first drafts of database scripts, both in a relational database environment and other types of environments. The models represent those physical implementations. The database scripting part is heavily modified after the first draft to include additional features of those database platforms. So we find erwin DM less valuable through that and we find it more valuable creating initial drafts and reverse-engineering databases. It cuts development time for us to some degree, maybe 10 percent, but all in all, there are still a lot of extensions to the scripting language that are not included with the erwin product.

In our company, there are about 130 users, globally. From time to time the number varies. Most of those users are either the data modelers or data architects. There are fewer enterprise data architects. The other users would just be erwin Web Portal users who want to have a little bit of an understanding about what's in a data model and be able to search for things in the data model. For deployment and maintenance of this solution we have about two infrastructure people, in an 8 x 5 support model.

The easiest way of exposing or sharing the model to all the users at the enterprise level is the feature I found to be valuable in the solution.

They should merge all those products because apart from the Mark Server, they have the Web Portal, which requires a separate installation and license. And it's not easy to maintain, but very easy to use. So you need additional resources such as memory, unlike if they merge those Web Portal and Mark Server, which would be a great solution.

I think they should be more open to or ready to be agnostic to any databases, such as MongoDB. Any database available in the market should be ready in their drivers because I don't think they can be ready. So all the popular databases like Oracle, MySQL, Microsoft, and SQL Server, but I haven't seen any connector in Cosmos DB SQL, so it should be in the big data or cloud solution.

I have been using erwin Data Modeler for a year.

It is not a very stable solution. I rate the stability five out of ten.

It is a scalable solution. Around 20 users are using the solution presently. I rate the scalability an eight out of ten.

The technical support team is fine.

Previously, we used SAP PowerDesigner. One of the primary reasons we switched to Data Modeler is that we need to expose our models so that the user can access them very efficiently and time-bound. If I develop a model and if it's a room, I can easily push that model into a web portal. The users can study and use it from there, unlike in the previous SAP PowerDesigner. You need to export an image or picture file or JPEG or PNG; then you have to share on SharePoint and upload it in Confluence of this. That is a very tedious way of sharing the model. The stability of the solution needs improvement.

The initial setup is straightforward. The solution is deployed through the desktop version available for Data Artifacts. There is also a repository, the data node, and a web portal which is the application or web application for data analysis and other users interested in starting the model. I did all the deployment.

The pricing of the solution is cheap. I rate the pricing a five out of ten.

SAP solution is more stable compared to Data Modeler and fits our requirements as an enterprise team.

I rate the overall solution a seven out of ten.

We use the erwin Data Modeler tool to document conceptual, logical, and physical data design. Business data models capture the understanding of the data from a business perspective, which can then drive physical design to ensure data is represented and used correctly.

The automated generation of the DDL ensures that the data store looks exactly as the data design. It also ensures that the standards that are governed are followed and implemented successfully.

We use the diagrams and data dictionary capabilities to help users understand the data environments, as well as how the data relates to each other. We'll use the naming standard master file to govern and ensure that we have consistent naming and abbreviations across and within data stores. We use the forward engineering templates to standardize and govern the generation of the data definition language that is used to actually make the changes to the data stores. We also use the Compare capability to ensure that we have up to date production data models. And we are looking forward to the integration of the Data Modeler metadata with the data intelligence suite in R2.

The visual data models for helping to overcome data source complexity and enabling understanding and collaboration around maintenance and usage are excellent. A picture speaks 1,000 words. Seeing a picture that shows you how the data relates to each other helps you better understand what the data is and how to use it. Pairing that information with a dictionary, which has the definitions of the tables, columns, the entities, and attributes, ensures that the users understand what the data is so that they can use it best and most successfully.

Its ability to compare and synchronize data sources with data models in terms of accuracy and speed for keeping them in sync is excellent. 

We don't typically use the configurable workspace and modeling canvas because while the platform allows for the flexibility to dynamically include multiple colors and multiple themes, feedback from business users is that the multiple colors and themes can become overwhelming. When you do that, you need to include a key so that people understand what the colors mean.

Its ability to generate database code from a model for a wide array of data sources cuts our development time. By how much depends on the number of changes that are required within the data store. It is certainly better to automate the forward engineering of the DDL creation, rather than having someone manually type it all out and then possibly make a human error with spelling irregularities.

Its code generation ensures accurate engineering of data sources. It decreases development time because it's automated.

I would like to see the reporting capabilities be more dynamic and more inclusive of information. The API is very sparsely understood by people across the user community.

I would also like to see a greater amount of integration with the erwin Data Intelligence Suite and the erwin Web Portal for the diagram delivery. That would be beneficial to all.

I have been using erwin for twenty years. 

It's very stable, especially having been available for use for so many years.

It is scaling well to include the new data structures, rather than being stagnant and only continuing to support the older DBMS types.

We have over 100 Data Modelers in my company and the users of the metadata go into the 1,000s.

We have an administrator who is responsible for the software upgrades, we have a governance community in the Center of Excellence, and we have the actual Data Modelers themselves who provide the delivery of the physical data models. We have data architects who create business, conceptual, and logical data models. And then, of course, we have our developers who use the data model information to understand the code that they are writing. We also have the business users who use the diagrams and the data dictionaries to understand the data so that they use it correctly.

Data Modeler is being used very extensively. We are considered power users within the community of users.

As new applications are developed, we may or may not need new licenses for erwin Data Modeler.

I have used SILVERRUN, which is a very old tool and actually has Sunset. I have also used SAP Sybase PowerDesigner. The primary reason for using PowerDesigner over erwin Data Modeler for that decision was that we were able to program the PL/SQL right into Sybase PowerDesigner. At the time, it had the capability to order the run of the PL/SQL. So the Sybase PowerDesigner would not make the changes to the database via the DDL, but it also generated the PL/SQL code that moved the data from source to target. That's a capability that erwin Data Modeler has never had. I don't know if it is on the roadmap for inclusion in the future, but I also do not see it as a requirement for erwin Data Modeler going forward because there are many ETL tools out there readily available.

I've also used IDERA. The interesting feature about IDERA that differentiates it from erwin Data Modeler is that the model repository actually separates the logical data models from the physical data models. Whereas erwin is basically the flip of a switch. It's not a true logical model, it's a logical representation of the physical data model.

I think the other thing that sets erwin Data Modeler apart is the model Mart repository, which protects a company's intellectual property within the data models and makes them available across the company so that the information is shared with anyone who has an erwin Data Modeler license. That was not available in SILVERRUN. It was also not available when I used PowerDesigner at the time. It was about 15 years ago for PowerDesigner. It is available for IDERA.

I find the setup straightforward. It is very easy to install. It took minutes.

We have seen ROI.

The reusability of some of the information within erwin Data Modeler, coupled with the capability to govern the information such as the data domains, the naming standard master file, degeneration of the DDL, every piece of automation ensures that there is consistency across and within data stores, and reduces the time to deliver the information because of the automation and governance built into the tool.

Whether or not the accuracy and speed of the solution and transforming complex designs into well-aligned data sources make the cost of the tool worth it would be a judgment call. I do think it is worth it. But of course, in this day and age where people are offshoring all of their work trying to save money, makes one consider the cost of any investment.

I think that the pricing is reasonable. It has called Concurrent licensing, where you can have a number of people share an erwin license. I think that that pricing is a little bit high, but that is a personal opinion.

The biggest lesson that I've learned is actually with a lack of data modeling. We have teams who have complained that data modeling takes too long. They would rather have developers manually code the DDL, which creates a lot of mistakes, increases the backlog, and increases not only the time to delivery but the cost to delivery. There is a lack of understanding of the agile methodology around data modeling and the incorporation of the emergent design happening in the scrum teams with the intentional design of the data architect creating a data model. Given an opportunity to follow the correct path and perform data modeling, we have seen a significant return on investment with decreases in delivery time and decreases in project cost.

I would rate erwin Data Modeler a ten out of ten. 

We use erwin to design conceptual, logical, and physical data models for new projects. We use a Forward Engineering tool to forward engineer data models into new database structures. We use the reverse engineering tool to bring databases into data models and erwin. We also generate HTML reports of the models to share with our customers.

Whenever we do have a new project that requires a new approach, we do try using erwin for it. For example, if we have an XSD message file, then we would try to see if there is a way to get that into erwin for better visibility of the structures that we have to work with.

The product has helped us standardize our data modeling efforts across the enterprise in regards to visuals and naming. We also use the Mart Tool from erwin, which allows us to store our data models in a centralized repository, which gives everyone visibility on what is out there and how it is all related.

We discuss existing and new business requirements with business users, data architects, and application developers to figure out how to capture and visualize concepts in their relationships. One thing we do have standard in all of our models is that we use the information engineering notation. This is standard across our enterprise. We do use a diagram hierarchical layout to help visualize things, especially when we reverse engineer a database, as we want to have some sort of a clear visual layout of things.

We find a few of erwin tools most valuable:

• The Bulk Editor lets us easily make a lot of similar changes within our data model.
• We use the Forward and Reverse Engineering tools to help us speed things up and create things that would have to be done otherwise by hand. E.g., getting a database into a data model format or vice versa.
• The Report Designer is extremely useful because we can create reports to share with our business users and have a business discussion with them on how things work.

We find the text manipulation through the Bulk Editor to be extremely helpful. There were times where we had a set of entities which were not following our standards. With the help of the Bulk Editor, we were able to form those names with a few Excel formulas to follow our standards.

The Reverse Engineering functionality is good and easy to follow. It works really well. For the most part, we have been able to get any database to work with our data model format.

We quite heavily use the templates that exist to apply our standards to the data models created by our data modelers. We are able to use the templates to apply things like Naming Standards, casing on names, and colors to all our data models without having to be on top of it.

Complete Compare is not user-friendly. For example, the save known changes as snapshot does not work as expected. We are unable to find the exported files in our workstations at times. Complete Compare is set up only to compare properties that are of interest to us, but some of the differences cannot be brought over from one version of the model to another. This is despite the fact that we are clicking to bring objects from one place to another. Therefore, it's hard to tell at times if Complete Compare is working as intended without having to manually go into the details and check everything. If it could be redesigned to a degree where it is easier to use when we bring things over from one site to another and be sure that it's been done correctly, that would be nice to have. We would probably use the tool more often if the Complete Compare were easier to use.

The client performance could be improved. Currently, in some cases, when we delete entities it causes the program to crash. Similarly, for Mart's performance, we need to reindex the database indexes periodically. Otherwise browsing through the Mart, trying to open up or save a data model takes unusually long.

There are several bugs we discovered. If those were fixed, that would be a nice improvement. We encounter model corruption over time, and it is one of those things that happens. There is a fix that we run to repair this corruption by saving the model as an XML file or to the Complete Compare tool. If this process could somehow be automated, having erwin detect when a model is corrupted and do this process on its own, that would be helpful.

There are several Mart features that could be added. E.g., a way to automatically remove inactive sessions older than a specified date. This way we can focus on seeing which users have been utilizing our central repository recently, as opposed to seeing all of what happened since five years ago. This would be less of a problem if the mart administrator did not have trouble displaying all of the sessions.

On the client side, there are some features that would come in handy for us, e.g., Google Cloud Platform support or support for some of the other cloud databases.

If we had a better way to connect and reverse engineer the databases into data models, that would help us.

Alter scripts can be troublesome to work with at times. If they can be set up to work better, that would help. On the Forward Engineering side of things, by default, the alter syntax is not enabled when creating alter scripts. We strongly believe this is something that should be enabled by default.

On the Naming Standards (NSM) side of things, there is a way in erwin to translate logical names into physical names based on our business dictionary that we created. However, it would be nice if we could have more than one NSM entry with the same logical element name based on importance or usage. Also, if erwin could bring in the definitions as part of the NSM and into a model, then we could use those definitions on entities and attributes. That would be beneficial.

We have been using it for at least 15 years, a very long time.

Overall, the server is mostly stable. After we implemented the reindexing fix on our database, everything works pretty well. On the client side, it is mostly stable, but sometimes it's not. There are certain actions that cause the client to crash. This has been much less of the case since we switched to the 64-bit version of erwin, which has been a great improvement.

We have found erwin’s code generation ensures accurate engineering of data sources. We haven't seen any issues. We pass our code off to DBAs to implement. Therefore, the DDL that we generate gets passed up to the DBAs who will add some physical features and may add some performance indexes, then we will reverse engineer that information and have that in our data models.

For our bug related issues, we have been given the recommendation to upgrade to the latest version. We are in process of doing that and will see how that works out. We also submitted some other things through erwin's idea board. There are a few issues that we haven't reached out to erwin on yet.

Currently, we have a team of people who take turns helping out other users. They figure out how to do different things. If there is a server side issue, we do have several people as well who will look into that. In the past, we did manage a lot with one person. However, we realized it was quite an undertaking. You either need one fully dedicated person to look into this or several people to take turns.

We have a Windows Server and a SQL Server database. Therefore, we have SQL Server dedicated staff to help us with any SQL Server issues and Windows support staff who help us with any Windows issues. We don't generally have any issues with erwin. From a technical support side, we do have a support staff if we were to run into any issues. Our team of five data modelers are pretty well-experienced with both the tool, Mart, and any sort of communication issues that we might have to deal with, e.g., if the SQL server went down, then these folks would be the liaisons to the SQL Server team.

Given our mostly constant user base and constant growth of new data, our impressions of the scalability are great. Currently, we have about 2000 models in the Mart repository. Reaching this capacity has slowed down interactions with the Mart as opposed to when we had a fresh Mart. When we first started using the Mart server, it took about two seconds to open things like the Catalog Manager or Mart Open dialogue. Now, it takes around 10 seconds to do that part. For the most part, it seems to be pretty scalable. We've been able to continue using the tool given our large volume of models.

There are 35 to 40 users plus some occasional DBAs who use it to tweak any of the DDLs that they might want to pull.

We are able to develop our data models for mission-critical tasks with the solution’s configurable workspace and modeling canvas. We have 20 enterprise data modelers. We are mostly working on the standard RDBMSs: SQL Server, Db2, and Oracle. We also use some cloud technologies, like GCP, Azure, and Couchbase. Then, there are approximately another 15 data modelers which work exclusively in Oracle Business Intelligence from a data modeling aspect. This is for dimensional repository and data warehouse stuff. Therefore, we have about 35 to 40 data modelers in our organization for pretty much every major project that passes some sort of funding gate. Anything that is mission-critical for our organization will come through one of our two managers, depending on whether it's relational modeling or dimensional modeling. All of the database designs come through these two groups. There are some smaller database designs which we may not be involved with, but all of the critical application work comes through these teams. In regards to focusing on mission-critical tasks, we really wouldn't be able to do it without a tool like erwin. Since we are all very well-trained in erwin, it is the tool that we leverage to do this.

Erwin generates the DDL for all our projects. We rely on the tool for accuracy as some of our projects have hundreds of entities and tables.

When it is bug related, we get a bug fix or are told to upgrade to the latest version. This has worked out in the past. Where it is question related, we have been pretty happy with their Tier 1 support's responses. We will receive some sort of a solution or suggestion on how to proceed in a very timely manner.

We would like support for JSON reverse engineering. That is something which is completely missing, but is something we have been working with quite often recently. If erwin could support this, that would be incredible.

On the client side, the setup was mostly straightforward. It was a matter of going through the installer, reading a little bit, then proceeding to the next step. In the end, the installation was successful.

On the server side, it has been a bit more complex. We did have some documentation provided by erwin, but it wasn't fully intuitive nor step-by-step. Some things were missing. It was enough to get started, then figure things out along the way.

On the client side, it takes five to 15 minutes to do the installation or upgrade to a newer version. On the server side, from the moment we backed up everything on the server and disabled the old mart application, the upgrade took about two hours. If you include all the planning, testing, and giving support users enough time to do everything, the upgrade took about three months. In general, these are the timeframes we experienced through in the past.

We simply used the documentation provided by erwin. Between the few of us that worked on the upgrade at our company, we had enough of a technical background to be able to figure out things out on our own. There were five to 10 people who worked on this initially:

• We had one person who helped with the database side of things.
• We had another person do everything on the application server.
• To test out of the different features of erwin in the new version and ensure that the existing features worked as intended, we involved several additional people from our team.

We go through a pretty rigorous testing procedure when we bring in a new release of any software like this. Although it's not affecting customers directly, it certainly affects 35 to 40 people. Therefore, we want to ensure that we do not mess them up by not having something work. Normally, we go through this with any product. We first install it on a test environment and have a bunch of folks jump on. This is to ensure everything is working the way we want and work out all the kinks when setting up the production server before we move it into production.

It is an invaluable tool for us. It has been part of our data governance process in regards to database design for at least 15 years.

The amount of time saved is proportional to the amount of changes in the databases that we are implementing at any time. The more code we generate (because the model is bigger), that saves us more time because we don't have to write everything up manually and check to make sure that the code is correct. If we had to give a number, this saves us anywhere from minutes to hours of work. The time frame depends on the data modeler, as some data modelers generate more code than others. Therefore, it could be on a daily, weekly, or monthly basis and depends on the project. Some projects are in maintenance mode and not going through a lot of changes. It is way easier to use this solution because then we have a data model to reference for something that was developed approximately two months ago and somebody can just pick it up versus if someone had to generate changes to a database without a data modeling tool.

The tool certainly makes the data modeling staff more productive than if they did not have a similar tool. Without erwin, our jobs would be a lot more tedious and take a lot more time.

We evaluated IDERA two years ago and decided to stay with erwin mostly because the staff is mostly familiar and comfortable with the tool. We think that was the overriding factor. The other thing would be converting from erwin to IDERA would be a major undertaking that we just weren't prepared to do.

The fact that it can generate DDL is a major advantage over something like Visio, where you can also do a database diagram. We don't have a Visio version that would generate DDL, so I'm assuming it doesn't, and any tool that can generate code for database definition will certainly have an advantage over a product that doesn't.

I would certainly recommend this product to anyone else interested in trying it out. The support from the vendor is great. The tool overall performs well and is a good product to use.

Having a collaborative environment such as the one that erwin provides through the Mart is extremely beneficial. Even if multiple people aren't working on a single model, it's nice to have a centralized place to have all the models. It gives us visibility and a central place to keep everything in one place. Also, it supports versioning, which allows us to revisit it at different points in time to go back to in the model, which is really helpful.

We do not use erwin to make changes directly to the database.

We have no current plans to increase our usage of erwin other than adding more models.

We would rate the solution overall as an eight (out of 10).

I use the solution for reverse engineering as well as forward engineering. I do logical and physical modeling, and some of what I'm doing right now is reverse engineering from actual databases because they have no diagrams. The solution helps me diagram the current and help me design the future.

Forward engineering, DDL generation, reverse engineering, and reporting are the most valuable features of the solution.

The solution's model mark could be better because it crashes sometimes.

I have been using erwin Data Modeler by Quest for many years.

erwin Data Modeler by Quest is a stable solution.

I rate erwin Data Modeler by Quest a nine out of ten for stability.

To add users, you have to start using the model mark, which is not great. I rate erwin Data Modeler by Quest a seven out of ten for scalability.

The solution’s technical support is good.

Positive

I have previously used IDERA ER.

The solution’s initial setup is easy.

I have seen a return on investment with the solution because I can't do my work for my company without it.

erwin Data Modeler by Quest is an expensive solution.

Before choosing erwin Data Modeler by Quest, I evaluated PowerDesigner. I chose erwin Data Modeler by Quest because it has the most features I might need in the future, and the report writing is really good.

I am using the latest version of erwin Data Modeler by Quest. I recently built a data model for integration with another software product that we're going to purchase. I did it really fast with erwin Data Modeler by Quest. If I didn't have the solution, I couldn't have done that, and I couldn't have shared the results.

I would recommend the solution to other users.

Overall, I rate erwin Data Modeler by Quest ten out of ten.

Our primary use is for doing database designs on just about any platform. The main users are dedicated data architects, while we also have development team staff using the tools to review models. Additionally, our database admins access the solution for implementing the Data Definition Language (DDL).

The solution is excellent in providing a visual representation of a database and can generate DDL for implementing changes. We use DDL for logical purposes to review with business people, ensuring they have the required fields for processing. We also use it as a data dictionary for the physical data model to understand all the purposes of the terms. This helps us map the logical and physical terms with the business definition to understand our data.

Data Modeler is straightforward to use and fulfills all our requirements. 

Although Quest Software has made tremendous strides in recent years, they need to evolve more in the big data arena; erwin Data Modeler could use a little more work when it comes to big database designs.

We've been using the solution since the 90s. 

The product is very stable. 

The platform is highly scalable; we use it for our entire enterprise data architecture. 

The tech support is pretty good, but there's always room for improvement, so I rate them eight out of ten.

Positive

Our initial setup was over 20 years ago, but I know it to be almost effortless; it's a basic software installation that takes about five minutes.

Regarding maintenance, there are occasionally new versions and releases, and we have dedicated data architect teams that coordinate so every team upgrades simultaneously.

We've continued to use the product for many years and compared it with others on the market. The pricing is reasonable considering what the solution offers and what we pay. There are cheaper tools, but they may not be as robust and easy to use, so it's worth the money.

I rate the solution nine out of ten.

My advice to those considering the solution is to use dedicated data architects; when you give this type of product to development teams, there can be issues around creating and following standards, which is essential for data model integration. You don't want different teams defining the same types of columns with varying lengths, like dollar amounts. If the entire company agrees that the dollar amount field is 18 digits long and two digits to the right of the decimal place, then you're consistent. If different teams disagree, data can't be transferred from one database to another without truncation. Having a centralized team that enforces standards is critical.

We are using it for a very specific use case, and it works pretty well for us. We do all of our database modeling based on this tool, and it is a repository of all data models in our business intelligence ecosystem. The logical representation of our metadata and anything that is created in a database, such as tables, is in it. 

It is an on-prem workgroup. We have a workgroup server that hosts our model.

We utilize it for its cross-database capability and logical representation of the data model. We have recently started to use its collaboration features, and we also use it to define all our relationship constraints and referential integrity within our data model. So, a lot goes out of it.

It has standardized our practices. For example, all customer-related entities and attributes have to follow a certain naming convention. It has helped in standardizing the process of creating our data models so that when we go and explore the data, we can combine them in a way in which we are confident of producing the right results. It has made a lot of difference in terms of naming standards, processes around our metadata, and the schema in which we create a database. We have a proper template to put the information through a well-structured data model. It helps users in getting the maximum value of the information that is available in the BI ecosystem. erwin Data Modeler makes it very simple and easy to navigate our very complex data.

Its visual data models are very good and helpful for overcoming data source complexity and enabling understanding and collaboration around maintenance and usage. We have a complex business environment where we have retail and supply chain space for distribution. There are a lot of cases where we use the models for customer promotions and events and loyalty systems. Different data modelers can do their own subject areas, and then they can bring them together in a workgroup workspace. It has allowed us to collaborate and distribute the data modeling work. Previously, it used to be very single-threaded. Now, a lot of different teams can run their own modelers, and then, later on, integrate them, which is very useful. It is also very useful in the database migration process. You can take a logical model and seamlessly transfer it over to the database. That's very useful as well. 

We use its modeling support for Snowflake Cloud. We don't use it in any special way. We use it the way we use an existing on-prem database. It just needs to follow Snowflake conventions, which it does. We have a standard logical model that can then translate to a physical model for any database we choose, and that's where erwin has been very helpful. We can set those naming standards, and it also does logical to physical translation seamlessly. This support for Snowflake is helpful. We have enough help to port our model from DB2 to Snowflake in terms of model creation. It has proven very helpful that way.

It can create table structures across a wide variety of sources, which is very useful for us. It cuts the development time of our database code quite a bit. Otherwise, we would have to rely on Excel sheets. Currently, our average project size is anywhere from 3,000 to 4,000 hours, and out of that, we spend around 5% on data modeling. If we didn't have this tool, it will take almost twice more time for any project.

It allows us to create logical data models. We can represent a database model in business terms, which is very useful for us. 

It supports a wide variety of databases, including the latest ones. We have chosen to go for a cloud-based database, and it supports that, which is very useful. 

It is very useful for maintaining relationships between tables. We can put constraints and foreign key-primary key relationships into the model, and it gets translated into the physical database seamlessly. 

Workgroup is another useful feature to store and share the models with the team for collaboration. 

In terms of improvements, support could have been better in terms of installation, especially of workgroups. We struggled quite a bit to get it up and running. Collaboration could have been better from an installation perspective, but it is trivial as compared to what we use it for. Other than that, I don't have much feedback. It works pretty well, and the fact that we've been using it for more than a decade shows that it is quite solid. 

In terms of new features, it would be great to have a cloud base. We should be able to put it on the cloud for better collaboration and data models sharing.

I have been using this solution for more than a decade.

It is very stable.

It is fairly scalable. We really haven't pushed it to the limit with respect to scalability, but we haven't found any issues.

Currently, we have around 20 users. They are mostly data modelers and data engineers. We have plans to increase its usage as deploy additional systems in our business unit. So, there are plans to scale up, but not in the immediate future.

I have interacted with their technical support. I would rate them an eight out of 10.

I have been in this company only for two years, but from the licensing, I know it has been more than 10 years. I am not aware of any other tool being used previously.

There wasn't a lot of stuff. When things didn't work, we had to go and figure out why this isn't working and which ports should we open. There was a lot of back and forth communication with their support, and they were very helpful, but it gets pretty difficult when something that could be done in one to two hours takes you longer than that. It took us a few weeks to get it right, but once it started working, it was pretty seamless.

There was no implementation strategy. You just download an installable and install it. The problem is that it requires a database, and it requires a particular configuration. All this is documented, but it doesn't work the way it is documented. So, it took time for us to figure out, "Hey, this thing is not working. Why is it not coming up?"

For maintenance, we don't have anyone. For the deployment of the workgroup, it took just one person. My data engineering lead just went and did it all by himself. It is a pretty simple product. It just took us a while to figure it out, especially the collaborative tool. Generally, it is supposed to take half an hour for one person.

We installed it ourselves. We did not use anybody to install it, maybe that's why it took us longer.

I don't have the metrics, but I would say we have seen an ROI. It has brought down the cost of implementation in terms of manpower. It might have saved us thousands of hours. It could also be more than a hundred thousand hours. 

The accuracy and speed of the solution in transforming complex designs into well-aligned data sources make the cost of the tool totally worth it.

There are no costs in addition to the standard licensing fees.

In general, for its purpose or use cases, it is the best tool in the market. It does its part in terms of metadata, but we have other challenges that erwin cannot resolve. We have a large pool of legacy data sources that are not labeled, and erwin really can't help there. I don't see any other tool filling that space unless we go for a catalog, which is a different product space altogether. erwin can process the legacy files, but we're just not using it for that because we don't have the bandwidth.

You need a skilled modeler to start off. It really depends on what kind of organization is implementing it: small scale, mid scale, or big scale, but collaboration really works. It is a very good tool, but proper training would be required to take full advantage of the tool. It helps to do a lot more on the job. You would need a lot of discipline before you start using the product. The standards and governance should be put up front before it can be utilized effectively.

The biggest lesson that I have learned from using this solution is that it cannot resolve governance issues. You need to have proper standards in place before you start using this tool. Bad processes lead to bad outcomes. The tool will help you shepherd those processes, but it doesn't solve them. So, you need to have proper process governance and standards. You need to make the tool enforce those processes and standards. You should have proper controls on the data inside in order to get the best results. Governance and process discipline are pretty important. 

On the database side, I come from organizations where some people follow one standard, and other people follow another set of standards, and if we use the same database and tools, then you get a mess. That's where the process discipline comes in for unified governance, which has got nothing to do with the tool. It has everything to do with how the organization is structured. The tool will help you to control that.

I would rate erwin Data Modeler a nine out of 10. If it can be on the cloud without any installs, that would make it a 10.

I am using it for database design. I am using it to architect and generate one database platform from another. It involves reverse engineering and SQL generation.

Its biggest benefit is the conversion from one database platform to another database platform and reporting.

It provides flexibility with the code. You can change the code as you want. Basically, you can change SQL based on what's best for your project.

There are some bugs here and there. The default code that comes with the customizable packages is a bit buggy on some platforms such as PostgreSQL. erwin has its own language in the backend, and the packages that come for PostgreSQL are a bit buggy. They should fix them.

It would be nice to have it on the Linux platform, not just Windows. If they can support Linux, there would be a huge market for it. 

Currently, we can import only 80% of features from other platforms. We would like to be able to get the remaining features. These import tools or plugins are not from erwin. They are from different companies. Ideally, erwin should take them over and make some of those better.

I have been using this solution for about a year and a half.

It is pretty stable.

It is very scalable. This is something very nice about it.

We have three users who use this solution. They are from the database administration team. For its administration, we have the database administration team lead.

It is used for database architecture and design. We use it only when we have to make some changes. We then produce documentation of the database design changes. As long as there are changes to be made, it is in use. Otherwise, it is not in use.

Their technical support is very good.

We used System Architect from UNICOM, which was outdated. 

It was very straightforward. The deployment took three days, which included evaluating our upgrades. Installing and configuring erwin took only 10 minutes.

We did it on our own.

We have not got a whole lot of ROI. We use it restrictively for database administration. I know it can be used for other plans of architects, but in our case, it is not fully used.

We didn't go for a subscription. It was a one-time fee. I don't understand who does subscriptions on such solutions. PowerDesigner comes with yearly subscriptions, and I can't understand how that is possible. Who in the world keeps on changing the database engine? Once you have such an application, you cannot just upgrade it like your phone. So, I cannot understand how they're pushing this.

erwin has this option where you pay a one-time fee and you have the license for six years, which makes sense because I don't upgrade my database engine every other year. I have an application that depends on it. This is something weird about PowerDesigner. 

There are no additional costs beyond the standard licensing fee.

We also evaluated PowerDesigner. It has an excessively high price. It is ridiculous. It was not that the company could not afford it, but the price was just unnecessary.

It is a very good product if you want to import existing designs. It is a tremendously flexible product for reverse engineering and database generation.

I would rate it an eight out of 10. The main reason is that it has lots of features. It is extremely flexible, but some of the areas need a bit more debugging, testing, and fixing.