Evaluating enterprise application software
Is IT's input really necessary nowadays?
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.
If you have any thoughts on this stuff, or want to share some war stories, tips or tricks with us from your own experience, we’d love to have your comments in the discussion area below. Alternatively, click here to complete our mini-poll which gets down and dirty on technical requirements for packaged applications. ®
Yup - security
I've come across systems that require all users to connected to the server as the same user - because otherwise the database throws a wobbly. So absolutely zero opportunity for any form of security - especially as the volume in question had to be mapped as a shared drive on every users desktop :-(
And then there are all the other irrelevant geeky questions - like "how much disk space will it need ?" It might be trivial, it might be less than trivial when 6 months after go-live, your dataset grows to exceed the filesystem size limit. Not just a matter of adding another disk, but of adding more disk and fudging around a bit to split the data across multiple volumes.
Another irrelevant geeky question I've always had to ask - what printers are supported. HPPCL only isn't very useful when you're entire infrastructure (for good reasons) is Postscript. You'd be amazed how many vendors can't see any reason to support anything other than HPPCL ! Second after that is "how easy is it for me to get at the print stream so I can fix print jobs to actually work/support printer features/work on network printers/etc ?"
And "Do ALL bits work on OS <insert preference> ?" Isn't it nice when the salesman and his 'techy sidekick' assure you that it will all run on a LInux server. And then you find that an essential, must run all the time, component is Windoze only. Grrr.
And lastly, how about "what other (usually expensive) bits of hardware and software will be needed that you aren't telling us about ?" Hands up those that haven't found themselves in one of those "but you'll need to by SuperWidgetProX" for that promised feature to work - and it only costs the other arm and leg" situations ?
enterprise single sign on
oh yeah... our app does single sign on. just make sure the users don't need passwords that are longer than 8 chars. Its not like anyone would store longer passwords in LDAP anyway.
I'm sure we've all seen the results
From what I've seen of <insert major database manufacturer's name here> student record system, it seems to have been developed without any thought for the poor sods who would have to use it. And demonstrated to senior managers who couldn't spell the word "usability" never mind having any concept of what it is! Perhaps the geeks are asking pesky user interface design questions? I certainly hope so!