This blog post is inspired by Roger Howard\u2019s excellent, thought-provoking \u201cWorkflow doesn\u2019t\u201d<\/a> critique of the workflow functionality in today\u2019s Digital Asset Management systems.<\/p>\n (I don\u2019t know which systems Roger has worked with. If you want to catch up with the state of DAM workflow engines, here\u2019s some links to get you started: Status-based workflows in Canto Cumulus<\/a>. The MerlinOne workflow engine<\/a>. ADAM Workflow<\/a>. DAM News on configurable workflow systems<\/a>. DAM News on workflow in DAM value chains<\/a>. Anything else?)<\/p>\n I like Roger\u2019s observations that \u201cexceptions are the rule in production\u201d, exceptions require decisions, and \u201cdecision making is something humans excel at\u201d. This reminds me of Jon Udell\u2019s old motto<\/a> that \u201chuman beings are the exception handlers for all automated workflows\u201d. Software that doesn\u2019t embrace this fact will stop the work from flowing.<\/p>\n \u201cWorkflow systems are rigid and don\u2019t reflect the constantly changing realities of most businesses\u201d \u2013 I can absolutely confirm this. So many times have we written code to automate a process, making the customer happy, until new business opportunities required changes and our code kept them from adapting quickly. Some larger customers make sure to have in-house DAM technicians who can code and configure without always having to go through us, the vendor.<\/p>\n Roger argues that DAM software should support power users, not enforce rigid workflow definitions. This is quite interesting: It obviously appeals to me as a developer (i.e., power user), but quite a few of our customers seem rather scared of power users. They\u2019d rather have a \u201cpower administrator\u201d and not leave much freedom to the regular user.<\/p>\n To me, another important point in Roger\u2019s article is this: \u201cValuable integration begins with the user experience, with the frontend.\u201d David Diamond demanded very much the same in Reinventing Digital Asset Management<\/a>. I have written about frontend Web app interoperability<\/a> before; it\u2019s hard, but this is the problem we have to solve.<\/p>\n The rest of this post is a scenario that helps me think about what workflow support might mean in practice. It\u2019s a bit lengthy, so feel free to stop reading here \ud83d\ude42<\/p>\n This workflow is common to our newspaper-publishing customers:<\/p>\n A newspaper editor asks a photographer to take pictures of an event. The photographer sends the pictures to the newspaper, and one of those gets printed in the paper.<\/p>\n Workflows consist of processes. Let\u2019s look at the processes involved: First, there\u2019s a planning phase where editors decide which topics and events to cover. One of the available photographers needs to be assigned the task of taking the pictures. The photographer, after shooting, selects the best photos and adds descriptive text and metadata to them. Then she sends the photos to the newspaper. At the newspaper, the favorite picture is chosen, the image cropped and enhanced, placed on the page and sent to the printer. Someone in accounting makes sure the photographer gets paid. And finally, the pictures \u2013 with more metadata for better findability \u2013 are added to the newspaper\u2019s image archives to allow reuse.<\/p>\n Note that there\u2019s no mention of software so far: This workflow is decades old and doesn\u2019t require any software at all, let alone \u201cworkflow engines\u201d. Now let\u2019s see how software can help.<\/p>\n Today, almost every task mentioned above involves software. But often, these tasks are performed in separate systems that don\u2019t talk to each other: Editorial topic planning might happen in Trello, while photographer assignments are tracked in a Google calendar. Photos are sent to the newspaper via e-mail, then manually uploaded into a DAM system. For image retouching, the image is downloaded from the DAM, the retouched version re-uploaded, then manually exported to the editorial system where it gets placed on a newspaper page. The next day, a librarian searches the DAM for each picture that appears in the printed paper and manually adds metadata including the date of publication. Based on that metadata, someone else can search for published images and enter payment data into the accounting system so the photographer gets paid at the end of the month.<\/p>\n In this scenario, there\u2019s many isolated software systems. Humans need to know where to look for information, and which data to manually copy between systems.<\/p>\n Pretty soon, people will want to automate parts of these processes: The photographer assignment notification should contain a DAM upload link so that images go directly to the DAM, with automatically-added assignment metadata. The editorial system should tell the DAM which images have been printed in the newspaper, so that the DAM can add publication metadata automatically, move the image into the long-term image archive, and send payment data to the accounting system.<\/p>\n A lot of time can be saved automating processes. But of course there\u2019s drawbacks, too: Automation implies the assumption that we always want the same things to happen. It means taking human oversight and decisions out of the loop.<\/p>\n What can go wrong? The photographer might send pictures not related to the current assignment, so the automatically-attached metadata is wrong. Not every published image may be copied into the archives for reuse. And humans would know that they can skip the logo that\u2019s in the paper every single day, even though it technically is a published picture.<\/p>\n This kind of automation is usually neither visible to end users, nor can they stop it from happening. Changing automated processes \u2013 to better align them with always-changing business processes \u2013 involves technicians, whether processes are \u201chardcoded\u201d in software or configurable.<\/p>\n And of course, no software works perfectly all of the time. When an automated process fails, you have a whole new class of problems: possible data loss, follow-up processes that already have run with incomplete input data, the difficulty of manually working around the problem while it persists, and cleaning up afterwards.<\/p>\n Even with automation, the software has no notion of the overarching workflow. It isn\u2019t aware of the context, so it cannot present the context to users. Human communication revolving around the workflow needs to happen \u201cout of band\u201d, i.e. via phone and e-mail, outside of the systems the information is living in.<\/p>\n Which information can get lost in our example workflow? Well, the photographer might want to communicate something to the Photoshop guy (\u201cmake sure to blacken out the license plate\u201d), or to the accounting staff (\u201cthe editor agreed on paying twice the standard fee for this assignment\u201d). She might have to alert the paper that these pictures must not be reused, an exception from the rule that all published pictures are marked as \u201cavailable for reuse\u201d. To make this last one more difficult, let\u2019s assume that she gets aware of this after she sent the pictures to the newspaper, but before the automated archiving process has run (so she cannot add this information to the image metadata, and the archivist she might call doesn\u2019t yet see the image in the archive).<\/p>\n Each of the persons (and automated processes) involved may have information to add, or questions to ask, or decisions to make that affect other (possibly automated) processes.<\/p>\n A fully workflow-aware DAM system would treat a workflow instance as an asset-related entity with its own metadata. Each asset used within a workflow would display its own routing sheet that shows what kind of workflow this is, which additional information has been attached to it, what happened so far and what\u2019s to happen next (manually or automatically). With appropriate permissions, the user could modify that sheet to add information, change what happens next, or move the asset out of this workflow instance.<\/p>\n The routing sheet with its workflow and process data would probably live in a separate system because real-life workflows cross system boundaries. And the same sheet would appear in all systems involved in the workflow; the Photoshop guy would see it in Photoshop, the photographer in her photo upload app, the accountant in SAP.<\/p>\n Can we do this? Does something like this already exist? Or would it be overkill and we should indeed refrain from workflow features and just let the power users define their own automation?<\/p>\n Update (2018-01-24):<\/em> See also Why DAM Workflow Is Not Flowing<\/a> by Ralph Windsor, DAM Workflow: Plan for success<\/a> by Cathy McKnight, Workflow That Works<\/a> by Uri Kogan, MediaBeacon Visual Workflow Editor<\/a>, Introducing: The [TACTIC Workflow Engine] Publish Node<\/a>, Cumulus RoboFlow Automation<\/a>, Using Merlin\u2019s workflow engine<\/a>, and Intro to [Widen] Workflow 2<\/a>.<\/p>\n","protected":false},"excerpt":{"rendered":" Workflow doesn\u2019t This blog post is inspired by Roger Howard\u2019s excellent, thought-provoking \u201cWorkflow doesn\u2019t\u201d critique of the workflow functionality in today\u2019s Digital Asset Management systems. (I don\u2019t know which systems Roger has worked with. If you want to catch up with the state of DAM workflow engines, here\u2019s some links to get you started: Status-based […]<\/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-1798","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\/1798","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=1798"}],"version-history":[{"count":0,"href":"https:\/\/www.strehle.de\/tim\/wp-json\/wp\/v2\/posts\/1798\/revisions"}],"wp:attachment":[{"href":"https:\/\/www.strehle.de\/tim\/wp-json\/wp\/v2\/media?parent=1798"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.strehle.de\/tim\/wp-json\/wp\/v2\/categories?post=1798"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.strehle.de\/tim\/wp-json\/wp\/v2\/tags?post=1798"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}An example DAM workflow<\/h3>\n
Level 0: Do everything manually<\/h3>\n
Level 1: Automation<\/h3>\n
Level 2: Workflow awareness<\/h3>\n