erwin Data Modeler by Quest Reviews

In one of the companies, we used it as an information tool. We created a logical model so that the business would know what was in the offices down to the warehouse. The current use case is also the same. We have some places for information, so we can do a logical data model for them, but, usually, it would go towards building an actual database, which also involves reverse engineering of an existing one because people don't know what's in there.

It is currently on-prem, but we still have a separate server.

We want to bring different erwin components together and tell a business user story. So, having all of it on one platform to be able to tell one story makes it not as fragmented as components have been in the past. 

In my previous company, when we had 1,000 tables, 6,000 columns, and 14 subject areas, trying to explain to people in the organization was difficult. Without the tool, it would have been impossible. With the tool, it was a lot easier because you could show a steward how this is his or her domain. For each steward, you could say, "Well, this is your domain over here." Once they had that, they could understand what you were talking about. So, it improved communication. We had a point where two stewards were looking at the models, and one of them said, "I think that one that you've got over there is actually mine." The other one said, "I think you're right." So, we actually moved an entity from one subject area to another because now they had the ability to see what was in their subject area. They could go and see what wasn't theirs and should be someone else's. If we didn't have the tool, we wouldn't have that visibility and wouldn't have been able to recognize that sort of situation. 

Its ability to generate database code from a model for a wide array of data sources cuts development time. You don't have to re-key things. You put in the information at one spot, and it flows out from there. There are so many parameters you can put on the physical side. You can put in your indexes, and you can put in expected size changes. You can store all sorts of information within the model itself. It is a really good repository of all that sort of information, and then you just push a button, and it generates the other end. It works really well. In terms of time-saving, if you had to write it all out by hand, it would take weeks. It would probably take three or four times longer without the tool.

It certainly improves accuracy for the generation of target databases because you're only putting information in one spot. You don't have to retype it. For example, I saw the word conceptual model misspelled today. So, if you have to re-key something, no matter how careful you are, you're going to misspell things, which would cause problems down the track, whereas if you make a mistake in DM, there is only one place you have to go and fix it, and then, you would regenerate the downstream stuff. This means that you don't have to touch anything physical. You generate it, and then you can use it.

Being able to point it to a database and then pull the metadata is a valuable feature. Another valuable feature is being able to rearrange the model so that we can display it to users. We are able to divide the information into subject areas, and we can divide the data landscape into smaller chunks, which makes it easier to understand. If you had 14 subject areas, 1,000 entities, and 6,000 columns, you can't quite understand it all at once. So, being able to have the same underlying model but only display portions of it at a time is extremely useful.

I am currently trying to compare and synchronize data sources with data models, and it is pretty good. It shows you all the differences between the two systems. After that, it is a matter of what you want to do with them. It is certainly helpful for bringing models in and being able to compare. At the moment, I'm comparing something that's in a database with something that was in the DDL statement. So, these are two different sets of sources, and I can bring different sources together and compare them in the one, which is really helpful.

I still use Visio for conceptual modeling, and that's mainly because it is easier to change things, and you can relax some of the rules. DM's eventual target is a database, which means you actually have to dot all the Is and cross all the Ts, but in a conceptual model, you don't often know what you're working with. So, that's probably a constraint with erwin.

They have made it a lot easier, and they've done a lot, but there is probably still room for improvement in terms of the ease of presentation back to the business. I'm comparing it with something like Visio where you can change colors on a box, change the text color and that sort of stuff, and change the lines. Such things are a whole lot easier in Visio, but once you get a theme organized in erwin, you can apply that theme to all of the objects. So, it becomes easier, but you do have to set up that theme. I think they've got three to four initial themes. There is a default theme, and then there are two or three others that you can pick from. So, having more color themes would help. In Visio, you have a series of themes where someone who knows about color has actually matched the colors to each other. So, if you use the colors in the theme, they will complement each other. So, erwin should provide a couple more themes.

They could perhaps think of having an entry-level product that is priced a bit lower. For extra features, the users can pay more.

I have been using it at least since 2003. I have used it at multiple organizations.

It has always been really stable in the different organizations that I've used it in. It has always been a pretty good product.

It works fine with the number of people who have been using the product. We're talking about 10 to 12 people, not thousands of people. I haven't ever been in an organization where thousands of people even needed to get to the product. Probably the biggest drawback in scalability is the cost per seat rather than the actual product. The product works fine.

