erwin Data Modeler by Quest Reviews

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

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

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

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

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

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

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

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

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

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

I've been using erwin Data Modeler since 2014.

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

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

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

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

We did not have a previous solution.

The initial setup was pretty straightforward. 

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

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

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

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

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

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

We pay on a one-year subscription basis.

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

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

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

We use it for our conceptual business-data model, for logical data modeling, and to generate physical database schemas. We also create dimensional modeling models.

One of the ways Data Modeler has benefited our company is that it gives us the ability to engage with the business alongside IT, because it's friendly. It has friendly views that we can use when we meet with them. They can follow them and understand them. That increases the quality and accuracy of our IT solutions.

The solution's ability to generate database code from a model for a wide array of data sources helps cut development time. We generate all the DDL for our hub through a modeling exercise and generate the alter statements and maintenance through the erwin modeling tool. I would estimate that reduces development time by 30 to 40 percent because it's so accurate. We don't have to go back in. It takes care of the naming standards and the data types. And because we use OData, we generate our service calls off of those schemas too. So that's also more accurate because it uses what we've created from the model all the way through to a service call with OData.

I find the logical data modeling very useful because we're building out a lot of our integration architecture. The logical is specific to my role, since I do conceptual/logical, but I partner with a team that does the physical. And we absolutely see value in the physical, because we deploy databases for some of those solutions.

I would rate erwin's visual data models very highly for helping to overcome data source complexity. We have divided our data into subject areas for the company, and we do a logical data model for every one of those subject areas. We work directly with business data stewards. Because the logical and the conceptual are so easy to look at, the business side can be very engaged and collaborate on those. That adds a lot of value because they're then governing the solutions that we implement in our architecture.

We definitely use the solution's ability to compare and synchronize data sources with data models. We have a data hub that we've built to integrate our data. We're able to look at the data model from the source system, the abstracted model we do for the hub, and we can use erwin to reverse-engineer a model and compare them. We also use these abilities for the lifecycle of the hub. If we make a change, we can run a comparison report and file it with the release notes.

I would like to see improved reporting and, potentially, dashboards built on top of that. Right now, it's a little manual. More automated reporting and dashboard views would help because currently you have to push things out to a spreadsheet, or to HTML, and there aren't many other options that I know of. I would like to be able to produce graphs and additional things right in the tool, instead of having to export the data somewhere else. And that should work in an intuitive way which doesn't require so much of my time or my exporting things to a spreadsheet to make the reporting work.

I've used the erwin Data Modeling tool since about 1990. I work more with the Standard Edition, 64-bit.

It's stable. This specific tool has been around a long time and it has matured. We don't encounter many defects and, when we do, a ticket is typically taken care of within a couple of days.

We're using standalone versions, so we don't need to scale much. In the Workgroup Edition we've got it on a server and we have concurrent licensing, and we've had no issues with performance. It can definitely handle multiple users when we need it to.

At any time we have six to 10 people using the Workgroup Edition. They are logical data modelers and DBAs.

We've already increased the number of people using it and we've likely topped-out for a while, but we did double it each year over the past three years. We added more licenses and more people during that time. It has probably evolved as far as it's going to for our company because we don't have more people in those roles. We've met our objectives in terms of how much we need.

I would rate erwin's technical support at seven out of 10. One of the reasons is that it's inconsistent. Sometimes we get responses quickly, and sometimes it takes a couple of days. But it's mostly good. It's online, so that's helpful. But we've had to follow up on tickets that we just weren't hearing a status on from them.

They publish good forums so you can see if somebody else is having a given problem and that's helpful. That way you know it's not just you.

We did not have a previous solution.

I've brought this tool into four different companies, when I came to each as a data architect. So I was always involved early on in establishing the tool and the usage guidelines. The setup process is pretty straightforward, and it has improved over the years.

To install or make updates takes an hour, maybe.

