{"id":1740,"date":"2014-02-25T00:00:00","date_gmt":"2014-02-24T23:00:00","guid":{"rendered":"https:\/\/wwwneu.strehle.de\/tim\/weblog\/archives\/2014\/02\/25\/1697\/"},"modified":"2014-02-25T00:00:00","modified_gmt":"2014-02-24T23:00:00","slug":"1697","status":"publish","type":"post","link":"https:\/\/www.strehle.de\/tim\/weblog\/archives\/2014\/02\/25\/1697\/","title":{"rendered":"Web of information vs DAM, DM, CM, KM silos"},"content":{"rendered":"

I have spent years of my life making our software work with other software, and I think we have a problem: The \u201centerprise\u201d is managing overlapping information in disparate systems that don\u2019t interoperate well<\/strong>. There\u2019s lots of system flavors: DAM<\/a> (interesting stuff like photos, videos, articles). DM<\/a> (boring stuff like forms, business letters, emails). CM<\/a> for publishing on the Web. KM<\/a> holds expert\u2019s contact info and instructions. CRM<\/a>, employee directories, project management tools, file sharing, document collaboration\u2026 Each one with a different focus, but with overlapping data.<\/p>\n

Now one system\u2019s asset metadata can be another system\u2019s core asset\u2026 Take the Contact Info fields from the IPTC Photo Metadata<\/a> standard, for instance: When a photographer\u2019s phone number changes, will you update it in your DAM system? How many places will you have to update it<\/strong> in the DAM \u2013 is it stored in a single place, or has it been copied into each photo? You\u2019ll probably just update your address book and ignore the DAM. A DAM system simply isn\u2019t a good tool for managing contact information. But it still makes sense for it to display it\u2026<\/p>\n

For a more complex example<\/strong>, here\u2019s a typical scenario from our customers: A freelance journalist submits a newspaper article with a photo. It\u2019ll be published in print and online, copied into the newspaper archive, and the journalist is going to get paid. Now when an editor sees that nice photo in her Web CMS and wants to reuse it, can she click on it to see 1) the name of the editor who placed it in the print edition, 2) the photo usage rights, 3) the amount paid to the journalist for the current use, and 4) the journalist\u2019s phone number? No, she can\u2019t. The data for 1) is stored in the print editorial system, 2) in the DAM (rights) and the DM system (contracts), 3) in the SAP accounting system, and 4) in the employee directory.<\/p>\n

Of course, all of this can be made to work since each system has some sort of API. With one-off interoperability hacks<\/strong>, for which you need a programmer who\u2019s familiar with the systems involved! Incompatible information silos are hurting the business and wasting a lot of developer time. This is a known problem, and the subject of two more acronyms: II = Information Integration<\/a>, and MDM = Master Data Management<\/a>. As a software developer, I see two possible solutions:<\/p>\n

First, going back to a monolithic system<\/a> that does everything at once is not a solution. Neither its user interface nor its backend implementation would be well-suited to the host of different tasks that users need software for.<\/p>\n

But we could find a clever, generic way to link information<\/strong> from various systems together so that we can \u201csurf\u201d it in any direction. Linked data in the form of HTML+RDFa is a great way to do this, see my post Publish your data, don\u2019t build APIs<\/a>. (And Lars Marius Garshol on Semantic integration in practice<\/a>.)<\/p>\n

Or a much more complicated (but fascinating) solution: Product developers stop rolling their own databases and assume they\u2019re going to operate on a shared datastore<\/strong> that is created and managed by someone else. Their software accesses it through a configurable data access layer. Imagine running WordPress and Drupal simultaneously on top of the same MySQL database, working on the same content! A shared datastore would allow for centralized business rules and permissions. But for practical reasons (performance!), this is likely not going to happen. (A baby step in the right direction: Use LDAP instead of creating your own users and groups database tables. We\u2019ve done this and it works great.)<\/p>\n

In real life, information doesn\u2019t stand alone \u2013 it lives inside a web of interlinked data. Until our systems can handle this reality, we\u2019ve got to break it down, remodel and copy it for each siloed system. Let\u2019s try to improve on that!<\/p>\n

Update:<\/em> See also Ralph Windsor \u2013 Digital Asset Management And The Politics Of Metadata Integration<\/a>. Related blog post by me: Dreaming of a shared content store<\/a>.<\/p>\n","protected":false},"excerpt":{"rendered":"

I have spent years of my life making our software work with other software, and I think we have a problem: The \u201centerprise\u201d is managing overlapping information in disparate systems that don\u2019t interoperate well. There\u2019s lots of system flavors: DAM (interesting stuff like photos, videos, articles). DM (boring stuff like forms, business letters, emails). CM […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"footnotes":"","_share_on_mastodon":"0"},"categories":[1],"tags":[],"class_list":["post-1740","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\/1740","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=1740"}],"version-history":[{"count":0,"href":"https:\/\/www.strehle.de\/tim\/wp-json\/wp\/v2\/posts\/1740\/revisions"}],"wp:attachment":[{"href":"https:\/\/www.strehle.de\/tim\/wp-json\/wp\/v2\/media?parent=1740"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.strehle.de\/tim\/wp-json\/wp\/v2\/categories?post=1740"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.strehle.de\/tim\/wp-json\/wp\/v2\/tags?post=1740"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}