erwin Data Modeler by Quest Reviews

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).

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.

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.

I am responsible for both a combination of documenting our existing data models and using erwin Data Modeler as a primary visual design tool to design and document data models that we implement for our production services.

My primary role is to document our databases using erwin to work with people and ensure that there is logically referential integrity from the perspective of the data models. I also generate the data definition language (DDL) changes necessary to maintain our data models and databases up to our client requirements in terms of their data, analytics, and whatever data manipulation that they want to do. I use erwin a lot.

It is either installed locally or accessed through a server, depending on where I have been. I have had either a single application license or pooled license that I would acquire when I open up erwin from a server.

We get data from many different sources where I work. We have many clients. The data is all conceptually related. There are primary subject area domains common across most of our clients. However, the physical sources of the data, or how the data is defined and organized, often vary significantly from client to client. Therefore, data modeling tools like erwin provide us with the ability to create a visual construct from a subject area perspective of the data. We then use that as a source to normalize the data conceptually and standardized concepts that are documented or defined differently across our sources. Once we get the data, we can then treat the data that has been managed somewhat disparately from a common conceptual framework, which is quite important.

At the moment, for what I'm doing, the interface to the physical database is really critical. erwin generally is good for databases. It is comfortable in generating a variety of versions of data models into DDL formats. That works fine.

What has been useful, I have been able to reverse engineer our existing data models to document explicitly referential integrity relationships, primary/foreign keys in the model, and create ERDs that are subject area-based which our clients can use when working with our databases. The reality is that our databases are not explicitly documented in the DDL with primary/foreign key relationships. You can't look at the DDL and explicitly understand the primary/foreign key relationships that exist between our tables, so the referential integrity is not easily understood. erwin has allowed me to explicitly document that and create ERDs. This has made it easier for our clients to consume our databases for their own purposes.

Its visualization is the most valuable feature. The ability to make global changes throughout the data model. Data models are reasonably large: They are hundreds, and in some cases thousands, of tables and attributes. With any data model, there are many attributes that are common from a naming perspective and a data type perspective. It is possible with erwin to make global changes across all of the tables, columns, or attributes, whether you are doing it logically or physically. Also, we use it to set naming standards, then attempt to enforce naming standards and changes in naming from between the logical version of the data models and the physical versions of the data models, which is very advantageous. It also provides the ability to document primary/foreign key relationships and standardize them along with being able to review conceptually the data model names and data types, then visualize that across fairly large data models.

The solution’s visual data models for helping to overcome data source complexity and enabling understanding and collaboration around maintenance and usage is very important because you can create or define document subject areas within enterprise data models. You can create smaller subsets to be able to document those visually, assess the integrity, and review the integrity of the data models with the primary clients or the users of the data. It can also be used to establish communications that are logically and conceptually correct from a business expert perspective along with maintaining the physical and logical integrity of the data from a data management perspective. 

We are not using erwin's ability to compare and synchronize data sources with data models in terms of accuracy and speed for keeping them in sync to the fullest extent. Part of it is related to the sources of the data and databases that we are now working with and the ability of erwin to interface with those database platforms. There are some issues right now. Historically, erwin worked relatively well with major relational databases, like Oracle, SQL Server, Informix, and Sybase. Now, we are migrating our platforms to the big data platforms: Hadoop, Hive, and HBase. It is only the more recent versions of erwin that have the ability to interface successfully with the big data platforms. One of the issues that we have right now is that we haven't been able to upgrade the version that we currently have of erwin, which doesn't do a very good job of interfacing with our Hive and Hadoop environments. I believe the 2020 version is more successful, but I haven't been able to test that. 

Much of what I do is documenting what we have. I am trying to document our primary data sources and databases in erwin so we have a common platform where we can visually discuss and make changes to the database. In the past couple of years, erwin has kind of supported importing or reverse engineering data models from Hive into erwin, but not necessarily exporting data models or forward generating the erwin-documented data models into Hive or Hadoop (based on my experience). I think the newest versions are better adapted to do that. It is an area of concern and a bit of frustration on my part at this time. I wish I had the latest version of erwin, either the 2020 R1 or R2 version, to see if I could be more successful in importing and exporting data models between erwin and Hive.