Our current organization has probably about 5 to 10 people using it. We're a consultancy, so we're using it in various roles. So, a lot of it is to do with understanding. As consultants, we try to understand what a client has in the organization and what sort of data they have to make sure there is actually data in the system that can answer their business questions. So, that's the sort of thing we use it for. We can turn around and give them designs. We can show what it is, and then we can turn around and make it what it would be. It is used by analysts and developers. They are not developing software. They are probably developing the database, but then, people would develop software.

I've used it on all the projects I've been on so far. I've been with this company for a short time, and it has come into play for pretty much all of the projects that I've been on. We want to use it more extensively. We want to use the erwin suite. We've got the modeler, but we also want to use their BI tool. We would like to evolve and come up with a story that links all of them together.

We have only just got the BI suite installed. We're starting to play around with it and see what we can do with it. We're doing some training on it at the moment. In a previous company also, somebody from erwin came to show it to us, and it was reasonably new at that point. That was last year. It is a reasonably new product. So, getting them to talk to each other has also been fairly new. erwin has only done it in the last couple of years. 

I haven't had dealings with them, but the dealings I've had with erwin as a company have always been really good. So, I would rate them a nine or 10 out of 10.

I use Visio on the conceptual side. We've got Informatica, and I think it has got a modeling component in there. We try to get a range of products because we're doing consulting in various organizations, and they have got various tools. Usually, it depends on what a client has already installed. Sometimes, it also depends on their budget. Something like Informatica is usually at the top right end corner of the Gartner Quadrant, but it could also be overkill for smaller organizations because the benefit may not be there. So, a lot of time, it is horses for courses. You have to sort of tailor any solution to meet a client's needs.

I haven't ever really installed erwin. One of the other guys has done that. Most of the places had it installed already. Usually, the complexity depends on how the organization does its software deployment. So, you have to go and request the software and then somebody has to give you the package. Once you get the package, it is pretty straightforward. It is usually less of a problem on erwin's side and more of an issue with how an organization deploys any erwin software, but once you deploy it, it works fine.

Some places that I've worked with were very strict about doing testing on COTS products to make sure that there are no viruses on it and also to make sure that it plays nicely with the rest of the system. So, those sorts of organizations may take longer in terms of testing. You put it on a test machine first and make sure it is not going to kill anything. They might have to repackage some stuff before they put it out to the network. To deploy a vanilla thing, I would think that it would only take a couple of hours.

In terms of maintenance, at the moment, I think we've got one person. The main thing is deploying new versions. You've got a server stood up, and you have to put the software out there. I don't know if there is anything else beyond that.

We haven't done an ROI for the current version. When you look at the total cost of creating or understanding what you've currently got through reverse engineering, and you look at the total cost of creating new products and new databases and maintaining them over time, and then you put that into the return on investment model, it is well worth it.

The accuracy and speed of the solution in transforming complex designs into well-aligned data sources make the cost of the tool worth it. If you didn't have the tool and a single developer or a single modeler was trying to do the same thing, the speed would be three or four times slower. If you multiply that by the cost of that person and then you also consider the cost of the other people who are waiting for that person to create a database design, it multiplies out. So, it is well worth it.

It has increased in price a fair amount over the years. It has always been expensive because it is a comprehensive product, and presumably, they have to do a tremendous amount of testing to make sure that everything works. It has always been dear because usually, a very specific target audience of data architects has the need for modelers, and not everyone in the organization would need to get a copy of it. Only people who are actually working in the database space need it. So, it has always been a very specialized piece of software, and it has been priced accordingly.

I don't specifically know what we're paying now. About three years ago, in another organization, I have this memory of 6,000 AUD a seat or something like that, but I am not sure. In the mid-2000s, it was something like 1,200 AUD a seat. I get the impression that there was a price jump when it was spun off from CA as a separate company, which is understandable, but it could sometimes be a barrier in some organizations picking it up.

I haven't talked to erwin people yet, but I'm going to suggest to them that they could perhaps think of having an entry-level product that is priced a bit lower, and then, you can buy the extra suite. That's what Microsoft does. They package a few things so that you have something, but if you want this extra stuff that has enterprise features, such as they talk to each other and have great bits and pieces, you have to pay more. I don't think there are any additional costs. It is per product, and there are different license levels. 