A lot of the implementation strategy for Data Modeler in my current company was the starting of a data governance and data architecture program. Three years ago, those concepts were brand-new to this company. We got the tool as part of the new program.

For deployment and maintenance of the solution we need one to two people. Once it's installed, it's very low maintenance.

We did it ourselves, because we have experience.

We're very happy with the return on investment. It has probably exceeded the expectations of some, just because the program is new and they hadn't seen tools before. So everyone is really happy with it.

erwin's automation of reusable design rules and standards, especially compared to those of basic drawing tools, has been part of our high ROI. We're using a tool that we keep building upon, and we are also able to report on it and generate code from it. So it has drastically improved what was a manual process for doing those same things. That's one of the main reasons we got it.

We pay maintenance on a yearly basis, and it's a low cost. There are no additional costs or transactional fees.

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

We looked at a couple of solutions. Embarcadero was one of them.

erwin can definitely handle more DBMSs and formats. It's not just SQL. It has a long list of interfaces with Oracle and SQL Server and XSD formats. That's a very rich set of interfaces. It also does both reverse- and forward-engineering well, through a physical and logical data model. And one of the other things is that it has dimensional modeling. We wanted to use it for our data warehouse and BI, and I don't believe Embarcadero had that capability at the time. Most tools don't have all of that, so erwin was more complete. erwin also has several choices for notation and we specifically wanted to use IDEF notation. erwin is very strong in that.

The con for erwin is the reporting, compared to other tools. The interface and reporting could be improved.

My advice would depend on how you're going to be using it. I would definitely advise that, at a minimum, you maintain logical and physical views of the data. That's one of the strengths of the tool. Also, while this might sound like a minor thing, it's important to create standard templates — Erwin is good at that — and you can customize them. You can create a standard template so that your models have the same look and feel. And then, anyone using the tool is using the same font and the same general layout. erwin's very good at helping enforce that. You should do that early on so that you don't have to redo anything later to make things look more cohesive.

Another feature of erwin is that it can help you enforce your naming standards. It has little modules that you can set up and, as you're building the data model, it's ensuring that they conform to the naming standards that you've developed. I think that's something that some people don't realize is there and don't take advantage of.

The biggest lesson I have learned from using this solution faces in two directions. One is the ability to engage the business to participate in the modeling. The second is that the forward-engineering and automation of the technical solution make it more seamless all the way through. We can meet with the business, we can model, and then we can generate a solution in a database, or a service, and this tool is our primary way for interacting with those roles, and producing the actual output. It's made things more seamless.

We work on different platforms like SQL Sever, Oracle, DB2, Teradata and NOSQL. When we take in requirements, it will be through Excel spreadsheet which is a Mapping Document and this contains information about Source and Target and there mapping and transformation rules. We understand the requirements and start building the conceptual model and then the logical model. When we have these Data Models built in erwin Data Modeler tool, we generate the PDF Data Model diagrams and take it to the team (DBA, BSAs, QA and others)  to explain the model diagram. Once everything is reviewed, then we go on to discuss the physical Data Model. This is one aspect of the requirement from Data Warehouse perspective. 

Other aspect of the requirement can be from the operational systems where the application requirements might come through as DDLs with SQL extension files where we reverse engineer those files and have the models generated within erwin Data Modeler. Some of them, we follow the same templates as they are. But some others, once we reverse-engineer and have that Model within the erwin, we make changes to entity names, table names and capture metadata according to RBC standards. We have standards defined internally, and we follow and apply these standards on the Data Models.

There are different access level permissions given to different users who are Data Modelers, Data Architects, Database Administrators, etc. These permission have read, write and delete options. Some team members only have read-only access to the Data Models while others have more. Therefore, this helps us with security and maintain the Data Models.

