Almost two years ago, I reported on the IBM acquisition of FileNet, wherein I quoted their plan to “integrate IBM’s BPM and SOA technologies with the FileNet platform”. I interpreted this to mean that FileNet BPM could finally get separated from its document-centric chains, and become the product that it should have been years ago. Just as Jessica Rabbit said “I’m not bad, I’m just drawn that way”, the FileNet BPM wasn’t (isn’t) document-centric, it’s just marketed that way. As the former director of e-business evangelism for FileNet in 2000-1 when they were launching this generation of the BPM product, I had some idea of what I was talking about — I saw that 40% of the BPM installations in some countries did not involve documents at all, and that this was due to the local sales and marketing messages and techniques rather than any inherently different BPM requirements between countries. So several years after I left FileNet, when the acquisition occurred and I saw that initial press release, I imagined that the best possible thing would be if the BPM product were to be separated out and made part of the IBM WebSphere suite, in order to flesh out the badly-needed human-facing workflow side of things over there. I realized that would mean some major surgery on the product, but a stronger unified BPM suite would emerge from that.
A few days later, an analyst call with IBM set me straight on that: the GM of the IBM Information Management unit that would be absorbing FileNet referred to FileNet’s BPM as “content-centric”. Uh-oh. I knew that couldn’t mean anything good for the product. I still have a lot of friends inside IBM-FileNet, and at first, it seemed like they were being allowed some degree of autonomy. Then, they gradually started being pulled into the “IBM way”, and a lot of people started getting unhappy, and many eventually left. There were few explicit purges, except for some redundant administration, but that doesn’t mean that there weren’t losses.
Recently, IBM announced its grand plan for BPM; Bruce Silver covered it here, describing how they plan to bring together process and content:
[T]he steps that involve content operations (e.g. adding/revising/securing documents) are done by a FileNet P8 process, which is invoked via WSDL as a subprocess in the end-to-end WebSphere process.
In other words, after more than a year, my premonition about the FileNet BPM product was realized, and it became — from a marketing standpoint — a shadow of its former self. I’m sure that customers using FileNet BPM for end-to-end processes (which IBM thinks are more suitable for WebSphere Process Server) cringed as they see the future of their installed product atrophy. I can only imagine the impact on the (still fairly segregated) sales team: one day, they’re selling FileNet BPM as a full BPM solution, the next day, it’s a document-centric subprocess handler, to be called from WPS. In much the same way that other BPEL vendors handle human-facing tasks as second-class citizen, calling a subsystem using WSDL to manage them, IBM is demoting FileNet BPM to the same realm. Although I predicted this right from the first analyst call, it doesn’t give me much satisfaction when I think about what it could have been.
The current monster acquisition in this space is Oracle and BEA, and it’s interesting to see the contrast in acquisition styles. Unlike the death-from-a-thousand-cuts method inflicted by IBM on FileNet, Oracle is more like the Borg: BEA is being assimilated, and fast. The acquisition — from the first rejected offer last October to the final accepted offer this January — was completed in late April, less than two weeks before the BEA Participate user conference. At the conference, I found that many of my BEA acquaintances were not staying on with Oracle; many others have announced that they’re leaving since then as well.
The Register reported yesterday on how Oracle is dismantling the AquaLogic product line: the AquaLogic web products (portals and Web 2.0) and, it appears, the WebLogic products will go one direction (hypothesized by the Register to be the Stellent team), with some rationalization of AquaLogic and WebLogic finally occurring; AquaLogic BPM will be moved under the Fusion middleware team. I haven’t dealt much with the WebLogic side of BEA, but when I dared to suggest that AquaLogic Pages could be used as a lightweight replacement for WebLogic Portal, I was “corrected” on the official party line. Given my confusion over this, I have to assume that some part of the market has also been confused over why BEA offers two different portal products. If it takes Oracle’s firm hand to finally merge them, that’s a good thing.
Oracle is doing exactly what I thought IBM should have done with FileNet: split up the product where it made sense and merge those pieces into similar teams that already exist, rather than try to maintain an intact semi-autonomous unit and brand, then gradually re-jig the product, potentially misleading customers about the final outcome.
As a member of the Enterprise Irregulars, I’ve been invited to a dinner hosted by Oracle next week at the Enterprise 2.0 conference; it will be interesting to see if BEA is so completely assimilated that the name isn’t even uttered.
Sandy,
Nice post. But in fairness, there are many in BPM marketing at IBM who would still describe FileNet P8 as you like it, as an end-to-end BPMS for certain types of processes… although they have a hard time articulating what that type is. The notion of P8 as a subprocess underneath WebSphere was put forward to me in the specific context of my BPMS Reports. IBM was insistent on one report covering both WebSphere and FileNet, based on one unified story. Two separate end-to-end suites is not one unified story, so forced to decide how they would fit together in such a context – i.e. chained, of if nested, which one on top? – they said nested, WebSphere on top, and FileNet called as subprocess via WSDL. So I’m not sure if that’s the “strategy” or just their best answer when backed into a corner…. But you may have additional data points on this.
Sandy, Bruce:
have you ever asked yourself why it was so hard to build process-centric solutions with the current BPMS architecture and metamodel?
Could you one second, just for one second entertain the hypothesis that the programming model familiar to document-centric workflows is not generalizable to building process-centric solutions.
Could you for one second, just for one second entertain the hypothesis that BPEL is not a “business process execution language” and will never be, it is a service implementation language and that services collaborate, assembled in a unit of work that results in a workflow, it is not the other way around.
IBM Zurich just published a plugin onto WBM that clearly establishes the relationship between business processes and business object lifecycles (http://www.alphaworks.ibm.com/tech/olcexplorer). BPEL is a programming language suitable for implementing object lifecycles.
Could you for one second, just for one second entertain the hypothesis that Object Lifecycles are extremely important in process-centric solutions? (and hardly in document-centric workflows)
I don’t know anything about IBM strategy, but what I know is that as long as people will keep banging their head on the wrong programming/execution model (which was designed 20 years ago to manage document workflows) there will be billions of dollars of unrealized ROI and sales in the BPM space.
You have been thought leaders in that space for so many years. Do you think BPM is where it should be? Do you think that PPT and Visio really are the best BPM tools? don’t you think it is time to look for alternatives? that there are structural flaws in the current thinking of the BPM community that prevent it to grow? What is not process centric? I don’t know many human activities which are ad hoc. Almost all of our knowledge can be codified into some sort of process. So why do BPMS achieve a marginal market compared to the IT budget. Yes, a BPMS company should be as big as Oracle, yes, BPMSs are as important as RDBMs, of course, so why is it not happening?
Thank god, IBM and Oracle (I don’t know about Microsoft, other than WF) are taking that route, they really understand the programming model that is necessary for enabling process-centric solutions (which includes naturally document-centric workflows).
Make no mistake, XPDL and ALBPM have hardly any room left in this space if you look carefully at what Oracle SOA Suite 11g is capable of. 12 months from now you’ll write a post about how Oracle killed ALBPM, how could they not to?
Jean-Jacques, I have no idea what part of my post set you off on a rant, but you may be misinterpreting my main message. I’m not saying that IBM-FileNet or Oracle-BEA have the right BPM strategy or product, I was comparing how two enormous companies treat the spoils of an acquisition.
One point of correction to your comment: the generation of BPM product currently sold as FileNet P8 is not 20 years old; the old FileNet WorkFlo product that was document-centric workflow was phased out after P8 BPM (eProcess when it was introduced in 2000), and not only was it not designed to manage document workflows, the original eProcess product didn’t even natively integrate with their document management. It was designed and developed to be a more generic BPM product.
I don’t think that FileNet BPM would have survived in its current state if it had been integrated as part of the WebSphere BPM suite, but there was the opportunity to reuse some of the key functionality to enhance the heavily integration-centric WebSphere product to make it more complete. With some luck, that’s what will happen to ALBPM within Oracle. I don’t consider that killing the product, I consider it an effective merging of the technology platforms.
Sandy:
what’s tripping me off is when people talk about how BPEL and human tasks relate (also how BPMN and BPEL relate).
You say “In much the same way that other BPEL vendors handle human-facing tasks as second-class citizen, calling a subsystem using WSDL to manage them”
Have you ever considered one second, just one second that this could be the right thing to do? That the way you look at the problem, though perfectly understandable and to a certain degree logical, could be not universal enough? I grant you that in a document-centric workflow view, what you are saying works, but have you considered the millions of other processes that the business needs where it does not work?
If you take the view of an Object Lifecycle and you understand the relationship between a business process and object lifecycles, then, you can understand where and how BPEL fits, and where and how Human Tasks need to be handled (in a separate Task container).
For almost ten years, since XLang and the BPML days, everyone has banged their head on the wall trying to “orchestrate” processes (model & execute). You would think after 10 years, somebody really smart in academia or a research lab would have come out with a solution to the problem. Look at how hard it is for Marlon Dumas to build a BPMN to BPEL compiler? And Marlon is really smart. When that kind of things happen, it is probably worth to reconsidering the problem and see if it cannot be formulated in a different way, where the solution is more obvious.
Could you please consider this argument:
Object lifecycles are intrinsic to the (business) objects.
How can someone design a process that complies precisely and exactly with the lifecycles of objects that participate in that business process?
In reality, Object lifecycles are totally independent of the workflow (i.e. the tasks performed to advance their state). They are enterprise class business logic that you never want to violate and always comply with (imagine if I could transition a check directly to deposited to credited without ever verifying that the money was compensated somewhere?)
I could go as far as saying that a process cannot be modeled, all you can model is the instance of a workflow corresponding to particular a state change path. Haven’t you noticed how often the users give you the feedback that the “system” does not let them perform a task at a particular point (in a particular state), that should make sense? The very reason is because a business process model cannot accurately reflect all the lifecycles of the objects it manipulates.
If you were to construct your system from the point of view of the lifecycle and “graft” human tasks to the transitions (they enable the transition from one state to another), you would realize that the system is a lot easier to define and there is no need for any process definition whatsoever. The workflow of human tasks is then “observed” rather than centrally orchestrated or even modeled. It is the lifecycle of the objects which is orchestrated and results in a workflow.
I encourage you to draft the lifecycle of a PO, Invoice and Payment from the supplier perspective for instance and see it for your self. You will see how these lifecycles interact nicely with each other and how easy it is to graft/associate human tasks to particular transitions.
Sandy, interesting news on both fronts, IBM/filenet and Oracle/BEA/Fuego 🙂
I have to say it was interesting to me to read your point of view on the filenet product in particular. I’ve been part of several projects that replaced or augmented filenet “processes” that didn’t go too well. I can’t say for sure that it was because the filenet product wasn’t a well-rounded BPM tool, or too document-focused, or because of the specific people and implementation decisions and technologies involved… There are always many variables that contribute to the perception that the product isn’t meeting the need.
Fair or not, the perception of these customers was that filenet’s bpm capabilities were vastly oversold w.r.t. to “true” bpm offerings (their choice of words). They also felt fairly burned by the takeover by ibm and loss of direction there. Certainly the perception of the pure-play bpm vendors was that these document-focused bpm products didn’t measure up when handling non-document-centric processes (and that wasn’t just marketing, it was a firmly held belief, reinforced by enough market data to make it feel like Fact )
The oracle-bea acquisition is interesting too, but I think it is almost a non-event for BPM space. Surely BPM hardly even registered in Oracle’s collective consciousness as they did this deal to acquire the maintenance revenue stream of BEA customers. This was almost a pure-play financial play, the way I read it. I would assign a high weighting to the possible outcome that the ALBPM (what an acronym!) stuff just gets mothballed. If not intentionally, then when the BPM developers move on (the quick moves by oracle, while healthy in most respects, can result in losing key organizational members that have the critical knowledge in their heads to maintain a viable software product). There’s a chance they get BPM right, but I think there was already significant risk under the BEA umbrella that fuego would become a pure IT play, and lose its business focus. I think that risk is magnified by the oracle purchase as they are now two levels removed from charting their own destiny.
I don’t see any reason (yet) to see why IBM and Oracle would start thinking about the BPM space as other than a middleware problem. as other than an “SOA” problem. I’m waiting to be proven wrong, and I’ll keep reading your blog and others and keep my ear to the ground in the market, but right now I don’t hear the footsteps of the big players coming… it looks to me like the pureplays that are left still have a window of opportunity open where the bpm market isn’t quite big enough to get the big guys to take it seriously. And the strongest pureplays will benefit the most – which to me sounds like Lombardi now.
I realize, re-reading my post, that I might come across anti-oracle or anti-ibm – quite the contrary (a lot of my work has used software written by both companies!) – if I had businesses as large as their software businesses, I might not give BPM overmuch attention either 🙂 And their strategic moves make plenty of sense whether BPM is a market or not – because they are justified by the economics of the middleware integration, cost savings, and maintenance revenue.
It will be interesting to see how this develops.