Previously, I was in high-tech, now I'm in healthcare. In both instances, we used this solution to increase data literacy and business literacy. In short, we were building out business glossaries, coming to an agreement on term definitions, understanding what reports mean, what the metrics and calculations mean — essentially getting it all documented in an enterprise-facing view. That was the bulk of the focus in my prior company — along with some reference data. At my current company, we are focused heavily on bringing in data dictionaries, including schema tables and columns, and understanding what data is in which database. We also look at what data is flowing from database to database and how it's used in Tableau reports or in a business or archive.

Currently, we're on-premises, but we're planning on moving to the cloud later this year.

Over the last 12 months, we've had 643 unique new users. Most of our users tend to be what I would call "data geeks". They are the ones that understand the value of and/or the aspect of leadership to catalog their metadata for their data dictionaries, etc. The business users have not had as much adoption at my current company because that's not the particular strategy at this time. At my prior company, that was the singular strategy — to increase business literacy.

In regard to my previous company, for eight years, our primary customers were business users, not technical users. They just wanted to come in and say, "What does it mean? Who do I talk to if I have questions? Where do I go for more information? How does this relate to that, and how do those things affect me in my business world?" That was a fantastic use case at my prior company. In my current company, we're utilizing the tool specifically to support our data management strategy. Our technology risk office is very much supporting us in the effort to do the cataloging of all of the metadata for all of the systems that we're utilizing, cross-functionally.

Maintenance must be defined. As with any software product that exists, there are regular maintenance upgrades that occur that the company pushes out. If you're on-prem, you can choose to do it sooner versus later. In the Cloud, they push it to you unless you state that you wish to wait. From a maintenance perspective, I have talked to other customers who are in a cloud environment. They say that the maintenance has basically dropped to nil. For on-prem customers, it does require a little more maintenance because obviously, you've got to make sure that the servers are up and running, etc. In my prior role at my previous company, I was responsible for the business IT side of it, which meant I kind of managed the platform. I just didn't manage the server.

I took care of the customers, etc. I'm not even a technical person at all, but still, it was not difficult for me. From a maintenance perspective, I don't feel that it is difficult.

If you have custom integrations that have been created, then it will require a little bit more maintenance because those integrations need to be monitored. Some customers require a lot of integration, and some customers don't. It really depends upon the use case. Custom integration is really where it gets more challenging. Depending on whether it's a one-way integration or a two-way data feed, it can get pretty complex. Two-way data feeds are always custom. But that's something that will be on the customer anyway, not Collibra.

We've only just relaunched this solution within the last 15 months. Currently, we only have about 240,000 assets in the tool, but we have a roadmap and plan to onboard a number of our customers. We'll probably double or triple our users over the next 12 months. 

Collibra is for the classification of data. Collibra is being sourced to all the intakes for the company, which might be legacy systems or new systems or might be lineage as well. Collibra takes up and does its own governance over there, and the data is fed into Ataccama. Ataccama and Collibra seem to be cascaded, but Collibra is the first player. But that doesn't mean it saves a lot for Ataccama.

There are different use cases, including integration with other applications, setting up operating models for specific business domains, such as finance or manufacturing, defining domain structures, and implementing data quality rules and scorecards. The specific use cases can vary from client to client, but they generally involve leveraging Collibra's capabilities to establish a strong governance framework and improve data management across the organization.

We've used it for cataloging or defining our business data entities and their associated attributes or data elements. Where appropriate, we are defining their sources and their modes of derivation. Rising above that, we are also using Collibra for the definition of our business metrics that are calculated from those data elements and the derivation definitions associated with them.

We primarily use the solution for when the customer needs data governance to establish cases. We're choosing the product in order to meet the requirements of the customer. That includes requirements such as establishing a governance council if the customer does not have one. It's for data management and the solution handles data quality and metadata management, et cetera. 

Collibra Governance has many use cases. I'm part of the enterprise data team and I also focus on other types of data enterprise, wherein governance is one of the workstreams. I'm working for a pharmaceutical company, so I try to onboard people on Collibra Governance from various verticals such as HR, vaccines, pharma supply chain, etc. Sample use cases for the solution include data quality for cloud stream software, automated data lineage, and other types of lineage. In general, I'm using it mainly for data governance.

We are focused primarily on the Data Governance Catalog (DGC) for our data dictionary use. We are not using it for information governance in terms of regulatory compliance, etc. We are focused on business glossary, data catalog, data dictionary, and some workflow processes to help with metadata management and other things.

