Some correspondents have questioned whether IBM can really compete with SAP and Oracle in the applications business using the approach I hypothesized. Using an approach like BPM BlueWorks, IBM Global Business Services consultants can share processes (and the code to implement the individual "tasks" in those processes).
To put this in some perspective, IBM Global Business Services has 190,000 employees, according to Wikipedia. While not all of them are coding, bear in mind that this number is on the order of 10x the number of developers at Oracle and SAP. In addition, IBM has a large software division and research labs, also able to support the creation of these processes.
IBM need not create the basic financial and human resource core processes. They don't even have to create the basic objects and the processes to maintain the connections between those processes. After all, those objects and processes already exist, for most customers, in their current, installed SAP or Oracle applications. Those cores do not need to nor do they benefit from change, which is why customers are so loathe to upgrade their cores. However, customers desire additional, high value processes on top of those cores - this explains the success of Siebel and i2 in the past, and Salesforce and SuccessFactors and Taleo and Lithium in the present.
As long as IBM can keep those stable cores in place, IBM can develop high value processes as composite applications using WebSphere/Lotus without investing in core ERP. Fortunately, IBM has a practice in place to take over running your existing enterprise apps, guaranteeing a cost reduction every year, and without the large periodic upgrade costs of staying current with SAP and Oracle.
In summary, IBM will compete with SAP and Oracle for applications business, but not by trying to replace current SAP and Oracle instances (the way Oracle and SAP compete with each other), but instead by building on them as a platform.
Subscribe to:
Post Comments (Atom)
This idea only works if you can achieve reuse of the composite applications. And reuse is a problem, has been a problem ever since people promised huge benefits from reuse of objects and methods.
ReplyDeleteWhatever IBM's or Dennis's theory of composite application reuse, it needs to advance some idea about why this stuff can be reused when earlier programming reuse didn't.
For BPM and BPMN, the prevailing theory has been that the higher the level of process modeling, the easier to reuse. So higher-level, highly visible business process models are going to be more available and easier to change than scripts or programs.
I have spent a lot of time reviewing products like ARIS, and I'm unconvinced. Once you start taking into account all the cases and exceptions and branching, you have spaghetti process models that look to little old me very much like spaghetti code.
Love to hear your thoughts, Dennis.
Would you say Software AG is also competing at this level?
ReplyDeleteDavid - Great thoughts! My responses:
ReplyDelete1. Obviously, reuse is possible, or SAP wouldn't have 35K customers on very nearly identical code bases (you can argue about how identical, but very nearly identical by my terms :) ).
2. I built composite apps at SAP that have hundreds or thousands of customers using them - they are not built as an abstraction, but they are built on an entity model (data model) abstraction that allows them to be deployed rapidly on many different schemas or underlying apps. If you strip out all the SAP functionality except core FI, MM, HCM, etc., SAP becomes little more than a taxation and treasury system with lots of master data, on which you can build any process you like! And the good news is that the core processes have pretty good APIs because they are called from throughout the SAP suite. I'm sure it's very similar with oracle.
3. BPMN approaches problems in a way that supports having many variations across customers much better than does traditional coding. Tasks are defined separately from the processes that connect them. Take the example of an employee-initiated transfer - in one division or company, the employee may get the offer before notifying her manager; in another, the employee may have to get the manager's approval before applying. With a BPM-based approach, the common tasks are identical (searching for a job, applying, getting the offer, making the HRMS change, etc.), but the processes are slightly different and there may be one new task in one variation. The process is not in code, it is in metadata, so the system can easily support running both variations (and many others) on one instance. Further, many common tasks (such as the approval mentioned here) can be defined as metadata, also not requiring any custom code per client. So, many variations can be handled with just configuration changes rather than new or different code, when built on a BPMS.
4. Let's say that there are differences that cannot be handled as described in 3 above. Still, there must be hundreds or thousands of the ~35K SAP Business Suite customers who would be happy with each variation, so it is possible to use this approach and pick off many customers from SAP and Oracle.
5. Finally, a BPM approach doesn't make the situation any worse than custom development in ABAP and PL/SQL ... :)
Sorry that this is a bit "stream of consciousness," but Blogger has a pretty limited comment editor :(
THANKS!
jr0 - I think Software AG could follow the same strategy I outlined for IBM, but it doesn't have the number of consultants/developers IBM has creating content. I think if Software AG took that path in earnest, SAP or Oracle would be forced to buy it, or kill it ...
ReplyDeleteThanks!
One small fly in the ointment. At least in their physical HR data designs, SAP and Oracle EBS/PSFT cores are not sufficient up-to-date to serve as a durable foundation, which is one of the reasons that the talent mgmt suite vendors cringe when they have to layer on top of these older HRMSs and are building out their own core HR object models. There's been huge changes in the fundamentals of HRM since these much older designs were laid down, and it shows. Just sayin' Naomi
ReplyDeleteDennis - Good post. Do you see the BPM integration working as an IBM "Public Cloud" architecture with integration to SAP exposed enterprise services (BAPI, Web Services etc.)? Or
ReplyDeleteDo you see the BPM integration working as an IBM "Private Cloud" architecture for the enterprise and their respective ERP systems?
In the case of "Private Cloud", the enterprise will gain from the automation of higher level abstraction of BPM. However they would not be able to fully leverage the truly "Distributed Business Processes" that "Public Clouds" present in my view. Thoughts? - Monty
I think IBM's approach will be private cloud, starting with outsourcing the company's full IT department ...
ReplyDelete