So, we have made some significant alterations to our existing whitepaper Video Digital Asset Management: 12 Crucial Points to try and cover some of this.  I must say, however, that while the formats and technologies move around, the general principles about needing to be realistic and pragmatic about what is actually (rather than theoretically) possible on your typical corporate network still remain and this part of the paper didn’t require a lot of updating.

The report is free of charge, you can place a request to get it sent to you from our reports area.

This prompted me to think about a few more of the inconvenient truths (to borrow a phrase) of delivering web based enterprise DAM systems and the extent to which a typical corporate IT environment can thwart and constrain the scope of what is feasible.  Below I outline six examples that the project implementation team here at Daydream run up against on almost every job we are involved in.  I also explain why I believe that if the DAM software industry does not come to terms with them that they could have a negative impact on demand across the whole sector.

Truth #1: Work with the client’s IT environment or don’t work at all

In larger businesses with centralised corporate IT divisions, making minor changes to a typical browser or desktop setup for significant groups of users involves an epic voyage of change request forms, risk management meetings, deployment and back-out plans before they even get close to implementation.  The IT department’s priority is keeping email coming in, viruses out and achieving a general level of “just don’t touch it” stability.  We have learned that it is best to build DAM solutions that will work with no internal changes required for either administrators or regular users - otherwise expect a long, arduous and frustrating wait to get any kind of solution deployed and into active use.

Truth #2:  Lots of people will still be using IE6

The subject of IE6 causes considerable anguish for designers, developers and vendor sales reps that have to deliver demos on one of their prospective client’s PCs.  Despite the numerous protests about IE6, it’s not going away.  Microsoft are offering support for it until 2014 because they know that while the web development community might hate it, the corporate IT departments who constitute their largest customer base regard upgrading it as a lower priority job that can be deferred until they finally migrate away from Windows XP.  Despite serious security flaws in IE6, the pain of upgrading thousands of desktops is still not sufficient to convince IT departments to bring forward technology refresh programmes.  Add in a recession with a squeeze on IT budgets and the wider picture of why we’re still supporting a browser from 2001 become clearer.  Daydream implements most client editions of our FocusOPEN Digital Asset Manager to work with IE6.  We fully expect to still be dealing with this browser until at least 2012 and the best we can hope is that most corporate IT departments will decide to skip IE7 and go direct to IE8.

Truth #3: IT will want to host it

Around 10 years ago when we first started installing web based DAM systems, most corporate IT departments did not like the idea of hosting any kind of web application and were more than happy to let us take care of that for them.  As far as they were concerned, they were merely ‘websites’ and not even core business ones at that.  Fast forward to 2010, apply some bad press about ‘Application Service Providers’ (what people now call SaaS), data protection concerns, stories about vendor mega-mergers leaving customers in the lurch, and add in the fact that many IT departments have sunk small fortunes into their own data centres and you have the current scenario.  If the IT department is involved, they often want to host the DAM system internally on their kit and using technologies they can support if the supplier bites the dust.  Where this can get tricky is if the vendor has developed using non-corporate friendly toolset like Ruby, PHP, Plone, Python, ColdFusion etc.  Although we at Daydream don’t have any objection to these technologies (we use many of them for internal systems ourselves), we have learned to use widely accepted enterprise technologies for enterprise DAM to avoid problems when the time comes to deploy to the client’s hosting infrastructure.  As people used to say about IBM, “no one got fired for buying Microsoft” and that is another inconvenient truth of enterprise applications.  Exempted from this are those vendors who chose to implement using that other enterprise stalwart: Java, however, they just have to get used to the inconveniently high cost of hiring anyone half-decent enough to code using it.

Truth #4: Corporate networks are not ready to handle HD content

Time was when people would do any serious internet surfing at work because their home internet connection would be a painfully slow 56k modem.  These days, enterprise connectivity has not kept pace with demand for web and internet services with the result that available bandwidth on many corporate LANs has decreased significantly to the extent that ‘traffic shaping’ and all kinds of other clever devices designed to throttle usage are all too common.  Meanwhile, most user’s home connections are DSL services offering megabits of bandwidth for a monthly cost equivalent to the price of a couple of cinema tickets.

