The pros and cons of business application packages - Poll results

Whether to build or buy, that is the question? Well, it is for many when it comes to business applications. It’s a topic on which we asked for your feedback as part of our latest workshop, and over 100 of you came back with your views on it. So what did we learn?

Firstly, the drivers for going down the ’buy’ rather than ‘build’ route are pretty clear. The majority see a reduction in the cost and time it takes to deliver new applications as being a strong attraction towards packages, with additional benefits being highlighted in the area of ongoing maintenance and support (Figure 1).

Figure 1

These top three factors are all to do with taking the heat off IT from a resource and budget perspective. This is consistent with most IT departments wrestling with a backlog of projects and being constantly under pressure to do more with less.

Another strong driver is completeness of functionality, providing room to grow. To appreciate the significance of this, consider that when building custom solutions, you don’t typically have the luxury of including functions or capabilities in scope that you can’t identify an explicit need for in the short to medium term.

As business needs change and evolve, new development is therefore required to modify or extend the application, which in turn means finding the necessary time and resource, often with very little notice. By contrast, with a package, the functionality tends to be a superset of the requirements from the software vendor’s entire customer base or target market. The upshot is that while you only make use of what you need during the initial implementation, additional capability is more likely to be already there to meet new requirements down the line.

Of course this principle is dependent upon the package chosen being a reasonable fit for the business context in which it is being used. And when we consider this question of fit in the broader context, it quickly becomes clear that finding suitable packages for everything is a pretty tall order. It is therefore not surprising that blending packages with custom developments is the way in which most organisations meet their application needs (Figure 2).

Figure 2

The neat looking bell curve we see here, however, hides an important point that a number of readers raised, which is summed up in this quote from one of our respondents:

Many of the packages we use have been heavily modified from base, are now out of support, difficult to find expertise on (since they are far from vanilla) and so on…

This brings us onto some of the practical challenges and pitfalls associated with the use of application packages, the most prominent of which revolve around constraints at either a functionality or technology level (Figure 3).

Figure 3

The first of these challenges is arguably a result of the second two, in that technical and functional rigidity constrains the degree to which applications can be tailored to deal with special requirements. The focus on this issue is understandable. In the real world, the chances of any comprehensive solution or suite being a good fit across all of the areas of functionality are extremely remote. While it might hit the spot perfectly in some places, it could be way off the mark in others.

In larger organisations, variations in policy and process across the business can also mean that the fit is different in each division or subsidiary, and if needs are met perfectly in one place, almost by definition, they will not be met in others.

While application rigidity is a common problem, however, the evidence suggests that the picture is not all bad. It is important to recognise that many application vendors have started to introduce more flexibility and openness into their solutions. Indeed, the chances are that the opinions gathered in our poll more reflect the historical rather than current situation given the typical application refresh cycle and the fact that many mainstream packages have only been rearchitected relatively recently around open standards, SOA, and so on. Nevertheless, there is a clear message to beware of problems in this area.

Finally, the other bugbear that comes out from the poll is that of licensing and maintenance costs (Figure 4).

Figure 4

This is an issue upon which it is very difficult to generalise. While some software vendors have been widely reported in recent times as attempting to abuse the hold they have over their customers by forcing them to accept new terms and price hikes unilaterally, it is clear that some customers take what they get too much for granted. It’s arguably a case of six of one and half a dozen of the other.

At which point, it is good to come back to where we started and remind ourselves of the drivers for packaged applications we were looking at previously – lower cost of delivery, faster time to benefit, lower overheads on IT, and so on, when compared to building or commissioning custom alternatives.

Netting all this out, the main conclusion is not rocket science. The right package deployed in the right way in the right environment can lead to significant advantages in terms of cost, benefit, responsiveness and risk management. If the fit is poor in too many places, or the architectural foundation for the solution is too rigid, then costs and risks will escalate and/or the business will be constrained. As a result, the approach of blending custom and packaged applications continues to be the best way of meeting business requirements.