erwin generally fails to successfully reverse engineer our Oracle Databases into erwin data models. The way that they are engineered on our side, the syntax is correct from an Oracle perspective, but it seems to be very difficult for erwin to interpret. What I end up doing is using Oracle Data Modeler to reverse engineer into the Oracle data model, then forward engineer the DDL into an Oracle syntax, and importing that DDL into erwin in order to successfully bring in most of the information from our physical data models. That is a bit of a challenge. 

There are other characteristics of erwin, as far as interfacing directly with the databases, that we don't do. Historically, while erwin has existed, the problem is the people that I work with and who have done most of the data management and database creation are engineers. Very few of them have any understanding of data modeling tools and don't work conceptually from that perspective. They know how to write DDL syntax for whether it's SQL Server, Oracle, or Sybase, but they don't have much experience using a data modeling tool like erwin. They don't trust erwin nor would they trust any of its competitors. I trust erwin a lot more than our engineers do. The most that they trust the solution to do is to document and be able to see characteristics of the database, which are useful in terms of discussing the database from a conceptual perspective and with clients, rather than directly engineering the database via erwin. 

erwin is more of a tool to document what exists, what potentially will exist, and create code that engineers can then harvest and manage/manipulate to their satisfaction. They can then use it to make changes directly to our databases. Currently, when the primary focus is on Hive databases or Hadoop environment, where there is no direct engineering at this point between erwin and those databases, any direct or indirect engineering at the moment is still with our Oracle Database.

I have been using the solution on and off for 20 to 30 years.

It is pretty stable. Personally, I haven't run into any real glitches or problems with the output, the ability to import data when it does work correctly, the export/creation of DDL, or generation of reports.

We are trying to upgrade. This has been going on now for several months. We're trying to upgrade to the 2020 version. Originally, it was 2020 R1, but I think at this point people are talking about the 2020 R2 version. Now, I'm not part of our direct communications with erwin in regards to Data Modeler, but there are some issues that erwin is currently working on that are issues for my company. This have prevented us from upgrading immediately to the 2020 version.

This gets down to how you do your data modeling. If you do your data modeling in a conceptually correct manner, scaling isn't an issue. If you don't do your data modeling very well, then you are creating unnecessary complexities. Things can get a bit awkward. This isn't an erwin issue, but more a consequence of who is using the product.

In the area that I'm working right now, I'm the only user. Within the company, there are other people and areas using the solution probably far more intimately in regards to their databases. I really don't know the number of licenses out there.

The problem is that our issues are related to interfacing erwin Data Modeler with the Hadoop Hive environments. The issues have always been either what I was trying to do was not fully supported by our version of erwin Data Modeler. People have certainly tried to help, but there's only so much that they could tell me. So, it's been difficult. I am hoping that I can get back to people with some better answers once the newest version of erwin is available to us.

The people who were previously responsible for the database development were very good engineers who knew how to write SQL. They could program anything themselves that they wanted to program. However, I really don't think that they really understood data modeling as such. They just wrote the code. Our code and models are still developing and not necessarily conformed to good data modeling practices. 

In the past, I was involved in the initial setup. In traditional environments, it sets up pretty easily. In my current environment, where I'm trying to get it as intimately integrated with our big data platforms as possible, I'm finding it quite frustrating. However, I'm using an older version and think that is probably a significant part of the problem.

In other environments where I've worked, the solution’s ability to generate database code from a model for a wide array of data sources cuts development time. In this environment, erwin is not very tightly integrated into the development cycle. It is used more for documentation purposes at this point and for creating a nascent code which down the road gets potentially implemented. While it's not used that way at my current company, I think it would be better if it were, but there is a culture here that probably will prevent that from ever occurring.

An issue right now would be that erwin doesn't have a freely available browser (that I am aware of) for people who are not data modelers or data engineers that a consumer could use to look at the data models and play with it. This would not be to make any changes, but just to visually look at what exists. There are other products out there which do have end user browsers available and allow them to access data models via the data modeling tool.