Oracle Data Modeler, which is free, is one of the competitors that erwin has. You can't argue with the price point on that one, but erwin is much more comprehensive and easier to use. It is easier to display information and models to business people than something like Oracle Data Modeler, which does the job, but erwin does it a lot better. So, my advice would be that if you can afford it, get it.

Its visual data models have certainly improved over time in terms of overcoming data source complexity and enabling understanding and collaboration around maintenance and usage. It was originally designed as a tool to build databases with, and it retains a lot of that. It still looks like that in a lot of cases, but it has also been made more business-friendly with a sort of new front end. So, it used to be all or nothing where when you wanted to show somebody just the entity names or just the entity descriptions, you had to switch all of the entities on your diagram just to show names. Now, you can show some of them. You can shrink down some of them, and you can keep some of them expanded. So, it has become a more useful information-sharing tool over time. It is extremely helpful.

In my previous company, it was the enterprise data model, and you could paper a room with it if you printed the information out. To present that information to people, we had to chunk it down into subject areas. We had to present smaller amounts of information. Because it was linked to the underlying system, we could reuse the information that we had in a model in other models. The biggest lesson was to chunk the information down and present it in a digestible form rather than trying to show the entire thing because otherwise, people would run away screaming.

One of the places didn't have a modeling tool in it, and they were trying to do the documentation using Confluence. It was just a nightmare trying to keep it maintained with different developers using different tables and then needing to throw something into one and adding something into another one. It was just a nightmare. If they had one tool where they could put it all in one place, it would have been so much easier than the mess they had.

I would rate erwin Data Modeler a nine out of 10.

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

erwin is deployed on individual desktops and the individual users install it or have a help desk person install it for them.

Our primary use case is for during any type of project development or maintenance and application maintenance, we go through a process of modeling our data before it gets put into the database. We interact with the application development teams to determine what their requirements are and build the data models, and then turn them into actual physical database items.

erwin has definitely helped us improve our enforcement of standards and database design best practices. Before we really started using the tool or having a data modeling type of team, application development efforts all had their own database structures. Developers tend to not be too concerned with the data. They just want to make everything work for their application as easy as possible. Having the tool and having a team built around it has really helped us make sure that we're following the best normalization processes, we're not duplicating data, and we have a standard naming scheme that everybody has to follow.

The modeling portion of the tool is the most valuable. There are some notes, naming standards, and other functions that we use as well. There's a whole boatload of functionality in this thing and we use maybe 10% of it. It seems to be pretty common that not all the functionality is fully utilized. But it's got gobs and gobs of stuff that you can implement if you so choose to.

We've definitely expounded on the amount of features we use. They've built in some automated naming standards that have been really helpful for us. That's probably the biggest leap we've used. We've always used the comments and notes features, but the automated naming features have been very helpful.

Its ability to overcome data source complexity and enabling understanding and collaboration around maintenance and usage is extremely helpful because they give a visual to not only developers and database administrators, but the user base themselves. So the typical user isn't going to understand database functionality. Being able to show them a picture of how their data is actually going to look in the database is very helpful for their understanding of what we're trying to do with their data.

erwin's ability to compare and synchronize data sources with data models in terms of accuracy and speed for keeping them in sync is very good. We utilize that service quite a bit. The one drawback is if you have an extremely large complex model, the compare process can take quite a bit of time, more than four hours. 

Its ability to generate database code from a model for a wide array of data sources cuts development time. The fact that you can generate the DDL correctly from the model saves us a bunch of time. I would say it saves us around 40% to 50%. So even though you can generate the DDL, you still have to go in and tweak it a little bit. 

The only real complaint I have is the time it takes to do a database comparison on a large model. If they could speed that up, that would be the only thing I can think of that needs improvement.

We've been using erwin since about 2000. We were using another product before, but it was way too cumbersome, so we switched to erwin.

Stability is excellent. It's been a solid product for years and I don't expect it to change.

It's extremely scalable. Our environment has hundreds of tables. 

