A couple of us spent some time recently at BEA World in Barcelona.

There was an issue raised in the keynote speech and echoed in later sessions that I wanted to pick up specifically, as it is another example of a vendor spinning an issue to suit its messaging in a way that can easily mislead if taken at face value.

The spin

BEA has been repositioning itself in recent times from a deliverer of "big iron" infrastructure for building and running business-critical Java applications, to the custodian of infrastructure-enabled business agility and flexibility. Moves into portal technology, social computing and business process management through a combination of acquisitions and in house R&D have all been part of this, and the introduction of the word “liquid” into a lot of its branding has reinforced the positioning.

At this level, BEA is right on the money. Our research has indicated repeatedly that businesses often feel constrained by IT’s inability to respond quickly enough to changing demands – so no arguments there. However, BEA is taking this one step further and questioning the value of packaged applications to support this "new world" of adaptable, service-oriented and people/process-centric IT. The words are carefully crafted with phrases such as “the days of being able to innovate through packaged applications are over”, but there is a clear objective to sideline the relevance of packaged applications as we look to the future.

It’s another example of the line we hear from other vendors and, indeed, some analysts, which argues that service-oriented architecture (SOA) and increasing expectations around the need for IT flexibility spells the death of the application software package. Great though this is for generating headlines or (in the case of BEA) promoting the build side of the traditional build-versus-buy argument, there are a few other things we should probably consider before throwing out our ERP systems and other packages.

The reality

Let’s start with some very obvious stuff. If you examine the way any business works, you will find that the majority of its business processes are non-differentiating. What we mean by this is that while you need to be efficient and effective in these areas to manage costs and risks, you are unlikely to compete any more effectively in the market by inventing new ways of doing them.

Examples include the vast majority of the accounting and administration that takes place in the average business, and for most to whom they are relevant, things like inventory management, manufacturing planning and execution, human resource management, logistics, and so on are non-differentiating too.

Sure, there are exceptions such Dell that gains significant competitive advantage from the way it manages its supply chain, manufacturing and logistics activities, but if we look across industries as a whole, most business processes we see are of the non-differentiating kind, for which it makes sense to simply adopt industry best practice rather than reinventing the wheel for the sake of it.

So let’s be blunt – if you are not using packaged software for non-differentiating business processes then you are mad. Even if you could build a better general ledger or accounts receivable system than SAP or Oracle, you would not actually have gained anything through doing so in business terms. Of course, the chances are that whatever you came up with would not actually be as good as a package solution that has been tuned over the years in line with industry best practice and the requirements of thousands of customers, so the reality is that you would probably be worse off.

Having said this, BEA and others make the argument that traditional packaged applications are relatively closed and monolithic in nature, which is a problem when integrating them into the overall landscape, and when you need to change the processes they support. Even non-differentiating processes need to be modified from time to time for efficiency purposes or to accommodate changes in business structure, merger and acquisition activity, new regulatory requirements, and so on. The argument continues that all of those investments made in the 1990s to put ERP and other packages into place has inadvertently locked business processes in a way that is constraining by modern standards.

Let's put aside the configurability of most packages for a minute, and accept this argument for the purposes of discussion. The question then becomes, if you have an old monolithic package that is holding you back, what should you do about it?

It is at this point that the SOA extremists pipe up with the purist line about packages becoming irrelevant in the future as organisations compose their solutions to meet the exact needs of the business by selecting and plugging together the optimum mix of best of breed software components and services.

The problem is, that’s a bit like saying that because the majority of components that make up a PC are now standard and can be plugged together easily, there is no longer a need for pre-built machines. It is basically nonsense. Whether you are a business looking to buy or rent software functionality, a consumer looking for a PC, or someone in the market for a new car, you are likely to want a product that has been assembled, integration tested, and delivered as a working unit, with assurances that it can be maintained and supported as such.

The move to assembly from standards-based components and the surfacing of standards-based interfaces has benefits in all contexts, however, and in acknowledgement of this, pretty much all mainstream application package vendors are moving in the direction of SOA. Will they get there overnight? Certainly not, but both SAP and Oracle, for example, are investing huge sums on re-architecting their solutions, which is something the purists often fail to acknowledge or dismiss as just marketing.

The work is real, though, and the aim is to allow standards based ‘services’ to be exposed for easier integration and for selective substitution where it makes sense. Just like you buy an off-the-shelf PC and perhaps upgrade the graphics card, SOA will allow you take an ERP package, for example, and ‘upgrade’, say, one of the advanced planning components with a third-party alternative.

So, what we need are flexible packages rather than an abandonment of the package concept altogether.

Conclusion

The story we heard from BEA this week is a very strong one, though all of the pieces are not in place yet. When listening to the pitch around the need for more IT infrastructure flexibility that can support the ever increasing rapidity of business change, however, it is important to remember that there is still a lot of relatively routine and boring stuff that will remain best dealt with through prescriptive packaged solutions that encapsulate industry best practice.

Furthermore, off-the-shelf packages or services (if software as a service catches on) are increasingly going to be based on flexible architectures anyway, and the trend away from customisation to ‘soft configuration’ so packages may be tailored to specific needs without code-cutting is already well underway. The ERP and CRM packages of 2007, for example, are inherently more malleable than those of mid-1990s.

In this respect, I would probably on balance disagree with BEA that "software package-enabled business innovation" is dead, though I would agree that IT departments should probably be shifting their attention to using the latest infrastructure, tools, techniques and ideas of the kind BEA is promoting to support the differentiating elements of the business in as flexible and high impact a way as possible. And in some situations, it may not be sensible to even model processes at all, let alone lock them down in software.

The world and technology landscape is definitely changing, but let’s not assume that embracing new ideas always means abandoning the old – or that the traditional stuff is standing still.