There is another tool now that people are using. It is not really a data modeling tool. It is more of a data model visualization tool, and that's SchemaSpy. We don't do data modeling with that. You get a visualization of the existing physical database. But that's where the engineers live, and that's what they think is great. This is a cultural, conceptual, understanding issue due to a lack of understanding and appreciation of what good data modeling tools do that I can't see changing based on the current corporate organization. 

It is the only meaningful way to do any data modeling. It is impossible to conceptualize and document complex data environments and the integration between different data subject areas. You can write all the code or DDL you want, but it's absolutely impossible to maintain any sort of conceptual or logical integrity across a large complex enterprise environment without using a tool like erwin. 

You want to look at what you are trying to accomplish with erwin before implementing it.

• Does the product have the ability to support or accomplish that?
• Based on the technologies that you have decided you want to use to manage your data, how intimately does it integrate with those technologies? 

From my perspective of using the traditional relational databases, I think erwin probably works pretty well. 

For the newer database technologies, such as the Hadoop environment databases, it's not clear to me how successful erwin is. However, I'm not talking from the perspective of somebody who has been aggressively using the latest version. I don't have access to it, so I'm afraid my concerns or issues may not be valid at this point. I will find out when we finally implement the latest erwin version.

I would give the solution a seven or eight (out of 10).

The whole purpose of the erwin tool is for the designing of databases. We use it for our conceptual, logical, and physical database modeling.

We've been using this product as long as I can remember at our company, so it's hard to say how it has improved things. It's existed since I've been here. But it gives everybody the ability to see the physical implementations in a visual manner.

The solution is extremely critical to driving business change and transformation in our company because we do 100 percent of our data modeling using this tool. We meet with the business to show what exists and we show them what our changes are going to be to meet new requirements. We review that with business to get its agreement to the approach. We also meet with technology to show how it's going to be transformed in the physical implementation. So it is extremely critical to our everyday process.

The most valuable feature is the physical or visual representation of the database, showing the tables, the columns, the foreign keys, and the ability to generate DDL, so you can physically implement databases.

It lets you display the actual physically implemented databases or the logical databases. That enables you to review them with business users or technology people, to understand the relationships of the data throughout the company and show how data is joined together to achieve whatever the desired business results are.

I would like to see more support for working with the big-data world. There are so many new databases evolving and it's very hard for them to keep up with all of the new technologies. It would be good if they were able to dynamically support big-data platforms, other than Hive and Teradata. There's a new release coming out this year and they're adding two more platforms in that next release. So they are striving to keep up with technology, but technology is just evolving too rapidly. There are just too many options.

I've been using erwin since 1998 or 1999.

The solution is very stable. It continues to evolve. 

A lot of the things, a lot of the new tools that they're introducing as part of erwin, are to make it more of a data governance tool in general, beyond just the data modeling which we've traditionally used. That whole piece is rapidly evolving. I've been watching it evolve over the past two or three years. We're not ready to purchase the products yet that they're putting out because we feel things are still evolving, but in the next couple of years they'll be the leader in the entire data governance realm.

Data Modeler is very scalable. It keeps evolving as new technologies come out. People put in requests for it to be able to support different database platforms, and in just about every release in the past couple of years they've come out with support for one or two additional platforms. They are trying to keep up with customers' demands. They're very good about continuing to upgrade support for their legacy stuff as well. They're evolving and they're doing a pretty good job.

The product was sold by a company called Platinum when I first started using it. It was then sold to CA and I was involved when CA produced its first rollout. After being owned by CA, it then was spun off to its own, standalone company, as erwin. I was there for the initial deployment of that as well. So, I've done many deployments of erwin, as different releases have come out.

The setup has become more complex. That's probably related to the fact that they're doing more things on the cloud, such as licensing, which has caused problems because we have very tight security here. Access to servers outside of our firewall causes issues for people who work in certain regions around the world because we restrict access to the cloud for governance purposes. So, we have had some issues with licensing. People can't connect to the license server, because it's done over the cloud, so they have to do an off-line license, which locks the license. We have concurrent licenses. So when a license is locked, even though the person is no longer using the product, because that person is not connected through the cloud, erwin's system doesn't know to release the license. We've worked with erwin and they have tried to help mitigate that, but we still do encounter issues with licensing.

