Although companies are content to commit to running the vast majority of their business on software from a single provider, they are often reluctant to go the whole way.
Over-commitment to a single vendor brings a specific set of risks along with distinct advantages, but it does draw attention to the motivations behind vendors' activities, particularly in the integration and business process management areas.
Enterprise application vendors have embraced these technology areas because they provide a solution to an old problem: the need to make it easier for themselves and customers to work with their applications.
They are also an acknowledgement that customers have an upper limit in terms of single vendor supply and that at maybe 70% or so, it is not as high as the vendors would like.
This is the backdrop to substantial efforts on integration platforms and the increasing focus on BPM, as applications cannot just make cursory attempts to work with third-party applications. The developments represent an effort to maintain and extend control outside the application domain.
The key is the business process. If vendors cannot own the technology on an end-to-end basis, the next best thing is to own the processes and the management of those processes.
On a technology level, processes bring siloed functionality together both within suites and between distinct applications. On a business level they bring business units together and contribute to better operational workflow. Furthermore, they provide a means of linking businesses more closely to their partner and supplier networks by extending processes outside the enterprise and that is a where vendors see a host of new opportunities.
By managing the end-to-end process, where the start and ends points may be outside the client organisation, vendors see major new customer and revenue opportunities built on ecosystems put together around the core customer.
Most enterprise applications, like those from Oracle and SAP, were assembled with some basic business processes built in, but they were conceived and delivered on a departmental basis. Now the need is for processes that span the internal organisation and reach out to the external business network, on the grounds that the business can operate more effectively if it runs complete business processes.
To achieve this, vendors need to offer an integration platform to link applications together, which the likes of SAP and Oracle have done. They also need to provide BPM capabilities that allow organisations to build and bounce a single business process across the disparate base.
This is why Oracle is pushing its BPEL-based Process Manager, why it is using business process modelling tools to create its Process Integration Packs, which are pre-built business process packs for its Application Integration Architecture platform that link applications to provide end-to-end processes, and why it is planning to provide customers with process modeling tools.
It is also why SAP is about to release a new set of BPM tools designed to enable users to execute or adapt processes without having to write code. NetWeaver Business Process Manager will provide a process composer to model business processes based on the Business Process Modelling Notation standard, and integrated into the Eclipse development framework. It will also include a process engine that will take and execute the process models without requiring model-to-code translation.
BPM represents the new frontier for enterprise application vendors and is motivated by their desire to own the business processes inside and outside the enterprise, having recognised that there are limits to what they can lay claim to in terms of internal applications and technology.
This means their BPM offerings will be centered on their application stacks, which has implications for end-user organisations with very heterogeneous environments.
An application-centric approach is not a bad thing but it pays to be aware, as vendor motivations impact organisations' implementations.