A Note: This is a blog that I have wanted to write since I started blogging on SDN. I find the topic fascinating and in large organizations, the description is not theoretical but based on the actual IT landscapes that such environments require. This blog contains lots of questions and interesting scenarios but doesn’t contain answers to all the questions that are discussed.
This blog examines the various possible scenarios that involve the use of business processes in a distributed environment. By distributed, I am referring to two or more portals. Based on this simple definition, what are the initial architectural patterns that are possible?
The picture below shows the first two basic types that are related to the relationship between portal technology and back-end (usually in our context based on SAP’s Web Application Server – WAS – and possibility being represented by a MySAP 2005 environment). The first possibility is that the portal and back-end are on the same server. The second possibility is the portal and back-end are on two separate servers. In the context of Guided Procedures (GP), the first model would be based on direct RFC / BAPI calls to get the necessary data, while the second model might be based on web-services. The form of interface is for our discussion, however, largely irrelevant. Of course, a process might also include multiple back-ends (representing a true composition application). This is also largely irrelevant for our discussion. What is important is that the process runs in the context of a single portal.
For this blog, the critical question is: what happens when multiple portals are involved? In the context of this discussion, the portal is critical, because this is the environment (design- and run-time) where processes (usually GP-based) are located. Thus, another architectural pattern is the focus.
Although the focus of this discussion will be on two portals, the number of portals could be two or more.
Organizational Context
This approach is supported by the usual composite approach to deal with the actual business environment based on the existence of “silos” or “stovepipes”. The figure below comes from Bruce Silvers Associates’ excellent report Understanding and Evaluating BPM Suites and shows the complicated process environment that exists in many corporations.
.
If you map this process-based perspective to a technical / infrastructure perspective, you would get something that might look like the simplified figure below where certain business functions are located together in one portal while others have their own portal environment. The figure below also shows one other variation that is possible as well – one thatis based on region.
Of course, one of the important variations on this architectural pattern describes an environment that include company-internal and company-external participants (such as business partners or suppliers).
Technical context
If you look at the technical architecture that is now available with SAP’s latest ERP release MySAP 2005, you will see that a portal that supports GP (which requires usage type “EP” instead of “EP Core”) is available out-of-box due to certain requirements (for example, linked to BI (Business Intelligence) that are usually present. Thus, most companies moving to this new environment will be confronted with a multi-portal environment. The decision to exploit these portals to their utmost and the manner of this usage depends on many factors (for example, decisions regarding portal federation, conflicts between central / decentral factions, governance, etc).
The fun stuff
Now that we have determined that this multi-portal environment is in all probability likely to be present from a technical perspective and that domain requirements linked to complex processes will mandate its presence, let’s consider what the impact of this new situation might be on the design- and run-time environments (especially regarding GP).
General analysis
Before we examine the two areas in question in detail, let’s take a quick look at the various ways in which a process can span multiple portals. The first possibility is a hand off between two portals that takes place where there are concrete process instances that exist in two separate portals. There is an abstract process that exists outside both portals that includes the two separate processes. The easiest way to pass the information from one process to another could be via a web-service.
The GP design-time has the ability to integrate Guided Procedures: Example of the external Web Service Callable object as well as the ability to initiate processes via a web-service interface. Thus, it could be possible to start a GP process on another portal using these functions. (I’ll look at the design-related issues later in the blog.) Of course, this interaction is based on a very loose-integration that makes important activities such as monitoring very difficult. Thus, a monitoring tool that is able to watch the entire process and report progress and problems may be necessary. This tool could be web-service-based and store the information collected in a database.
Of course, there are other issues that affect the scenario. For example, the abstract process contains two concrete process elements that are exist in separate run-time environments but are still part of one process. What happens when an exception occurs in the second process influences the process flow and a block step in the first process should be called as a result of the exception? Or what happens when two processes are running in parallel in two different portals? What might be useful in this situation is a process that monitors and controls these processes. This “Big Brother” process could run either on one of the existing portals or on a third portal.
Up until this point, we have been looking at processes as monolithic objects. However, as we all know, processes are composed of smaller entities (blocks, actions, tasks, etc). It is imaginable that at some point process-based run-time environments will be able to use distributed process entities as well (sort-of like a Global Portal). For example, in a GP environment, a process based in one portal might include actions or blocks from other portals. The figure below demonstrates this potential and shows a process on one portal that includes a action (or the associated Callable Object) from another portal. The action accesses data from a back-end that is protected by a firewall.
The integration just described could take place in two variations: 1) a copy of the remote GP object is copied into the portal that is hosting the process or 2) the process could access the remote process element via some interface (perhaps web-service-based). In the figure above, a copy of the remote action wouldn’t work, because of the infrastructure-related limitation associated with firewall access to the back-end. This access is often restricted and it might be expected that the firewall access is just permitted for the second portal based on security reasons.
Of course, there are other issues in such distributed environments that shouldn’t be forgotten.
- What about the roles that are involved in this distributed process environment. Should they be identical between the two portals or can they be different? What about the usual Overseer role that can watch the status of the particular processes? How would this work in a distributed environment?
- Of course, Single Sign on must exist between the multiple portals; otherwise, there would definitely be problems in the runtime environment.
- Helpful would also be an identical identity store to minimize complexity. In environments where processes span company boundaries, this supposition might not be true in that portals from external business partners might include different users.
- What about Business Process environments that are based on different vendors? BPEL might be useful for automatic processes but what about processes with human interaction?
- UWL interaction might be troublesome as well. In which portal do UWL work items appear? Of course, users shouldn’t have to switch portals to have a complete picture of all their tasks. Should a UWL federation based on portal federation be used or should a central portal be the only access point for UWL. This is, of course, notpractical for processes that include external customers who have no access to internal portals.
One possible solution to some of these isues might be the use of a common Business Process Management (BPM) runtime of connected SAP systems to bridge different portals. This might provide a foundation for all the different environments in that the BPM runtime then has full process control.
Unfortunately, I haven’t tried this solution.
The fun stuff: Design-time
The big question here is how do you design a distributed process? A related issue is who must design these elements. Actually, a distributed environment is closely related to infrastructure issues; therefore, the details of such environments should be hidden from BPXs. Ideally, the BPX would be able to use an Enterprise Service Repository (ESR) that has access to both portals and store information concerning their respective process, GP elements, etc. Thus, the BPX would have an interface that reflects his domain needs while hiding the distributed nature of his environment.
Of course, things become complicated when multiple BPXs (usually focused on the process elements in one particular portal) are working on the same processes. Then questions can arise such: who can design/has responsibility for which process elements. This situation can be even more complicated if each portal has its own ESR.
Without a Meta-ESR that includes elements from both portals, process design that crosses “smokestacks” will be very difficult.
The potential interaction between processes that are based in different silos is also interesting. A loose interaction is imaginable where the interfaces between silos are agreed upon and the internal process contents are then the responsibility of the silos and their respective BPXs. As long as the process results are correct and the associated SLAs are not violated, then if the process within a particular silo is based on five blocks or two is largely irrelevant and might be hidden from other silos.
Summary
This blog contains many hypothetical situations that together create a very complicated process-related environment. Although some readers may suggest that these descriptions just apply to large corporations, this proposition is only partially correct. All organizations wish to optimize their processes and one main area for this improvement is the interaction with customers. Although one solution to deal with this interaction is to place customers and internal users on the same portal, a process arena that includes other external portals is more powerful and more likely to lead to innovations that provide those critical leaps forward that enable companies to become leaders in their industry.
The distributed portal architecture with its resulting complexity in process-related activities is destined to complicate all our lives (irregardless if one is a BPX, administrator or developer). Although this new environment will cause a myriad of problems for all involved, it also enables a quantum leap in creating processes that really reflect the real business environment.
- SAP Managed Tags:
1 Comment
