Last month, an article on CMSWatch.com by Theresa Regli discussed the difficulty of assessing how a DAM system will perform on a typical corporate laptop as compared with what the vendor uses to demonstrate their product at a sales pitch. In particular the thorny subject of older browsers and devices that don’t support Flash (e.g. iPads and iPhones) was raised.
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 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.
