(Cover image is a diagram in the Oasis spec.)
Thanks to Venky on LinkedIn, I came across this CDP specification on OASIS (Customer Data Platform Version 1.0 Committee Specification 01).
The Technical Committee is chaired by Serge Huber of Jahia and Thomas Lund Sigdestad of Enonic. This CDP specification illustrates Consent Management, Privacy Management, Personalization, Newsletters and A/B Testing but mentions this should not be considered as an exhaustive list.
Do You Need Standards and/or Specifications?
When you build your MarTech stack, even if you go with so called “suite” vendors, you will always end up with several products, point solutions and platforms. Always.
Chief Marketing Technologist Blog by Scott Brinker recently published some beautifully visualised stacks for your inspiration.
You will notice that all those examples have several components and products. Each product and vendor has a proprietary way for integrations, data exchange, process management, APIs and so forth. Some suite vendors, who built their products via acquisitions have multiple different approaches for integrations and data exchange for different products in their suites.
When you have thousands of products and vendors, each with their own proprietary approaches, it would seem that some sort of standardisation would be useful.
In addition to simplifying integrations and data exchange, Standards and Specifications have several other advantages. For example, you can:
- Focus on solving business use cases rather than technical challenges
- Simplify your resourcing, skills, training and hiring needs
- Create components that work across platforms
- Reuse skills, resources, hardware, software, code, templates…
- You can have a predictable costing model
- And so on..
So having standards and specifications is good.
In Theory, at least.
History of Standards
I have been covering this (and associated) marketplaces for a long time and when I was reading this spec, I was reminded of some other standards and specifications in content technologies that promised a lot but were not able to deliver. In particular, recall the JSR (170 and 283, 186 and 286) and OASIS Content Management Interoperability Services (CMIS).
They haven’t really caught on.
Some reasons include:
- Support from vendors and community
- How do you differentiate? If everyone follows the same approach, it does limit a vendor’s ability to differentiate
- Standards are meant for features that are no longer niche: Even this spec describes only the most common features
- Provide Lowest Common Factor and hence you sacrifice features
- Many standards are evolving and slow to mature
- Discourage innovation and creativity
- What is mandatory and what is optional?
- Too many standards (and standard bodies)
- Parallel standards
- Do other applications in your environment comply?
- Etc
So that’s a long list. But essentially, what it means is:
Standards Can Be Helpful but Don’t Go Overboard.
Consider:
- How likely are you to port to another system
- Do other applications in your environment comply?
- Immature/evolving standard Vs mature proprietary solution
- Willing to sacrifice features?
Oasis CDP Specification
Okay, back to this Oasis CDP specification.
The two chairs (and members so far) are Jahia and Enonic.
Both of these were essentially Java-based Portal/CMS providers who have now expanded into other areas. In fact, Jahia now also has an open source CDP offering. This is based on Apache Unomi (which was created by Jahia only).
The site does not list any other members or any commercial CDPs that support this specification.
I have also not seen any customer RFPs that list support for this specification as a key requirement.
I hope the TC brings some learnings from history and that more vendors start supporting this spec. Some serious work needs to happen to popularise it and build a community around it.
Until that happens, I am sceptical of this (and other such) specs. But I do hope I am proven wrong with this particular specification. Best of luck to the TC and members for the success of this spec.