{"id":1791,"date":"2014-12-10T00:00:00","date_gmt":"2014-12-09T23:00:00","guid":{"rendered":"https:\/\/wwwneu.strehle.de\/tim\/weblog\/archives\/2014\/12\/10\/1753\/"},"modified":"2025-11-07T14:06:15","modified_gmt":"2025-11-07T13:06:15","slug":"1753","status":"publish","type":"post","link":"https:\/\/www.strehle.de\/tim\/weblog\/archives\/2014\/12\/10\/1753\/","title":{"rendered":"Dreaming of a shared content store"},"content":{"rendered":"\n

All the content-based software I know (WCMS, DAM and editorial systems) is built the same way: It stashes its data (content, metadata, workflow definitions, permissions) in a private, jealously guarded database<\/strong>. Which is great for control, consistency, performance, simpler development. But when you\u2019re running multiple systems \u2013 each of which is an isolated data silo \u2013 what are the drawbacks of this approach?<\/p>\n\n\n\n

First, you\u2019ve got to copy data back and forth<\/strong> between systems all the time. We\u2019re doing that for our DAM customers, and it\u2019s painful: Copying newspaper articles from the editorial system into the DAM. Then copying them from the DAM into the WCMS, and WCMS data back into the DAM. Developers say \u201cthe truth is in the database\u201d, but there\u2019s lots of databases which are slightly out of sync most of the time.<\/p>\n\n\n\n

You\u2019re also stuck with the user interfaces<\/strong> offered by each vendor. There\u2019s no way you can use the nice WordPress editor to edit articles that are stored inside your DAM. You\u2019d first have to copy the data over, then back again. User interface, application logic and the content store are tightly coupled.<\/p>\n\n\n\n

And your precious content suffers from data lock-in<\/strong>: Want to switch to another product? Good luck migrating your data from one silo into the other without losing any of it (and spending too much time and money)! Few vendors care about your freedom to leave<\/a>.<\/p>\n\n\n\n

I don\u2019t believe in a \u201ccentral content repository\u201d in the sense of one application which all other systems just read off and write to (that\u2019s how I understand CaaS = Content as a Service<\/a>). No single software is versatile enough to fulfill all other application\u2019s needs. If we really want to share content (unstructured and structured) between applications without having to copy it, we need a layer that isn\u2019t owned by any application, a shared content store<\/strong>. Think of it like a file system: The file system represents a layer that applications can build on top of, and (if they want to) share directories and files with other software.<\/p>\n\n\n\n

Of course, content (media files and text) and metadata are an order of magnitude more complex than hierarchical folders and named files. I\u2019m not sure a generally useful \u201ccontent layer\u201d can be built in such a way that software developers and vendors start adopting it. Maybe this is just a dream. But at least in part, that\u2019s what the Semantic Web<\/strong> folks are trying to do with Linked Data<\/a>: Sharing machine-readable data without having to copy it.<\/p>\n\n\n\n

P.S.: You don\u2019t want to boil the ocean? For fellow developers, maybe I can frame it differently: Why should the UI that displays search results care where the displayed content items are stored? (Google\u2019s search engine certainly doesn\u2019t.) The assumption that all your data lives in the same local (MySQL \/ Oracle \/ NoSQL) database is the enemy of a true service-oriented architecture<\/strong>. Split your code and data structures into self-contained, standalone services that can co-exist in a common database but can be moved out at the flip of a switch. Then open up these data structures to third party data, and try to get other software developers to make use of them. If you can replace one of your microservices with someone else\u2019s better one (more mature, broadly adopted), do so. (We got rid of our USERS table and built on LDAP instead.) How about that?<\/p>\n\n\n\n

Related posts: Web of information vs DAM, DM, CM, KM silos<\/a>. Cloud software, local files: A hybrid DAM approach<\/a>. Linked Data for better image search on the Web<\/a>.<\/p>\n\n\n\n

Update (2017-01-31):<\/em> The \u201cheadless CMS\u201d fits my \u201cshared content store\u201d vision pretty well, and it finally starts entering the hype cycle \u2013 see Greg Luciano\u2019s CMSWire piece What\u2019s Next for Headless CMS in 2017?<\/a>.<\/p>\n\n\n\n

Update (2025-11-07):<\/em> The Solid Project<\/a> \u201cPods\u201d are designed to achieve something similar for individual people\u2019s data.<\/p>\n\n\n\n

<\/p>\n","protected":false},"excerpt":{"rendered":"

All the content-based software I know (WCMS, DAM and editorial systems) is built the same way: It stashes its data (content, metadata, workflow definitions, permissions) in a private, jealously guarded database. Which is great for control, consistency, performance, simpler development. But when you\u2019re running multiple systems \u2013 each of which is an isolated data silo […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"footnotes":"","_share_on_mastodon":"0"},"categories":[1],"tags":[],"class_list":["post-1791","post","type-post","status-publish","format-standard","hentry","category-weblog"],"share_on_mastodon":{"url":"","error":""},"_links":{"self":[{"href":"https:\/\/www.strehle.de\/tim\/wp-json\/wp\/v2\/posts\/1791","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.strehle.de\/tim\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.strehle.de\/tim\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.strehle.de\/tim\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.strehle.de\/tim\/wp-json\/wp\/v2\/comments?post=1791"}],"version-history":[{"count":2,"href":"https:\/\/www.strehle.de\/tim\/wp-json\/wp\/v2\/posts\/1791\/revisions"}],"predecessor-version":[{"id":2258,"href":"https:\/\/www.strehle.de\/tim\/wp-json\/wp\/v2\/posts\/1791\/revisions\/2258"}],"wp:attachment":[{"href":"https:\/\/www.strehle.de\/tim\/wp-json\/wp\/v2\/media?parent=1791"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.strehle.de\/tim\/wp-json\/wp\/v2\/categories?post=1791"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.strehle.de\/tim\/wp-json\/wp\/v2\/tags?post=1791"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}