As I have mentioned in many posts before, SOA built right can provide business agility and flexibility. Yesterday I discussed how to leverage data services and a few days back I discussed enterprise mashups. Today the focus is on business processes. 
Separating business processes from code is an ideal way to build an architecture that enables systems to adapt more readily to change. Let's make believe that we are working for a large eCommerce site that sells many different categories of products from multiple suppliers and warehouses each with their own distinct business processes. Abstracting the business processes gives us some very important advantages:
- Creates a set of standard business processes for a consistent user experience
- Allows us to quickly bring on additional suppliers
- Allows us to change a core business process once and apply it to all suppliers
- Allows the business to make modifications to its processes with minimal or even no coding
This work flow speaks to my first point "Creates a set of standard business processes for a consistent user experience". The complexities of working with multiple suppliers, each with their own processes and systems is hidden from the end user. Regardless of what products the customer is buying and which supplier is fulfilling the order, the user experience is exactly the same. On the other side of the equation, bringing on a new supplier can be as simple as collaborating on a set of services to integrate the supplier's back end system to the core business processes of the eCommerce site. Had we not separated the business processes from the code, we would have to make modifications to our existing code base which is already running in production and would have to go through a complete testing cycle. Instead, we simply tell the business processes which set of new services to integrate with for the new supplier. All of the existing code is not impacted and does not need to be retested. Instead, we can just validate the new services and the new supplier flow.
Here is another benefit. Let's say that we just signed agreements with three new suppliers and have contracted to launch them all in 4 weeks. Without the separation of business processes from code, all three supplier integration efforts would have to be coordinated and most likely bundled into one build. This creates huge project risks because slippage in any one integration effort can delay all three. By separating the business processes from the code, each supplier integration can be implemented whenever it is ready. We can stub out a call for each supplier and assign the appropriate WSDL when the services are completed. For example, the "Fulfill Order" process could be an integration with SAP for supplier 1, PeopleSoft for supplier 2, a custom built fulfillment process written in Java for supplier 3, and a custom built fulfillment system written in .Net for supplier 4. The business and the business processes have no need to be concerned with the technologies behind the fulfillment process. They are only concerned with the inputs, the outputs, and the quality of service (QoS).
As we move up the stack it gets even better! Next post I will discuss the importance of business rules. Stay tuned.