We are fully updated, and we are using its latest version.

We use the solution to organize data. The IT team has access to the data and knows where it is stored, but when it comes to legal compliances and various regulations, the business itself does not have control over where the data is stored and how it is stored. Typically, the business wants to have control over where the data is stored, the various data classifications, and data sensitivity. That is the main reason why we use Collibra Governance.

I have been working on Collibra for a data governance assignment. Along with that, we also use Ataccama for data quality purposes. It is a Collibra/Ataccama mixture that we use.

Collibra is generally used as a data governance tool, maintaining all metadata repositories. For each and every data that has been cataloged in Collibra, there'll be an owner assigned to it, whether it's a subject matter expert, a data streamer, data owner, etc. All the data is catalogued into Collibra. It has a single source of truth for data. I'm a senior Collibra consultant and we are customers of the company. 

The solution that I had worked on was related to the technical implementation of metadata for capturing analytics. That said, that particular implementation missed the bus with using it for business use and getting a proper buy-in from the users.

I worked with this solution a few months ago and the main use case of Collibra was as the central metadata tool for the enterprise. The plan was to have all of our data dictionaries, our business glossary, to expose data lineage through Collibra and show all of the relationships and connections between our various tables and databases and the actual semantic business layer, in Collibra. It was a way to unify our technical metadata with our business metadata and with our actual applications.

We use the solution's Data Stewardship part. We tried to explore the policy management piece, but we were unable to get through it. We haven't worked excessively on that. It was just some POCs or MVPs, but this is something that we would like to explore in the future. This is something that will be our future requirement in six to seven months down the line.

Our major use case for Collibra Governance involves maintaining lineage, as well as linking business terms and technical terms together. Then, our use revolves around linking policies with actual data, such that we can create data sharing policies within the tool, storing data and quality results.

I am currently working on about 10-12 projects with Collibra Governance using the latest cloud version. It is available on both cloud and on-premises, but currently all our solutions are moving to the cloud.

Collibra Governance is mainly used as a one-stop solution for data discovery.

There is a master glossary which includes all of our business fields. The fields are related to particular lines of business such as account numbers. We then build business rules around these fields and complete data integrity checks. 

We plan to increase our usage of this solution over time. We will have to use other functionality within this application as it is currently limited. We currently have 12 team members using this solution. 

Our use cases include connecting a lot of legacy data systems to our logical components. For example, if somebody has a question that they post to us and say, "Tell me everywhere in our organization where we have a policy stored?" the primary use case is to logically define what a policy is, and then we use Collibra to tie that logical construct to a technical implementation. We may have six or eight, however many, different admin systems. We bring in the schemas of the way that those systems look, and then how a policy exists in this database and this table and this column, for example, in that legacy system. 

The second use case that we implement is the ability to track the provenance or the lineage as to how something changes over time. For example, if we bring data in from a legacy system and we use some tool set (e.g. Azure Data Factory) to extract the data into a Hadoop data lake, and then perform some transformations on it, we want to be able to track it; "It came from the source system here, and this field got changed to this name, and we applied this transformation on this field and it eventually shows up on this report here."

We use it to track where a policy exists and also how it got there: it exists on this report and here's how it got on that report, here are all the steps that it took getting through to that particular report from the actual source system itself. Because quite often what we're finding is that our business users will get a report and they'll say, "I think your report's wrong. How did you get that value on that report?" That provenance or lineage is what helps answer those questions.

We have data stewards who are the resources that if somebody proposes a new logical asset based on what they think the customer means, these data stewards are the ones that would get together and look at what's being proposed and make sure it works across all of our business units for a generic implementation, or create business unit specific terms if required. They're the ones that say a particular system or term or logical construct is ready for consumption by end users.

Another group we have is the end users. We try to have people use Collibra by asking, "Don't tell me what system you want to get access to, tell me what you're looking for in business terms/constructs." In our example, it would be the question, "Tell me about all the policies in our system." They would go to Collibra and "shop" for that data and pick a policy and put it into the shopping cart basket that Collibra provides as part of their interface. Then they would submit that request for approval/access to the underlying data.

We also have data stewards who approve the use of new/updated business terminology and end users who are looking for their data to make business decisions. We also have some power users who are the resources who are setting the direction for the application of where we want to go with it, (e.g. new workflows or new functionality within Collibra).

For us, the Collibra application is an on-premise installation (although we use IaaS VMs to host it on cloud); it is not their SaaS implementation.