In terms of deployment, just the install of the product on somebody's machine takes about 10 minutes. It's not very long at all. There are other features, such as setting up users in Model Mart, which take longer because you have to analyze the user's needs and set up appropriate permissions. That could take longer, depending on what the user's roles are.

As for our implementation strategy for Data Modeler, we just deployed it on someone's computer. We tested it on that person's box, one that everybody had access to. We all got to try the tool to see that we wanted to use it and to understand its features. Once everybody was comfortable with the features of it, we then had to upgrade our Model Mart repository, which is where we store all of the erwin models. Everyone has to be on the same release. So, we have to QA the whole process of upgrading our Windows Server and upgrading our database server. After we do those upgrades, we can then deploy the software on the machines. 

That's probably one of the biggest issues: Everybody has to be on the exact same version and release to be able to work together, if you're using the Model Mart repository. It's not very backward-compatible.

We did have to involve erwin consultants because of the firewall issues that we were having when we were doing testing. We had to involve their helpdesk. Their helpdesk is extremely responsive. They actually tried to help us immediately on the phone. We needed a higher level of support so they scheduled meetings where we were sharing screens with them and they were able to help us. They were very helpful. One of the best features of erwin is its helpdesk.

It's hard to know how to gauge ROI. We've been using it since I got here. With the tool, we have a very good service-oriented architecture. We know exactly where all the data is; it's very clearly documented. If we didn't have this tool, I don't know how we would manage knowing where data is or manage having a consistent business glossary or data dictionary.

We've experimented with other solutions, such as ER/Studio, which has had different names. We experimented with SAP PowerDesigner, but that was not as robust in performing what we wanted it to do.

The main differences between the products we evaluated and erwin would be the ease of use, between logical and physical transformed models. The logical is more on the business side, and the physical is more on the technical side. The ease of maintaining those two models together was the number-one advantage of erwin. Number-two is the ability of the tool to support many platforms while successfully creating DDL, without issues with the DDL. erwin also has the ability to do compares of the models against the database, and to synchronize differences, whether importing database changes into the model or exporting the model to the database. Those were the primary things that it did well.

But I come back to ease of use. It's a very easy tool to train somebody on and for them to use. ER/Studio is probably the second-best product, but it's not as self-explanatory, it's not as easy to use. It's a little bit more clunky. It probably performs just as well, but it's a bit more difficult to use.

If you want good data architecture in your company, you need to have database design done. It's probably the most important factor for having things clearly modeled and documented. erwin Data Modeler is not just a modeling tool, it's also used for documentation. If you're using the tool's functions properly, analyzing the documentation, flagging fields that are NPPI data, it is invaluable for business use. You can generate data dictionaries, you can make sure people are speaking common languages, and you can enforce company standards so that people are doing things in a consistent manner. It's an invaluable tool. If you want to have good data architecture, you need to have a tool like this.

We don't currently use the collaborative web modeling capability. We just recently purchased that tool and we are planning on deploying it at the end of Q1 of this year.

We don't use the erwin data transformation for integration to a wider ecosystem. We are actually able to directly do all of the transformations that we need from erwin, so we're not required to do any transformations. It supports legacy systems like Db2, Oracle, SQL Server, and now Teradata and Hive, which were introduced in the past few years. But it can currently support all of the data modeling we need to support, so no transformations are needed.

We have different flavors of people who use the tool. We have people who are dedicated data architects, that's their full-time job. There are 15 to 20 of them in the company. And we have many people who do use it for very specific applications on more of a part-time basis, where they're doing the data modeling and reviewing it with an enterprise architect. There are about 150 people who are doing that. Overall, we have about 170 people who have access to the software.

For deployment, upgrades, and maintenance of the solution, we generally require four people. We require somebody to do a Windows upgrade; we require somebody to do a database upgrade, and that's for the Mart repository portion; and we have two people who do the testing for the erwin tool: somebody who installs the upgrades of erwin on the local machines, and somebody who's testing it. When it comes to the installs and the upgrades, each person who's using the tool is expected to do that on their own. We set up a deployment package and everyone runs it when they're told to execute the upgrade.

I use the solution for entity relationship data modeling to build the databases.