We have five data modelers using the tool. That's the team that actually works with the app dev and DBAs to actually come up with the database design. Then we have another five users that act more in a read-only type of mode. They just want to look at the data models, but they don't actually do any of the design work.

Their support was excellent. Typically it has to do with going through the upgrade process. If we have an issue, we'll reach out to them. The other thing we've had to reach out to them about was the time it was taking to do a data comparison on our extremely large model to the actual physical database. They were very helpful and very professional.

We don't typically have problems transitioning between the models. We did last time, but it was actually an error on our end. It wasn't an error on the erwin end.

We were using Cayenne. We switched because it was cumbersome.

The initial setup is typically straightforward. Just follow their instructions and everything goes pretty smoothly.

For the Data Modeler portion itself, on each desktop, the setup took around half an hour, and we have around 10 desktops.

We didn't necessarily have a deployment strategy. We just gave the product to anybody that thought they needed it and let them run with it.

For maintenance, we need one person, but it's definitely not a full-time job. It's just adding and subtracting users and going through the upgrade process when we do that. As far as installation, everybody basically installs it themselves. We don't require a full-time person for that either.

We have a team around it, so if we add our data modeling team up, we use it about six hours a day per person. That would be about 18 hours a day for those guys. The read-only users rarely use it, so they're pretty insignificant. 

We probably only use 10% to 20% of the functionality and I don't see us expanding on that a whole lot. There's a lot of neat little things in there, but we don't have time to implement them all. There's some overhead that goes with those functions that we choose not to undertake.

Since we got a new guy on our team, he's gotten into some of those functions and has been able to utilize some of that stuff some more. We're actually probably closer to 30% or 40% of the functions at this point. We're not thinking about expanding because of the overhead. 

I don't remember what our costs are. I know they just recently switched from a per seat type of licensing to a concurrent user type of licensing agreement, which is neither here nor there. I don't think it has increased or decreased the cost at all, but it's not obtrusive or invasive as far as the cost goes. It's fairly affordable.

There are also internal costs if you have hosted on-prem because you have to have a server and database to stand it up on.

We didn't evaluate another solution because I had used erwin at another location and was extremely familiar with it. And I had also used Visio and some more manual-type methods like Visio. At the point that we decided to switch over, I was confident that erwin was the best solution out there.

erwin is by far the best tool I've ever used. 

My advice to somebody considering this solution is to go for it. It's easy. The functionality is fantastic. It's easy to pick up. It does basically everything you could want it to do.

The automation of reusable design rules and standards has helped us immensely once we implemented it because having the automated naming standards and things like that, we don't have to go in and think about it. We don't have to go in and physically type it. Between generating the DDL and getting it into physical implementation was saving us 40% to 50% of time. It's because of those automated features that that's happening as opposed to having to sit there and type out the DDL from scratch, it saves a ton of time.

It produces a time savings of about 40%.

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

My advice would be to let things evolve over time. Start with the basics first. Just get into the ERD functions first and then start implementing some of the automated naming standards and things like that as you go. Otherwise, if you try to dive into the whole thing, you're just going to get overwhelmed because the product is so deep as far as features go. It's extremely intuitive. As far as the basics go, as far as getting your ERDs established, it's probably the easiest tool I've ever used. If you understand the basics of database design, it's extremely natural. If you have no clue about database design, then your learning curve is going to be large no matter what tool you pick. But erwin definitely cuts that learning curve down just because of its intuitiveness.

Once you start diving into the automated feature sets like naming standards and things like that, the learning curve there is a little steeper, but it's still not too bad. For a brand new person, if you try to delve into the automated stuff and all the additional functionality, you're just going to get overwhelmed and feel that there is too much overhead. But you don't need to implement all those features right off the bat.

I would rate erwin a ten out of ten.

We are implementing erwin to streamline data modeling and automate network changes for increased efficiency and comprehensive data development. This option simplifies the need for better data indexing.

Quest can create conceptual and physical data models to facilitate effective communication between business and IT. It can also integrate expertise from various engineering and database systems within your organization to enhance data management and administration.

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

I rate the solution’s stability an eight out of ten.

We are testing the capacity in our environment for more than six thousand databases.

When we were working with third-party providers, they were giving very good support.

The initial setup depends on the tool if you are using the data model environment. Stopping the server could be complex and require strong expertise.

