Customizing Livelink – OScript development – Scary huh?

Many organisations that use Livelink get kind of nervous when I mention a specific problem can be solved by developing a custom Livelink module in OScript. And of course, they are right to have some concerns. (Over-) customization is a risk for your Livelink (or any other!) system. A heavily customised system will be more difficult to support and to upgrade.

This is absolutely true, but what is the alternative? An enterprise-wide system such as Livelink will, out of the box, never cover all functionality that is required by every department/process/user in your system. So what are you going to do? Tell your users to work in a different (less-effective?) way? Change their business processes because Livelink doesn’t support theirs? Or perhaps buy a standard add-on module from Open Text or a third party? This last one may seem like a good idea, but being a standard module, it is generic in nature and will most likely still not solve your specific business needs completely.

So perhaps we should consider customisations after all… Let’s take a closer look at what the fears and risks really are, and how they can be managed. Most heard fears is that a new, custom Livelink module might be hard to maintain and upgrade and could have a bad influence on performance…

It´s not that scary

One general fear that I want to take away first, is the fear of the unknown. The fear that this scary, obscure customization will make changes everywhere to the core system and that you will from then on always be dependent on one of these hard to find, expensive OScript developers to keep your system alive.

Specifically when talking about maintenance and upgrade problems, it is important to realise that a custom module is not at all that exotic. What clients typically don’t know, is that Livelink’s modular architecture, makes it possible to customise the system in a good way. It’s not the case that Livelink itself is a big, robust, single system and that any customisation is just an add-on that hacks into this big system. The functionality of Livelink itself is made up from separate modules. Technically, there is no real difference between Livelink’s own ‘Discussions’ module and a custom module.

Even when you need to modify standard functionality, Livelink’s approach of orphaning and callbacks gives you the possibility to make your changes in a separate module, without modifying the original code. Impact is typically low; the customisation can be undone by simply uninstalling the module (assuming no database modifications have been made).

Document your fears

For a client it is important to identify the risks or concerns you have and then make sure they are part of the requirements specification and the design documents. Too often I see that even though some fears or doubts exist, the requirements are only aimed at the functionality of the application. The non-functional requirements such as maintainability, reliability, performance, etc, are too often forgotten in the requirements specifications, or not seriously dealt with in the functional and technical design documents. A lot more non-functional requirements (or ‘quality attributes’) exist that you may want to include in your specification document. For example, see http://en.wikipedia.org/wiki/Non-functional_requirements or http://en.wikipedia.org/wiki/List_of_System_Quality_Attributes.

Code quality is important

Still, sometimes it will be necessary to make changes that go beyond the standard options that Livelink provides. If this is the case, it is up to the developer to clearly document where this happens (and up to the client to demand such documentation from the developer). I always provide a standardised ‘Quality Assurance’ form with any customization I make. This form lists important information such as database schema changes (including uninstall behavior), overridden/patched features, mapped html files, list of error messages, etc. Such details have proven to be very valuable for the system administrators.

Support contracts

A support contract with the system integrator can lower the risk even further. This could ensure you will have no compatibility problems in the future. Still, it may complicate things when an issue arises that cannot directly be connected to the customisation. Who will be responsible for doing the support? The best solution would be to have the customisation certified by Open Text and then be included in the existing OT support contract.

To sum it up. A custom Livelink module does not need to be that scary. It can be an effective (and perhaps the only) way to optimise your system with improved usability and the ability to handle your specific business needs in the best way possible.

Think big, act small. But not too small!

A lot of Livelink implementations are not 100% successful. Typically, an unsuccessful implementation results in either an ECM system not being used at all, or a system used in such a way that your users (and your content) are out of control. The first one, is the one I see the most.

Nowadays there is a lot of focus on the change management aspect of an ECM project. This is extremely important when looking at user acceptance, but my thoughts are on the system itself. Many organisations roll-out a very basic system and plan to add more features later on. However, by that time, a lot of damage has been done. On such a limited system, it is very hard to convince end users why this system is soo much better than the network shares they were using before, as most arguments seem to benefit the organisation itself, but not the end-user directly.

So here are the 10 things you should have in place before you roll out your Livelink system (in no particular order by the way). Without these, it will be more difficult to win the hearts of your users.

1. Directory Services
   No discussion possible. You need single sign on from the start!
2. Office and e-mail integration
   Livelink will be the central storage for the content your users create, so make it easy for them to add content to the system.
3. Explorer integration
   For the same reason as #2, your users will need either Livelink Explorer or WebDav (or a combination)
4. e-Link
   E-mail enabling your system greatly enhances productivity, but perhaps more important, your users will love it.
5. Workflow
   Workflow is often not implemented in ‘phase 1’ of the ECM roll-out. However, workflow is a great way to get things into your system in an organised way. You users will quickly see the benefits of the ECM system compared to a fileshare ‘system’.
6. WebForms
   Even if you’re not using them for a business purpose at the start of your Livelink roll-out, you can create one that your users can use to request access to specific areas or functionality of the Livelink system itself. This is just another way of giving your users something extra, something they didn’t have before.
7. WebReports
   WebReports can be used to make your LiveReports more attractive, and once you start using them, you will find out many, many more uses for them. WebReports can also be used turn your Enterprise Workspace into an attractive dynamic homepage.
8. Appearances and Customviews.
   Add some corporate branding to your Livelink pages using Appearances and spend some time creating attractive customviews for the main folders in your Livelink system. Add a few lines indicating the purpose of the folder and add an icon or small image to make it more attractive.
9. Object Importer
   You don’t want to start with an empty system. You will have many documents to bulk-load from existing systems. Object Importer is the perfect tool for this. Make sure you have some Excel templates ready which can be used to generate the XML you need easily.
10. A good viewer
    The ‘View as webpage’ option is simply not that good. A viewer like Brava can be a nice (but expensive) replacement with a lot of additional options you may use later on (markups, limiting downloading/printing of classified documents). It especially becomes a ‘must have’ when you have engineering drawings in your system.

Introduction

Hi, welcome to my ‘Livelink thoughts’ blog. I’ll be posting my thoughts on Livelink related matters here from now on.

But first, let me tell you who I am. My name is Rick Breemer, born in 1976, living in Dordrecht, the Netherlands. I have been working with Open Text Livelink since 2000. I have specialised in Livelink software (OScript) development for Open Text’s flagship product Livelink Enterprise Server. Over the years I have worked with many different Open Text products and have played many different roles in a variety of client environments.

From this experience I will be posting my thoughts on approaches, tools and techniques that I believe are most successful. My target audience? I guess anyone who is interested in Livelink!