How to approach an SOA project

Service Oriented Architecture is all about business processing. How is the current/future business process is defined? What are the rules within this process? What is the input and the output of the process. How are will the business process act when in some particular stage a failure occurs. For example, the customer does not pay, the partner does not deliver the goods, the product is out of stock or some technical issues occurs; the netwrok is down, database crashes and many many more.

To implement a business process into a Service Oriented Architecture is not different before SOA did not exists. All the information flows, business flows , exceptions should be described in detail. This is what we still call the functional design. While we normally describe this in one or more documents, we should now focus more on process diagrams and data flows. An image says more than thousand words.

Drawing business process with their information flows make the process more transparent and the communication to the customer more clear. Drawings are easily to change, in case new functionality is added or flows should be combined to make the process more efficient.

A functional process flow diagram should the describe the whole process including the exceptions. After the functional process flow diagram a design will be made of the process. This means that the business process could be split in one ore more other processes. In practice it will result in many processes.

These small processes can be split up again in two different flavors, processes that are related to functional business process and processes that are more technical. Examples of functional processes are "collect products for shipping", "select customers who did not pay their order". Technical processes are for example; "send customer an notification", "update the order status for a customer".

Technical processes should not be exposed to the outside world. They are not meant to be called as a reusable service. These processes will not cover the business rules from their parent processes.

The functional processes can marked for being reused in the business process itself, but can also be exposed to other processes in the organization or third parties.

To summarize:

• Define the functional process with all the incoming and outgoing information flows.
• Define all internal information flows.
• Described the content of the flows.
• Describe the type of flows.
• Split the functional processes into smaller processes.
• For each smaller process, described also the previous steps.
• Define which of the smaller processes can be reused.
• Define for each smaller process the technical processes needed.

Regards,

Marc Kelderman
Technical Architect
http://orasoa.blogspot.com