erwin Data Modeler Reviews

We use the Workgroup Edition for sharing data models across the organization. The primary reason we're using the Workgroup Edition over the Standard Edition is the centralized repository of models.

Standard Edition requires individuals to determine how to share data models, whether you share them in a local LAN directory, through email, SharePoint, or Livelink. You have to come up with your own versioning scheme and your method for sharing models. With the Workgroup Edition, because it has the centralized repository with version control embedded in it, it standardizes how your organization does versioning and centralizes all the models at the same time.

The solution's ability to compare and synchronize data sources with data models is fantastic. We use it for that on a regular basis to make sure that changes haven't been made to the database outside of the modeling process. I can take existing databases and reverse engineer them and understand their structure within 15 minutes. If I didn't have Data Modeler it would take hours. It increases our productivity and helps in understanding our legacy application.

The organization that I'm currently with has not historically done data modeling as a discipline. We're using the tool to introduce data modeling into the organization because it is an intuitive tool. There are other modeling products on the market that aren't as intuitive, tools that are currently in use at my company. With this tool, we have an easier ramp-up with our new staff because it is more intuitive.

The solution's support for Snowflake affects our organization's data modeling tremendously because we didn't have a decent tool for the Snowflake product. There are a couple of tools on the market, but they are not good modeling tools. The fact that erwin Data Modeler supports Snowflake is a huge benefit to this organization. The existing procedures couldn't be satisfied with the tooling that my company was using. It's a huge plus because it was difficult for teams that are migrating to Snowflake to adhere to the internal company standards of data modeling, because there were no products that offered Snowflake as one of the solutions.

It also reduces development time because you don't have to write DDL manually anymore. You use the data modeling tool to generate the DDL. It reduces development time by about 10 percent. Workgroup's code generation helps to ensure accurate engineering of data sources, which reduces the number of errors during development. If someone is writing DDL by hand and they don't get the syntax right, they have to figure out what's wrong with it to be able to fix it. It helps you build your table structures more quickly so that you can actually begin development of the business logic in your application layer.

The most valuable features of the Workgroup Edition are the

• centralization of the models
• flexibility of the directory structure
• application of the naming standards across all models in the repository.

The centralization of models helps share models across the organization. Instead of having to email someone and say, "Hey, where did you put the model for this?" it's easily found. It also makes it easy to organize models. When you work in a large organization that has more than 1,000 models, you need to be able to organize them in some fashion.

Historically, the Workgroup Edition had a flat structure so you had to name a model in a particular way to be able to find it, when you had thousands of models. With the current version, because you have a flexible directory, you can organize your models any way that your organization feels would work well.

In addition, the visualization side of erwin really helps people to understand the structure of their data. It greatly enhances their ability to create the appropriate modifications to their existing structure, because they can graphically see how their structure is currently laid out. It helps with maintenance on existing applications, and it dramatically helps, when you're doing greenfield, in understanding your data requirements in a graphical format. The graphical aspect helps non-technical people to understand the database design. For the non-technical folk, it is very helpful for understanding the design and whether or not the design is meeting their requirements.

For anyone who's interested in the data design of an application, or a warehouse, the erwin Data Modeling tool is very helpful. That's especially true for people who don't understand the structure of databases. It helps them understand the relationships between tables, and what is contained within a table. It's an understanding that they don't have without this kind of product.

I would like to see the ability to support more NoSQL platforms more quickly. 

In addition, enhancing the graphics to render more quickly would be beneficial for any user.

I've been using erwin Data Modeler since 1992. In my current company, they were already using Data Modeler when I started in December of 2020, but I'm implementing the Workgroup Edition. They didn't have that.

Workgroup is a really stable product. 

The challenges I have found with it, from a stability perspective, are simply because of the sizes of the organizations that I have worked at. The sizes of some of the warehouses we have are quite ridiculous. When you get upwards of 5,000 tables and a million columns in a single model, the tool shows symptoms, primarily, of memory issues, and it becomes slower. To be frank, it's a result of poor design of a legacy database in the first place. It's not a fault with the erwin product, rather it's the fault of the people who designed that database.

In the past, we have had problems with scalability, but the vendor has fixed all of those issues over the last two years. I contacted them directly and they fixed things in the product for all of their clients.

Their tech support is adequate. It's easy to elevate an issue if I run into support personnel who aren't capable of handling it.

