As previously mentioned by @yogeshVU, it would be good to decouple the data dashboard from the design studio. The explicit required components still need to be formalized but here is a quick draft:
Taxonomy Provider: An endpoint returning a taxonomy in a common exchange format. This could be a static file server hosting taxonomies or generating the taxonomy on the fly (in the case of the design studio). This must include both the taxonomy and content type definitions.
Data Provider/Backend: A data provider like PDP, MongoDB, etc. One challenge is making sure that the appropriate credentials are used for any of the backends.
Data Dashboard: The component that needs to be configured with the above info (and other data).
The former two could be provided in a configuration for the data dashboard. This configuration could be dynamically generated by the taxonomy design studio to make usage as simple as it is currently (while allowing it to be usable for many other use-cases, too).
Since the data stores a reference to the taxonomy used to tag it, we could make it easy to switch between taxonomies from the data dashboard... (Especially, if we allow viewing data that is in the data store but incompatible with the current taxonomy.)
As previously mentioned by @yogeshVU, it would be good to decouple the data dashboard from the design studio. The explicit required components still need to be formalized but here is a quick draft:
The former two could be provided in a configuration for the data dashboard. This configuration could be dynamically generated by the taxonomy design studio to make usage as simple as it is currently (while allowing it to be usable for many other use-cases, too).
Since the data stores a reference to the taxonomy used to tag it, we could make it easy to switch between taxonomies from the data dashboard... (Especially, if we allow viewing data that is in the data store but incompatible with the current taxonomy.)