As databases have become like legos to be plugged into various enterprise apps — so too, the DAM will become a ubiquitous component in tomorrow’s enterprise.
So what does a large footwear manufacturer have in common with a company that prints 16 million grocery coupons every day, or with a desktop software company, or an online employment recruiter? Yes they all rely on a Digital Asset Management (DAM) system. But not in the way you might think.
Many companies think of DAM as a web-enabled file server. It's a lot more than that. Some use a DAM to manage their marketing materials. But it can be a lot bigger than that. Yes, DAM can provide storage, management, organization, and distribution. But think bigger.
DAM is becoming a platform.
Much in the same way that databases moved from obscurity to core business components, we’re seeing a similar shift with Digital Asset Management. In early software development, applications were developed using a myriad of custom data models, often in very ad hoc ways. Each new application had its own data framework. And why not? What else would you use?
But in the 1970's something changed. There was a consolidation, a growing consensus around a new technology: the relational database system (RDBMS) — a common underlying framework that could support any number of applications. By the 1980's, SQL — what became the common language of all databases — became the intergalactic data-speak for most Enterprise applications. In fact, the SQL92 standard still drives a vast majority of today's Enterprise and Web applications.
Today, it’s easy to see how the database is an entrenched component of modern business. But go back decades, when databases where first being utilized and deployed — how would you describe the benefit? Over time the benefits became clear: Incredible efficiencies. Any developer can quickly understand any application. And just about any tool can be quickly integrated.
Ironically, SQL became the anti-oracle: something clear, something anyone could quickly come to know.
The Database Re-visited
The world of DAM is moving rapidly towards common standards. Schemas are slowing consolidating. Dublin Core and other schemas are looking to create common metadata vocabularies. Adobe's XMP has become a popular tool for transporting metadata within the asset file; and this has expanded beyond just bitmap formats to now include video and other formats.
NetXposure has provided a Web Services SOAP API for many years. Recently, this was further augmented with REST-based services that make integration much easier to implement and utilize. Using popular libraries like JQuery, any Content Management System can publish data directly from the NetXposure DAM.
Content Management Interoperability Services (CMIS) builds on this, using the same protocols — SOAP and REST — but goes much further by defining a common nomenclature for DAM objects. (Google is also moving in this direction with their new "Web Intents"; though for Google, this is a common language for all Web apps.) The concept and goal is the same: a rosetta stone or babel fish for web services. Only this time, the services provided by the DAM are much more extensive than plain old relational-data in the database.
This starts to move Digital Asset Management down the same road today as SQL did in the 1970‘s for the database: a common toolkit, a common language. And with that comes the same benefits.
But what about our protagonists? Manufacturers, marketers and non-profits are all driven to increase efficiencies with their systems. We have our footwear company, the print coupon publisher, the desktop app company, and the job board. What are they doing? Yes, they still need the database. But for them, that's not enough. They have files, semantics, workflow, and dynamic imaging. Now they need something else; something more.
For them, the DAM has become a tool. Just like the database in the 1980s, now the DAM is taking on this same role, and yet providing much, much more.
The footwear manufacturer needs to conceptualize prototyped products. In this workflow, the product concept starts out as pure data from a merchandizing database. Concepts that move forward are routed to an illustrator, who mocks up the shoe from the underlying data — the style, the fabric, and the colors. Concepts that are approved, are sent to a factory in other parts of the world to be made into a physical prototype. That prototype is then photographed. At each stage — the data, the illustration, the photograph — the data is evolving. The context changes, the users who interact with the asset change (data, illustrators, manufacturing plant operators, digital photographers), and the underlying "asset" file changes (metadata, illustration, digital image). This is done in the DAM.
The coupon company spends more money on ink than its employees. So each coupon is carefully analyzed and desaturated to strike a balance between visual appeal and cost-effectiveness. This company produces many renditions of each coupon; the user context drives the data presented on the coupon — the product, the price, and the offer. Third-party product vendors participate in the Coupon production, as approval, analysis, desaturation, transcoding, and distribution are all handled through the Digital Asset Management system.
The desktop application company provides added services to its customers in the form of source files for content creation — fonts, images, templates and the like. This distribution relies on the efficiency of Content Delivery Networks (CDNs) of course. But underneath that, there's a need for searching, browsing thumbnails, permission controls, and high-availability download capabilities. This is done using the DAM.
The recruiting company provides a specialized information, catering to a specific industry. However, this is an online enterprise that has dynamic imaging requirements, content search, organization, and workflow. How do you accept resumes in all the common formats, and then display that information on today’s popular devices, including tablets and mobile? Why not convert all the Word docs, and everything else into PDF? And why not create the underlying images to drive a page-turning user interface for browsing those resumes? For searching, it's necessary to index all the underlying resume text, regardless of the original format. This is done using the DAM.
All these stories are the same story: the DAM is not just a traditional repository or distribution, it's becoming a tool. It's the new platform. And the same bright future.