The solution’s ability to generate database code from a model for a wide array of data sources cuts development time in only some scenarios for us where we have the data model build into the erwin tool. E.g., I can generate a DDL for the DBAs to create tables on the database. But, in other scenarios, it will be the DBAs who will access the erwin tool with read-only access. They will fetch the DDLs from the models that we created. Once the DDL is generated from the erwin tool, it is all about running the script on the database to create tables and relationships. There are some other scenarios where we might add an index or a default value based on the requirements. 90 percent of the work is being done by the tool.

The solution’s code generation ensures accurate engineering of data sources, as there is no development time. Code doesn't even have to be reviewed. We have been using this solution for so long and all the code which has been generated is accurate with the requirements. Once we generate the DDLs out of the erwin tools, the development team does a quick review of the script line by line. They will just be running the script on the database and looking into other requirements, such as the index. So, there is less effort from development side to create tables or build a database.

We have a very large number of operational and Data Mart Data Models inside of the erwin tool. It has a huge volume of metadata captured. Therefore, when we are working on a very large requirement, there is an option called Bulk Editor where we can input large files into the erwin in one shot to build the Data Mode with much lesser time. All the built-in features are easy to use.

We make use of the solution’s configurable workspace and modeling canvas. All the features available help us to build our Data Model, show the entities, and the relationship between the entities, define the data types and add description of the entities and attributes. With all of this we can take out the PDF version of the Data Model diagram, then send them across for any teams to review.

Not to forget the version saving feature. Every time we make changes by adding, deleting and modifying to the Data Models and save, the tool automatically create a new Data Model versions so we don't lose any work. We can go back to the previous versions and reverse all the changes and make it a current version if needed.

Some Source official systems give us DDLs to work with and they have contents not required to be part of the DDL before we reverse engineer in the erwin DM. Therefore, we manually make changes to those scripts and edit them, then reverse-engineer within the tool. So, it does take some time to edit these DDL scripts generated by the source operational systems. What I would suggest: It would be helpful if there were a place within the erwin tool to import the file and automatically eliminate all the unnecessary lines of code, and just have the clean code built-in to generate the table/data model.

I have been using this tool for five years. I have used this tool at my previous companies as well as in my current company.

One recent scenario that we came across was in our day-by-day activities, where Data Models are growing in very large numbers. For some reason, the performance was bit low. It was suggested to upgrade to the newer version, which is erwin Data Modeler 2019 R1. So, we are already in the process of moving into the newer version. Once we migrate, we will do all the user testing to see how the performance has increased from the previous version. If there still are any performance issues or other features errors, we will get back to the support team.

So far, whenever we have moved to a newer version, there has always been a positive result. We keep that version until we see a newer version. Every six months or once a year, we get in touch with the erwin support team to ask for any suggestions to see if any new features added and any enhancement to the newest version. Or, is it a right time to move into the newest version or just stick to our current version? They suggest based on our use cases and requirements.

For deployment and maintenance of this solution, five to 10 people are needed. E.g., two people are involved from our team, two DBAs, and two people from the server team and other teams.

What we have is a huge volume of data so far. We have a very large number of Data  Models with Operational Systems, Data Marts and it still has room for extension and expansion. 

Within my current company, this product has been accessed by Data Modelers, Database Administrators, Data Architects, and Data Scientists. 50 to 100 people have access to this solution.

Once a year or every two years, we upgrade to the latest version. If we are looking for any new features or enhancements to be used for new use cases or requirements, we get in touch with the erwin support team. They are very helpful in understanding and providing the best possible suggestions and solutions with a very impressive SLAs. They really guide us and give us a solution when we have to upgrade versions.

I have not used another solution with my current company. While I have used other solutions before, the majority of the time, I have been with erwin Data Modeler.

Whenever there is a new release, we do the testing, installation from scratch. The initial setup is straightforward. Once you install the product, it downloads onto your system. Once you double click, it gives you the basic instructions, like any other product. You just have to click on "next", where everything is configured already. 

