Origins of DAM

PvT: Okay. Talk a little bit about digital asset management and whether or not that’s a feasible way for global organizations to manage their corporate brand identities, photos, and videos—their brand assets?

MM: Sure. Well, just for a little bit of a history on that. My firm invented the term “media asset management” in 1994 in our work with Aldus and MediaStation.

Later in 1996 or so, we expanded the term when we wrote the white paper for Apple Computer as part of their Masters of Media Program—a brilliant industry-wide marketing framework that included Adobe, Agfa, Kodak, Quark, and Xerox conceived and executed by Jeff Martin, then the Director of Marketing for their Advertising, Design, New Media, and Publishing division.

Apple commissioned an executive white paper to make the business case for their line of Apple servers. IBM picked up from there and commissioned another white paper and international roadshow—also to make the case for the IBM Content Manager.

In 1998, my partners and I wrote the first full market report on DAM and continued with the reports until 2002.

In 2001, we began our long-standing partnership with Henry Stewart Events and their DAM Symposium.

In 2003, as the Editor in Chief, I started the Journal of Digital Asset Management—with which I continue today.

Strategic Capability

I say this all as preamble, do I consider digital asset management strategic capability? The short answer is, emphatically, yes. You can’t manage a global brand and a pan-regional marketing operations without some form of DAM. In fact, we have published a series of executive white papers on the subject.

Now DAM has a lot of misinterpretations, or misunderstandings in terms of what it constitutes.

DAM, first and foremost, constitutes business strategy for accelerating operational processes within media, entertainment, and publishing, and marketing content processes within global brands. So it’s reducing cycle time, reducing cost, and having a process that’s far more agile or flexible in adapting to change.

I contrast digital asset management with content management. I used to say somewhat tongue in cheek that content management is really ‘crap management’.

Content management deals with more or less self-descriptive files—documents or Web pages for which you do not need a lot metadata to describe its contents, meanings, semantics associations with other content and, more specifically, who owns the content or images—from where did the editorial or copywritten material come, when does it expire, all that.

Digital asset management, in contrast, deal with non-descriptive files, hence the emphasis on metadata and the systematic reuse and transformation of preexisting digital media files. This entails the creation and management of metadata associated with findability, reuse standards, and permissions or digital rights management.

Now a reusable digital file may represent an image, photograph, or publishing template. Digital assets may include text or product claims used in marketing communications, or video clips, MP3 podcasts, and type fonts, or Flash animation. Or elements that contribute to immersive virtual world experiences 3D and 2D models or primitives.

A digital asset might also include software code assets—scripts and programming—and things like IT service management policies and business rules or software libraries and software objects. Or learning objects or reusable pieces curricula that flow into books, instructional DVDs, or online courseware.

So, digital asset management is really about reuse and creating metadata that give you competitive advantage: Cost reduction, time to market, higher quality, greater process agility, and the ability to maintain transparency or governance across an entire marketing supply chain.

As a business strategy, digital asset management starts with a DAM repository—where you put all those bits—and begins to really payoff with an operational group—a DAM service group—that maintains the integrity of metadata, digital asset files, and user productivity.

This brings us to the current state of the art in DAM:  Managing a supply chain for continuous improvement and reduction of cost, cycle time, defects, and opacity of key business processes.

So, I do not consider digital asset management an option, nor a luxury. Just like you have an email system, you must have a DAM. It’s just not an option.

–

Breaking points

–

MM: Could you give us a little bit of the history of business intelligence?

MB: Oco was formed to address the problems of existing BI tools, which were too difficult to develop and use. I can give you the historical perspective on that.

Back in the early 1990s, people started building data warehouses, because they didn’t have access to corporate information for the purposes of reporting and data analysis. They had lots of different operational systems, but they didn’t have systems that had data from all over the place gathered together.

These projects were originally pushing the relational database technology to the breaking point. Very large data warehouses were created, and every one of the vendors struggled to make these very large databases work.

But the software has matured now, allowing companies to put together quite, quite large data warehouses. There’s now an array of companies that offer BI tools. There’s also been some consolidation in the industry lately with SAP acquiring Business Objects and IBM acquiring Cognos and so forth.

Now there’s robust relational database software out there, and there are tools for accessing the information, but it has still been much too difficult. A recent report from Gartner estimates that still over 50% of these data warehousing or business intelligence projects fail.

–

–

Professional background

MM: Let’s start with an introduction.

MB: My name is Mike Beckerle. Let me explain a little bit about my background. I joined in January of 2008. As the CTO, I’m responsible for product development of new products and technologies and the strategic direction for existing products.

I joined Oco from IBM, where I was involved in large-scale computing. The core of my experience comes from spending much of my career in developing large-scale parallel processing for commercial data processing workloads. The result of this work is now the core part of the IBM information server product. I was responsible for much of the scalability of that product.

I joined Oco because it was a very good fit with my background, and my experience is very relevant to Oco’s strategic direction. For example, during the dot-com era, I was involved in “SaaS,” at a startup called Fact City, although it wasn’t called that at the time. We did something that was fundamentally SaaS and quite similar to Oco’s solution in taking data in disparate forms and using it to construct a high-volume Web-accessed data service.

I decided that putting scalable commercial data processing and SaaS together would provide a great value proposition for the marketplace. I was thinking about launching this type of solution, and discovered that there was already a company doing it — Oco.