Is Five Monkey Syndrome in your DAM?
Blitline IPaaS Blog guest post by Ralph Windsor, DAM News
Scene: A DAM Development Studio Somewhere In The World
“We’re developing a system that has to generate thumbnails and previews of images, videos and some other stuff. What components will let us do that? There must be some cheap or open source thing that will do it all for us? I know, ImageMagick and FFMPEG will do the job. They’re open source so we won’t even have to pay anything. Let’s plug them in and see how it goes.”
(Two days later)
“This seems easy enough, give it a bunch of images or videos and we’re generating thumbnails, previews etc. no problem. Job done.“
(2-3 weeks later)
“What do you mean client X is reporting that all their thumbnails are blank? Oh yeah, colorspace, I didn’t think of that. Well not many people use CMYK these days anyway. Oh, we told them we would handle it and they say they’ve got 7,000 other images like it?”
“Right, I’ve sorted that out. Job done.”
“What do you mean there are still images that aren’t processing? Oh, they’re in [some obscure color profile]. I didn’t think of that.”
“Right, I’ve sorted that out too. What do you mean now the videos aren’t processing properly? I’ll take a look, I’m sure it will be easy to fix.”
(The Following Monday)
“I spent the entire weekend figuring this out and I’m in the doghouse now with my [wife|husband|girlfriend|boyfriend|kids|pets] but I’ll make up to them next weekend. At least I'll never have to look at that stuff ever again. I suppose I'd better document this, but what the heck, I'll do it later…”
(Friday before next weekend)
“So, they uploaded 500 really huge TIFF files at the same time as those other people were uploading a 2TB 4k video, obviously it wouldn’t handle it! Yes, I know Steve in sales promised them we could scale up to meet the demand, but not right now because we’re still trying to make it stable. They want it now or they’re saying they won’t pay their bill? Oh, OK then. Steve is paying for the dev team’s pizza tonight though, right?”
(Saturday morning)
“I’ve done it. What do you mean half of the images haven’t processed? OK, I’ll get that done too. I’m certain once we get through all these teething problems, we can just leave this thing and it will be fine. That’s it now, I’m absolutely sure of it.”
(Six months later - very early Sunday morning)
“What do you mean the server has been hacked? How did they get in?”
“The version of ImageMagick we’ve got is out of date? OK, we can update it. Oh, but if we do, plugin x won’t work anymore.”
“What if we implement [very complex workaround] just for them? I can’t think of any other option, we can’t leave this as it is.”
(One week later)
“So, the media processing is stable now? Great, now we can get on with some real work.”
(Two weeks later)
“So Steve promised these guys that we could process 3D and CAD files as well as Word and PowerPoint documents? Why didn’t someone ask me first?”
“We’ve done that now. Please tell me there isn’t anything else?”
“What do you mean the guys who have all those images in a weird colorspace are saying nothing is processing properly again? But if we upgrade them, it will conflict with everyone else. We’ll need a separate environment just to process their stuff! This is ridiculous!”
“This media processing thing is harder than it seems! We’re backed up with keeping this running night and day, we hardly have any time left to work on enhancements that will keep customers happy and new features that will keep us competitive. Surely there must be someone who will take care of all this for us so we can get back to doing some proper work again?”
Scene: A DAM Development Studio Somewhere In The World
If you have ever worked on the development of Digital Asset Management systems, the above section of faux-dialogue will be all too familiar. Across the world, DAM developers go through something like the above, almost as a rite of passage necessary to earn their credentials as a 'real' DAM developer. While this activity might provide a near limitless source of war stories to share with colleagues and tech-savvy friends when they're down the pub, it is a massive waste of time and effort that could be far better employed on something more productive.
The situation with transcoding services bears some comparison with The Five Monkey Experiment, wherein a scientist places five monkeys into a cage with a bunch of bananas located overhead. In the story, after one monkey ascends to reach the bananas, the scientist sprays the monkey with cold water and then sprays the other monkeys with cold water. A second monkey attempts the same feat and brings the same outcome to themselves and their cohort. When a third monkey tries to climb, this time the other monkeys – including monkey #1 and monkey #2 – attack the monkey in order to ensure they avoid the cold water. The cycle continues even when new monkeys are brought into the cage.
How does the syndrome relate to DAM platforms?
I believe there are some interesting parallels when it comes to the Five Monkey Syndrome and legacy “requires insourcing” designation that many DAM software providers assign to certain functions within their platform. I have written before about the lack of innovation in Digital Asset Management, one of the primary causes is that the industry collectively exhibits the same characteristics as the five monkey experiment.
Sometimes the decisions about what to insource are made at the developer level and other times at the management level. Sometimes they’re the optimal choice. Sometimes not. Frequently, they are simply inherited and persist despite the toll they incur in terms of development resources (which are usually scarce for most DAM vendors), reduced speed to market and opportunity cost. Simply put, too many DAM vendors collectively re-invent the wheel and re-create identical functionality which someone else has already built (often in a superior manner).
The role of outsourcing via Platform-as-a-Service (PaaS) solutions
Outsourcing key infrastructure or core platform functionality has historically been frowned upon or generally overlooked by developers and product managers. Despite this, outsourcing and Platform-as-a-Service (PaaS) models are becoming ubiquitous across the entire Digital Asset Management supply chain.
This process started decades ago. In the 1990s, it was commonplace for DAM vendors to implement their own proprietary database. It is inconceivable that any vendor would do that now. Similarly, at one time, vendors would purchase physical servers and host on-line DAMs from private co-location facilities (or their own offices or even garages in a few cases).
These practices are rapidly disappearing because it adds an additional tier of responsibility and point of failure that typically isn't commercially justifiable. The same process is now occurring downstream in the digital asset management solution delivery supply chain.
There are some obvious areas where PaaS is used by both for start-ups and larger incumbents outside DAM. For example, metrics, log management and monitoring to name a few. As with the database and hosting examples, it is commonly accepted that these areas should be outsourced as this allows vendors to free-up devops resources to focus on high value offerings instead.
The theory behind this is covered in an article I wrote for CMSWire seven years ago called The Digital Asset Management Value Chain. Many of the trends described in that piece have already played out. Are there other DAM applications where the trend is to move from internal to PaaS? I believe so and that Image Processing-as-a-Service (IPaaS) may be on of the next PaaS solutions poised to become a de facto standard in the DAM industry.
Image Processing as a Service (IPaaS) at-a-glance
For DAM platforms with internal image processing applications, it is not uncommon to find that nearly every piece of the application has historically been cobbled together using open source libraries loosely tied together with in-house scripting and codebases.
As mentioned in the piece of fictional dialogue earlier, most developers start by installing an image processing solution like ImageMagick along with a number of additional libraries. Together, these become the foundation of everything else they build.
What normally happens next is that the DAM starts to grow and expand. Periodically, developers may update a few image libraries or update the machine’s OS that the image processing lives on.
Generally, if new image processing functionality like adding a new image format, stuff gets hacked onto existing platforms. This is after trying to remember how it works, since nobody has probably touched it in a year (and obviously, no one has got around to properly documenting the solution yet either).
Another often overlooked problem is image processing library vulnerabilities. Take a look at the CVE (Common Vulnerabilities and Exposures) DBand there will probably be a few familiar libraries. Have they been updated? Do these upgrades happen as part of OS updates. Who on the team is responsible for managing those?
What about image formats? Are PDF, SVG and EPS files in on vendor roadmaps? If they aren’t now, they probably will be someday. How about RAW image formats? Have you ever tried to manage color profiles with ImageMagick? If you have, I’m sure you have scars.
Building a robust image processing platform is like a long, complex game of whack-a-mole. Dealing with all the issues involved with properly maintaining and expanding it becomes a massive technical challenge. Image Processing as a Service (IPaaS) reduces the need to worry about legacy code, to make OS updates, or to mix and match media libraries.
With IPaaS not only does this kind of maintenance all go away, you generally gain significantly more functionality, improve queuing, and can also more quickly add functionality with the right partner. For example, color extraction, perceptual hashing, RAW formats, and brand new image formatsall come out-of-the box with IPaaS. The total cost of ownership is likely to be cheaper compared to developing and hosting an internal application.
What about reliability? What happens if your IPaaS goes down and interrupts your DAM platform file processing? This is a risk for any cloud platform, so if you are already doing any business in the cloud (e.g. AWS/EventBridge, Google Cloud, or MS Azure) then you have probably have already accepted this sort of potential issue.
If so, it may be better to focus on identifying if there are IPaaS solutions that can meet or exceed your own thresholds for uptime reliability, scalability, backup systems preparedness, and security.
Preferably, the chosen solution should have a long history of operational use during which time it has evolved considerably and had the opportunity to incorporate years of experience into the design – from how to keep a system up and running, how to accommodate new requirements (from you and your clients) and how to scale while keeping costs affordable.
The Secret of Modern DAM Success: Choosing Your Battles Wisely
There are an ever-increasing range of functional requirements from end-users which DAM vendors now have to contend with. I would argue that the primary function of most modern DAM solutions is to act as an integration conduit for DAM users' digital asset supply chains.
The purpose of the DAM is to provide the command and control center so the business can make informed decisions about their digital assets. In order to fulfill this role, vendors need a laser-like focus on where they can add most value for their clients. While activities like asset media processing appear to be 'core business', in reality most end-users tend to regard them as maintenance features, they only care about when they don't work.
Sooner or later, every DAM vendor reaches a point where they need to make decisions about which components of their application they wish to maintain, rebuild or outsource. Adhering to ancient wisdom or saying “it’s always been done that way” may not always be the best solution for you and your company.
When vendors think about image processing and other applications inside their DAM platforms, they need to consider not only whether or not all this activity really is integral to their firm. They must ask themselves whether or not they really are as 'best of breed' as they currently perceive themselves to be. If not, then maybe it is time to climb the monkey cage and grab a few bananas.
About the Author
Ralph Windsor is Project Director of DAM Consultants, Daydream and Editor of DAM News. He has over 25 years of experience in the DAM industry acquired as a DAM software developer, project manager, digital asset manager and consultant.