There is confusion about packaged applications and process management. Application vendors are now claiming that they are BPM players. Platform vendors claim that they have significant intellectual property build on their platforms, so they can support the sequencing of application components/services. The independent BPMS claim that they can easily cross platforms and have a growing amount of jump start processes available around vertical and/or horizontal processes besides being able to support application services plus intense human process activities. Long term they are headed in similar general direction, but there are important issues in the details around focus, timing, lock-in, and best practices that differentiate these three classes of vendors. In reality, most organizations need all three types even though their area of overlap will continue to grow but not converge entirely.
![MPj04309850000[1]](http://blogs.gartner.com/jim_sinur/files/2009/03/windowslivewriterdoubleyourpleasureapplicationpackagesand-8bb4mpj043098500001-2.jpg)
The Packaged Application View: There is Process in my Application
Processes are the enablers of best practices embedded in applications and BPM is considered part of the middleware infrastructure. Let’s examine the level of process functionality in application packages. They are mostly focused at transactional sequencing and straight through processes. Most packaged vendors have little human process support and are not focused on human interaction management. Few are leveraging true agility. Yes, some can support SOA, but SOA only brings a few facets of agility. On the other hand they will be bringing solid service/component directories to the market, but most of their existing application functionality does not yet run optimally in their newly evolving platforms. There is still a strong binding of the rules and processes to the application transactions. Package vendors will mostly employ their new process function to surround their existing core/standard functionality. This will allow for a modicum of differentiation and lock organizations into their standard functionality.
The BPM View: There are Application Service/Composites in my Process
Applications are transactions that can be embedded in differentiating and agile processes. Let’s examine the level of best practice here. Process vendors give a powerful process platform that affords great agility and functionality, particularly around case management, content management and collaboration, but organizations have little best practices out of the box. The exception to the rule are BPMS vendors that provide jump start processes and/or can access the service directories of the application vendors and leverage a great deal of the standard transactions available from application vendors plus wrapped legacy. For organizations that believe that excellent processes out-deliver the best transactions, process vendors will be appealing. BPM vendors will continue to out deliver application vendors in supporting the human intensive knowledge workers and the process workers and I do not expect to see this gap narrowed soon. The scramble will be too build intellectual property and/or attract enough partners who will build on the new process platforms.
These down economic times are causing organizations to leverage what they own, so the combination of packaged applications as the transactional corner stone with surrounding BPM enabled processes is a good compromise to enable organizational differentiation while leveraging existing assets. This is a true best practice.
7 responses so far ↓
1 Akiva Marks // Mar 4, 2009 at 9:06 am
The question I ask is will the traditional application vendors decompose their big box departmental and enterprise applications down to a sufficiently granular business-process service level so that I can use BPM and/or application assembly tools to use them as transaction and process engines in the unique combinations of value to my business?
Will we see SAP and other major vendors using SOA primarily as an API for inputs and outpost of their big-box functionality (which is what we see today), or will they offer us granular processes we can compose as needed? Or even further, offer us a menu of business-processes we can buy as composable pieces?
2 Jim Sinur // Mar 4, 2009 at 11:48 am
You are right on this issue. The application vendors do not provide a pure SOA solution for their existing application functionality, but they do provide a pseudo service approach that in some cases can support a benefitical business process implmentation. I tihnk this is a journey for the application vendors, but there are benefits in pariing the application functionality with BPM. It’s not perfect, but benefit delivering.
3 Anatoly Belychook // Mar 12, 2009 at 11:40 am
Is this an updated release of your year-old article at bpmenterprise.com?
Anyway… The issue of processes embedded into applications is that you must be a specialist trained to this particular application (ERP, CRM whatever) to be able to reach process models. In case of standalone BPMS a business analyst owns the process model (except implementation details), in case of application-centric approach he depends on IT guys. This compromises the core BPM idea of bridging business-IT gap.
4 Jim Sinur // Mar 12, 2009 at 2:41 pm
This is an updated version as you noticed, but the question keeps coming up. It would be great if one would not be dependent on those IT folks that know how to leverage the package APIs.
I think that some intelligent wrapping of those APIs/composites as pseudo services with references in the service directory would be a good step forward for the commonly leveraged APIs. I don’t think the IT folks want to be in the way of process progress. This is not pure BPM driven by business types, but incrementally better than common parctice of the day.
5 Applications or Processes: Which Comes First, the Chicken or the Egg? // Aug 19, 2009 at 2:03 pm
[...] We definitely need both to cooperate to make businesses run just like we need chicken and eggs to survive. See http://blogs.gartner.com/jim_sinur/2009/03/03/double-your-pleasure-application-packages-and-bpm-toge... [...]
6 BPM Delivers Better Practices and Best Practices // Oct 2, 2009 at 5:33 pm
[...] http://blogs.gartner.com/jim_sinur/2009/03/03/double-your-pleasure-application-packages-and-bpm-toge... Share and Enjoy: [...]
7 Mark Norton // Oct 3, 2009 at 6:10 am
Jim, I agree with your premise. In support of your point I would like to observe that it is always surprising to us just who is asking for vendor help with ‘best practice’ – we find that it is more likely to be a market heavyweight than a new entrant. The inference is that static systems are a market impediment that is protecting stronger brands at the expense of real innovators. When nobody can innovate quickly, then it becomes difficult to differentiate through evolving best practise. But when systems become more agile then brand and current market position will become less important – best practice will be driven by innovators, and they will start to drive the market.
Leave a Comment