Somethings might be company-specific requirements. For these, you have to make sure you select the right options. Apart from that, everything is straightforward. Until you get to the last page, where you give it your Server details and selecting the windows credentials to log in, and that is company specific.

Once we have it on the production environment, privileges are given only to Data Modelers who can read, write, and delete to design the Data Model.

This is implemented in-house where this software is packaged by Application Support team who deploys it on the production environment on our internal Software Center application. To download and install this solution takes about 40 to 50 minutes.

We haven't moved away from this product for a very long time. I am sure the company has seen benefits and profits out of the solution, saving a lot of work effort and resources.

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

This company had bought the license for three years, and it's not an individual license. While you can buy a license for each individual, that would be very expensive. There is something called concurrent licenses where you can purchase licenses in bulk and 15 to 20 people can access the license and model. Concurrent licenses are scalable to the number of users and are proportional to the cost. 

When I joined the company, the product was already here. Our internal team will have a meeting to discussion on new releases of this product. When we talk to the erwin support team, we ask, "What are the newest features? Will these be beneficial for our company based on the requirements and use cases?" Once everyone has given their opinion, then we move forward in upgrading to newer version considering the performance, new features or enhancements.

For our use cases and requirements, we are very happy with the erwin product. If we come across any issues or have any doubts about the tool, we get really good support from erwin support team.

They definitely have a positive impact on overall solutioning because of how they design and capture data. This is definitely something any company who is involved with data should look into, specifically when there are many database platforms and dealing with huge volume of data. It is definitely scalable as well, as we are one of the biggest financial institutions and have a very massive Data Models inside this tool.

The biggest lesson learnt from using this solution is how we can capture metadata along with the data structure of the database models. Sometimes, when we go to the business showing the designs of the conceptual/logical model, they want to understand what the table and each field is about. So, we do have an option to go into each entities/attributes to add the respective information and show them the metadata captured for these entities and attributes.

I would rate the newest releas as 9.5 out of 10. When our requirement use case change, the solution moves to a newer version and everything works fine. We are happy with that. However, as time goes, a year or two, we might come across some situations where we look for better enhancements of features or newer features.

erwin Data Modeler does conceptual, logical, and physical database or data structure capture and design, and creates a library of such things.

We use erwin Data Modeler to do all of the levels of analysis that a data architect does. We do conceptual data modeling, which is very high-level and doesn't have columns and tables. It's more concepts that the business described to us in words. We can then use the graphic interface to create boxes that contain descriptions of things and connect things together. It helps us to do a scope statement at the beginning of a project to corral what the area is that the data is going to be using.

Then we do logical data models, which are completely platform-independent. They're only about datasets, the owned attribution, and different key analyses to determine what primary keys we want.

And then we do database designs, which relates to the physical data models. 

We also do reverse-engineering where we are capturing the catalogs of existing systems, or purchased software, or even external vendor datasets. They send us data sets and we can reverse-engineer what they send us, especially the backup snapshots where a vendor in the cloud will send data as a backup restore. So to help the documentation for the reporting team, we do reverse-engineering so that they know what the table and column structure look like, along with sizing, nullability, and keys and constraints.

erwin is on-prem. We have the Workgroup Edition, which means that we don't just have client-side software. We have client-side software that stores the data models back into a database which is on an on-prem server.

When I got to my current company two years ago, it didn't have any collection of its data assets into reporting services. If someone wanted to know where a social security number was in all the databases, they had to download all of the structures and do all of the research. I came in and did a full production-environment, reverse-engineer library. Once I did that using erwin front end, I could help the CCPA team find the PII data by simply doing Workgroup Edition Data Mart reports that crossed all of the environments. 

The cool thing about that is that the erwin models will bring in data from a dozen or two dozen different platforms. But once those models are in your Mart structures, you can do your search, looking for something like names of columns, across all of them. So you could be doing a search across Oracle, PostgreSQL and, because it's in your library, you can look at your assets holistically. For us, we went from zero to 500,000 columns of information. You can do that in Excel or in other ways, but this is a very simple way to do it. And you don't need to be highly-trained and skilled. You could actually bring in a college intern and set them loose with creating those libraries for you. Not needing highly-skilled people is one of the great things about erwin. It's very intuitive and it's not hard to use.

