October 5, 2010 by huionn
In software development, there are two types of complexities – essential complexity and accidental complexity.
Essential complexity refers to a situation where all reasonable solutions to a problem must be complicated (and possibly confusing) because the "simple" solutions would not adequately solve the problem. It stands in contrast to accidental complexity, which arises purely from mismatches in the particular choice of tools and methods applied in the solution.
Accidental complexity is complexity that arises in computer programs or their development process (computer programming) which is non-essential to the problem to be solved. While essential complexity is inherent and unavoidable, accidental complexity is caused by the approach chosen to solve the problem.
One of the causes of accidental complexity is coupling.
coupling or dependency is the degree to which each program module relies on each one of the other modules.
There are two type of coupling: intentional coupling and accidental coupling.
Accidental coupling is bad and need to be eliminated. We can achieve loose coupling through event-driven architecture (EDA), messaging, SOA (for large and complicated systems) etc. One example I can think of is that during sales fulfillment, the stock quantity fall below reorder level. A low_stock_level event is raised. Procurement module which subscribes to this event will start its procurement process. Procurement module is independent of Sales Fulfillment module and it won’t care who raise the low_stock_level event.
On the other hands, intentional coupling is considered as good coupling and it improve the understanding on the system. For example, in sales fulfillment, customer account need to be verified and updated, stock quantity need to be reduced, etc. These processes are important to business and must be well defined. However, how to model the processes in comprehensible way?
In my opinion, intentional coupling should be shown declaratively. One way to achieve this is through business process modeling (such as BPMN). The declarative nature of BPMN diagram emphasizes on what to do instead of how to do. In addition, it is self-documented. Human are better to grasp information from diagrams than words.
In spite of its benefits, BPM is technically complex and relatively new in Malaysia. I am going to experiment it on a small POC project with basic BPMN features and determine the future plan based on its result…
Ordering and delivering pizza business process from BPMN 2.0 by Example – OMG