In demanding scenarios such as delivering video, large print media etc. many corporate connections will struggle to cope.  Those slick HD videos of the client’s latest TV commercial being smoothly streamed from the sales guy’s laptop can often translate into a jerky Dadaist farce when viewed on a corporate network.  The inconvenient truth of many enterprise DAM scenarios is that their corporate network doesn’t live up to the performance employees may have grown used to  – especially with bandwidth heavy content like video or large print files.  Before promising to provide these facilities for corporate clients, Daydream consult with IT department to find out about the bandwidth situation and we try to manage the expectations of what can realistically be achieved.

Truth #5: Enterprise IT security products hate AJAX and Flash

IT departments are often keen on a plethora of firewalls, proxy servers, hardware security appliances, packet inspectors and a range of other security paraphernalia (possibly to help deal with all those IE6 security holes).  Whether the DAM system is hosted internally or externally, these devices can frequently cause Flash and AJAX to fail mysteriously and under obscure combinations of circumstances that are difficult to reproduce.

We have learned that it’s advisable to keep the clever client-side scripting or Flash/Flex to a safe minimum and test it very early to avoid the next inconvenient truth that proxy servers, firewalls and other security devices will frequently disable client-side functionality and leave the users with interfaces that are less functional than basic HTML.  I’m not saying that AJAX or Flash should never be used, at Daydream we have taken advantage of both technologies to help with a range of requirements which would have been very difficult to deliver in any other way.  However, we have drawn up a laundry list of tests that anything we implement in them has to survive before we risk using AJAX/Flash in a production environment.  We also try to avoid gratuitous use of them where they do not add anything that cannot be achieved via conventional techniques.

The Final Truth: It’s one thing to build applications, it’s quite another to deploy them

A former senior colleague often used to remind myself and my fellow developers that it’s one thing to build applications, it’s quite another to deploy them.  Over the intervening years I have come to more fully appreciate the significance of this inconvenient truth and what it means when it comes to delivering robust software that will work properly in enterprise IT scenarios.

There is a danger currently that DAM vendors are getting into a features arms race to provide points of differentiation and a wow factor that will help swing attention their way in an increasingly crowded market.  All too many are throwing ill-conceived AJAX or Flash based interfaces into environments where they may fail spectacularly.  The problems often seem to be glossed over by keeping quiet about the potential pitfalls of pushing the envelope and using technologies or techniques that have not been properly tested outside the developer’s lab.

Currently, the DAM market is riding something of a wave of high demand that has bucked the recessionary trend despite an era of declining budgets.  Most vendors with a serviceable product and visible presence have seen their customer acquisition rates rise as a result.  To sustain interest and obtain a foothold as an integral enterprise solution (in the same manner as say HR or Accounts/Finance applications), the DAM software industry needs to get more realistic and honest about how our technologies are going to be used by a typical enterprise customer and engineer for greater robustness and reliability.

If this does not happen we collectively run the risk of our class of applications developing a reputation for hype, riskiness, low reliability and high rates of user abandonment.  This will encourage prospective clients think twice about whether our products can offer long-term ROI and if a better strategy may be to consolidate requirements into do a bit of everything - but none of it very well systems like SharePoint which are perceived as safe, reliable and corporate friendly.  This will be the ultimate inconvenient truth and one I hope we do not have to experience.

• Garbage In = Garbage Out - how organisations end up with low quality metadata and the impact on ROI
• The 7 ways this can happen
• The digital asset supply chain and why metadata is fundamental to it
• Tactics for simplifying cataloguing and metadata entry
• Methods of simplifying search (using metadata)
• Metadata education - why it is important that marketers understand metadata
• Getting marketing staff involved and collecting feedback from them
• Bringing all elements together to form a metadata strategy

The paper can be requested via our digital asset management reports area along with our other information titles.

As a special bonus to readers of this blog, this PDF is the presentation deck from the Earley presentation and is a great accompaniment to the paper.

Several commentators, however, have raised concerns about the nature of the solutions provided and how much support and assistance users can realistically expect to obtain from taking the open source route.  In particular, the measurement of ROI when taking into consideration the costs of support and implementation services is raised as a negative point about open source DAM.  These discussions highlight some popular misconceptions about the nature of open source software, mainly because they tend to be free of licence charges.

