How Granular Should My Microprocesses Be? By Jan Kettenis
Blog: PaaS Community
As with all modularization principles, finding the right granularity is not always trivial and the more important. Some of us have seen complete projects fail because of getting this wrong. The Microprocess Architecture is no exception to this rule and in the following I discuss this topic, hoping to guide you in getting it right.
As explained in the article introducing the Microprocess Architecture the rationale for applying it consists of a combination of reducing impact when implementing new features and bug fixes, ease applying them to an already deployed business process, supporting parallel development and few others. Said differently and in one word: agility.
To correct the mistake made in the introducing article of not defining what a microprocess stands for:
A microprocess is a subprocess of a larger business process, where the subprocess spans the execution of one or more activities to reach a business significant state change of the business process, and which can be developed and deployed as a stand-alone component.
This definition implies that the scope of a microprocess has business visibility. However, as such that does not yet clarify the right granularity. Too course-grained and there is a risk of not delivering on the core value of agility, too fine-grained and you risk issues with performance and scalability.
So, what is the right granularity? First let me try to illustrate by example. I then capture some of the main characteristics that should give you guidance on how to apply it for your use case.
Order handling example
An order handling process of a bank, that starts with a customer submitting an order form and ends with invoking one or more back-end systems to handle the delivery, could consist of the following microprocesses: Read the complete article here.
For regular information on Oracle PaaS become a member in the PaaS (Integration & Process) Partner Community please register here.