If you have everything set up and configured, Erwin is straightforward. You can deploy it in a few hours. In our case, it took a couple of months to address internal conditions, assign machines, and set up everything for the services.

I rate the initial setup a six out of ten, where one is difficult and ten is easy.

The reseller set up the whole department.

The product is expensive. I rate the product’s pricing a nine out of ten, where one is cheap and ten is expensive.

Reverse engineering is a very powerful feature. I have used it many times when working with clients, which has helped solve implementation issues.

Erwin utilizes artificial intelligence to automatically create definitions and generate logical or physical data models tailored to specific industries.

I recommend the solution.

Overall, I rate the solution a ten out of ten.

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.

I am using the solution for data modeling. We also use erwin Data Intelligence Suite for data governance.

We like that we can go straight from Data Modeler to Data Intelligence Suite. We can go from the business glossary to the data catalog. It gives us a holistic view. The product lets us import different types of models from various databases. It also allows us to export or implement them within the same databases based on new changes.

The modeling capability is cumbersome. It doesn't allow us to put different types of objects in there. We can only put data objects. It doesn’t allow us to put any class structures and enterprise architecture objects. We can only do data monitoring. We can't do a holistic view. It's quite cumbersome to enter data. We cannot type things into a sheet. We always have to open the object and enter it.

The layout is a very old-style diagram. The product must allow users to put different types of objects and link them to data objects. The tool must provide large data objects under which there can be other data objects. For example, if a customer is a large data object, it must then contain the customer’s name, address, and type. The interface must be improved.

I have been using the solution for more than ten years. I am using the latest version of the solution.

I rate the tool’s stability a seven out of ten. It doesn’t stay up all the time. The stability must be improved.

I rate the tool’s scalability a seven out of ten. We have some issues with performance, but I'm not sure if it's us or the tool. We have 50 to 150 users.

The technical support team is quite helpful. The team members don't always know their stuff. Sometimes, we end up teaching them things, but they do try to be helpful.

Neutral

I have used Rational Rose, Visual Paradigm, and Oracle’s old product. I use Visual Paradigm for my personal use cases. I prefer Visual Paradigm. It has a lot of features that erwin doesn’t. The only problem with Visual Paradigm is that it has many license levels. I only have a cheap license. However, its capabilities are much stronger. It is a lot easier to use than erwin, and it produces much nicer diagrams.

The solution is cloud-based. We use both AWS and Azure as our cloud providers. Maintenance is done automatically by the vendor.

The tool is expensive. It is not worth the price. I rate the pricing a three out of ten.

We are looking for other tools to replace the solution. We're going to do an RFP for data modeling, data catalog, data quality, and marketplace. The vendor is trying to charge for Data Intelligence Suite like it is an enterprise tool, but it's still getting patched together. I have a hard time giving erwin a strong recommendation, but it's a tool that works and does what it says on the box. It could be made a little better. Overall, I rate the product a seven out of ten.

I was part of a standards organization and we built a data model that is a standard data model for use in retail. That data model is now been released in version 7.3 and it is implemented all over the world. We don't implement the model, we've built the logical model and then the companies build their own physical model from there. 

erwin is a retail data model, which means that it handles the operational side of retail, which means there are somewhere around 8,000 attributes in it. It has got around 10 groupings of things. We have a grouping on transactions and there are all kinds of transactions that can occur in retail. The whole customer life cycle is covered in the inventory, items, and all that. The use case is for retail operations. It's massive. There are hundreds of use cases in this.

We don't implement, we simply tell other people how to do it. It's a beautiful model for the new microservices world, so we can help people understand how to fit this into their world. In terms of us actually doing something and implementing it and all that, that's really not in scope for what we do.

erwin is easy. In the microservices world, having a unified retail model like this one that is a standard and allows two companies to inter-operate easily in the past. In fact, the whole reason the model was created was in 1993, was because about half a dozen major retail CIOs got together and said, "We've got to have a standard model because every time we buy a new point of sale system, we need to re-architect our entire enterprise." They started building this model back in 1993, and the beauty of it is it does precisely what they say. A retailer can now integrate two vendor's systems easily, as long as they all follow the same model. It reduces their cost of integration dramatically, as well as being quite a powerful model in and of itself.

