RE: Oracle... That doesn't mean I think Oracle's work flow solution is a particularly strong option right now. This is an analysis I wrote after we got back from San Francisco last week...maybe it will help someone here with a decision...
Oracle appears to be pushing their software solutions in all the right directions, with software that is extensible, compliant with open standards, and reasonably modular. The company's seemingly ubiquitous push toward open standards and it's contributions to those standards shows a mature understanding of the present and near term future of durable software solutions. We saw quite a few software solutions Thursday in San Francisco that any Oracle-running shop would (and should) be eager to put into production, such as their Enterprise Service Bus for lending some management to a company's web service portfolio, etc. However, with Business Process Management (BPM) as a key topic, it is worth putting some analysis in to that area of their offerings. Oracle's current work flow solution is primarily (and for the time being, almost exclusively) a BPEL engine. To paraphrase one of Oracle's developers on Friday, the Business Process Execution Language (currently in version 1.1 and also in the 2.0 draft) is an orchestration language that internally has made no real provision for handling human tasks. While Oracle developers have taken a step to address this limitation in BPEL by creating a custom web service component that wraps some user-assignable functionality, an effective enterprise-wide work flow solution must offer a complete set of features for managing human tasks. Two task management features missing from Oracle's near term solution are swimlane assignment of tasks and separate work group assignment for tasks (in which task ownership is simultaneously composed of both user and work group information). For those who may not be familiar with swimlanes and work group assignment as mentioned in this context, please consider the following two examples: Swimlane assignment: NTC generates a large portion of it's revenue by the renewal of existing commercial contracts. Securing a renewal is a predominately human process in which a representative assigned to a particular customer may contact the customer several times over a period of months, attempting to both secure a renewal of the contract as well as up-sell services, maybe having to offer discounts or appease some dissatisfaction along the way. Once a representative has begun working on a particular renewal, it is generally important that that same representative be subsequently assigned to every customer contact task that follows in that process instance. It is also generally important that if a particular customer renewal is reassigned to a different rep for some reason, that the new rep be automatically associated with all further tasks. In this described case (and given a swimlane implementation) all human contact tasks in the process form a 'Rep' swimlane, and each newly created task instance belonging to the Rep swimlane will be automatically assigned to the individual user currently associated with the swimlane. At some point, the swimlane (or role) within the process instance can be associated with a different user, and subsequent tasks in that swimlane will be automatically assigned to that new user. Work group association: consider that a particular trouble ticket task is associated with a 'Ticket Pool' from which members of the Customer Care group claim tasks. A user named Bill claims a task out of the pool but does not perform the task for some reason, and the ticket must revert back to the pool. If our system supports separate work group assignment, our task contains assignment data related to both the current actor (Bill) and it's governing work group (the Ticket Pool); consequently, simply disassociating Bill from the task allows the system to see this task as being back in the Ticket Pool. If we didn't have both user and group data simultaneously associated with the task, the system wouldn't know to which pool to return the task. We could not determine this simply by referencing to which pool Bill belongs, because Bill may work out of more than one pool. Naturally, each work flow feature, like those listed above, not found in a particular commercial package adds to the amount of in-house development required to be layered on top of the package. In addition, information like swimlane/task association which should arguably be developed (and stored) as part of the process definition, must be developed and stored apart from the package's core definitions. Of course, if the the commercial package is upgraded, those in-house extensions/customizations must keep pace. Oracle's product will likely make up the difference in features at some point in the future, but ...<stuff probably covered by some NDA somewhere> Also, to add a bit of perspective to the holy grail that quite a few people seem to be looking for, Oracle's developers also confirmed that it is basically impossible for a business analyst to produce truly robust process definitions without the involvement of a developer at some point. This is not knocking either BPEL or Oracle's solution; I believe this is simply the nature of the beast and will hold true no matter who's software or standard is evaluated. On a positive note, the extensive number of connectors provided out of the box means developers wouldn't have to spend much time tooling handlers for FTP, file system access, and several other popular, third party systems. Also, Oracle's GUI for process design seems to be quite thorough. On Thursday, one of the presenters mentioned explicitly that it was not possible to manually override a BPEL process (ie., administratively completing an otherwise automated state); however, one of the developers assured us that this was possible through the APIs. This needs to be clarified, since the ability to manually administer the completion of an otherwise automated process state is occasionally an unfortunate necessity. In the end, Oracle's product is an excellent first shot at BPM; however, as an architect, I would have liked to see them put some of the effort that went into connectors and the GUI, rather, into fleshing out a better framework for handling human oriented work flow. The lack of the latter in up-coming releases may prove costly for current adopters who intend to deploy the software business-wide. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3912718#3912718 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3912718 ------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_idv37&alloc_id865&op=click _______________________________________________ JBoss-user mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/jboss-user
