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.
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.
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.
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.
I've been using the solution for almost two years now.
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.
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.
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.
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.
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.
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.
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.
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.
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.
We are customers of Informatica PIM and I'm a senior architect.
Informatica comes with a predefined data model which is the way in which you enrich your products. It acts not only as master data but also as a product enrichment tool. The product provides flexibility; you can go for an undefined number of attributes that define a product. You can plug it in with any e-commerce website. That's its value to us and why we need it.
Database access is highly restricted with PIM. If you're using the cloud version, you probably won't have database access or a view of it. If you're wanting a customized application, you can develop the out-of-the-box PIM solution with a little bit of customization here and there without even needing a database. That's a very big drawback. As a developer or as an architect, you need to have a data model. I know some people use it without database access and the issue is that they don't know what that data model is built on other than just seeing it through UI tabs. The one thing I'd really like to see is for the solution to be made scalable.
The solution is stable, in terms of bugs they're very good. They keep evolving their toolset. I have encountered many bugs in Multidomain MDM, but to date not in P360.
Scalability depends on your use case. If you're using it as an integrator, then it is definitely scalable. That said, it would require an altogether separate MDM solution. If you don't have MDM, then there are likely to be some limitations. We're in the process of installing now but in my previous company, we created the core set of attributes through MDM. From there it went worldwide through an e-commerce website. We have 50 to 60 people internally using it as a tool. If you're exposing your data through an e-commerce website, then it's accessible to all, although just for reading and not for updates.
If you're working with Informatica, you need to interact with them on the out-of-the-box features. They are very efficient and quick in their response times.
I've trained in Stibo which is a little bit better than PIM and I've used Oracle PDH and CDH. Those were basically a package MDM solution. If you're using SAP, I would suggest Oracle products. But there's been a very big evolution over the past decade when it comes to enterprise MDM tools. Most people working in companies are disbursed in different locations and using multiple toolsets, they can't be restricted to one technology. That's the reason that Informatica, Stibo, Riversand, and other technologies are very useful and very powerful. When comparing PDH to PIM or CDS to Multidomain, managing the Informatica toolset is easier in terms of effort required in comparison to managing Oracle MDM or Oracle CDH or PDH because they have their own set of limitations. The good thing is that they can be very easily coupled with an ERP solution. Here, you have to build real-time or multiple interfaces.
The setup is relatively easy I would say. But if you need additional attributes, it gives you a repository manager feature where you can use XML, add your own attributes and then configure it. To my mind, the setup is simple to moderately complex.
Licensing costs are a little pricey. For my previous client, as a support contract partner, we were making less money than Informatica was charging them.
Informatica 360 PIM was bought from Heiler and is a very good tool if you already have MDM in place and you simply want to use it as an enrichment tool. With Informatica, you perhaps need to go somewhere into the roots of Multidomain. P360, Multidomain, and C360 are all different things. Managing a thousand plus attributes into that data model is going to be very complex. If they could come up with a standard data model that Oracle offered customers like PCH or PDH, similar to what P360 has, that would be my preference. Also, my recommendation is to always utilize your team as an integrator rather than being a master data manager.
I rate the solution eight out of 10.
We primarily use the solution for tasks such as masking. It's used to mask the customer data.
We are using end-to-end features of Informatica. Everything comes under the product. We really like that the solution is part of a bigger use case that can all be under one umbrella system.
There are new features that are being built to help more closely link all of the solutions we use, and we like that they are always thinking about how each product interplays with the other.
We've used the solution for quite some time, so in our organization, the product is pretty mature.
There are lots of use cases surrounding the use of the product.
The integration could be a bit better. The process is something new.
They need to include more documentation and support around the build.
It's my understanding that they are currently fixing quite a bit and building in updated capabilities in the upcoming version. We'll have to see what that looks like.
The general design of the resolution could simply be tweaked a bit.
I've been working with the solution for five or six years at this point. It's been quite a while.
We've worked on both the Windows and Linux platforms and have not had any issues with stability. It's been very good in both cases, and we have not faced any errors. There are no bugs and glitches. It doesn't crash.
We have 100 user licenses and we are using them in real-time. We work with an Indian bank that often requires more users. We can implement MDM to accommodate their needs at any given time.
I've worked with support from Oracle and a few other vendors, so I can compare it to those experiences. When I compare with other vendors, Informatica support is better, feedback-wise. Their documentation is great. They are very responsive to their customer base and very quick to respond to inquiries. We're very satisfied with their level of service.
I don't really have experience with other solutions. I only really know MDM.
The initial set up's complexity or simplicity depends on the requirements of the organization. Some have simpler implementation cases. Others are more complex. I would say for the simple to medium cases, the installation and deployment is very straightforward.
When it comes to bigger builds, we need to be a bit careful in order to configure a few more settings to make it work properly. In general, the solution has simple to medium level complexity during the set up process.
The time for development usually takes a few days. It does depend on who is setting everything up. If you are well informed on the solution, the deployment process itself may only be a few hours. For a downtime point of view, you don't have too much time between products. Depending on when you do it, you can have 0% downtime as well, however, it would need to be strategically planned.
The solution has a couple of pricing models. You can go via can go a number of records, number of CPU, and various other items. I don't know what current model we follow.
My experience on pricing is maybe four to five years old. I don't know what the current model is based on in our organization.
Although we're on version 10.3, we're working to move over to 10.4 soon. We're about to upgrade.
If you look at the Gartner quadrant, MDM is the top product. There are a few platforms available, however, I don't have good experience with other products in order to compare and to recommend. From my personal point of view, definitely I would recommend MDM.
I'd rate the solution seven out of ten. We're still testing a few capabilities that the solution provides, however, we aren't using them yet. We do plan to implement them in the future. Since we aren't extensively using the core features, I'm not giving them a higher score. We need to see how things progress.