It reduces monthly savings by hundreds of thousands of dollars. Think about a company like Costco and all of the points of sale systems in Costco, all of the systems, and the applications, but if all the applications in Costco all had their own data model, trying to integrate those, upgrade them and manage their different versions of the same model throughout the store, is an absolute nightmare. It's phenomenally expensive. This helps reduce that cost significantly. I'm talking on the orders of hundreds of thousands of dollars.

erwin is pretty easy. I've been using it for so long it's like second nature. 

The visual data models are pretty easy for helping to overcome data source complexity and enabling understanding and collaboration around maintenance and usage. It's easy to add, change, and update things. We get feedback from retailers. For example, somebody wants to update something in the item area, they want to use a new item identifier and it's just a matter of going in and adding it to the numerations for that. Or somebody might come in and say, "We're using a little bit of a different pricing model so we need to add this information into the pricing area." Or people will say "We need to add Bitcoin," so we can go in and add Bitcoin and the attributes you need to support it and do it very easily. At this point, we're not adding new capabilities, we're simply expanding existing ones.

The navigation is a little bit of a challenge. It's painful. For example, if you've got a view open and you want to try to move from side to side, the standard today is being able to drag and drop left and right. You can't really do that in the model. Moving around the model is painful because it doesn't follow the Windows model today.

Otherwise, it's got everything I need and it's not hard to use for me.

The stability is great. We don't have any problems. 

I actually did use their support, I had some issues getting it installed and it had to do with that they've given a copy of the Data Modeler for me to support the standard data model, and getting that approved and authorized and all that was a bit of a challenge. I went through the help desk and they got it done pretty easy for me. I had a unique problem.

Positive

I had used D-Base. This was a long time ago, but I used D-Base to build a model for the oil industry. That was a long time ago. It was a 1980s vintage so there is no comparison.

The initial setup is straightforward. You can install it without a lot of hassle.

They gave us a copy because of supporting a standards data model, so pricing and all that is really not something I can compare. I think it's a bit expensive, but it supports and does what we want.

At one point we had a data modeler who wanted to switch to Embarcadero, and it turned out that that was a huge mess so we dropped it. It didn't last very long, but it was a data modeler who came in and wanted to do it in Embarcadero. I think she had an agreement with them and got a bonus for trying to get it converted or approved to convert but it was such a huge mess we didn't do it.

The Embarcadero model is huge. It's got 8,000 attributes in it. Being able to go through and validate that every one of those 8,000 attributes properly converted over to the correct place in Embarcadero was such a massive job. We didn't mess with it. It's not just the attributes, but it's the relationships and table names. It was a huge job so we didn't do it. I suspect if we had gone to Embarcadero, it would have been just fine, but it was just too big of a job.

erwin DM is good. It does the job and it's been around a long time, so I think it would be a good one to use. I don't have any problems with it.

I would rate erwin DM a nine out of ten. Nothing is perfect. I don't have any real issues with it. It does everything we need it to do. It's really good.

The use case was normally to update data model designs for transaction processing systems and data warehouse systems. Part of our group also was doing data deployment, though I personally didn't do it. The work I did was mostly for the online transaction systems and for external file designs.

I didn't use it for data sources. I used the solution for generation of code for the target in the database. Therefore, I went from the model to the database by generating the DDL code out of erwin.

We had it on-premise. There was a local database server on SQL, then we each had a client that we install on our machines.

At one of my previous jobs, we had a lot of disparate databases that people built on their PCs, which were under their desk. We were under a mandate to bring all of that into a controlled environment that our DBAs could monitor, tune, etc. Therefore, this was a big improvement. I put the data that was in whatever source into an Excel spreadsheet, reverse engineering it into a SQL file and putting in the commas, and then I could reverse engineer that SQL into a data model. That saved us a tremendous amount of time instead of building the data model from scratch.

I educated a number of my colleagues who were in data architecture and writing the DDL by hand. I showed them, "You do it this way from the model." That way, you never have to worry about introducing errors or having a disconnect between what is in the model and the database. I was able to get management support for that. We enhanced the accuracy of our data models.

I do like the whole idea of being able to identify your business rules. In my last position, I got acquainted with using it for data lineage, which is so important now with the current regulatory environment because there are so many laws or regulations that need to be adhered to. 

