Wednesday, February 3, 2010

Leading Edge or Bleeding Wedge?

Quite often in the software industry we come across the question of whether to use the latest version of a product or technology.

There are pro's and con's for being the first with a new product, using either the latest version, or the tried and trusted version that everyone else is using.

In my capacity as being an IT Manager, and now a consultant for a software vendor, this issue has cropped up many times. So what exactly do you need to know in order to make that decision, that ultimately could be the difference between a successful implementation, or an expensive failure?

Being first cab off the rank has its advantages... someone has to be first! What can that mean for you? On the other hand, knowing that someone else has already gone through the pain is an easier pill to swallow for your Senior Management, those we have to justify our decisions to, or get the funding from.

There are a few areas of consideration which I've touched on below. It's not an exhaustive list by any means, and I would encourage any comments/suggestions.


Risk would be the most compelling reason not to use a new piece of software. Risk is probably the first thing on the mind of those with the cheque book.

Obviously, no-one releases software that hasn't been tested (!) But testing for the infinite combinations of computer systems is impossible. Testing for human behaviour would cover for only small percentage of users. Data models and quality of data is also something you couldn't expect to have been tested to exhaustion. That leaves your own testing. Only you can test a product on your infrastructure, with your data. How critical is the software to your business? What is the impact of a failure, in terms of cost, reputation or time if you go with an immature product?

Let's not forget that most new versions of software are there to address bugs or deficiencies. The latest version may fix a critical item on your requirements list. Improvements in workflow or compatibility may directly be pertinent to your situation.

Knowing that the software is in production somewhere is a comforting thing. Knowing that someone in your industry is using the same technology successfully offers further reassurance. Even if someone else has taken the bold step to be first, is no guarantee for your business.

Being (one of) the first may enable you to be first to market with your offering. Competitive advantage can often come from your systems. You may be competing in a busy market place. Having leading edge technology could be the differentiator you've been striving for.


Functionality is a major factor in choosing software. The latest version may contain that one piece of functionality you really need. In some cases, a newer version may omit critical functions (perhaps to be included in later releases).

Using an older version may mean you'll have to add customisations or work-arounds. They'll have to be costed into your implementation, and then of course future consideration of upgrades (see below)

Certainly integrations tend to get better with newer versions. Product suites such as Oracle SOA Suite have moved toward a common (application server) platform. In the past you might have had to implement different server technologies to realise business functionality.


If you do decide to go down the tried and trusted path, you're almost certainly going to want/need to upgrade at some point. That then throws up present and future considerations.

Depending on the version you go with, there may not be a smooth migration path to a newer version. One click migrations are few and far between. If you've made customisations then there's a good chance you might have to do them again! Data migration and the subsequent testing can be a costly exercise, particularly if you have to do it multiple times.


Here's the clincher.. maybe! Risk mitigation may come in the form of support. You can almost guarantee that if you're considering implementing leading edge technology before anyone else, then you've probably already caught the eye of your vendor. Leveraging that attention can be an opportunity for you. In a previous life, I was in the position where I took the first Australian license for one of the Oracle SOA Suite products. In return for getting on the Early Adopter Program, and being a reference site, I received direct access to the product developers, and a substantial amount of local support. Of course we had teething problems, but Oracle made the process somewhat painless. We got involved in the Client Advisory Board, and had many of our suggestions and feedback on our experience incorporated in subsequent versions.

When negotiating with your vendor to take on a new release, you'll probably want to get some commitment from them that they'll have the cavalry standing by. Just how much that might positively influence your stakeholders will be for you to find out!

In terms of support, older versions of products are sometimes given a shelf life i.e. they're not going to be supported forever. The different levels of support offered by your vendor may mean that if you do experience problems in the future, you could be on your own. You may not want to be running business critical systems on software that is on End of Life.


When looking at any technology, you'll want to ensure that your internal team has the skills to implement and manage your systems. You might want to supplement your team with partners, contractors or vendor personnel. Upskilling your team or hiring contractors might prove costly, especially for the rarer skills. Vendors will most likely have a good supply of experts and backup support to be able to provide services for you and present an opportunity for your internal staff to pick up the skills on the job.


The luxury of time is something most of us don't have. Looming deadlines and compelling events are always against us.

Implementation time. How long might it take to implement either a previous version, or the latest version? For new software or technology, your vendor might not be able to give you an accurate expectation of implementation time. If they do, you can bet they will err on the cautious side! A mature product will have many veterans to call on to share their experience.

Getting onto a beta program is a great way to "play" with latest technology before anyone else. Oracle has a Beta Program for its technology products, that was used by LogicalTech to give some comfort to their customers. "Some database owners were renowned for being reticent to upgrade" ... "in case it introduced instability issues".

With unlimited time, we could test everything and mitigate most risk. Just how much effort do you want to put into product suitability and system testing, when your stakeholders and users are keen to get into UAT?

All in all there are many reasons to go with either option. Each implementation will have its own requirements, justifications, and objections. Hopefully I've given a few things to think about when starting out on this journey!