At my current company, we're not using it for much custom work, but in my past, the solution's ability to generate database code from a model for a wide array of data sources absolutely helped to cut development time. If you do your design on paper or in an erwin model before the developers start coding, and you review them to make sure that you've got everything in there, you do much less break-and-fix. If you can have an overview model, even for your Agile developers, and say, "This is where we're going," even if you don't deploy at all, it makes it much simpler. You don't have to drop your structures and recreate and reload your test data because you're pretty confident you've gotten your database design right, before people start coding.

erwin improves your standards because your naming standards and your design standards can all be reviewed much easier. You can make sure that misspellings, for instance, don't get all the way to production, or to the point where you have to live with them because people are already coding against them. You can do so much more QA analysis on your structure before it's deployed, if you're using a model.

You could probably use something like Visio to draw boxes and lines, especially for conceptual, very high-level things. But when you're getting down to the database level, where you're building a design and you're creating DDL out of it, or you're going in the other direction where you're reaching into system catalogs and bringing things back, that starts to really require specialization. Visio isn't going to reverse-engineer that for you. Those features in erwin are valuable.

In addition, erwin has versioning so you can keep versions, over time, of those models and you can compare any version to any version. If you're looking at a specific database and you want to see what changed over time, that's really useful. You can go back to a different version or connect that to your change-control processes so you can see what was released when.

With versioning, you can also compare between development environments and production environments. You can see what may not have actually changed or what changes are in the works. It also enables you to do the kind of troubleshooting where you're looking at: Why on this server does this copy of something seem to behave differently than on that server? erwin highlights that really quickly for you. You don't have to closely eyeball your comparison. erwin creates a report that comes back and says what is different. And you can focus on almost anything, from the privileges in the catalog to a data type or a name anomaly. Even for servers that are case-sensitive in their structure, it will tell you the difference between something in all-caps and something that's mixed-case. If you're getting to that level of detail when you're troubleshooting, erwin is great at doing that sort of thing.

In terms of the solution's visual data models for helping to overcome data source complexity, erwin shows you "what is," if you're talking about the physical layer. When it comes to being able to make things clearer and more understandable, it depends on what your structure is. If you've just reverse-engineered SAP, it's abbreviated German. You may need other tools to help you understand it. If you're doing forward work — if you're going from conceptual to logical to physical — erwin is fabulous at letting you change what you see in the graphic. You can change your data model from just looking at primary keys to looking at primary keys and foreign keys, to looking at just the definition of the table in boxes. It allows you to change that visualization depending on your audience. If you're working with the DBAs, you can add metadata and it expands the box showing the visual of the table structure, so you can concentrate on just data types, or you can do data types and nullability and foreign keys, and all different sorts of things. You can do the indexes on top of it as well. You could end up with a table graphic that's the width of your screen if you've added all the details in.

And if it's too hard to look at that way — if you're trying, for instance, to make sure that EmpID Is always a varchar 250 — it also has the ability to take that graphic and move it into what's called the Bulk Editor. That looks much more like an Excel spreadsheet, within a view in your erwin model. You can sort your Excel spreadsheet by column name and see all of the details next to it. That way, everywhere EmpID shows up in that model, it is now in more of a column-row view, and you can easily look at that to make sure that all the EmpIDs say varchar 250. If you see one that's wrong, you can actually change it in the Bulk Editor and it changes it in the graphic automatically, because an erwin model really isn't a graphic, it's much more like a little Access database. So when you change it on one view, it fixes it in the other.