We use the product for classification based on the different regulations and compliance requirements.

I've been working with multiple companies, but with two of the companies we have been using Collibra mostly for data governance. With these companies, our use case is all about metadata governance, lineage, and data-related policy management. We're doing policy management directly inside Collibra and we're also using it for issue management on the analytics side.

If someone has a data concern, they just call me in and then put that concern into Collibra as a front-end UI for the data stewards and data scientists, and we start processing them.

I am using it essentially for the GDPR implementation over here in Europe. This is my second project on Collibra. Before that, I have worked on the CCPA part for a US-based project.

I have worked on an on-prem solution and a solution on the cloud. I was the one who had created all the components on AWS because our client was not ready to move onto Collibra's cloud solution, but I believe they will be moving to SaaS soon.

We are on version 5.7.5. Version 5.7 is the latest, but because we're not on SaaS, it's quite tedious to upgrade each and every environment. We have four environments or five if you include what the developers work on, so it is a bit tedious to upgrade. 

We mostly use Collibra Governance for governance-related tasks like building business glossaries and creating policies.

My company, a financial institution, decided to implement data governance for data analytics, et cetera. We designed an entire metadata management system using Collibra. Initially, we designed the metadata management, and then we enabled the receivership at the organization-level and also roles and responsibilities. After that, we created the lineage between the technical and business assets, and we automated the process of insertions and updates.

We use it for metadata management, data lineage, and automated governance processes. I am working on the SaaS deployment, but I have also worked on the on-premise deployment. I am currently using its latest version.

In my company, we use Collibra Governance for data catalog.

We use this solution for workflows and for specific use cases. For our retail and insurance clients, we meet governance requirements by using all the features that Collibra provides. We do most of the work using workflows and connectors. We build connectors where the data will be extracted from a third party tool and  input in Collibra.

We have 40 to 50 team members using this solution. We have three admins who manage this solution. 

We use Collibra for IT data governance, specifically for GDPR compliance. Our company is in the banking and financial institution sector and we are customers of Collibra. 

Collibra Governance can be deployed on-premise and in the cloud. The solutions can be used for lineage data quality, business glossary, and data cataloging.

I am part of implementing the workflow through it, setting up the glossaries, and importing the assets to Collibra Governance. 

Our clients are typically using it for metadata management. From a broader perspective, Collibra establishes an excellent foundation on which to build an enterprise data governance program. 

We use the solution mostly for a client. There are a port catalog and dashboard cataloging features that they use. That said, the principal use case, even though there are a number of use cases, is using it as a business glossary for terms throughout the institution.

The main use case for our organization was to collect and collate information for our business users, such as definitions, business rules, etc. 

The customers' names were stored in a data warehouse on Oracle, and with this product, you could insert information related to the customer. You could use Excel, for example, to add in data. You'd have all the information you collected from other places on one tool that users could navigate across to see all of the information.

We have a client that was planning to do a digital transformation. They came up with the use cases and they have a couple of departments. They are mainly based on legal systems including corporate trust, etc., that they want the data to govern. Their requirement was basically if any new person is hired, they would have everything in Collibra, including all of the business glossary or the tables or the reports. Basically, everything for their onboarding process was available there. It was also necessary to give that to anyone that wanted to know about their department.

We are using the product mainly for metadata management as well as some data governance practices such as roles and responsibilities set up. We're also using different workflows - mainly approval workflows or request access workflows where people can actually request access to data. We have use cases based on different teams, based on what they need. It's mainly the glossaries, such as business glossaries, data dictionaries, and report catalogs.

I don't use it as an individual. It's basically for my clients. I serve as a consultant for the tool. The typical use cases for the clients that we get is around metadata management and around building lineage. You can create a lineage by modifying out-of-the-box Collibra asset models.

Collibra Governance helps us set the business rules and define critical data elements.

We're a very large pharmaceutical organization so it's difficult to quantify exactly how many users are using Collibra.

Within our organization, there is a data governance team that we had set up. I am the person in charge of that team. While working on the data governance processes, we thought of leveraging Collibra for things like data dictionaries, developing data lineage, ensuring that business artifacts like KPI catalogs and board catalogs can be built within Collibra itself. 

Our use case is to manage master data inside of Governance.

The solution is deployed on cloud. We have around 10 data analysts using the solution.

Our primary use case of this product is for metadata information for our technology assets. We also use it for all the governance dictionaries, and for minutes as well.