The company that I'm with now uses IBM InfoSphere Data Architect. We're switching to erwin because the IBM product is inferior and it is in maintenance mode and will not be supported. It also does not support Snowflake or any non-relational databases, such as Cassandra or Couchbase or Mongo. Workgroup does.

The initial setup of Workgroup is easy. The installation software is very straightforward.

You make the rest of it as difficult as your organization needs it to be. The directory structure that you establish is dependent on what your organization requires. In addition, it offers two different methods of user-authentication and four different profiles to manage the security of who can do what within the centralized repository. It gives you complete flexibility for your data modeling practice to be as open or as closed as your organization desires.

The amount of time the deployment will take will be dependent upon the specifics of an organization's modeling. In a large organization, you can't just install software. You have to go through a process that takes weeks, such as packaging the software for distribution onto desktop. The back end of the Workgroup Edition, which provides you the centralized repository, is an easy implementation. It's the directory structure, and the security that you want as an organization, that drive complexity into the deployment. If I wanted to let every person in the organization modify every model, I could be done in a day. If I need 20 different Active Directory groups and different levels of security, then I have to think through how I want my organization to use the tool, to set up the security appropriately. The tool itself makes it very easy to do that. The hard part is deciding how you want your organization to operate.

We work directly with erwin.

I don't think we'll have any return on investment in the near term. It's more of a long-term investment and a change in the culture of the company. It will take time before it shows any ROI.

The tool is definitely worth its price.

We looked at ER/Studio. We chose erwin because ER/Studio does not support Snowflake or Cassandra or Couchbase. They do support Mongo, but that isn't a database that we use.

You really need to sit down and consider how you want to organize your models, and how you should set up security, based on your organization's needs. The bigger the company, the more complex it can be, so you really need to think that through prior to implementing.

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

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

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

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

We find a few of erwin tools most valuable:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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.

For the first 30 years of my career, I worked on many small projects. Since erwin was released, I used it to help develop projects up until about two years ago. At that time, I moved to a new company and I still use erwin in my current role.

When I moved to the new company, I recommended erwin and explained it to my colleagues and my clients. When the most recent version was released, I looked at the licensing and became familiar with its new features and benefits.

I have developed a couple of projects myself in the past two years, including one that had to do with mail, in Serbia, which was an interesting project. Another and the other to do with handling automotive equipment maintenance. One of the projects is something that I started from the beginning, whereas the other was reengineered with changes made and new features added.

I have also worked with erwin from a higher-level role. Rather than developing smaller projects, I have taken responsibility for a much larger project worth several million Euros.

In general, if you start using erwin from the beginning of a project then it provides a lot of benefits. You have to start with the process modeling, and then find data and create an entity, and the process continues. Essentially, you have to have something before you create the data model. However, if you're talking about reengineering a project that has existing data models or existing processes, then the benefits of using erwin are really big. You can save 50% of the time if you're working on reengineering existing processes or existing data models.

The visual data models are okay for helping to overcome data source complexity. If the project is started with erwin from the beginning then I can create the database, stored procedures, and everything that I need. However, when it comes to reengineering an existing product, and if the database changes then some of the stored procedures, as well as other things also need to change. For example, in one project, the original database was Informix and the new one is Microsoft SQL Server.

The erwin ETL functionality has room for improvement when it comes to mapping databases with a classic entity-relationship model to a data warehouse model. If you have a legacy database like Informix, Oracle, SQL Server, or something similar, then you need to create a data warehouse database. These use completely different logic and you need to create some procedures to map the tables.

The number of databases should be extended.

To have more documentation or available knowledge on how to connect is very important. This is probably the most important issue that I have experienced. Specifically, I would like more information on how to connect, how to transfer, and how to do the mapping from a legacy database.

If you try to open a file from an older version of erwin, you can only open files from one version back. This is all that they support, so they need to add the option of opening all older versions. As it is now, they push people to buy a new version every year.

We have been using erwin since the beginning when it was first released by Logic Works in 1993.

There is absolutely no problem with the stability.

In terms of scalability, there is not enough long-term support for each version of erwin. In the past, the extensions of some erwin models, or files were ER1. After that, the file extension was ERW and now it is ERAN, which created some confusion.

In my current company, I am the only person using erwin because we are not specialists in development. In my previous company, five or six people were using it.

