What is our primary use case?
We have a couple of really important use cases for erwin. One of them is that we automate the pull of metadata from the repository itself, so that we have all the model metadata that we can then put into a centralized hub that we can access with other applications. Another reason we pull all the metadata out of the model is to run it through our model validation application, which telsl us if this model is healthy or not and if it meets our standards or not.
The other use case that's really important is managing the abbreviations file that erwin uses to convert logical terms into physical terms. The way that you manage it today within erwin is very manual and you'll go from a spreadsheet, make changes, and upload, et cetera-- but we've created an API application where if we take the main standard file and keep it in the database, make the changes in the database, then we have an application that goes out into the Mart file, deletes the glossary, replaces it with the table from the database. It's all automated at the push of a button. It's things that would take us days to make changes in the standard files and do updates in eight different files.
How has it helped my organization?
Data warehousing is the best example of how this product can make a huge difference because it's an integration of a lot of different source systems. You have to be able to visualize how you are going to make the information from sources A, B, and C merge together. It makes it very important.
The ability to automatically generate DDL and have the to do it in different flavors (Teradata DDL or Oracle, et cetera), and to be able to fine-tune the forward engineering file so that it comes out the way your shop likes to see the DDL done is critical. It's soup to nuts from the design all the way to implementation. It's really critical.
We find that its ability to generate database code from a model for a wide array of data sources cuts development time. The ability to create one model in your design phase and then have it generate DDL code for Oracle or Teradata, or whichever environment you need is really nice. It's not only nice but it also saves man-hours of time. You would have to take your design and just type in manually. It has to take days off out of the work.
The code generation ensures accurate engineering of data sources especially because you can tweak it.
Development time is another critical issue. If you had to tweak every single piece of code that comes off the line because there's only a one-size-fits-all solution, then the problem would not be worth anywhere near as much as it is. It has the ability to create a customized forward engineering code that you can use to generate your code for your shop so that it always comes out the way you want it.
What is most valuable?
The product itself is fantastic and it's about the only way to get an enterprise view of the data that you're designing. It's a design tool, obviously. Once you add the API to that where you can automate things, you can make bulk changes. You can integrate your data from erwin into another in-house application that doesn't have access to the data because the erwin data is encrypted. It's been quite a boon to us because we're very heavy into automation, to have the ability to create these ad hoc programs, to get at the data, and make changes on the fly. It's been a wonderful tool.
A data modeling case tool is a key element if you are a data-centric team. There is no way around it. It's a communication tool. It's a way of looking at data and seeing visually how things fit together, what is not going to fit together. You have a way of talking about the design that gets you off of that piece of paper, where people are sitting down and they're saying, "Well, I need this field and I need that field and we need the other field." It just brings it up and makes it visible, which is critical.
What needs improvement?
I love the product. I love the ability to get into the code, make it automated, and make it do what I want. I would like to see them put some kind of governance over the ability to make changes to the mart tables with the API, so that instead of just using the modeler's rights to a table -- it has a separate set of rights for API access. That would give us the ability to put governance around API applications. Right now a person with erwin and Excel/VBA has the ability to make changes to models with the API if they also have rights to make changes to the model from erwin. It's a risk.
We have a really good relationship with erwin and whenever we come across something and we contact the product developers and the contacts that we have, they immediately put fixes in, or they roll it into the next product. They're very responsive. I really don't have any complaints.
It's a wonderful product and a great company.
For how long have I used the solution?
I've been using erwin since version 3.0 in the '80s.
What do I think about the stability of the solution?
It's very stable. It's very mature.
What do I think about the scalability of the solution?
We have about 70 licenses and we have about 70 people using the product full time. I've worked in shops where there were two or three to a dozen. Besides these 70, we also have other parts of the world, shops that have it. It scales right up. I have not worked in a shop where it was either too small or too large.
We have full-time data modelers. We have architects. We don't make a distinction between the data architect and the data modeler. The data architect is designing the enterprise-level view of data and how we use it as a business and then modelers work on specific projects. They'll take this enterprise view and they'll create a project model for whatever it is that we're rolling out.
We've got an architecture person, a modeler person, and we also have some developers who do some smaller database modeling when they had to get out something that's just used in-house. It's not used downstream by the end-user. We have the use of a portal product. Everybody at the company has access to the web portal product. They can go in and see what data has been designed and do impact analysis.
The business analyst will look at it in the web portal to see what the downstream impact would be for them to change a particular name that the company uses for something. They check what the downstream and upstream implications are. Then, the developers use our DI tools for creating the mapping from the source system to the target system. Our data stewards use the tool for the business glossary and for how we define things. Every part of the company that deals with data uses eriwn.
How are customer service and technical support?
Customer service is fantastic. I know a lot of the guys by first name that work in tech support.
When we have a problem, typically we're broke because we have people here on staff who answer most of the questions and most of the problems. If we have a problem, it's a big problem. They put us straight through and they handle us right away.
Which solution did I use previously and why did I switch?
I've used four different data modeling tools. Every modeling tool has its strong point but there's none of them out there that are as robust to me as erwin. If I have to choose one tool, it's going to be erwin, especially since I've gotten into the API and I know how to use it. Some of the things the other tools add in terms of being able to manipulate the underlying metadata, erwin has with that API. I won't say they now have it. They've had it since day one, but I've just picked it up in the last year or so.
How was the initial setup?
The setup gets more complex every time. Especially with 2019, they completely changed the interface and that was another learning curve. But for the most part, if you know data modeling, you can find the logical task that you want to do within the physical form and menus of the product. I didn't find the learning curve so bad because I was already a data modeler.
I started the upgrade process today, as a matter of fact. We just got the software installed on a Mart, and I'm going through the new features. I'll play with it for a week. Then we'll get other testers to actually do some formal testing for a week. And then we'll put in our change because we're a large shop. It's around a month cycle to get an upgrade in place. That's if there are no problems. If we come across something that tells us that we can't use this product until this is changed or fixed then it's a stop. For the most part, a happy path, takes around a month in a large shop like ours.
As far as the upgrade itself on dev, it took maybe an hour to upgrade the Mart. And it took me maybe an hour to upgrade the desktops that we use for testing.
We've been doing upgrades for years. I'm been involved in it with multiple companies and it's what I do here. We have a cycle, a strategy, and a checklist that we go through for every upgrade.
The first thing we do is we have a development system. We have virtual machines that we set up, so it's not on anybody's particular desktop. We upgrade the product and then one person will go through and I'll look at the new features and I'll see, number one, if we need the new features. Number two, if there is anything in these features that will break what we're doing today. Those are the first things I look at. If we pass those first two tests, then I start looking at the features and check what we are going to have and what it is going to involve in terms of training the user. We check how it is going to impact the modeler that's actually down in the trenches.
I've got to do the training materials and then the next thing is we have a warranty period. We have a group that pushes the software to the desktop. We have a special day that we roll it out. And then we have a warranty period where we set a virtual call that anybody could sit in if they have a problem. We have a virtual call so that if anybody, when they come in on Monday morning, can't get into the product, or if they're having any problems with that at all, we're right there to answer their questions. We allow for that for the first week. After that, we turn everybody loose. Of course, it doesn't account for the physical part of backing up the database, doing the install, validating over the weekend, and all that stuff. It's just the standard software upgrade stuff.
What about the implementation team?
We implement in-house, but always have access to a World-Class vendor.
What was our ROI?
I wouldn't know how to measure ROI. I can only say that the alternative is spreadsheets, typing, visually inspecting things, never being able to integrate, never being able to communicate. I can't give an ROI, but I can say that I wouldn't want to work in a shop that didn't have a data modeling data tool.
erwin's my first love. I know that I have been using it long enough that I am under the covers and I know it backward and forwards. It's the one I prefer.
What's my experience with pricing, setup cost, and licensing?
I don't deal with pricing or licensing here. I know that you can get a per-seat license. You can get concurrent licenses. To me, if you're a full-time modeler, you need a per-seat license. If you're a developer or a data steward, you use it a couple of times a day, maybe a couple of times a week, you can have concurrent licenses so that a group of five people will share one license. If someone's using it you can't, but if it's free then you can go ahead and use it, or you can lock it, or whatever. There are different ways of licensing it.
What other advice do I have?
The one thing that having a CASE tool does is it takes the drudge away from modeling. You get to actually think of what you're doing. You think about the solution and not how you are going to keep track of what you're doing. It frees you from a lot of mechanical things that are part of keeping track of data modeling, and it allows you to do the thinking part.
There's not a lot of documentation on the API. You're pretty much going to have to teach yourself. If you have a specific problem where you've gotten to a certain point, you can always touch base with the guys at erwin and they will help you to get little snippets of code. But if you're doing things like we have, which is to write a full-blown application to extract the data or to make changes to the model, you're pretty much going to have to learn it on your own. That's just the one drawback of the API but if you're a programmer and you want to DM like me, it's a lot of fun.
It's a challenge but it's very rewarding to be able to automate stuff that people are doing manually and to be able to hand them a solution.
From one out of ten, I'd give erwin a 9.99. Everything has flaws. Everybody's got these little quirks like I mentioned about the ability to make changes that you shouldn't make. But as far as the product itself, I love it. It's right up there with a 10.
Which deployment model are you using for this solution?