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.

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!