Legacy Document Automation Systems

- I got my support but are you gonna get yours?

 

I narrowly escaped the shedding of a tear a few months back when I was 're-structured' out of Oracle's organizational plans. Having put in about 13 years with the company that started out as Insystems but eventually ended up in Oracle's portfolio of acquisitions after several other incarnations as Standard Register, Whitehill and Skywire, it was a daunting prospect to think that I would be abandoning the comfort and familiarity of the environment I had known for well over a decade. It was far from a surprise as Oracle had redundant offerings for document automation software in their toolset and had chosen to move forward with the Documaker application instead of the IStream software where the majority of my background was rooted.

Nonetheless, a shock to the foundation such as sudden unemployment causes one to undergo some personal reflection, but with the support of my family and a full complement of qualified professionals, I was able to soldier on. Among my revelations, I suffered a particular disappointment in my recognition that there existed a large base of users of the document assembly and insurance process automation software that I had spent so much time supporting, implementing, marketing and selling who I would no longer be in a position to help. Upon surveying my situation and that of the insurance document automation market landscape, I realized I was not yet prepared to abandon my experience and expertise - who many would argue is primarily attributable to a reliance on those far smarter than me - to move onto something brand new.

Witnessing the demise of Mosaic, Calligo, IStream, <xml> Transport, Documerge and several other commonly used document assembly platforms, it became clear that there were bound to be many users of these applications left with no long term outlook for support or evolution of these applications. Sure these systems may still work and meet current needs but I have seen too many times the crippling effects of continuing to rely on applications that have minimal vendor support. Consider these questions:

 

  • What level of assistance would you expect to obtain if you encounter a bug that requires core software modification to resolve? The answer is probably pretty obvious when you consider that the software is not undergoing active development and the vendor no longer has processes or staff in place to handle such a situation
  • Have you noticed that COBOL programmers seem to drive very nice cars? As applications become outdated, qualified resources to help support and maintain these systems become sparsely available and very expensive to acquire.
  • Ever had a corporate mandate to upgrade an application that is at the foundation of a core system that does not support the version to which you want to upgrade? This is all too common of a scenario when you continue to use a platform that the vendor has abandoned and you are left supporting these one off configurations that do not conform to your preferred standards
  • Customer support responsiveness is always acceptable to meet your needs for issue resolution and assistance, right? I have heard many a complaint about the support systems of vendors' over the years. This can only be expected to worsen when an application becomes obsolete and the internal skillset starts to drop off and resources are re-deployed.
  • You may not want to be leading edge, but do you really want to be trailing edge? Understandably, avoiding the risk that unproven new technology introduces may be important, but being on the trailing edge of technology can be equally as risky as a result of exposure to the issues noted above and as the opportunity cost of experiencing the benefits new and efficient technologies can offer is foregone

 

While waiting to find my next unsuspecting employer, or the winning lottery numbers, I spent some time leveraging the contacts that I had made over the years in working with dozens of insurance and financial services companies across North America to do some analysis. The majority of these organizations were using one of the aforementioned legacy and soon-to-be-obsolete systems, and were not well-informed of its support status. Stated more simply, the vendors were not being very forthcoming as to what level of support and product maintenance these organizations were getting for the maintenance dollars they were often still being charged. In addition, most companies acknowledged that they would certainly have found this information useful in decision-making and planning for their current and future investment in and usage of the legacy software.

I will admit that I was somewhat surprised and miffed; in many cases organizations were unwittingly continuing to pay maintenance and support bills from vendors (often times in the tens and hundreds of thousands of dollars) simply because it was budgeted and had been for many years without any additional rationalization of value obtained from such expenditure. There should absolutely be some onus on the consumer to evaluate the on-going value reaped for their software support and maintenance spend, but a little good-faith honesty from the vendor would have been the high road to becoming a respected solution provider. Furthermore, complex tiered support policies are often difficult to decipher and make it hard for the application user to understand what they are actually getting under their support agreement. Even when you see terms like lifetime support and extended support, I urge you to take a good look at what you are being offered, and what the vendors can reasonably deliver for applications that are no longer under active development.

 

I can fully appreciate the constraints preventing many organizations from abandoning legacy applications such as IStream and Documerge in one fell swoop. Conversion costs, resource limitations, user re-training, software investment expense among other things can make justifying the adoption of a new solution challenging. Implementations of the traditional alternatives that you have seen in the document automation market space are often hindered by these issues and can be stricken by impediments to easy deployment such as:

  • bloated application footprint
  • proprietary development tools that require significant training and technical expertise to comprehend
  • limited flexibility in configuration scenarios and strong configuration preference for vendor-supplied stack of applications
  • difficult and inflexible conversion option availability for existing legacy content

 

For those that follow the market analysts, you will realize that it is not too often that attention-grabbing new entrants in the document automation marketplace come along. I had been a regular follower of the Celent, Forresters and Novarica industry reports when I noticed the appearance of Xpertdoc early in 2011. Still employed by Oracle at the time, I went only as far as checking out their website, watching some clips of their software in action and making a mental note that the solution looked quite interesting and different from most other options.

Fast forward to the summer and exhausting my tolerance - I mean financial reserves - being a stay at home dad a few months after departure from Oracle, I decided I must begin the search for gainful employment. In a rare occurrence of actually being able to recall something that happened more than 24 hours ago, I summoned my positive recollections of Xpertdoc and made contact with the leadership at this organization. I don't think it took long to realize that this was a very innovative organization and even more importantly, one that had a clear focus on the insurance industry with an advanced solution that differed from most others. Just as intriguing for me, with my exposure to so many insurance organizations stuck on legacy document automation systems, was the ease of conversion and adoption that Xpertdoc offers. Never had I seen a solution with such availability of comprehensive functionality in a package that was so easy to understand and so flexible to implement. I liked the look of it so much I joined the company and have been diving headfirst into implementing the software and promoting its merits as a fantastic replacement for legacy document automation platforms.

In a future postings, I promise to share some of the features that I think make Xpertdoc so exciting and of such high potential value for anyone suffering from the risks of using software on its way to obsolescence and who has been dissatisfied with other available options. Stay Tuned!

This entry was written by Chris Tully posted on December 10, 2011 . Follow any comments here with the feed for this post. You can post a comment.

Related pages


Post a comment