A recurring theme of this series is how partitioning systems reduces costs of a POA. Here we discuss this in more detail. Today I’ll elaborate as to how information and views should be organized and why.
Consider this scenario where we show the role of the process vs. the view dispatcher:
Let’s look at this screen view (below) for a work item. It’s a form used to enter order data. This form is a view rendered by the view dispatcher. In this single view, there are items that need to be known and used by the process and those that the process does not need to know.
The process may need to know certain things about the work item like Key Performance Indicators (KPIs), work item states, status or actions taken by the user. In our example, both order and issue items are sub-classed from a common parent. Information needed by the process about the work item, like order amount and order number (work item identifier), should be placed in the common work item object.
The process may also need to tell the view what actions to expect when the user is finished with the view, such as what actions are allowable to the user; i.e. accept, deny, save, delete, escalate, (or as in our example Save Changes, Cancel Complete) Information about the view, such as the style, type (external app or simple html form) or technology used to render the view are not important to the process and are left to the View Dispatcher to resolve.
The role of the View Dispatcher is to put together the specific view needed by the user. The need to create an order versus fulfill an order requires different views, but are part of the same end-to-end process. These views are resolved or put together by a view dispatcher according to information from the process. Partitioning the system in this way allows the view dispatcher and technologies used to implement the view to utilize very modular and re-usable components that make up the view. And virtually all UI technologies are compatible with this architecture. Technologies like Eclipse RCP, Struts or Spring M/V/C and tiles technologies jump to mind. I will not elaborate too much on it here except to say that some technologies are easier to integrate then others.
Further partitioning of the system, the data model in a POA also needs to be properly designed. This doesn’t impose requirements on the system any more than using an M/V/C architecture imposes particular design constraints on web applications. The data model just needs to consider how the system will use the data. So an example data model for POA could contain three regions: Business process data, functional data and content.
This can be shown as a domain diagram with overlapping regions:
- The region concerning the business process consists purely of process related data like work item action (accept, approve, deny), KPIs and employee assignments.
- Functional data refers to specific work item details concerning the order or issue like customer name, billing info and issue description.
- Content domain represents blocks of data that are referenced by or useful to the process or view like product info, help menus, MS Word documents or spreadsheets.
Business process data may be placed in the common parent work item object and/or be included in with process instance information. Functional information can be in the parent or sub-classed work items. Content may be referred to by the process or views, but should be on a file server, document repository or database.
This data model will be developed further in a later blog entry. Various design considerations like façades, Data Aspect Objects (DAOs) and applicable technologies like Hibernate, Spring, EJBs, database and document repositories will be considered. For now, we will use this general data model so we can look at how views work in our POA.
After the view is dispatched, the controller used to render the view, (e.g. Struts Controller) may need to call back into BPM or use EJBs to get information for the view, persist changes, create objects, etc. The common process may just pass the object type, object identifiers and a list of action buttons for the view. With object identifiers, the view controller loads information into a form-backing object from the data in the work item and renders the view. Some actions available to the view may be save, cancel, accept or deny the order. The controller will persist changes if the person clicks on save changes or completed. It would then return whatever action (save, cancel, completed) back to the process so the process would know what action was taken by the user. If the process needs information from data collected from the work item, it can load the data from the persisted work item via EJBs or directly from the database. This way process stays synchronized with related information like KPIs, deadline information or assignments if the data was changed through the user interface.
While I’ve added some technical details to illustrate these scenarios, the main take-aways are that POA partitions the systems so that each part performs its own jobs so that process, view components and data components can be leveraged and re-used for profound cost-saving benefits.
Next week: Business Process Integration