If you're able to show where the data came from, then you know the source. For example, I was able to use user-defined properties (UDPs) on one job where we were bringing in the data from external XML files. I would put it at the UDP level, where the data came from. On another job, we upgraded a homegrown database that didn't meet our standards, so we changed the naming standards. I put in the formally known UDPs so I could run reports, because our folks in MIS who were running the reports were more familiar with the old names than the new names. Therefore, I could run the report so they could see, "This is where you find what you used to call X, and it is now called Y." That helped. 

The generation of DDL saved us having to write the steps by hand. You still had to go in and make some minor modifications to make it deployable to the database system. However, for the data lineage, it is very valuable for tracing our use of data, especially personal confidential data through different systems.

Complete Compare is good for double checking your work, how your model compares with prior versions, and making sure that your model reflects the database design. At my job before my last one, every now and then the DBAs would go in and make updates to correct a production problem, and sometimes they would forget to let us know so we could update the model. Therefore, periodically, we would go in and compare the model to the database to ensure that there weren't any new indexes or changes to the sizes of certain data fields without our knowing it. However, at the last job I had, the DBAs wouldn't do anything to the database unless it came from the data architects so I didn't use that particular function as much.

If the source of the data is an L2TP system and you're bringing it into a data warehouse, erwin's ability to compare and synchronize data sources with data models, in terms of accuracy and speed, is excellent for keeping them in sync. We did a lot of our source to target work with Informatica. We used erwin to sometimes generate the spreadsheets that we would give our developers. This was a wonderful feature that isn't very well-known nor well-publicized by erwin. 

Previously, we were manually building these Excel spreadsheets. By using erwin, we could click on the target environment, which is the table that we wanted to populate. Then, it would automatically generate the input to the Excel spreadsheet for the source. That worked out very well.

When you do a data model, you can detect the table. However, sometimes I would find it quicker to just do a screenshot of the tables in the data model, put it in a Word document, and send it to the software designers and business users to let them see that this is how I organized the data. We could also share the information on team calls, then everybody could see it. That was quicker than trying to run reports out of erwin, because sometimes we got mixed results which took us more time than what they were worth. If you're just going in and making changes to a handful of tables, I didn't find the reporting capabilities that flexible or easy to use. 

The report generation has room for improvement. I think it was version 8 where you had to use Crystal Reports, and it was so painful that the company I was with just stayed on version 7 until version 9 came out and they restored the data browser. That's better than it was, but it's still a little cumbersome. For example, you run it in erwin, then export it out to Excel, and then you have to do a lot of cosmetic modification. If you discover that you missed a column, then you would have to rerun the whole thing. Sometimes what you would do is just go ahead and fix it in the report, then you have to remember to go back and fix it in the model. Therefore, I think the report generation still could use some work.

I don't see that it helped me that much in identifying data sources. Instead, I would have to look at something like an XML file, then organize and design it myself.

I started working with Data Modeler when I was in the transportation industry. However, that was in the nineties, when it was version 1 and less than $1,000.

I found it pretty stable. I didn't have any problems with it. 

Sometimes, when you're working with model Mart, once in a while the connection would drop. What I don't like is that if you don't consistently save, you could lose a lot of changes. That's something that I think should work more like Word. If for some reason your system goes down, there's an interruption, or you just forget or get distracted by a phone call, then you go back and something happened. You might have lost hours worth of work. That was always painful.

I have worked on databases that had as many as a thousand tables. In terms of volume and versioning, it is fine. We've used the model Mart to house versions that introduce another level of complexity to keep the versioning consistent. 

There is a big learning curve with using model Mart. Therefore, a lot of groups don't really fully utilize it the way they should. You need somebody to go in there every now and then to clean things up. We had some pretty serious standards around when you deployed it to production and how you moved it in model Mart. We would use Complete Compare there. It scaled well that way. 

In terms of the number of users, we had 20 to 30 different data architects using it. I don't know that everybody was on it full-time, all the time. I never saw a conflict where we were having trouble because too many people were using it. From that point, it was fine.

I think the team got as large as it was going to get. In fact, right now they're on a hiring freeze because of COVID-19.