The support is okay and I am satisfied with it. However, it's a little slower getting support for the role that I'm in now, as compared to when I was at my previous company.

In the past, the support was always okay. Within a few hours, I either had an answer or was at least speaking with them. We sent emails to discuss how to solve the problem.

Overall, I'm really satisfied with the support.

I have used several other modeling tools in the past, including SAP PowerDesigner and Bizagi. My experience with them has depended on what I needed to do. For example, Bizagi has a completely different way of developing a model. I am not satisfied with it because they don't follow the rules for relational modeling.

On the other hand, Power Designer is quite a good tool that works well. It's a complex tool that can be used for data modeling and process modeling. They use BPMN methodology and in terms of functionality, it has enough. From a cost perspective, it is cheaper than erwin.

The initial setup is straightforward, it was no problem.

The installation can be done in five minutes. The new version may take a little longer, but it is very fast.

When we have completed, we have erwin come to analyze the process.

We start with global entities, or how I can see it on a higher level without talking about the relationship model. I am looking for the relation, and foreign keys, then we search for the stored procedure and functions.

We look at the first creating the keys, the primary and alternative keys in the tables, entities, and at the end, we develop the indexing. The indexing requires daily analysis when you put the database in operation they look at the speed of everything. you can change the indexing to make your database faster.

In my previous company, there we had a really large return on investment from using erwin. In one of the systems that we re-engineered, there were more than 2,000 tables. If these had to be created from the beginning then it would have taken a really long time to collect all of the information. When it comes to reengineering, the database usually stays the same with perhaps 20% to 30% of the model being modified.

In my current company, we are trying to educate our clients on using erwin. Many of them are not using it in their everyday business. The problem is that bigger organizations, like government departments, usually want to have somebody from outside their own organization develop the solution.

The price of erwin Data Modeler is very expensive, in particular for this part of the world. I think that for the United States and Europe, the price is probably okay. However, in Serbia, the salary of an IT engineer is perhaps 50% of what it is in the United States. Because of this, erwin needs to have a different pricing model for different countries.

For example, you cannot sell products in places like Serbia, Croatia, Bosnia, Bulgaria, Romania, and other places in this part of Europe at the same price as countries like Germany, Norway, or the United States. This is something that needs to change from a licensing perspective.

In terms of erwin's code generation and the accurate engineering of data sources, for some of the databases, it is quite okay. However, in others, it is not exactly following the rules of the database in the way that I want to generate the model.

There are two ways to generate a model. The first is to create a schema, which is a textual file that contains everything needed to create a complete database structure. The second is to have erwin connect to the databases directly. In this case, erwin installs and creates the database.

In some cases, it is better to first create a DB schema, which is an SQL file where you can look for syntax errors or other problems in the code. Once complete, you can create the database, including the tables and everything else.

When I start to use erwin in a project, it is normally right after I analyze the process. The second thing I do is look at the global entities, so I can view the system from a high level without dealing with the relationship model. After that, I start looking for relationships, creating the primary and alternative keys in the table. I then start looking for foreign keys. At that stage, I begin to look for stored procedures and functions. After this, I work on the creation of indexes.

The indexing needs to be analyzed daily, once the database is put into operation. This helps with database performance. When you change the indexing, the database gets faster.

My advice for anybody who is planning to use erwin is that sometimes, it should be used to develop models right from the beginning. It will depend on the project, as well as the organization and the experience that they have with erwin. It is also possible to have different people and different teams from the same company working on one model. For example, we have three development centers that are all working on the same model.

The biggest lesson that I have learned from using erwin DM is that it pushes you to use the notation and methodology exactly. You must follow the rules. Several years ago, they started adding tools and options that are used to verify a model, and this functionality helps to point out mistakes in the models. Once the model is correct, you can move on to working with the databases and the specifics of each one. You can move very easily between databases such as Informix, Oracle, and MySQL, without losing much time.

I would rate this solution a ten out of ten.

We use erwin DM as a data modeling tool. All projects in the data warehouse area go through the erwin model first and get reviewed and get approved. That's part of the project life cycle. And then we exude the scripts out of DM into Snowflake, which is our target database. Any changes that happen after that also go through erwin and we then make a master copy of the erwin model.

Our solution architecture for projects that involve erwin DM and Snowflake is an on-prem Data Modeler desktop version, and we have a SQL database behind it and that's where the models are stored. In terms of erwin Data Modeler, Snowflake is the only database we're using.

