erwin Data Modeler by Quest Reviews

Our company is the solution's only partner and reseller in China. We use the solution to provide data lineage to our customers' production environments. Most of our customers are in the mid-sized range. 

The data lineage feature is very valuable. 

There is a lack of local support in the China region. 

The solution needs to be available in the Chinese language. 

I have been using the solution for 15 years. 

On occasion, we experience some issues with performance so the stability is rated a seven out of ten. 

The solution is scalable.

Local support is lacking in the China region. We try to seek support but also have to do our own research to resolve technical issues. 

The setup is easy and there are only a few steps. You just download the package and install it in the customer's environment. 

We implement the solution for customers and deployments take several days. We handle everything so the customer can just start using the solution. One person can handle setup and deployment. 

There are two license options and the pricing is reasonable.  

The solution is the best option in the market. I rate it 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.

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

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

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

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

This is a very complex product.

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

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

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

We are using version 9 or 9.1.

Pricing is very high compared to any other product.

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

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.

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

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.