Are packaged applications becoming less relevant?
Or are they the only way of keeping up with demand?
The imminent death of traditional packaged applications for dealing with ERP, CRM and other core business requirements has been proclaimed in many quarters recently. Whether it’s SOA purists telling us that we’ll all be self-assembling solutions from components, enthusiasts of modern development environments wanting to build everything from scratch, or the SaaS evangelists saying it’s all going to go into the cloud anyway, it is trendy to dismiss application software packages as being out of touch with the needs of the 21st century.
Even if you take the disruptive rhetoric with a pinch of salt, however, there is no denying that some of the underlying points being made by the challengers touch a nerve. Most of us can probably think of at least one instance of a packaged application doing a great job initially, but ultimately becoming a straightjacket on the business. All too often, organisations have become constrained by packaged applications that couldn’t be adapted quickly or cost effectively enough to keep up with changing requirements.
The significance of such historical rigidity is contrasted by a lot of the language we hear today surrounding IT in general. It’s almost impossible to listen to a sales pitch or browse a supplier website without having words such as ‘flexibility’, ‘agility’ and ‘responsiveness’ thrust at you.
This is not just because people have been burned in the past, but also an acknowledgement that both the IT and business sides of the equation are becoming much more dynamic in general. As technology advancement enables businesses to do things more quickly and in different ways, this perpetuates the need for even more efficient and effective IT in order to keep up, and so the relentless spiral of need continues.
Another couple of words that frequently crop up today are ‘empowerment’ and ‘productivity’, underlining the increased emphasis on that most valuable and costly of resources – the workforce. Sometimes this boils down to providing employees with the information and access they need to innovate and generally make better decisions. But it could also simply be about broadening the reach of systems so more people can participate electronically in important business processes. In practice, this takes us into areas such as business intelligence, collaboration, mobile/remote access, and so on, all areas that have received a lot of attention over recent years.
The upshot is that the old days of static packaged applications serving the needs of selected groups sitting behind the firewall in a very prescriptive way are probably over. But is it a case of driving everything back to more of a DIY approach, as the challengers suggest? Well here we have to consider some practicalities.
While application packages may have had their issues, many organisations actually have more of a problem with custom built applications. In lots of environments, the maintenance of bespoke legacy is not only tying up valuable budget, but is also effectively a dead-end in terms of migration.
As we look to the future, do we really want to carry on reinventing wheels and potentially creating even more burdens of this kind? Indeed can we afford to, as the automation footprint expands from the back office to the front office and even to the field and the employee’s home? Throw in the need for collaboration, coherent and pervasive business intelligence and further functionality and that’s a lot of software to design, build, test and integrate if you don’t take full advantage of pre-built software suites.
While this might sound like volunteering to get tied up in even more constraining ways, the good news is that the packaged application business has not stood still. Most modern solutions are designed and built with a lot more flexibility in mind. Today, ‘configuration’ is the watch word, allowing a lot more tailoring of functionality without the need for coding.
So, are we all sorted then?
Maybe in some cases, but the truth is that both vendors and their customers can only move so quickly, and while the latest incarnations of ERP, CRM and other packaged applications promise a lot, migrations and new implementations consume both time and resources.
With this in mind, we would be interested in your thoughts and experiences. How are needs evolving in your organisation, for example in the areas of analytics, collaboration, broader access by non-traditional users, etc? And if requirements are changing, how are packaged applications and/or the teams looking after them being stressed as a result? Looking forward, do you then have any tips on how to strike a balance between packages and custom solutions?
It would be great to have your views in the comment section below.
Packages simply too big
The competent computer user, on unix at least, back in the day, knew how to write his own shell and other small language scripts (reason why AWK exists, for example). Nowadays, the cultural imperative for "no education" and "clickibunti" means that your warm bodies are essentially glorified keyboard peckers and mouse movers, and capable of packing up their own repetetive tasks and have the machine repeat them for them, they are not so much.
This is why you have a toolsmith, or "systems programmer" in IBM lingo: His job is to come up and package solutions for tasks to speed them up, bind together organisational knowledge and when done properly, document the quirks and warts as well as the environment where and why it was needed.
The "packaged application" idea is to gather all that, add special corporate "integration" sauce, and sell it. Mucho profit in a booming market to be sure. But installing those things --so many bells and whistles and modules vaguely aimed at various types of businesses, they are the very definition of software bloat-- requires basically your old system programmer again. Only this time in the form of a gaggle of Highly Paid Consultants. So, they're self-defeating. I don't really see how virtualisation and outsourcing right up into the cloudy sky helps to "flexibilise" that. It's fancier ways to throw more cycles at the problem, not a solution that capitalises on the strenghts of both mechanical computing and human effort.
That very bloat is why free software has a good chance to win big, though: Those scratch-an-itch things tend to do one thing well (and if not someone else'll come up with a better, meaner, leaner solution) and for their other needs have to lean on other solutions. So, open source software needs to play well with others. Add ye olde toolsmith to bend the iron to a shape suitable for local consumption, and Bob's yer uncle.
If corporate and proprietary is to survive it'll have to learn how to play well with others. We might see that in order to do that such corporations choose the easier, less sue-thy-neighbour and more long term route, and go open source with an updated business model to match.
The virtual pint because if I wasn't so broke I'd donate a real one to my own beer fund.
A way to go
I've been working in desktop estate management for a while now, and amongst the many lessons that I have learnt, the one that stands out the most is beware of the proprietary.
Thick or thin client, big or small, these are the applications around which you need to exercise the most caution as they are the most likely to break as the desktop environment changes around them, and the least likely to adapt quickly to said changes.
Unfortunately, as you have rightly pointed out in this article, desktop envrionmental change is becoming faster, and more prolific. Thin client, or web-based software was supposed to be the answer to this, but from what we've seen, has fallen into exactly the same traps that have besieged the traditional software development cycle.
The evidence for this is can be witnessed in the browser usage statistics. The only reason IE6 still dominates the stats is because there are so many corporations whose hands have been tied by web based apps/intranets which have not, or possibly even cannot be updated to use modern browsers.
But this is the primary internet facing component of your operating system. From a security perspective, do you really want it to be stuck in a timewarp? Can you really afford to sit on critical security updates while you wait for your web app suppliers dev cycle to catch up?
We are currently holding off IE8 deployment because one of our primary web-app suppliers is soon switching from SAP to Oracle, and doesn't consider work on the current system to be 'economically viable'.
So, all the disadvantages of the traditional software cycle, with the added stone dragging your browser into the dark ages too?
The real irony is that traditional software has steadily become easier to manage. There are a miriad of solutions out there, allowing you to keep on top of your software suites, all the way from SCCM through to the lighter/cheaper solutions, and any mid to large environment will already have such solutions well established.
Even the the primary benefit originally touted, that of a single point of update has backfired in this new age of global enterprise. It's all very well being able to take one machine (or cluster of machines) offline to update them, but if that machine is serving clients around the world, one man's night, is another mans peak usage hours.
With fat client management software on the other hand, maintenance hours can be scheduled and staggered around the globe.
Finally, all these applications are built on a very immature and rapidly changing environment, with little sign of it stabalising in the near to mid fututre. The recent revelations pertaining to googles rather gun-ho attitutde over security in the HTML5 standard should give any web app developer pause for thought.
Web apps are already plagued with issues from cross-browser compatibility, 3rd party plugin dependencies, security restrictions, security certificate/dns routing, bandwidth, offline/disconnection, security of your data 'in the cloud'...
For these reasons, the web is not the idyllic solution portrayed by sales-speak evangelists, and really should be considered only as a solution if your exsisting product is suffering explicitly because its' client is of the lardy variety, not because your marketing department can break open a fresh box of buzz-words.
The first custom solution is...
...to know how your staff is working and then you define the level of integration that you need.