In addition, anybody using erwin to do forward engineering will find the solution's ability to compare and synchronize data sources with data models, in terms of the speed of keeping them in sync, to be almost instantaneous. You can connect an erwin data model to a database and deploy your changes, or you can deploy just delta changes. Or you can deploy one little piece because you've identified one little piece of your model. But most of comparing and synchronizing data sources with data models comes down to people and process. The tool will absolutely help you get there, but it's not going to take on all of the requirements of putting standards and processes in place. If you haven't tied your erwin Data Modeler to your change-control, it can't help you. So it's not a dynamic connection to your servers, it's just a tool that you can use with your environments.

Also, while I'm not configuring erwin, I do have templates that erwin lets me set up to configure models: different templates do colors and domains and prebuilt macros for definitions, based on different things. You don't have to configure erwin. You just have to tell it what sort of a platform you're either going to or coming from. You can also set up some draw templates and customize the colorization of different things. If you want all your primary keys to be red, you can configure that, and set that up as a template.

Finally, the solution's code generation ensures accurate engineering of data sources. With reverse-engineering, I have found it to be completely accurate. I've never found a time when it didn't get the source information correctly into the model. If you're doing a data warehousing project, where you're going from source to target, erwin can produce an extremely comfortable and dependable and trusted graphic of where you're coming from, while you design where you're going to. You know what the data types are, what the nullability is — the structure of the data. You don't know all the characterizations of data values because erwin is not profiling data values. It's just picking up the catalog structure of the tables. But it is completely trustworthy, once you've reverse-engineered it. It has never let me down along those lines.

One of the things I've been talking to the erwin team about through the years is that every data model should have the ability to be multi-language. So along with the fact that I can change, for example, the graphic of the model to look at just the definitions in boxes, or just the key structures in the boxes, I'd love to be able to change the language. When I was working at Honda, it became very difficult to work with the Japanese teams using just one model. You can have two models, one in English and one in Japanese, but that means you have to keep the updates back and forth, and that always increases the risk of something not being updated.

The world is getting to be a very small place, and being able to have one file that has all of that metadata in whatever form you need to read it, is the best way to manage that data. That would be a big change for them and it would be a big change to the Mart structure. It would be a one-to-many on the logical side of the business names, but it would also a one-to-many on the definition side of the tables and the columns and everything else, where you can have notes. I know that it's a big change I'm asking for, and they've had to put it off a little bit, but their business glossary tool now kind of looks at it that way. I'm hoping that the erwin model itself will be able to allow for that in the future.

I've been using erwin Data Modeler from way before erwin owned it; since the '90s when it was Logic Works. That was before it went to Platinum and before it went to CA. And now they're spun off as erwin.

It's a very stable tool. It doesn't have problems with crashing or anything like that.

I've never had a problem with its scalability, especially using the Workgroup Edition, because you keep all of your models in the database. It's not a problem to collect hundreds of different data models. Even scalability on your desktop or in your laptop would be more about the laptop itself, not the tool. It's kind of like Word. It saves the data outside of itself, so it doesn't have that problem.

There was no data modeling tool when I got here two years ago, so it is new to the culture, and this is a 40-year-old company. It is mostly being used with our master data management and our data warehousing, which is still doing a lot of development work. It's being expanded into supporting the data governance initiatives, to do data asset management. And I'm expecting that over time it will be used more for data asset change-control. We use a lot of vendor-purchased products, and being able to see the difference between their table structures before an upgrade and after an upgrade isn't being documented in a model right now, but it probably will be.

Also, the new California Consumer Privacy Act is forcing us to do much more of that data governance and data asset management, as well as data classification, so that we can identify PII data. That's definitely picking up steam.

I use their technical support all the time. Sometimes it's just to ask them — because it's such a rich tool, they move menu items in the upgrades sometimes — "Okay, where did you put it this time?" But they've always been very helpful. They do have live chat on their website. About 75 percent of the time the chat agents can answer my question. If not, they hand me off to somebody. Given the amount of time I've worked with erwin, I almost know all their first names. They've always been very good and have taken care of me.