Drag-and-drop data modeling and reverse engineering out of databases are the most valuable features of erwin Data Modeler by Quest.

I would like the solution to be less rigid in terms of its theory. It supports the theory very well, but it's too rigid. It's focused on database design and theoretic database design. I'd like it to be able to do better extractions.

I have worked with erwin Data Modeler by Quest for 20 years.

The solution is too rigid in terms of usability. The other thing is you can do things to make it crash, and when it crashes, the models created with it become read-only. To be honest, I prefer using Visual Paradigm.

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

It took some coordination to get the license transferred to me. Otherwise, the solution's initial setup is straightforward.

I've probably spent half a day not running the installation but waiting for emails back from the vendor.

It's a good enough solution if the whole purpose of your data modeling is to generate databases. I also use data modeling for other purposes, and that's why I prefer Visual Paradigm. It allows me to do data modeling that's not so much focused on databases.

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

We usually use it to design new databases as well as reverse engineer some databases from third-party products, e.g., ERPs or monetary software.

The most valuable features are the ability to reverse engineer and do model comparison. With the reverse engineering, I can understand the databases from third-party products. With the model comparison, I can track the differences between two versions of the same database.

Because I can graphically see the Modeler database, that is very helpful for my job as it helps me understand the database. It is very different from SQL and DML scripts, which are very hard to understand with just sentences. When we have a graphic, that is very helpful. We can save time understanding that database.

I like the synchronization ability a lot because it can tell me to apply some level of governance to my models. I can be sure that the model in my documentation or development environment matches with the database that is working in our production environment. It is accurate. Though, it is not always fast when we have dozens of tables, but it works. I wait about an hour in order to have a big database synchronized.

The solution’s code generation ensures accurate engineering of data sources. It avoids rework.

I would like to have more data sources from other, different vendors. In recent years, the vendor has reduced the number of data sources, and I would like to have more data sources for every brand. For example, with Oracle, I would like to have compatibility for many versions, including old ones, not just the most recent. 

The technical support could be better. They could give faster solutions.

I have been using this solution since 1995.

It is stable.

Only when the database is too big, then we could have some trouble. We are talking about maybe 12,000 tables, then it starts to have some problems.

With erwin, we just need to add memory to the computer in order to work with bigger databases. However, it would be good to have erwin for other platforms, e.g., Linux and Macintosh, not just Windows. 

The technical support is good. They are highly skilled. 

Before erwin, I was manually using Notebook for my databases. Before erwin, I was designing databases and analyzing them manually all the time.

We chose erwin because it was the only solution which could help us design a database on the computer.

It saves a lot of development time. I think we are saving from two weeks to one month annually. It depends on the size and complexity of the database.

The solution’s automation of reusable design rules and standards is good compared to basic drawing tools. It saves time and keeps us from errors, which are very costly in the database. Therefore, we can get back our money very quickly.

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

erwin is expensive compared to other solutions. We are paying almost $6,000 per seat a month.

I have used different solutions along the way, but then I moved back to erwin. Besides erwin, I have tried IDERA Embarcadero, but I think erwin is more usable and has helped me to do my job better.

I rate this solution as nine out of 10.

We used this solution for three to five projects that we had.

They have a lot of features and the most up-to-date technology integration, which I haven't seen in other products.

In terms of features, I believe they were doing very well in the latest technologies as well.

There are too many features. People find it extremely difficult to navigate. It's a great product, but there are too many features and no one knows exactly where things are. For example, the documentation is not always straightforward, which is why I use another competitor's product, which is simpler and easier to use. It has more features than the product I previously used.

This is a very complex product.

They have a lot of features, and that may be the reason why I'm not familiar with them and has made it more complicated for me. 

In comparison to other products I've used, such as ER studio, which is a competitor to erwin. It is simple and easy to code as well as other functions. Even the coding has become much simpler. I can see that this is a little more complicated. I'm not certain. Right now, I can explicitly state that no features are required because I still need to explore some areas. Maybe the reporting area will be interesting if it is more dynamic.

I have been working with erwin Data Modeler (DM) for approximately four years.

We are using version 9 or 9.1.

Pricing is very high compared to any other product.

I would rate erwin Data Modeler (DM) a nine out of ten.