Evaluating enterprise application software

A seasoned ERP salesman coaching a junior colleague once said: “The trick, my boy, is to avoid the IT department like the plague for as long as possible, as they’ll just make your life complicated by asking lots of irrelevant geeky questions. Win the hearts and minds of the business people first by convincing them the software will meet their needs, then IT will have no choice but to follow.”

Many a deal has undoubtedly been won on this basis, and many have seen the conflict, resentment and real practical issues that arise when a software vendor, aided and abetted by its consulting partners railroads a solution with little regard for harmonisation with the rest of the IT landscape.

That said, some of us also have experience of defensive IT groups who go out of their way to obstruct progress when some big application implementation is proposed. Whether this is because of the perceived threat from highly paid consultants invading their territory, or some other form of power politics, such behaviour is equally undesirable.

In healthier situations, in which the IT department is properly involved in the evaluation and decision making process, what are the things that matter from an IT perspective?

Starting at the top, or the bottom if you take an architectural view of the world, the platform upon which the application is founded could be an important consideration. We may, for example, care about whether it is based on Java, .Net or some proprietary execution environment, depending on our existing operational landscape and the skills we have in place from a management and support perspective. The same goes for the underlying database, e.g. a Microsoft shop might struggle looking after an Oracle-based setup, and/or is reluctant to invest in the skills and tooling.

The software underpinning the application might also matter from a development and integration point of view. Again, there is the question of skills and experience, but the ease with which extensions, modifications and interfaces can be designed, built, tested and maintained will have a direct impact on both cost and risk – not just in relation to the initial implementation, but on an ongoing basis.

Fortunately, many packages nowadays provide some flexibility in terms of platform requirements, often supporting more than one application execution environment and database management system. The embracing of standards by the software vendor community in general also minimises the impact when compromises are necessary. This is particularly the case when thinking about integration, with support for Web services interfaces now the norm rather than the exception – at least with mainstream packages.

The degree to which you care about whether the vendor has taken a component-based approach, or even implemented a full-blown service oriented architecture (SOA), will probably depend upon your overall IT strategy. Some organisations are very comfortable with and application landscape comprising a series of essentially black boxes with interfaces between them, on the basis that each element can be supported and maintained discretely.

However, it is much more common nowadays to strive for as little redundancy in application functionality and data as possible, given that many of the costs and risks associated with IT nowadays are a function of fragmentation and disjoints. Componentisation and SOA can potentially make a big difference here.

Beyond the underlying architecture, there are then some philosophical and practical questions around the way in which an application is tuned or customised to meet the needs of the business. The more this can be achieved through configuration rather than coding, the better. This not only cuts implementation times and reduces the cost of ongoing maintenance, but also helps as successive releases of the software are implemented. One of the most common challenges with upgrading an application is migrating customisations, but if it’s all managed through meta-data and software switches, everything is so much easier.

Coming back to where we started, while we have only touched on some of the technology related dependencies and impacts here, the truth is that there is actually quite a lot to consider from an IT perspective when evaluating packaged applications – it’s not just about business functionality.

But is this principle now well accepted within your organisation? Is IT involved early enough in decision cycles to make a difference? Or perhaps you agree with that ERP salesman quoted at the beginning, and think IT people should be kept out of the loop as much as possible. And if you’re leaning in that direction, with the current media and marketing frenzy surrounding all things cloud, maybe you would advocate business people just whipping out their credit cards and signing up for SaaS services without IT even knowing about it.