We are not utilizing a complete round-trip from DM for Snowflake. We are only doing one side of it. We are not doing reverse-engineering. We only go from the data model to the physical layer.

We use erwin Data Modeler for all enterprise data warehouse-related projects. It is very vital that the models should be up and running and available to the end-users for their reporting purposes. They need to be able to go through them and to understand what kinds of components and attributes are available. In addition, the kinds of relationships that are built in the data warehouse are visible through erwin DM. It is very important to keep everybody up to the mark and on the same page. We distribute erwin models to all the business users, our business analysts, as well as the developers. It's the first step for us. Before something gets approved we generally don't do any data work. What erwin DM does is critical for us.

erwin DM's support for Snowflake is very helpful from the data modeling perspective and, obviously, the JDBC and native connectivity also helps us in simplifying the push mechanism we have in erwin DM. 

Primarily, we use erwin for data modeling only, the functionality which is available to do logical models and the physical model. Those are the two areas which we use the most: we use a conceptual model first and the logical model, and then the physical model.

When we do the conceptual data model, we will look at the source and how the objects in the source interact, and that will give us a very clear understanding of how the data is set up in the source environment. The logical model gives developers, as well as the data modelers, an understanding of exactly how each object interacts with the others, whether a one-to-many, many-to-many, many-to-one, etc. The physical model, obviously, helps in executing the data model in Snowflake, on the physical layer.

Compatibility and support for cloud-based databases is very important in our environment because Snowflake is the only database to which we push our physical data structures. So any data modeling tool we use should be compatible with a cloud data warehouse, like Snowflake. It is definitely a very important functionality and feature for us.

We are planning to move, in 2021, into their server version, where multiple data modelers can work at the same time and share their models. It has become a pain point to merge the models from individual desktops and get them into a single data model, when multiple data modelers are working on a particular project. It becomes a nightmare for the senior data modeler to bring them together, especially when it comes to recreating them when you want to merge them. That's difficult. So we are looking at the version that will be a server-based model, where the data modelers can bring the data out, they can share, and they can merge their data models with existing data model on the server.

The version we're not using now—the server version—would definitely help us with the pain point when it comes to merging the models. When you have the desktop version, merging the models, two into one, requires more time. But when we go over to the server, the data models can automatically pull and push.

We will have to see what the scalability is like in that version.

Apart from that, the solution seems to be fine.

I've been using erwin DM for years, since the early 2000s and onwards. It's a very robust tool for data modeling purposes.

We have five to seven data modelers working on it at any moment in time. We have not seen any scalability issues, slowness, or that it is not supporting that level of use, because it's all desktop-based

When we go into the server model, where the web server is involved, we will have to see. And the dataset storage in the desktop model is also very limited, so I don't think going to the server model is going to impact scalability.

In our company, erwin DM is used only in the data warehouse area at this moment. I don't see any plans, from the management perspective, to extend it. It's mostly for ER diagrams and we will continue to use it in the same way. Depending on the usage, the number of concurrent users might go up a little bit.

I have interacted with erwin's technical support lately regarding the server version and they have been very proactive in answering those questions as well as following up with me. They ask if they have resolved the issue or if anything still needs to be done. I'm very happy with erwin's support.

The biggest lesson I have learned from using erwin DM, irrespective of whether it's for Snowflake or not, is that having the model upfront and getting it approved helps in reducing project go-live time. Everybody is on the same page: all the developers, how they interact, how they need to connect the various objects to generate their ETL processes. It also definitely helps business analysts and end-users to understand how to write their Tableau reports. If they want to know where the objects are, how they connect to each other, and whether they are a one-to-one or one-to-many relationship, etc., they can get it out of this solution. It's a very central piece of the development and the delivery process.

We use Talend as our ETL and BI vendor for workload. We don't combine it with erwin DM. Right now, each is used for its own specific need and purpose. erwin DM is mostly for our data modeling purposes, and Talend is for integration purposes.

Overall, erwin DM's support for Snowflake is very good. It's very stable and user-friendly and our data modelers live, day in and day out, on it. No complaints. There is nothing that impacts their performance.

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

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

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

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

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

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

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

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

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

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

I have been using erwin for twenty years. 

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

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

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

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

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

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

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

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

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

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

We have seen ROI.

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

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

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

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

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