In simple terms, open source guarantees nothing other than that access to the source code will not be restricted - it does not necessarily mean that there is no cost involved or that there is an obligation on the part of the author to distribute copies of the code to anyone who asks for it.

The GPL is one of the more common open source licences in use and allows software authors and/or distributors to charge a fee for supplying open source software.  Also, they can refuse to distribute copies of the code publicly.  The fact that many open source software authors agree to provide the source code for free via downloadable links on public websites is more of a marketing strategy or personal choice than a stipulated requirement of the licence.

The metaphors used to explain open source do not help with dispelling these myths.   One example often used is the self service supermarket checkout concept.  There are others, but see these separate articles by Jeff Atwood and Henrik de Gyor for examples (the latter specifically relates to DAM).  Although both are interesting observations and make some valid points, they are arguably inaccurate when considering open source software.  The premise of both articles is that open source software resembles a ‘self-service’ supermarket checkout where users can avoid the time cost of checking out via a human operated till with a lengthy queue of shoppers, however, they are forced to deal with rudimentary service related issues that would be handled for them in the human operated checkout.

I would argue that this metaphor is not really valid because supermarket customers are most certainly charged for the products they wish to procure (that is evident by the receipt provided whichever checkout is used).  Customers are invited to discount the time required to use a managed checkout service in return for taking on this work themselves.  In software terms, this is like being charged licence fees for your product but then having to pay for your own learning and acquisition of skills to complete real world tasks with it. To me, this characterises the closed source packaged, non-bespoke software experience most people are used to already - they are expected to handle the service element of the software implementation themselves and work out how to use it on their own.

So how should prospective buyers compare open source digital asset management systems against closed source ones?  To quote from Richard Stallman, an open source pioneer, “you should think of free as in free speech, not as in free beer.”

In larger companies, a preference for open source is usually due to risk management factors rather than any kind of evangelical or altruistic preferences.  In this sense, the open source licence is an alternative to a software escrow agreement and side-steps the legal complexity and expense incurred by both vendor and customer when drafting these agreements.

The second key benefit of open source in an enterprise context is the bizarre fashion in which some closed source software vendors use an arbitrary ‘per user’ licence model for web based solutions when the marginal cost has fallen to virtually nothing (or at least does not move in neat straight line).  Again, the open source model is effective at removing these pricing inefficiencies - for enterprise software at least.

An open source licence allows both buyer and vendor to focus more clearly on services and the actual work of delivery.  For enterprise software, it is a more honest and professional way to create and consume value.  These are the crucial factors that buyers need to consider when buying a enterprise DAM solution for a large organisation.  The ‘free’ cost of one product licence versus another is a dangerous distraction from considering the overall ROI.

Currently, Daydream has elected not to offer publicly available distributions of FocusOPEN (although we do not rule out doing so in the future).  As I have illustrated, this does not invalidate our open source credentials.  Having an open source solution without a licence cost also does not leave our clients without support or the additional services they need to implement a large scale DAM effectively.  I would argue it places greater emphasis on the services element of software implementation such as user support, training and hosting.  These have been and will continue to be the more significant factors for anyone implementing enterprise digital asset management.

It seems that the term ‘brand asset management’ has been adopted by a two distinct practitioner camps in recent years, leading to some confusion of the term’s definition, or more importantly, to whom its problems should be tasked.  Companies in both the technology and creative industries release press on the subject and all have their respective brand asset management solutions.

Essentially, the broader term appears to belong to the academics of brand strategy, most notably Scott Davis in his book “Brand Asset Management: Driving Profitable Growth Through Your Brands” (The Jossey-Bass Business & Management Series, 2002). In this realm, brand is recognised as amongst a firm’s most valuable assets, which requires careful management in order to maximise brand value and draw consumers in.

However, the term brand asset management has also found its place in the terminology of software engineering companies, to refer more specifically to a range of Digital Asset Management features for ensuring brand compliance throughout marcomms production and delivery.   In this definition, technologists respond to the very practical need identified by Davis to ensure that “all communications coming from your company deliver a consistent message to consumers…must reflect the brand value, persona and vision.”

To effect a cohesive brand strategy across a modular organisation, brand managers must maintain some control over marketing communications at the point of production and an ongoing dialogue with those responsible for brand execution, namely designers, copy writers and producers, both staff and external agencies