Archive for August, 2006
Even though the meat-and-potatoes of BPM 2.0 — business-oriented, top-down model-driven process implementation (without code), based on some form of SOA — hasn’t yet been finished, BPMS vendors want to skip ahead to dessert, with system-generated recommendations on how to optimize the process design. Lombardi was the first out with this, but now both BEA and Savvion are planning to offer a similar concept in their next major releases.
Lombardi’s Process Optimizer perspective blends simulation analysis and historical performance data to identify points in the process model where projected performance falls short of target KPIs, and then offers recommendations on how to bring those KPIs back in line. Some of the suggestins are fairly obvous: ”To decrease wait time [at a human task], TeamWorks recommends adding more resources to the Lane Participant of the activity.” Well duh.
But others are much cooler, for example, suggesting replacement of a human task, such as an approval, with an automated business rule for some subset of process instances. An analysis wizard looks for correlations between the approvalStatus value and some other variable, such as orderAmount. It might report, for example, that when orderAmount is less than 5275, approvalStatus was ‘approved’ 94% of the time, but only only 47% were ‘approved’ when orderAmount is greater than or equal to 5275, and suggest a business rule to automatically approve orderAmounts under 5275. If you agree with the suggestion, the wizard even creates the rule for you.
What about the 6% that normally wouldn’t get approved? Isn’t it dangerous to autoapprove those? Maybe you can add another rule to lower that to an acceptable level… I’m not sure exactly how it works. But it’s an intriguing approach. For me the cool part is the correlation analysis, more than the recommendation.
If you read James Taylor’s blog, you’d say this sounds similar to something he writes about frequently, called “predictive analytics.” That’s something used in high-end decision management, like underwriting loans and insurance, to predict risk based on historical trends using a combination of business rules and business intelligence technology. Sounds like BPMS vendors are trying to take a ‘lite’ version of that and make it part of the suite. Could guided process optimization be Gartner’s next ’must-have’ BPMS feature?
August 31st, 2006
Normally when the Ayn Rand references start flying, I head for cover. But since Phil Gilbert’s rant on the futility of foisting an SOA primer on naive business managers tracked back to my post on what BPM on SOA would look like, I guess I’m obligated to say something. Phil’s nominal beef is with the mere idea of a book called SOA for Dummies, which commits the sin (in his eyes) of equating SOA with web services and ESBs. The deeper issue, however, seems to be misappropriation by the SOA community of a value proposition that really belongs to something called Business Architecture, things like business-IT alignment, agility, reuse, etc. Business architecture, from his description of it, looks at business and IT together as an “organic” whole (with a slight top-down business-oriented perspective), rather than starting with IT infrastructure and then seeing what you can build on it.
So I guess he’s sort of agreeing with my post (I can’t tell), where I noted the inherent dissonance between BPM (top-down, business-driven) and SOA (bottom-up, IT infrastructure-driven). But he thinks that trying to explain technology to the business is a misguided approach:
As Frank Lloyd Wright said: “Form and function should be one, joined in a spiritual union.” SOA is the form to the business function. And today, the closest thing we have to being able to define business function is called “BPM.”
So my problem with notions like “SOA for Dummies” is that, once again, we are spreading a technology-led message to less and less technical people, in an effort to help them “get it” when what we should be doing is spreading business-led messaging to more and more technical people so business understanding is shared.
I agree with the goal, but not with the tactic. IT architects already believe they are business-driven. They think their SOA initiative already is a proper response to business-driven concerns. If it’s not adequate — and I agree with Phil that it’s usually not — then the technology has to be demystified for those dummies in business if you want anything to change, because they’re the only ones who can change it.
In most cases, the strategic goal of the CIO is the same as the strategic goal of the line of business executive. What’s different are the priorities, the timelines, the degree of centralized control. Inserting another level of priesthood — the Business Architect — into the picture is not the answer. The problem with SOA already is too much “A” and not enough “S”. My approach would be to rearm the business with an understanding of what today’s technology can do. Empowering the business might make it possible, for instance, to build business solutions concurrently with the service-oriented infrastructure. Perhaps business people, not just architects, could have a voice in defining the scope and granularity of business services.
So I love the idea of SOA for Dummies. IDG, if you’re ever looking for a companion BPM for Dummies, give me a shout anytime.
August 30th, 2006
While all BPMS vendors today mumble something about SOA, BEA Systems is one of very few that are making sense. They acknowledge that you can do BPM either with or without SOA, and that doing it without SOA is quicker and easier, but go on to say that as BPM deployments proliferate in the enterprise, doing it with SOA is ultimately better. And they provide software to do it either way. Quoting from CEO Alfred Chuang’s August newsletter,
Today, as we work with customers moving to SOA and learn from their practical experience, it is becoming clear that although BPM can be effectively deployed without SOA, there is a strong synergistic benefit in combining BPM’s set of coordinated activities with the architectural benefits of SOA. …
There are many IT systems sufficiently compact and stable to optimally support BPM without SOA—at first. If companies choose a BPM suite with sufficiently rich connectivity to underlying applications and databases, they will at first get the benefits of BPM without a SOA. But this initial success contains the seeds of its own downfall: As more departments come online, more managers have a hand in controlling the IT environment. And as the system’s growth necessitates more changes, the BPM solution will soon be suffering the coordination, integration, and management problems SOA was invented to solve.
Yesterday I spoke with Shane Pearson, head of the BEA unit that acquired Fuego earlier this year and turned it into AquaLogic BPM Suite. At the time of the acquisition, a number of commentators (including me) noted the incongruity of making a non-SOA BPMS the centerpiece of BEA’s strategic SOA platform. Since then, it has become clearer that AquaLogic is not (yet) a “platform” but really more of a “brand” that distinguishes the company’s broader SOA initiative from WebLogic, its J2EE platform. There is, for example, a highly rated AquaLogic ESB and service registry, but these are in a different division from the one that houses BPM and portal (ex-Plumtree). Today, AquaLogic BPM mostly stands on its own — without SOA — but the company is beginning to build better connections to the ESB and registry, so that customers who want to step up to BPM-on-SOA can do so easily.
Facilitating such a step up is more market education than tools and technology. IT architects in the SOA world still have no idea what BPM is, and they still don’t know what they don’t know. Process owners on the business side don’t really know what SOA is, although they’ve heard it’s good. They just want to improve business performance, however it gets done. This is why BEA — along with IBM, Oracle, SAP, webMethods, and Cordys… — has to better articulate the integration, what it means, how to do it. So far, only BEA appears to be gearing up for this task.
In more concrete terms, here’s how Shane explains it. Let’s say as part of a business process you need to retrieve a customer record in SAP. With AquaLogic BPM 5.5 (i.e., the original Fuego product), you can directly introspect the SAP system, select the right BAPI, catalog it as a process component, and invoke it as a component method directly from the process. That’s “direct integration” — not SOA. It’s quick and easy.
But in a global enterprise, as BPM projects that need to interact with SAP proliferate, having each one implement its own direct integration in this way becomes hard to manage. This is where SOA comes in. Probably BAPI is too low a level for the integration; it’s not a “business service.” Probably better to support asynchronous connection with reliable delivery and consistent fault handling. Probably better to leverage centralized service governance so that all consumers of the service use the approved current version. Instead of directly introspecting SAP, AquaLogic BPM looks in the service registry, and binds to that service. If deployed over an ESB, what the process invokes is a proxy endpoint that hides all of the data transformation and other “mediation services” performed by the bus. This is all SOA infrastructure; the process designer doesn’t have to think about it.
In AquaLogic BPM 5.7, coming up fairly soon, there will be a bit tighter linkage between BPM and the AquaLogic service registry, but a lot of this you can already do today. And probably you can do it with almost any BPMS that can consume web services with just about any SOA registry and ESB. When you can and when you can’t, what makes BPM, ESBs, and registries either hard or easy to glue together — those are stories that neither BPM nor SOA vendors are yet telling. I don’t understand it yet myself, but I’m going to try to do so.
In the meantime, you can read all about how AquaLogic BPM 5.5 works in the 2006 BPMS Report series, available for free download from BPM Institute.
Update: New information added by Shane:
Current State (AquaLogic BPM 5.5)
- AquaLogic Service Bus (ALSB) includes support for UDDI and provides a pre-built UDDI taxonomy for AquaLogic Service Registry (ALSR). In-depth understanding of all the ALSB proxy service types is NOT required. ALSB supported services published to AL Service Registry are reusable saving time that would otherwise need to be spent designing, building and testing.
- The integration between ALSB and ALSR is bi-directional. AquaLogic Service Bus proxy services can be auto-published to the service registry. Business services can be imported from the registry to be used in an AquaLogic Service Bus proxy service. Notifications are generated when business service changes in UDDI, and needs to re-synchronize with ALSB.
- AL BPM interoperates with ALSB or ALSR since it can directly import external services for use in business process flows. Using the AquaLogic Service Bus and/or AquaLogic Service Registry makes the implementation more robust since any changes to underlying IT systems do not have to impact the interfaces used in the business process. It also provides a separate level of control and governance outside of the AL BPM suite, which is an example of the value provided from using BPM with a service-oriented architecture.
This level of support will be enhanced in the upcoming AL BPM 5.7 release. These enhancements both add value to ALBPM as a BPMS and make it easier for people to leverage BPM and SOA when necessary. The UDDI interoperability enhancements in ALBPM will make it easier to discover, register and use external services within business processes. And for people using ALBPM with the broader set of BEA products, the company will provide pre-built examples of how to use ALBPM with AL Service Bus and WebLogic Integration.
August 22nd, 2006
BPMS vendors love to throw a bone to SOA, and if you weren’t paying attention you might even think that BPM on SOA was real. I’ve written at length about how BPM and SOA aren’t enemies but natural allies, but they are allies with distinctly different goals and aspirations and mental models of the world. Kind of like America and France.
Following his post on the subject, I’ve been having a side conversation with Jesper Joergensen of BEA about what real BPM on SOA would look like. I admit I’m still trying to figure it out. Here’s where I am so far.
Let’s start by acknowledging the inherent Mars/Venus-ness of BPM and SOA. For example:
- BPM is top-down. It starts with the end-to-end process in mind. SOA is bottom-up. It starts by factoring the world into atoms and molecules of reuse — business services — that can be consumed by any number of processes or applications.
- BPM is business-driven. A “model” created by the business drives the implementation. SOA is IT-driven. Technical architects define the scope of business services based on their own notions of “abstraction” rather than business need.
- In BPM, success is measured by business metrics and KPIs at the end-to-end process level. In SOA, success is measured by architecture, logical consistency, ease of integration. Performance goals do not extend beyond the individual service level.
- BPM is project-oriented. The goal is solving a real business problem today. SOA is enterprise infrastructure-oriented. The goal is creating a foundation for solving many business problems a few years down the road.
- In BPM, what is reused is the process model, i.e. the “abstract” design of a process fragment. It is inherently transparent — you see its steps and their individual performance parameters. In SOA, what is reused is the service implementation. It is inherently opaque, defined simply by its interface. Its internal steps and performance parameters are invisible, except for an overall SLA for the service as a whole.
- In BPM, a business process is inherently hierarchical, composed of nested and chained orchestrations. In SOA, services are inherently independent. An end-to-end process is more likely to be implemented as a spaghetti-like SCA assembly than a nested hierarchy of BPEL orchestrations.
- In BPM suites based on service orchestration, process activities are bound to service endpoints. In SOA (supposedly), orchestrated services are supposed to be abstract, with connection and mapping to endpoints mediated by an ESB. The ability to swap out endpoints performing the same abstract service is the effective definition of loose coupling. I don’t know of any BPMS offerings oriented to this mode of orchestration.
If you accept most of the above, you might ask why try to save this marriage anyway? But the goals of BPM and SOA are not opposed, just different. Bringing them together is mostly a question of timing. BPM, trying to solve real business problems today, starts by acknowledging that the refactoring of the enterprise into “business services” — macro-scale units of reuse — doesn’t yet exist, so the best approach for now is simply to incorporate service-oriented middleware here and there — mostly in application integration – in the BPMS.
In SOA, BPEL orchestration in reality is mostly used to assemble business services out of low-level APIs. They call that “BPM,” even though it’s not what the business means by that term. Eventually, there will be enough of those business services in the registry that BPM can orchestrate them in end-to-end business processes. That’s the end state that makes bringing BPM and SOA together worthwhile. We’re just not quite there yet.
So let’s wind the clock forward a bit to a time when, in some organizations at least, the set of defined, built, deployed, registered, and governed business services is significant enough to form the basis of key business processes. What would a BPMS layered on that infrastructure look like?
First, it seems that in such a world, BPM and SOA likely each have their own enterprise repository/registry. The SOA one would hold opaque service implementations - IT assets - bound to physical endpoints, SLAs, and perhaps other “contractual” aspects of the provided service. These services are not “abstract,” but real services offered by real service providers. The BPM one would hold transparent process models - specifications of business services - in which activities can be mapped to services in the SOA repository to create an executable instance of process model. Processes (including process fragments, or abstract business services) in the BPM repository could be reused throughout the enterprise to provide standardization and consistency with best practices, mapping model activities to different service providers in each instance.
Second, I believe that services in the SOA repository will generally not include human tasks, even though business services that include human tasks (payInvoice and things of that nature) are frequently described within the SOA vision. Unless the human interaction component is very simple and a minor fraction of the functionality, services that include human tasks should be represented within the BPM repository instead. One reason is you want to retain the transparency, i.e visibility of internal state, as well as ability to configure and analyze human resources to optimize performance. Conceivably one could add such attributes to the SOA repository, but they would no longer describe “services” as meant by SOA. Another reason is that the individuals and groups mapped to task performer roles are going to be different in each reuse of the model. This notion of reuse is fundamentally different from that of a single web service being consumed by multiple applications or processes across the enterprise. The latter is more about outsourcing than reuse.
In my mind’s eye, the distinguishing characteristic of a BPMS layered on SOA would be a design environment that can:
- retrieve and copy process fragments from the BPM repository, and assemble them within larger end-to-end processes
- search the SOA repository for available business services as a guide to scoping activities in the process model
- bind process activities to services in the SOA repository, via proxies defined by SOA infrastructure (e.g. ESB). Any mapping from the service interface to backend systems providing the service is handled by the ESB and mappings within the SOA domain; BPM doesn’t have to think about it.
- turn newly created processes and process fragments into “abstract business services” and store them as models in the BPM repository.
- leverage SLA, cost, and other service properties from the SOA registry in BPM performance analysis (simulation, BAM, etc.)
In Part 2 we’ll talk about how this differs from the way current “SOA-based” BPMSs work, and how it might evolve.
August 21st, 2006
Ismael posts an interesting reader request on IT|Redux addressed, it seems, to both of us:
Ismael, Bruce:
Do you think maybe it’s time for experts such as yourselves to get together and establish a standard model for BPM 2.0 in simple, concise and hopefuly universally applicable terms that can be ported throughout various functions and industries?
My work is in the supply chain arena, where about 10-15 years ago there was a similar debate regarding what constitutes a supply chain, which business function was responsible for what portion of the chain, what were some characteristics unique to the supply chain, but standard enough that could be used across all industries, etc… you get my point.
On that background, a number of experts and major clients in the supply chain arena got together and formed the Supply Chain Council, with the mission of developing a standard model, performance metrics and best in class practice, which they called the Supply Chain Refernce Model, or SCOR.
This maybe be to a certain extent what BPM 2.0 needs — a standard model, the basic tenets of which all experts agree on. A model that is relevant to all parties (Business and IT), yet simple enough that it can be easily understood by all involved, so that its use is being promoted by the debate, and BPM’s adoption rapidly expanded.
SCOR is such a model in my area of expertise, and I can tell you that by its development and use modern supply chain concepts were easily and widely adopted by practitioners.
Just a thought.
-Ryan Armasu
He goes on to relate his experience with BPMI and his personal reaction to Ryan’s idea, which is worth reading. I’m wrestling myself with what such a reference model should include, and how it relates to other standards out there, like BPMN and BPEL, or even Gartner’s BPMS functionality checklist to qualify for the magic quadrant. Individually and in combination, these three de facto standards have not provided clarity around what BPM is, much less the much narrower notion of BPM 2.0.
For example, take BPMN. Is it a design language or just a drawing notation? OMG won’t say. I’m not sure if they even know. Eventually it may have a metamodel, but it still has no methodology. It has nowhere to put simulation parameters used by virtually every BPMN-based modeling tool. It does not distinguish between core elements that must be supported by every compliant tool and other elements that are optional.
For example, take BPEL 2.0. Is portability a goal? What about human tasks? Subprocesses? These are not included, just vague white papers that surfaced a full year ago with not a peep since. BPMN devotes half the spec to BPEL mapping, but as Assaf Arkin and others have pointed out, hasn’t aligned its concepts with BPEL sufficiently to allow such a mapping unambiguously.
For example, take Gartner’s checklist. It’s fine as a list of functions that an executable process design should support, but when the suite is defined as a set of SKUs from a single vendor it starts to make less sense. Content management? Business rules? In SOA, aren’t these just services?
Ismael’s starting point is the combination of BPMN and BPEL.
If I were to create a standard model for BPM 2.0, I would start by defining what it is, without trying to re-invent the wheel, and the quickest path toward this would be to start from the BPMN and BPEL specifications. Take BPMN and BPEL, figure out what this gives you, then describe a set of benefits that business and IT users would get out of it.
I don’t agree, because the only product that combines them today is Intalio. Maybe when Oracle integrates ARIS and adds their special sauce, they might qualify. But who else? So BPMN+BPEL lacks critical mass. I prefer something like that but more “abstract” or at least more technology standards-neutral. My abstraction of BPMN would be a business-oriented modeling notation that supports both analysis and basic executable design, and includes semantics of events and choreography in addition to orchestration. My abstraction of BPEL would be an execution language that supports the general notion of “service orchestration” including fault handling and business transaction recovery, and I’d have to throw in subprocesses and human tasks as well.
Now at least we’ve got the chance of critical mass: IBM, Lombardi, BEA, Oracle, Cordys, Intalio… Within this technical framework, BPM 2.0 needs to add a general methodology and best practices. When you’re using BPM 2.0 to model and build a process, what’s the order of activities? What functions are provided by business analysts, process analysts, and developers, using which tools, and what skills are implied by those titles anyway? How does the model drive the implementation? What elements should be added by IT, and to what degree should these be surfaced in the business view? What does this top-down, bottom-up, middle-out business really mean?
Things like portability of the design are orthogonal to BPM 2.0. Maybe BPMN 2.0 will be the portability standard, maybe BPEL 3.0, or maybe even XPDL 3.0. BPM 2.0 shouldn’t be about portability, but about how business and IT collaborate to model, design, and manage business prcesses.
August 10th, 2006
Unlike Sandy, I’m not “totally speechless,” but on balance pretty surprised by today’s announcement that IBM is buying FileNet for $1.6 Billion in cash. It’s really about enterprise content management, but there are BPM implications. The ECM vendor landscape has been consolidating for several years now. There used to be 3 top-tier vendors — IBM, FileNet, and EMC — so now there are just 2. Usually M&A in the ECM space is about filling in a missing slot in the portfolio, like records management, imaging, media asset management, rights management…
This is different. IBM and FileNet both got started in CM via document imaging back in the 80s, and “fixed content” is still the strongest component of their respective portfolios, although FileNet tends to emphasize production imaging and workflow, while IBM emphasizes database and search architecture. EMC, the other competitor, has ramped up its own imaging and production workflow capabilities in the past year with considerable success (see my 2006 BPMS Report on EMC Documentum Process Suite when it goes up next week), so perhaps IBM is feeling the heat from that. Or beyond that, seeing the next generation of content management competition coming from database/infrastructure providers like Oracle and Microsoft, IBM is just bulking up.
I just caught the tail of the conference call, but a few items of interest pop up in the slides.
- Customer investments in both IBM and FileNet platforms will be protected and enhanced. Yeah, they always say that in M&A, but there is a LOT of overlap here. It took years for IBM to sort out the ECM overlaps out of its Lotus acquisition, and this won’t be any different.
- IBM admits FileNet BPM’s strength is in content-centric processes, and WebSphere BPM’s strength is in business integration. Bowing to the obvious, yes, but before today neither company was willing to say it out loud.
- IBM is talking about this as part of their SOA strategy. There is nothing SOA about FileNet.
- “Expanded value” for existing IBM clients is purportedly integration of BPM with email management, forms management, and records management. Hmmm, IBM already has those 3 ECM components, but they just never bothered to integrate with their own BPM.
- “Expanded value” for existing FileNet clients is federated records management and email archiving compliant with SEC/NASD regulations. Hmmm, a dig at FileNet’s records management?
But this is all just tea-leaf reading. Hopefully the implications will become less murky as the dust settles.
August 10th, 2006
I’ve just finished up 4 new reports in my 2006 BPMS Report series: Lombardi TeamWorks, BEA AquaLogic BPM, EMC Documentum Process Suite, and Cordys Composite Application Framework. They should be going up on the BPM Institute website next week when the webmaster returns from vacation.
The BEA report replaces Fuego; the others are new, bringing the total to 10, plus an overview report that explains the common evaluation framework and report format. (The others are IBM WebSphere BPM Suite, Savvion BusinessManager, Pegasystems SmartBPM, Global 360 Enterprise, Adobe LiveCycle Workflow, and Vitria BusinessWare.) Like the others in the series, the new reports are free to download from the BPM Institute website. Each report is around 30 pages in length, loaded with diagrams and screenshots. Based on product documentation and deep-dive briefings and demos, each report walks through product functionality end to end, including modeling, process design, human workflow, application integration, business rules, content and collaboration, events and exceptions, product architecture, and solution frameworks.
It’s more than a functionality checklist, since, let’s face it, all products today can tick off all the checkmarks. But a capability that is richly elaborated in one product might just exist at a bare minimum in another. At the end, each product is evaluated for its suitability in six process types or use cases: basic workflow, content lifecycle processes, complex collaboration, case management, production workflow, and transactional/straight-through processing.
The notable qualities and focus of each product stand out. For example, in the new reports:
- Lombardi and Cordys show how the full power of BPMN, including intermediate events for exception handling, can be used for executable design: one based on service orchestration and the other not.
- EMC illustrates the unique capabilities of content- and collaboration-aware BPM, and provides rich support for production workflow.
- BEA demonstrates the extreme flexibility of user-defined scripted methods to cover a wide range of process types.
- Lombardi makes the promise of rapid iterative development real, with the ability to instantly play back process activities at any stage of modeling or design.
- Cordys shows what it means to layer a BPMS on top of an Enterprise Service Bus. For all their talk about SOA, most other BPMS vendors don’t do that.
The new reports should go live next week.
August 8th, 2006
Oracle’s Devesh Sharma has corrected my speculation yesterday that the ARIS deal is mostly focused on the dogfight between Oracle Fusion Apps and SAP/NetWeaver. That’s one motivation, for sure, but Oracle plans to impact the mainstream BPMS market with the integration of ARIS and Fusion middleware (including BPEL Process Manager and Designer) in an offering intended to bridge the gap between business and IT. A key innovation, he says, is a unique integration concept based on metadata shared between ARIS (BPMN/EPC) and the SOA Suite (BPEL, workflow, rules, and BAM). Keeping the business view (model) and executable process in sync is a familiar topic of BPMS Watch, and Oracle claims they’ve found a neat solution. I hope to find out more later this month.
August 3rd, 2006
You gotta love the press release: “Oracle’s BPM product portfolio, which now includes IDS Scheer’s ARIS Platform, will support…” Before today’s announcement that it was OEMing parts of ARIS, Oracle to my knowledge did not offer a BPM product portfolio. Sure, they had an SOA Suite that included BPEL Process Manager and BPEL Designer - both excellent products - but the company never mustered the courage to say, “We understand what BPM is and we have a BPM suite.” A few months ago I tried to convince Edwin K and other BPEL honchos at Oracle to officially declare themselves in the BPMS battle, but they either felt they weren’t ready or had bigger fish to fry with SOA. The missing piece was on the analytical modeling side. Now that piece is no longer missing. And it looks like they’re in.
Here is my understanding of the deal, which was announced today. Oracle will OEM key parts of the ARIS platform and has acquired a license to develop internal reference models for Oracle Applications, similar to those ARIS supports for SAP. The components will offered as the Oracle Business Process Analysis Suite. The deal does not include BAM, which Oracle already has. The surprising part, obviously, is IDS Scheer’s teaming with SAP’s arch competitor, given IDS Scheer’s close 15-year relationship with SAP, including joint development of SAP supply chain management, CRM, intellectual property management, and PP-PI modules, ARIS for NetWeaver, and collaboration on SAP xApps.
IDS Scheer, however, admits to no favorites. “A company can store its process knowledge and manage the process lifecycle in ARIS,” the company’s Dr. Mathias Kirchmer told me recently, “and then load the model into any execution engine of choice, such as NetWeaver, Lombardi, or [now] Oracle.”
From a BPM standpoint, the interesting technical tidbit in the press release is support for BPEL round-tripping, a subject we’ve talked about frequently on BPMS Watch: Together, ARIS and BPEL Process Manager “will enable closed-loop process automation and optimization via shared metadata and unified repository so changes made at the Business Process Execution Language (BPEL) layer will be reflected back at the process design and modeling layer and vice versa.”
While they now have the components to do it, I still doubt Oracle will push into the mainstream BPMS market in the manner of, say, IBM or BEA. I think Oracle still sees BPM (and SOA, too) as just the latest evolution of the enterprise applications battle, which is basically a two-horse race. The middleware is there to support the packaged applications, make them more flexible, integrate better with the outside world, etc. Ultimately, this deal may impact Oracle’s Fusion Applications far more than Oracle’s position in the BPMS magic quadrant.
August 2nd, 2006