A lot of the technical staff moved with the tool, so they've stayed intact as it went through buyouts. I've always enjoyed working with the erwin team. They're very supportive, very helpful, and are very responsive to my requests and thoughts.

My current company did not have a previous solution, other than Excel spreadsheets and Visio — nothing that I would call an industry-standard modeling tool.

I was involved with the purchase and installation in my current company. I work with the DBAs so I don't touch the buttons for the installation. But the erwin support team is always a great help. I have never heard from any of the DBAs, during any of my "lifecycles," that installation is anything more than straightforward.

There's all sorts of bureaucracy that happens at a company, and that's true in our company as well. The deployment happened over the course of a couple of days: the installation, the tests, the verification, and making sure that the client-side could connect to the databases. I don't think any of that took too much time, other than getting everybody together to do it.

Our implementation strategy was to work with a very temporary dev environment and then roll it to a prod environment and then drop the dev environment. We don't keep a dev environment full-time because it is just a COTS tool. They do backups and restores just like any other mission-critical data. And we're using a combination of named licenses and concurrent licenses in our strategy so that we can leverage who uses it the most.

As for the number of people involved in an upgrade. I take on the SME role. We have the main DBA who is scheduling the upgrade into the environment. Then we generally have a DBA who is assigned to do the upgrade. And our service desk helps with the deployment of the client-side out to the users. So there are four people involved.

We saw return on our investment in erwin once we got our model library in place across all of our different data environments. Of course, you can always search using your DBA tools to find different things on a server. But once you've got your models in place, you can cross all the servers in your search, because you've pulled all that metadata into one place. It doesn't matter if it's an Oracle backend, an Access backend, a mission-critical Excel spreadsheet. Whatever it is that you have a model of, you can go search for something like a social security number. Just being able to do that, it almost pays for itself. When you think of how much time people spend to try to find things, it's completely amazing.

It depends on how many servers you have, how complex your environment is, and how many of your teams are going to look at stuff. If you have a really obfuscated structure, then you're actually profiling the data to figure things out.

Being able to type in, "Go find column names with SSN in them," it comes back almost immediately. That probably gets you 80 percent of the way to finding that particular aspect. How much time did we spend in the Y2K crisis just to find dates? Just identifying the columns that were going to be impacted was a feat. I keep telling my cohorts that social security number data is going to be the next Y2K. As soon as we run out of numbers, they're going to have to add a digit, but everything is hard-coded to the current span of digits. As soon as the federal government decides that it's going to do that, we are all going to have to go fix it.

The nice thing about having your assets in a database is that the more value-add you've done on your models, the less you have to look at physical names on columns. If you've put your logical or your business names on columns, that's even better.

I could imagine that in very serious research, you're going to cut 80 percent off the time it would take, depending on how complex your environment is. You can get there so much faster. Obviously, it won't give you everything because human beings just don't have it all written down. Or it could be that some nitwit is putting social security numbers into note fields and you don't know about it. But it's going to get you a long way there.

The erwin model is much more like an Access database. The return on investment is that it is a very three-dimensional type of metadata collection about your model. In some of Visio, you can add notes on a little graphic piece. But you can't add multiples. You could approximate multiples with carriage-returns in the block, but you can't categorize your metadata. You also can't add more value about that metadata. One little box on an erwin model can be opened logically and there will be 10 tabs worth of value-add you can put in. You can open the model so that you're looking at the physical side of the house, and still have another 10 tabs that have nothing to do with the logical side, other than that they share the primary key of the little graphic piece that you're looking at.

erwin is so much more flexible. And, with respect to return on investment, it's customizable. erwin has the concept of user-defined properties where if you need to do something special within your models that says something like, "Is this used by this line of business?" you can create flags, or dates, or text, or drop-down lists, and attach it to anything in the model itself. In that way you've created some value-add that is customized to your company's needs. To me that adds tremendous power to the return on investment. You can't do that with just plain drawing tools.

