What is our primary use case?
We're using the solution for reference data, master data management. To basically implement data governance around the reference data.
One of the big initiatives is to capture all the information that the branch operations team is looking to capture. Or operational information or reference data. We're a credit union. We're like a bank. It's all about managing the data of the branches, and the ATMs, and some of the business partners that are at the branches.
How has it helped my organization?
There used to be a lot of handholding by ISD. This kind of solution gives control to either ISD or business units to do what they need to do. We don't have to play the game of telephone or do any handoff. We don't have to specify "Here's what I want" and then get it translated unnecessarily by the ISD people that don't understand the business.
That's why the business is entering the information. They're verifying the information for files or tables or whatever that aren't really controlled by that department. Then the ISD can kind of step in as custodians and handle some of that for them. Typical stuff like stuff that's sourced externally - like an ISO country table.
They don't want the department saying that there is such and such a country, and adding to the country table. We basically want to pull it from the internet, from the ISO International Standards Organization, and say, "These are the official, full list of countries and country subdivisions," which are states and provinces and such.
What is most valuable?
The data modeling is very good. It creates for you a GUI interface, which are the forms that the stewards would fill out to add or modify data. That works fairly well.
I like the features of that, especially with regard to the product key relationships, which result in pull-down lists in the forms.
The workflow models are great. We use them a lot. It's text-based and you can basically add different kinds of steps right into the workflow. There are different parameters for each kind of step.
What needs improvement?
It's a pretty steep learning curve, I find. And not really fluid and flexible. There is some graphical rendering of the workflows, however, you can't really develop them in terms of the graphical picture. Whereas a lot of BPM-type tools will give you that kind of capability.
The workflows need improvement. You need to develop, kind of conceptually, what you want. It's basically a web app generator, so there's a lot of magic under the covers. When you're trying to promote the changes through a version control system, it's hard to know what to expect as far as all the content. For example, if we were building and writing Java code, we would know what's changing. However, due to the fact that we're just putting in models and embedding some business logic in the models and such, it generates a web app, a job of whatever. It generates XML and some other stuff. And that's XSD. Then when you go and say, "Okay, let's push these changes," in Git or in Eclipse, et cetera, it's tricky to have a multi-developer environment where you're not stepping on each other a little bit. You're not as aware of the repercussions of your design changes.
The documentation needs improvement. It would be helpful to have more during implementation, for example. It would help make the initial setup more straightforward.
In a workflow, you can't set default values for certain columns, which would be nice.
If you're handy with Java, you can create your own services and such and do something there, however, it should be out-of-the-box functionality. If you have a generic system, you should be able to say, "Hey, this structure supports A, B or C." Yet, if you launch it, if department A launches it, assume that certain values are set to their preferences. As department D launches assume that the department is B and you know, certain values are set, et cetera. Otherwise, everybody comes in generically, and then they have to know more than they want to know.
There's this thing called replication. You could replicate the XML database to SQL Server on Oracle. That replication doesn't happen if you use certain features of the product. For example, with one of these features, you can do calculations or calculated fields. You could say it's X, then do a sum, et cetera. If you have a calculated field, you're not allowed to replicate it. It would be better if they could allow the replication, even if maybe they have to limit the functionality to those columns.
There's an item called inheritance. You could say, I don't want to, if I asked for your name, I don't want to ask for your name three more times. So when I get to another file on the table, it's already there. It will carry information by inheritance, so you're not going to enter it wrong three different ways, however, once you have inheritance, you can't replicate. It would be better to ignore the inherited fields, just nix those columns, yet allow the table to replicate. Then you can have an SQL server go in and read the data in a relational way, which is very helpful to make it acceptable to developers and business analysts, et cetera.
For how long have I used the solution?
I've been using the solution for almost two years now.
What do I think about the stability of the solution?
We just recently ran into an issue in one of the test environments. The jury is still out on stability. It's been fairly good and pretty reliable. I believe I haven't seen the system come down on production really, other than when some of the teams involved make mistakes on rolling out the next deployment. It gets a little rocky if they don't know what they're doing, however, that's just an operations issue.
What do I think about the scalability of the solution?
The scalability may be somewhat limited. Basically, the application is designed to run on a single application here. You can have it hooked to various different databases. It works with Oracle or SQL Server. We implemented a SQL Server. SQL Server itself is not horizontally scalable. You can't add servers. They're just replications. It's good for high availability, however, not for scalability. That said, it also can run in SQL Azure, and SQL Azure in my understanding is scalable both vertically and horizontally.
The tool is not limited. On the database tier, the database isn't limited. It's only limited by your implementation choice. If we're in Oracle or SQL Azure, we can scale. For reference, data is probably not that relevant because it's relatively small volumes in the grand scheme of things.
However, for the application, if we rolled this out across the organization and had a lot of activity, we could get into potential trouble as you can't run with load balancing and such. You basically have an active-passive failover. You have some high availability and not the scalability of the applications. That could be designed in various ways. We haven't tried that yet.
We only have a handful of people who have access to the solution. They're either stewards such as subject matter experts or they are some kind of reviewers, approvers, overseers. There are also developers that are functioning like admins. There are two main departments that are using it currently.
How are customer service and technical support?
When it comes to technical support, most of the challenges have been at development time on production, and therefore we haven't really had much opportunity to test their response in a production outage situation.
However, in development, it's a lower bar. Sometimes we don't get a quick response. It depends on who is helping us, who's been assigned to support us. Some guys have been great and other guys are out of office and they don't seem to have anyone backing them up and we need to wait for them to return. We don't know what the answer is. Sometimes getting answers has been challenging.
The technical support is average, or slightly above. On a scale from one to ten, I'd rate them somewhere between five and seven.
We had a contact that was really good and then, after the acquisition, when Orchestra sold to TIBCO, TIBCO started migrating some of their functionality to direct with some of their other products. Things shifted a bit and after they were solidified, with COVID, they've cut resources and we've ended up losing one of the good resources that was giving us pretty good answers to technical challenges.
Which solution did I use previously and why did I switch?
We didn't really use a different solution previously. For data governance, we used some homegrown stuff, basically. We're still doing that in some areas.
How was the initial setup?
The initial setup can be a challenge due to the fact that there is not enough examples to model after. There isn't enough documentation to go off of.
They gave us some templates and things to work from, and that helped those artists. We also had to dumb down some of the templates and start from almost scratch to kind of get the workflow actually working. It would be great if there were some standard items to work off of. It would be nice if there was a bigger community where you could share ideas with other customers about the product.
The deployment took a while. We were refocused three times on different aspects. Then there were multiple organizational changes, department changes, et cetera. The first production implementation took almost a year. After that, we've probably handled seven or eight subsequent releases.
We're rolling out to different groups more frequently. It's not just the branch shops. We've done some things for other teams as well. In general, it's been a year and a couple of months.
For maintenance, right now, we're down at two or three developers.
What about the implementation team?
We didn't really solicit any outside help. The implementation was handled by employees and our internal consultants, and not any kind of system integrator. Everybody on the project kind of learned from the ground up. It would have been nice if we have here an implementation team that some third-party ran. It would help to have outside help from a company that was familiar with the product and the process. However, that wasn't available.
What's my experience with pricing, setup cost, and licensing?
While my understanding is that the solution is on the less expensive side, I can't describe the actual costs. We do pay an extra fee that covers upgrades and support. While that may have been included in the original cost, it may have to be renewed every year.
Which other solutions did I evaluate?
We evaluated a few different options. We looked at Teradata, which has some kind of reference data management. We looked at Informatica MDM. We looked at Collibra, which is more of a governance tool than an MDM tool. We may have looked at an Oracle tool as well.
In the end, we felt technically this product had more robust data modeling capability, especially for the foreign key referential integrity.
Collibra is very atomic. It'll handle a lot of reference tables. However, there was no referential integrity plus no relationships between tables and stuff. That was pretty much non-existent.
What other advice do I have?
We aren't using the latest version of the solution. We're a few minor versions behind.
There are some questions coming up, of what our direction is going organizationally. There are some new directions that may include moving to the cloud from on-premises.
That could have an impact. There's also an appetite for high availability and scalability and all of that as we are a very large organization. On the other hand, some of the competition that is using the same tool, are some of the really big banks and such. There are other organizations, other financial institutions that use it. Their typical complaints are concern over scalability but they're using it, so it's not so surmountable.
The advice I give to others is if it's the first time you're doing data governance, you're not just implementing what you're doing manually today. You want to improve the process. There has to be some practice and awareness of the process design and the rules about governance.
I'd rate the solution at an eight out of ten.
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.
I have a question about the git workflow you are using. Specifically, in regards to the issue of XSD, you mentioned in the review. How do you manage the XSD when multiple developers are working in parallel on the same model?