What is our primary use case?
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.
How has it helped my organization?
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.
What is most valuable?
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.
What needs improvement?
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.
For how long have I used the solution?
I've been using erwin Data Modeler since 2014.
What do I think about the stability of the solution?
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.
What do I think about the scalability of the solution?
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.
How are customer service and technical support?
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.
Which solution did I use previously and why did I switch?
We did not have a previous solution.
How was the initial setup?
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.
What was our ROI?
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.
What's my experience with pricing, setup cost, and licensing?
We pay on a one-year subscription basis.
What other advice do I have?
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.
Which deployment model are you using for this solution?