What is the difference between Collibra Data Governance and Azure Purview?

These are actually very similar products - in fact, an ex-Collibra person I know had the impression that MSFT must have just looked at Collibra's application and essentially duplicated it.  At their core, both are essentially Business Glossaries and Data Dictionaries (Catalogs) with a bunch of window dressing.

In terms of where each may have an edge:

1.  Collibra's strength is as a collaboration platform.  So, their workflows are more developed to enable things like approval of terms, etc,, and capture the historical proposals/changes.  Although MSFT obviously delivers collaboration through Sharepoint, integrated workflows with Purview may take a while, even though the capability is clearly there and MSFT should not be under-estimated.  

I know some clients that want a DG tools-independent approach (i.e.  do not want to spend the money on a separate DG-specific toolset such as  Collibra, Alation, ERwin, Informatica), so they instead use Sharepoint and add something like Nintex to handle the workflows and it apparently works quite nicely.  It also should be noted that the out-of-the-box Collibra workflows are pretty basic, and clients will need to build their own for anything that is more involved or based on client-centric processes - this involves building swimlane workflows in Eclipse and importing them into Collibra.

2.  Microsoft's strength is in the potential integration of the data management tools required to *fix" data quality issues to deliver business outcomes through a governance process.  One of the three primary governance use cases is analytics, and Power BI is a very prominent player in the BI/dashboarding space, so one assumes that MSFT will have an advantage for APIs related to PBI and ingestion of related metadata.  MSFT also has DQ/DI (ETL) through SSIS to enable data profiling, etc.  Collibra did recognize this gap and purchase OwlDQ recently, but one guesses that it will be a year before this is actually integrated.

The single biggest issue on the technology side in Data Governance is integration (surprise! =).  This is the biggest area of weakness for Collibra, as their strategy has changed multiple times over the past couple of years, and the breadth of integrations that customers are looking for just aren't there (ERwin actually has an impressive story on that front).  This continues to haunt Collibra projects and means that a lot of time and money is spent on the technical side to build a foundation.  This inhibits clients from implementing programmatic components that drive business participation.  The related issue is that business sponsors and potential business participants come to see DG initiatives as technical infrastructure projects and do not view them as mission critical in the delivery of a digital transformation strategy, which is what they should be.  And once business leaves the table, it is very hard to get them back for a second round when they don't see the value.

Purview is able to work with any Azure cloud application data or on-prem SQL Server metadata (in addition to AWS cloud application data to some extent I believe), but their broader API strategy remains to be seen as it is still early days (launched in Dec. 2020).  If they take this as seriously as they are claiming however, expect MSFT to make gains in this area quickly, but don't trust the promises of any vendor: if you have specific sources to ingest, then ask for a reference customer and a demo of the integration actually working, no matter which vendor you are dealing with.

My final comment:  both good products, but remember that DG is all about growing a program based on documenting your internal business and data management processes.  As a result, my advice would be to choose the most cost-effective option that has the *existing* (not promised) APIs that you need for your sources, and use it to formalize these processes within a tool.  If you get this in order, you can change your tool over time.  The DG marketplace has evolved so that the "tool is the solution" approach is no longer valid, and people realize that the build of a DG Program is more about their own internal processes than it is about the purchase of technology.