We came up with a two-part concept with our licensing. Our data architects have named licenses that only they can use. We have four named licenses today. But we also bought three concurrent licenses, two that are just for developers and the DBAs, and one that's a "read-only" that anybody can use. It's a little bit difficult for me to tell you how many people use those, but probably no less than 10 and possibly upwards of 25.

We pay for maintenance on a yearly basis. There are no additional costs for the Workgroup Edition, which has the server component. That is the edition where you can save your models back to a database, which we installed on SQL Server, but I think you can install it on any of several different platforms.

Our company looked at two others. Because I have worked with erwin for so long, I wanted to make sure, when I came in, that my current company got the opportunity to make its choice based on what everybody's needs were here. We did a full vendor tool assessment back then. Although I don't have it in front of me, I know we looked at Embarcadero and it may be that we also did the highest level of Visio, so that between them we looked at a very high-grade tool and something that would just get us by. 

When I got here, the DBAs had already put acquiring an erwin license into their next year's budget. They had already made that choice. But I took us all the way back to doing a tool compare because I wanted to make sure that everybody got the opportunity to weigh in on the choice that was made.

A lot of the difference between erwin and other products was the licensing and pricing structure for maintenance. Some of it was the inter-connectability with other tools. erwin does a really good job of building bridges between many different tools. Part of it was also its ability to be very sustainable because it had the Workgroup database backend, which Embarcadero has as well, but Visio does not. That was part of the decision point: whether we wanted to go with something really small and move up to a more industry-standard tool, or just take the opportunity to bring in a couple of licenses. We brought in a smaller footprint last year, and we added a few more licenses in 2019.

The primary reasons that erwin was selected were that it was much more affordable for us and it was easily maintainable.

Take the time, especially if you're going to use Workgroup, but even if you're using desktops, to figure out how you're going to manage the models. They need to have a naming convention. They need to have a directory organization that makes sense to you. They need to have change-control, just like code. You need to figure out how you're going to use it because once it gets past 50 models, finding something and knowing how to change it and where to change it and where to publish it back out is going to be your biggest headache. You need to think long-term. It's easy when you just have a few models. As soon as you have 1,000 of them, unless you've thought ahead, you're going to have a huge cleanup problem.

The biggest lesson I take away from using erwin Data Modeler is that we should all be doing much better library sciences with our data assets than we do. erwin is a great tool to capture your library sciences. It can tell you what you need to know about a piece of data, or a row of data as a dataset in a table, or a collection of tables. You can add information not just about single things but collections of things. 

We should have many more people whose job it is to add that value. Right now, companies still mostly use erwin for custom development and it needs to be much more built into documentation of any type of data. I use erwin to do data models of reports and of API calls, for example. Any data set, to me, qualifies as needing a model so that you can tell what data elements are in it and what that dataset is used for.

Through all the years, erwin has done a great job of making things better and better. There are always things that we're talking about in terms of improving it, but the fact that it's now starting to integrate better with data governance-type tools so that all of your definitions can move to more of a glossary form, rather than just being in the models, is tremendous. The more that that's integrated back and forth, the better it's going to be.

Out of all of the modeling tools, erwin is a 10 out of 10. It hits all the high points for me. There are some pieces of functionality that competitors come up with, maybe a little bit earlier, but it's a leapfrog-type of thing. Every time the vendors find that something is needed in the world of modelers, they all start to bring it in. I find erwin to be very responsive to those needs. So now, erwin has NoSQL modeling aspects in the tool and they're connecting with their own suite of data governance tools. That means you can push definitions to your data governance tool or bring them back from your data governance tool. It's starting to become much more of an integrated solution, rather than just a standalone.

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

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

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

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

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

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

I've been using erwin since 1998 or 1999.

The solution is very stable. It continues to evolve. 

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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