By Dave Poyser, Director, Xpress Document Solutions

We’ve come a long way in terms of the functionality, capabilities and scope of document management, and its related solutions – and the DM Collaborators’ blog shows off a lot of these advances in very succinct, well written pieces.

But today’s topic is, shall we say, a little more taboo. It’s the subject of “bespoke software development”, a phrase guaranteed to induce sweaty palms and ashen faces amongst clients when first discussing solution scenarios for a prospective document management project.

Now, I don’t know whether this is a throwback to the bygone era of document management software’s infancy where big frameworks and bespoke development were the ‘norm’ (as were the big ££s involved) or whether it’s just a general fear of the unknown – either way, I’d argue that the “concerns” -for want of a better word – are more unfounded now than ever.

Sure, cost is still a big factor in commissioning what is effectively your own document management product. But in my experience, that usually comes down to “feature creep”, that ever flowing river of ideas that “everyone” feels must be implemented – which of course increases the development time.

But, like any project, keeping a handle on that comes down to defining the specification in a thorough manner and having the right management structure in place to keep things on track. Something that’s no different even if you’re implementing a product.

Strip any document management solution down to its core building blocks and you’re pretty much left with a database and some form of access to that data.   The tools that link these basic components together have become (thanks to some very clever developers at some very positive and forward thinking companies) much easier to use, and provide much quicker times for taking a concept and turning it into a reality.  You can pick a development framework, a database solution, and specialist components to perform specific tasks relevant to your requirements; the components take care of all the heavy lifting and work seamlessly together (removing a huge barrier related to maintenance and configuration).  By bringing it all together in the right way, you get exactly what your organisation requires.

If it’s that easy then, you might ask, then why isn’t everyone building their own solution? To that, I would say:  it simply comes down to striking the right balance with your requirements and the solutions that are available.

If you have a product available that meets your requirements (in terms of features/cost/delivery time etc), then re-inventing the wheel would seem like madness.  After all, the document management vendors have put an untold number of man hours into developing their products. They have honed the products based on real world usage and feature requests across a broad spectrum of organisation types.  So why not benefit from that experience?

Conversely, if you’re unable to find a product that meets all of your requirements – for example to get the most business critical functions enabled, the products themselves have to be customised by the vendor or extended through their own plugin framework – then maybe the option of creating something that does must surely be explored to its fullest extent?

So am I advocating a revolution, where we all build the document management software solutions that we want? No, I’m not; what I’ve tried to highlight is that the legacy of the software development Dark Ages is no more and that there are plenty of similarities between building and buying. I’m advocating the uptake of document management as a solution in as many client organisations as I possibly can, using the best means necessary.

If that’s an “off the shelf” product such as EASY Software, then that’s brilliant – but try to keep an open mind, because the answer to the question “should we build it?” isn’t as straight forward as you might at first think.