What is our primary use case?
We were trying to evaluate and compare it with other architecture tools.
One of my colleagues, a servicing data architect, was trying to create a use case for one of his more recent projects, where he services an auto loan. I was trying to create a process around when some of the dealers sell an automobile, procure an automobile, and finance the automobile, then sell the automobile and get their money.
How has it helped my organization?
If we could have gotten it to work, I think it would have really been useful. The software architects felt that what they did already linked to it because it had the data modeling portion. When they did their technical specs, they used Evolve to drive out their technical specs. They would give us their overall technology/technical specifications to then model the data, but we were very frustrated because of the way the data was presented.
At a detailed level, the software architects would say how the data element should look, what characters it should have along with the naming convention, and how long it should be. We would definitely challenge them on that because we felt that this was our job to do. In some cases, they would throw everything in one table, and we would say, "No, that's not the way we're going to do this because we were doing things in third normal form for our operational databases."
We reserve the right to change the design, so a lot of the software architects would have to say, "These are just for illustration only. The final data design will be done by the data architect," since that document was the one that the QA testers would use. There was always this problem with them having to update their spec when we made changes. We thought with erwin Evolve we could get something that was more robust from a data point of view.
What is most valuable?
I really liked that it mapped out processes and was able to attach the data model to the appropriate process. You could map out the process, then when you got down to a specific couple of data elements, you could attach the table in the database that supported that process. You could connect it with erwin Data Modeler for that.
The integration capability with erwin Data Modeler was easy and great.
What needs improvement?
As we were trying to evaluate erwin Evolve, it was so rich in functionality that we'd get lost in the details. We didn't know where to start. After, we did get started, then we would break away and take on our daily activities. However, when we went back to go look at the solution, we couldn't remember, "How did I get here? What did I do?" Unfortunately, because it took us so long and we were having so much trouble, we couldn't do a complete evaluation to make it into our budget cycle.
It could have had a more streamlined navigation. It seemed that when you went to the explorer panel, there were just so many different ways of doing the work that I could not remember, "How did I do this? How did I get to that point in that model to get back to it?" If I wanted to build a new one, where do I start? It just seemed like there was such a smorgasbord of ways of doing it that it was just overwhelming.
If there is a change to the data model, then it's not automatically reflected in erwin Evolve. You have to go back and reattach it. That could be an issue in a database which has frequent changes. If erwin could find a way to simplify the navigation of getting into the meat of what you want to do, that would help a lot.
We use erwin Data Modeler most of the time. You could have a combo right there, where you see your process and the data right there. I thought that was pretty cool, but navigating to get to that point is what I found too cumbersome.
The integration capability is limited in that if you subsequently make a change in erwin Data Modeler to a table or data element, then it's not automatically reflected in erwin Evolve. This means that you would have to put in a task for erwin Data Modeler that every time they updated the data model to see if it is attached to erwin Evolve. It looked like a manual check to see, "Do I have to reattach that data model to that process because I've made a change?"
They could make it simpler for people to get into the tool and learn the tool, because it just seemed like the learning curve would be very steep.
For how long have I used the solution?
My previous company, GM Financial, reviewed it last year for potential use. The evaluation was around late Summer, lasting over a month.
What do I think about the stability of the solution?
What do I think about the scalability of the solution?
I didn't see a problem with it being scalable.
We were a team of about three consistently using it at a time. If we could have gotten it deployed, we were a department of maybe 20 to 30 data architects. Of that, probably our operational architects would have used it first, and that would have been about eight or 10 people. Then, we would have roll it out to the others because we were organized into operational architects, data warehouse architects, and data vault architects. We saw that the operations folks probably would have been the first in line to work with it.
How are customer service and support?
The technical support was always very responsive. It was just the tool itself that we just found too difficult to work with for our use.
The young lady who was our pre-sales consultant was very good. She would help us and answer all our questions. We had the sales executive, then there was also a woman who had the more technical hands-on. We asked her, "Could you please... " and then she made some adjustments for us to sort of make it easier, but we still were awfully slow at being able to get it to work.
Which solution did I use previously and why did I switch?
Our software architects had a different tool that they were using. We were hoping to show that Evolve was more robust and see if we couldn't encourage them to use our tool rather than theirs.
How was the initial setup?
The initial setup was not a big deal, I don't remember it being terribly painful. They sent us links which we accessed, then we were in the tool. It was pretty simple.
What about the implementation team?
One of the guys who was working with me, because I was sort of leading the effort with three of us trying to test it, already had a pretty significant library of Excel and Visio diagrams. He said, "I'm not seeing that this is buying me any advantage, because I already have this using Visio, etc." Of course, we kept saying, "Well, we still want to...," but he couldn't see the value of spending the money and extra time trying to test this solution, especially since it was so hard to work with it.
We didn't work on it constantly, because we have our typical job duties. We would go in and out, at least that's what I did. My colleague spent more time with it than I did. Then, one of the guys just got too busy with his project work and didn't do anything at all, which was a little frustrating to me. I went into it sporadically, a couple times a week, to try and spend an hour or two. My manager did the same thing. She tried, when I explained to her, "Here's what I'm coming up against. I just don't know how to get around this."
We set up several calls with the folks at erwin where she would demonstrate how we do it. They created a couple of templates for us to get started so we could just go in and try it. However, we felt like this solution would take a lot of setting up and help from erwin before we could really make use of it.
Which other solutions did I evaluate?
We had a template in which we looked at the different architecture tools. We had some criteria that we said we wanted from a data architecture point of view, and this was the first tool that we had a chance to get our hands on other than the one that our software solutions architects were already using.
What other advice do I have?
For what it says it can do, it does a good job, but using it is too difficult. When the young lady demonstrated it, we thought, "Oh, this is great." Then, when we went to go use it, and thought, "Oh, my God, it was just too difficult."
Biggest lesson learnt: The ability to really do a function framework and integrate the data associated with the function.
I would rate it as a four out of 10. If you're going to break it out by its functionality, I would give it a seven or eight, but then I would put the ease of use very low. We didn't move forward with it. We couldn't demonstrate it to our senior leadership to say, "Look what this tool can do." We never got good enough at it.
Which deployment model are you using for this solution?
On-premises
Disclosure: My company does not have a business relationship with this vendor other than being a customer.