Over a period of five or 10 years, the few times I've had to go all the way through to erwin, I talked to the same young lady, who is very good. She understood the problem, worked it, and would give me the solution within two phone calls. This was very good.

Prior to erwin, I had used Bachman and IEF. Bachman I liked better, but IEF was way too cumbersome. 

Bachman was acquired by another company and disappeared from the marketplace. The graphics were very pretty on Bachman. Its strongest feature was reverse engineering databases. I found erwin just as robust with its reverse engineering. 

IEF also disappeared from the marketplace, and I didn't use it very much. I didn't like it, as it was way too cumbersome. You needed a local administrator. It was really tough. It promised to generate code and database as well as supposed to be an all encompassing case tool. I just don't think it really delivered on that promise.

It could very well be that the coding of those solutions didn't keep up with the latest languages. There was a real consolidation of data modeling tools in the last 15 to 18 years. Now, you've only got erwin and maybe Embarcadero. I don't think there's anything else. erwin absorbed a lot of the other solutions but didn't integrate them very well. We were suffering when it didn't work. However, with the latest versions, I think they've overcome a lot of those problems.

Usually, the companies already had erwin in place. We had one company where the DBAs would sort of get us going.

The upgrades were complex. They required a lot of testing. About a year ago, we held off doing them because we wanted to upgrade to the latest version as well as we were in the midst of a very big system upgrade. Nobody wanted to take the time. It took one of our architects working with other internal organizations, then there were about three or four of us who tried to do the testing of the features. It was a big investment of time, and I thought that it should have been more straightforward. I think companies would be more willing to upgrade if it wasn't so painful.

The upgrade took probably two months because nobody was working on it full-time. They would work on it while they could. One of the architects ended up working late, over the weekends, and everything trying to get it ready before we could roll it out to the entire team.

For the upgrades, there were ;at least half a dozen people across three different groups. There were three or four data architects in our group, then we had two or three desktop support and infrastructure people for the server issues.

I think they used Sandhill for the initial installation.

If it's the first time, I recommend engaging a third-party integrator, like Sandhill, whom I found them very good and responsive.

We always had a problem keeping track of all the licenses. All of a sudden you might get a message that your license expired and you didn't know, and it happens at different times. At GM Finance, they engaged Sandhill to help us manage it. I was less involved because of the use of Sandhill, who was very helpful when we had trouble with our license. I remember you had to put in these long string of characters and be very careful that you didn't cut and paste it in an email, but that you generated it. It was so sensitive and really difficult until the upgrades.

if there was a serious problem, then it was usually around the licensing, where there was some glitch in the licensing. Then, we would call Sandhill who would help us out with it. That's something where we had to invoke a third-party for any technical difficulties.

I wish it wasn't so expensive. I would love to personally buy a copy of my own and have it at home, because the next job that I'm looking at is probably project management and I might not have access to the tool. I would like to keep my ability to use the tool. Therefore, they should probably have a pricing for people like me who want to just use the solution as an independent consultant, trying to get started. $3,000 is a big hit.

I think you buy a block of users because I know the company always wanted to manage the number of licenses. 

I really haven't spent a lot of time on other data modeling tools. I have heard people complain about erwin quite a bit, "Oh, we wish we had Embarcadero," or something like that. I haven't worked with those tools, so I really can't say that they're better or worse than erwin, since erwin is the only data modeling tool that I've used in the last 15 years.

There might be some effort to do some cloud work at my previous place of employment, but I wasn't on those projects. I don't think they've settled on how they're going to depict the data.

Some of the stuff in erwin Evolve, and the way in which it meshes with erwin Data Modeler, was very cool.

Sometimes, your model would get corrupted, but you could reverse engineer it and go back in, then regenerate the model by using the XML that was underlying the model. This would repair it. When I showed this to my boss, he was very impressed. He said, "Oh man, this is where we used to always have to call Sandhill." I replied, "You don't have to do that. You need to do this." That worked out pretty well.

Biggest lesson learnt: The value of understanding your data in a graphical way has been very rich in communicating to developers and testers when they recognize the relationships and the business rules. It made their lives so much easier in the capturing of the metadata and business English definitions, then generating them. Everybody on the team could understand what this data element or group of data elements represented. This is the biggest feature that I've used in my development and career.

I would rate this solution as an eight out of 10.