skip to main |
skip to sidebar
Business Process Management (BPM) is used to model, simulate, automate, manage, and monitor processes, in order to coordinate operations with dynamic business priorities.
With BPM, workflows (both human and automated) are determined in real-time by events and/or outcomes within the process, and effective knowledge transfer is made possible as processes become well-documented business artifacts on which staff members can be trained.
To enjoy the full benefits of BPM, processes must integrate with existing applications and systems (e.g., hospital EHR and EMR, to name a couple of areas currently being funded by the Obama administration in the U.S.). This is where Service Oriented Architecture (SOA) - the subject of earlier posts - comes in. BPM and SOA are a natural match. There are links to a few of my early articles on SOA, in the bibliography at the bottom of this blog.
In preparation for my next post to this blog, I'd like to cite the following book:
This book shows the reader how to fill the semantic gap between the process model and the applications:
Modeling business processes for SOA and developing end-to-end IT support has become one of the top IT priorities. The SOA approach is based on services and on processes. Processes are focused on composition of services and in that sense services become process activities.
Experience has shown that the implementation and optimization of processes are the most important factors in the success of SOA projects. SOA is so valuable to businesses because it enables process optimization. In order to optimize processes, we need to know which processes are relevant and we have to understand them – something that cannot be done without business process modeling. There is a major problem with this approach – a semantic gap between the process model and the applications.
This book will show you how to fill this gap. It describes a pragmatic approach to business process modeling using the Business Process Modeling Notation (BPMN) and the automatic mapping of BPMN to the Business Process Execution Language (BPEL), which is the de-facto standard for executing business processes in SOA. The book will also cover related technologies like Business Rules Management and Business Activity Monitoring which play a pivotal role in achieving closed loop Business Process Management.
From
http://www.packtpub.com/business-process-driven-SOA-using-BPMN-and-BPEL/book
The BPEL specification focuses on business processes, the activities of which are assumed to be interactions with Web services with no additional prerequisite behavior. But the spectrum of activities that make up general purpose business processes is much broader. People often participate in the execution of business processes introducing new aspects, such as human interaction patterns. Workflow tools already cater for the orchestration of user interactions.
User interactions range from simple scenarios, such as manual approval, to complex scenarios where data is entered by the user. Imagine a bank’s personal loan process. This process is made available on the internet site of the bank using a web interface. Customers can use this interface to enter the data for their loan approval request and to start the approval process. The process performs some checks, and eventually informs the customer whether his or her personal loan request has been approved or rejected. Processing is often automatic and does not require any human involvement. However, there are cases that require bank staff to be involved. An example of such a case is if the online check of a customer’s creditworthiness returns an ambiguous result. In this case, instead of declining the request automatically, a bank clerk could check the request and determine whether to approve or decline it. Another example would be if a request exceeds the amount of money that can be approved automatically. In this case, a manual approval step is required, in which a member of the “approvers” group either approves or declines the request.
User interactions in business processes are not limited to approval steps. They also may involve data. An example of a user interaction that involves data is when an e-mail from an employer is manually attached to the process instance, or when the summary of an interview with an applicant is keyed into the process via a simple form or custom-built application.
To support a broad range of scenarios that involve people within business processes, a BPEL extension is required.
BPEL4People is defined in a way that it is layered on top of the BPEL language so that its features can be composed with the BPEL core features whenever needed. We envisage that additional BPEL extensions may be introduced which may use the BPEL4People extension introduced here.
BPEL4People is the WS-BPEL Extension for People as proposed in a joint white paper by IBM and SAP in July 2005.
In June 2007, Active Endpoints, Adobe, BEA, IBM, Oracle and SAP published the BPEL4People and WS-HumanTask specifications as a follow-up to the whitepaper, describing how human interaction in BPEL processes can be performed.
The OASIS WS-BPEL Extension for People (BPEL4People) Tecnical Committee is working on standardizing the BPEL4People and WS-HumanTask specifications.
Click here for a very engaging podcast that describes the inner workings of Technical Committee’s (something you usually don’t hear much about), describes the work the OASIS TC has recently accomplished and articulates the grand vision for business process management (BPM) and workflow that the committee has been working on.
I strongly encourage you to listen to this podcast. You’ll hear how some the of most important thought-leaders in the IT world, including IBM, SAP, Oracle, Microsoft, TIBCO and Active Endpoints are discussing BPEL and BPEL4People.
Disambiguation of IDs is the process of resolving multiple potential matches into a match with the correct person. In general, statistical matching algorithms are likely to require substantially more-frequent disambiguation compared to that required by a system that uses theoretically perfect universal IDs; often, disambiguation is done by human intervention. Such disambiguation imposes significant costs and operational inefficiencies, particularly if, for example, a physician must resolve the ambiguities.
Note 1: Many of the efficiency and safety benefits theoretically possible with health information technology (HIT) systems depend on eliminating such human involvement and its concomitant slowness, expense, and propensity for error.
Note 2: What follows applies to IDs in general, even though I’ve chosen the healthcare industry for much of this discussion.
Disambiguation sometimes entails implementing significant new workflows that may require substantial time and resources. When human involvement is required, many of the potential benefits of automation are lost. For example, at the point of care, disambiguation is often done by asking the patient further questions regarding personal characteristics and/or health care history.
The potential for error in the statistical matching methods (see my December 1 post on unique patient IDs) has important safety implications, which are a chief concern for many in the health care profession. Two types of errors are involved in statistical matching: false positives, in which there is a link to the wrong patient’s records, and false negatives, in which not all of a patient’s records are found. A graphic representation of these types of errors and of how they relate to the probabilities and threshold for matching is shown in the figure below.
The horizontal scale shows the score of a particular match. As more and more attributes match and as the match is weighted by its score, or value, the higher is the probability that the patient is correctly matched to that record. A low score indicates a low probability of match (and a high probability that it does not match). It is possible to use a threshold above which the record is assumed to match and below which it is not assumed to match, which leads to the shaded areas above and below the threshold.
The area shaded to the right of the threshold is the region corresponding to false positives, or picking up the wrong patient’s records. The shaded area to the left of the threshold is the region of false negatives, or the records of the patient that are not picked up because of some non-matching personal attributes. Setting a balance between the two types of errors involves tuning.
Another approach illustrated in this figure is to define a region of ambiguity within which possible matches are tagged for human resolution, or disambiguation. Whether matching uses a single threshold or two thresholds, it is not possible to avoid encountering false-positive and false-negative matches. Adjusting the threshold or thresholds can result in a different proportion of false-positive and false-negative errors, but cannot be used to eliminate them because they result from the inherent characteristics of the population that lead to the two S-shaped curves.
As stated above, many end-to-end business processes require human interactions with the process.
Task Assignment and Routing
Human workflow supports declarative assignment and routing of tasks. In the simplest case, a task is assigned to a single participant (user or group). However, there are many situations in which more detailed task assignment and routing is necessary (for example, when a task must be approved by a management chain or worked and voted on by a set of people in parallel, as shown in the figure below). I’ve chosen tools in the Oracle SOA Suite to illustrate (in the figures below) human workflow that can provide declarative pattern-based support for such scenarios.
I’ll briefly elaborate here with an introduction to human workflow and continue the discussion in my next post, where I'll talk about how you might implement such a system.
Participant Type
In simple cases, a participant maps to a user, group, or role. However, workflow supports declarative patterns for common routing scenarios such as management chain and group vote. The following participant types are available:
Single approver
This is the simple case where a participant maps to a user, group, or role. Since at least one human being is involved, much more than his or her looking at a monitor screen and clicking with a mouse is involved.
For example, a vacation request is assigned to a manager. The manager must act on the request task three days before the vacation starts. If the manager formally approves or rejects the request, the employee is notified with the decision. If the manager does not act on the task, the request is treated as rejected. Notification actions similar to the formal rejection are taken.
Parallel
This participant indicates that a set of people must work in parallel. This pattern is commonly used for voting.
For example, multiple users in a hiring situation must vote to hire or reject an applicant. You specify the voting percentage that is needed for the outcome to take effect, such as a majority vote or a unanimous vote.
Serial
This participant indicates that a set of users must work in sequence. While working in sequence can be specified in the routing policy by using multiple participants in sequence, this pattern is useful when the set of people is dynamic. The most common scenario for this is management chain escalation, which is done by specifying that the list is based on a management chain within the specification of this pattern. More on routing later.
FYI (For Your Information)
This participant also maps to a single user, group, or role, just as in single approver. However, this pattern indicates that the participant just receives a notification task and the business process does not wait for the participant's response. FYI participants cannot directly impact the outcome of a task, but in some cases can provide comments or add attachments.
Readers who are interested in learning more about the subject of human resolution or disambiguation in an otherwise automated system might look at the following two books, while waiting for my next post.
A system that includes new and old technologies -- partially represented by the use case diagram shown below -- will be the subject of upcoming posts. Interoperability -- technical and semantic -- using open, standard protocols will be my focus.
{double click for larger view}
For anyone not familiar with use case diagrams, here's a link to an easy-to-follow introduction to using them and another link to the Wikipedia entry for use case diagrams.
The discussion of technical interoperability will include, but not be limited to, whether to employ Web services with BPEL or ESB (or both) and business activity monitoring (BAM) tools.
The discussion of semantic interoperability will include, but not be limited to, whether to employ HL7 version 3 messages or CDA documents (or both).
Other topics such as service level agreements (SLA), key performance indicators (KPI), telemetry, and telemedicine will be included.
As the title suggests, this post, the first in a series of continuations of my June 13 post, is about the technical aspects of interoperability. For your convenience, I’ve copied the figure below from the earlier post. 
The word "interoperability" means different things to different people. To DBAs, for example, the ability of SQL Server, Oracle and DB2 to recognize each other’s commands is a sign of the interoperability of these databases. In the current post, however, I'll focus primarily on a distributed computing model that is capable of cross-platform and cross-programming language interoperability, Web services. In the process, I'll compare Web services with a couple of its predecessors, CORBA and DCOM, which are still being used widely.
Why CORBA and DCOM success is limited Although CORBA and DCOM have been implemented on various platforms, the reality is that any solution built on these protocols will be dependent on a single vendor's implementation. Thus, if one were to develop a DCOM application, all participating nodes in the distributed application would have to be running a flavor of Windows. In the case of CORBA, every node in the application environment would need to run the same ORB product. Now there are cases where CORBA ORBs from different vendors do interoperate. However, that interoperability generally does not extend into higher-level services such as security and transaction management. Furthermore, any vendor specific optimizations would be lost in this situation.
Both these protocols depend on a closely administered environment. The odds of two random computers being able to successfully make DCOM or IIOP calls out of the box are fairly low. In addition, programmers must deal with protocol unique message format rules for data alignment and data types. DCOM and CORBA are both reasonable protocols for server-to-server communications. However, both they have severe weaknesses for client-to-server communications, especially when the client machines are scattered across the Internet.
CORBA overview
Common Object Requesting Broker Architecture (CORBA) provides standards-based infrastructure for interactions between distributed objects. It allows software components running on dissimilar hardware, hosted on different operating systems, and programmed in different programming languages to communicate, collaborate, and perform productive work over a network.
A CORBA system accomplishes this magical task by confining the interaction between objects to well-defined interfaces. To use the service of a distributed object, you must interact with it through the interface. How the interface is implemented -- or even where it is implemented -- is not known and doesn't have to be known by the client. The figure below illustrates the workings of a typical CORBA system.
Object interactions in CORBA
Achieving location transparency In this figure, the client code makes use of a server object through its interface. In fact, the interface is implemented by a stub object that is local to the client. As far as the client can tell, it's only interacting with the local stub object. Under the hood, the stub object implements the same interface as the remote server object. When the client invokes methods on the interface, the stub object forwards the call to a CORBA component called the Object Request Broker (ORB). The calling code in the client does not have to know that the call is actually going through a stub.
DCOM overview Distributed Component Object Model (DCOM) is a Microsoft proprietary technology for software components distributed across several networked computers to communicate with each other. However, it has been deprecated in favor of the Microsoft .NET Framework, which includes support for Web services. Internet poses problems for CORBA and DCOM DCOM was a major competitor to CORBA. Proponents of both of these technologies saw them as one day becoming the model for code and service-reuse over the Internet. However, the difficulties involved in getting either of these technologies to work over Internet firewalls, and on unknown and insecure machines, meant that normal HTTP requests in combination with web browsers won out over both of them. Web services overview Web services specifications such as SOAP, WSDL, and the WS-* family are currently the leading distributed computing standards for interfacing, interoperability, and quality of service policies. Web services are often called "CORBA for the Web" because of their many derivative concepts and ideas.
There are several ways to think about Web services when building applications. At the most basic level it is an advanced communications protocol family allowing applications to talk to each other. This level has progressed quite significantly over the past few years with many tools (e.g., Oracle’s JDeveloper and Microsoft's Visual Studio) that allow software developers to write interacting Web services and build complex applications. This level is often characterized by direct one-on-one interactions between services or relatively few services interacting with each other. SOA overview However, just using Web services as a communications protocol belies its true power, that of the service-oriented architecture (SOA). The SOA describes an entire system of services dynamically looking around for each other, getting together to perform some application, and recombining in many ways. This model encourages the reuse of technology and software that evolves the way applications are designed, developed and put to use. It brings the world of distributed computing to a closer reality. At this level software developers need to think of the SOA model and design their distributed application across the model. This level is characterized by the use of technologies to allow distributed communications of services such as the use of an Enterprise Service Bus (ESB), which is a common distribution network for services to work with. More on ESB in an upcoming post.
Finally, the highest level is to look at this SOA model and the many component services as building blocks that can be assembled in whole sections into full applications instead of the traditional method of writing line after line of code. By examining the connecting interfaces, we can build whole applications without ever really writing code. For that matter direct code may even get in the way since the services may be written in numerous different languages and platforms. The blocks can be put together into a workflow of operations that define how the application performs, and other tools can be used to monitor the effectives of the workflow at each service or group of services. At this level, developers can put away the use of regular programming languages and work in a Model-Driven Architecture that helps them to build applications more accurately to a design. More on workflow in an upcoming post.
