In our example from last week, POA implements the requirements for a call center handling new orders and product issues. The process itself may be common for both work item type or it may inherit characteristics from a parent business process. In order to take advantage of this architecture, the business process needs to interact with back-end systems in a more abstract fashion. For example, let's say the process needs to perform some back-end system hand-off operation or synchronization after the call center is finished with the work item. Regardless of whether the work item is an issue or new order, the common process can utilize an abstract way of dealing with work items to perform the hand-off. The back-end systems may simply be a database or it can involve SOA concepts such as web services, service bus or JMS or all 3 at once. Interfacing with the back-end using an abstract interface would help the common process deal with the handoff or back-end synchronization for the different types of work items.
Not all back-end interfaces should be abstracted for commonality. When it makes sense from a system design standpoint, the underlying functionality can be tightly coupled in order to be handled in the same way by the common process. Conversely, the back-end systems may be loosely coupled by performing the operation in the child process where specific order or issue tasks can be performed. The tightly coupled designs would put them behind common back-end integration points. The loosely coupled design would leave them separate. Choosing the best approach can only be done by understanding how the business process and back-end systems need to work.
Tightly coupled designs provide a better way to extend and reuse functionality across an organization, which is preferred. Implementing use cases such as training, management oversight or breaking apart functionality for communities of process users are more easily implemented when processes and back-end systems are tightly coupled. POA will leveraged tightly couple back-end interfaces to implement requirements and aspects such as training and management oversight different users and communities effectively and with efficiency.
Let's consider three common aspects of back-end systems; Databases, EJBs and SOA using web services. We will consider how message-driven beans, JMS and service bus technologies play as well. We will start with simple examples and then show how more complex use cases can be handled.
Modifying Altering, Changing or Deleting (MACD) work item objects are handled best by the common process. Since we have designed the work item object such that things pertaining to the common business process are located in the root work item, MACD for orders or product issues is as easy as just handling the root object. If there are specific changes to the underlying work item, these changes should have been made by the view controllers, so we may not have to worry about them in the process. But if that is not the case, we can always abstract these operations behind a common back-end operation (or Data Aspect Object) or using helper methods within the process. Another approach would be to subclass the process and handle the differences there.
Figure 1 shows a data model using EJB concepts. The roles of Clerk and Biller are different and separate. The Clerk is working on a particular order, and the Biller is processing an invoice. The order and invoice work items share information, but the information is "sliced" (or partitioned and segmented as building blocks that are reconstructed as a new object, such as an invoice or order) differently as required to satisfy the two roles. Work item objects are pulled up using Data Access Objects (DAOs), which contain logic as to how to put the work item objects together. The DAO may use simple information like object identifier and object type, but they may also use role information, which is especially important if the objects being collected require policies involving Access Control List (ACLs).
Depending on the work item type, work item ID and role, the DAOs build the work item by pulling information from the database, repositories and/or services. In Figure 1, database objects are retrieved using container managed EJBs. Information stored in repositories can be obtained by the DAO through a web service or Bean Managed Persistence. In our example Bean Managed Persistence objects handle MACD of Documentum repository information.
In an enterprise, obtaining real-time information is important. Since the underlying technology leverages EJBs, POA can build on these technologies to create a fully integrated solution. Processes for particular communities and process across the organization or enterprise can share common information. POA properly quantifies and slices this information into the particular views seamlessly. The clerk updating an order, the agent billing a customer, and the manager overseeing the operation all share and look at the same information, but it is processed and viewed to best suit each role.
The underlying work item is an abstraction, which is the goal for our back-end implementation as desired for a POA. The back-end design didn't depart from best practices, either. Instead, POA ensured the back-end is constructed with basic building blocks that can be extended and reused not only by our business processes, but by other systems in the enterprise. POA simply leverages the back-end by requesting a work item for a particular role with the work item identifier, or primary key. The work item is construction by the DAO while persistence and object life-cycle is managed by EJBs.
DAOs and EJBs are not the only way to implement back-end services. We could have just as easily used web services, JMS, Message Driven Beans and/or a service bus in the same way. The important thing here is to decouple back-end systems from the process by abstracting and reusing them in various parts of the enterprise. Depending upon the technologies used by the organization before the BPM initiative began, POA can leverage these technologies in the best way.
Figure 2 contains another example of how back-end objects can be abstracted and reused by POA. Instead of DAOs, we're using a Service Bus to interface and coordinate back-end systems. If building a new order requires persistence to a database, calling a web services and using EJBs, the Service Bus can be used to manage this function. BPM can now coordinate human workflow with back-end service orchestration using other enterprise strategies.
POA organizes the process, views and the calls to the back-end systems by tightly or loosely coupling these objects as it make sense for the business. Once these components are organized in this way, current and future needs of top-level management, individual contributors and communities of users can be accounted for. The design or implementation of this POA will yield the most optimally efficient system possible because it anticipates business change. By finding commonality where it makes sense and structuring the design to make use of concepts such as OOD and Aspect Oriented Programming, POA can achieve what has been done for business applications (using SOA) in the realm of BPM.
The next blog entry will be the final of this series: a summary of BPM. Be on the lookout for my white paper entitled "How Process Oriented Architecture (POA) Reduces the Cost of Oracle BPM Implementation" coming in June.