What is the level of difficulty to do the initial tagging and classification?
Is it the amount of data or size of company or complexity of the industry or access permissions that are the variables or something else altogether?
Few companies seem to have a data governance policy - much less an organization-wide one. And not all companies seem to have a chief data architect or even chief systems architect. Investment banks and other financial services companies.
Data has been cobbled together over decades and continued to append without labeling/organizing/ontology across disparate systems, geographies with different data privacy rules, and in terms with high turnover where institutional knowledge was lost.
The level of effort is low when companies build incrementally. The mistake most make is to map everything up front. Building tags to support specific use cases monetizes the effort quickly and justifies doing more to expand tags to support new use cases.
From an execution standpoint, this is how I visualize this process:
1. The infrastructure for mapping is in place.
2. Information is being collected on the success of the current use cases (data flywheel does this).
3. Based on the output from #2, decisions are made.
I'm thinking that for #1
- either a baseline infra is enough, and this can be expanded as well, OR
- build a more advanced infra upfront.
I've separated the mapping infra from the actual execution (mapping itself), and I think that both can have their own continuous improvement process, guided by the results. There are also different levels of complexity involved when improving infra or the mapping itself; and they're interconnected.
Now I know that their Data Cloud functions as the "Context Layer" cloud version, which makes a lot of sense. Agents need access to this context layer to execute, so this is the communication layer the service needs.
I'm thinking that depending on the date-storage solutions companies employ, those providers may offer different solutions to this high-level context. If that is not easily available, or it requires additional transformations, it creates a barrier to adoption.
If the data-storage providers are exploring their own agentic solutions, their monetizing strategy won't include making it easy to use a different context layer provider.
What is the level of difficulty to do the initial tagging and classification?
Is it the amount of data or size of company or complexity of the industry or access permissions that are the variables or something else altogether?
Few companies seem to have a data governance policy - much less an organization-wide one. And not all companies seem to have a chief data architect or even chief systems architect. Investment banks and other financial services companies.
Data has been cobbled together over decades and continued to append without labeling/organizing/ontology across disparate systems, geographies with different data privacy rules, and in terms with high turnover where institutional knowledge was lost.
The level of effort is low when companies build incrementally. The mistake most make is to map everything up front. Building tags to support specific use cases monetizes the effort quickly and justifies doing more to expand tags to support new use cases.
From an execution standpoint, this is how I visualize this process:
1. The infrastructure for mapping is in place.
2. Information is being collected on the success of the current use cases (data flywheel does this).
3. Based on the output from #2, decisions are made.
I'm thinking that for #1
- either a baseline infra is enough, and this can be expanded as well, OR
- build a more advanced infra upfront.
I've separated the mapping infra from the actual execution (mapping itself), and I think that both can have their own continuous improvement process, guided by the results. There are also different levels of complexity involved when improving infra or the mapping itself; and they're interconnected.
Thank you for writing this comprehensive article!
Now I know that their Data Cloud functions as the "Context Layer" cloud version, which makes a lot of sense. Agents need access to this context layer to execute, so this is the communication layer the service needs.
I'm thinking that depending on the date-storage solutions companies employ, those providers may offer different solutions to this high-level context. If that is not easily available, or it requires additional transformations, it creates a barrier to adoption.
If the data-storage providers are exploring their own agentic solutions, their monetizing strategy won't include making it easy to use a different context layer provider.
Platform distribution problem.