4 - Identifying Business Functions and Business Process Modeling

Definition and identification of business tasks (activities) and processes are driven by the business requirements. These requirements may be captured as use cases diagram or document. It is obvious that every business has some sort of business process to implement. A business process involves orchestra ration of two or more business services. I want to point out here that, once implemented, a business process is a business service by itself. What this means is then a business process may orchestrate single task oriented services and processes – the later being a sub-process to main process.

By now you have got the feeling of kind of work a business analyst and/or business architect should do. The following type of questions needs to be answered at this phase:

• What is the right granularity of a single task (or activity)? For example, should a customer book order handling be a single task or should it be broken into two –say, Check the item availability and Ship the item tasks?
• What are the business processes implied in the requirement and what are the tasks in each process?
• Do you have any logical data model? At least you need to know the input and output data associated with the tasks and processes you identified. This data model is not a physical data model as in database. It is more of high level logical model that is tuned to business terms. I will leave the other important of data – i.e. its semantics – for later discussions.
• What are business exceptions and errors?
• If business error happens, do you require roll-back or compensation?

By answering these and more questions, the business analyst and/or business architect transforms the business requirement use cases, etc. to a business process model using tools. There are various types of business process modeling tools out there and the choice depends on your environment. The main thing to keep in mind in selecting this tool is that it should be standards based for several reasons. SOA development and deployment environments must be standards based for interoperability, reusability, cost, etc… A standard for business process implementations, that is getting more popular, is BPEL (Business Process Execution Language). It is very important that the tool you select interoperates with other development tools via BPEL, WSDL and XSD standards (what I mean by this will be clear shortly).

By using standards based tool, the business activities (tasks) and processes can be modeled easily. If data models (schemas) are available, you should be able to import those schema files into the tool and associate data to the input and output of those elements in the model. If you don’t have pre-agreed upon logical data model, the tool should still allow you create one and then use it in your process model. A good process modeling tool also lets you associate external resources to the model elements and capture more things associated to the process model. It should also let you simulate the process easily.

After completing the business process model, you should be able to export model artifacts in a standard way; so that these artifacts can be imported into other development tools for further service design or service integration. The expected standard model export format should be BPEL, WSDL and XSD files. All process related artifacts are exported to BPEL file. All data schema used in the model is exported to XSD file. All activities specified in the process model are described by their respective WSDL files.

This approach has many benefits:

• The business requirement is captured clearly, verified and passed down to development environment without a loss of meaning or misinterpretation.
• The same data schema (logical data model) can be used in process modeling and service interface design down the road. Developers will not come-up with their data schema during service implementation.
• Business rules are properly defined and integrated into the process model.
• Business errors are pre-identified and the mechanism of handling them is specified. BPEL standard specifies how errors (faults) can be communicated within a process (i.e. Fault handlers).
• If a business requires compensation, this can be captured and integrated in to the model. BPEL standard supports compensation and clearly outlines how to do that association between processes to compensation service (i.e. Compensation handlers).
• The legacy barrier (gap) between business and IT is removed; and things flow smoothly from one to the other. If business requirements change, the IT can quickly respond to that change with less cost and with more efficiency.

Next, I will discuss more on service orchestration and design … stay tuned -J