Moore's Law to an end, now what?
In '65, Gordon Moore, founder of Intel, made a prediction. Computer chips double every two years in terms of number of transistors. This prediction has been valid of the past 50 years. Unfortunately is has come to an end. The lines on the chips are now only a few nanometers wide, cannot be smaller. In a few nanometers in width, there are still only 5 to 10 atoms adjacent to each other. Even narrower lines and all kinds of "quantum mechanical" effects are manifest. So computer chips will not become faster / smaller / cheaper as we were used to. What should we do to satisfy our hunger for more affordable technology? We need to be smarter! Does my boiler indeed requires 7 * 24 hours connection to the Internet for only about 10 switches a day? Should all APPs on my phone indeed constantely measure my exact position and my heart rate etc? Probably not. But whether it is necessary has never been considered when designing. There was sufficient computing power anyhow. So what do we do now? Consider under what conditions we need anything. In requirements management is already taken into account; the word "when" in defining a user story. Today, you'll have many user stories without "when". So from now use the "when" so our computers do not get stuck in the future...
Business rules or business processes?
In many companies, employees are busy capturing their operations in "business processes". In defining these you face a few challenges:
• What standard do you use, for example BPMN 2.0
• What drawing tool do you use, Visio or a more sophisticated tool
• Which level of abstract do you choose, descriptive level 1; Level 2 analytical; Level 3 executable
• Will you also record the business rules in the processes, and if so, how
• How do you harmonize the processes across the locations / units / countries / etc
• How do you deal with exceptions
To start with the last point, how to handle exceptions? Often the first draft of a business process is drawn in a workshop. During the workshop a discussion with "yes-but" will occur. In other words, the right process is drawn, unfortunately there are some exceptions. After some discussion and wrangling comes the liberating word: "Let's not model exceptions, but the main process. We aim for a 95% coverage. " For the drawing, this approach is fine, unfortunately for implementation not. The automated systems to support the processes must 'understand' when anything is permissible to deviate from the 95%. Software does not understand this automatically, so there should be clear rules for that. As a result, all transactions will be enforced through the drawn process, or there is a loophole created for the exceptions. When and how the loophole is used is often ambiguous.
There is a solution that always works. Capture the business rules. Business rules can be described as 100% adequate. Just try to write all the rules in an existing process containing a decision. Drawing contain "approved / disapproved." For the approval of products, the rules could be:
• Temperature between 2 and 5 ° C
• Weight per bag between 10.0 and 10.5 kg
• Label scannable
• Packaging damage
• Etc
If one of the criteria is not satisfactory, it is clear that the process cannot continue. That is clear to everyone, and you do not draw complicated loops in the process.
In short, in order to successfully execute a change, drawing of a process is not enough. It is also essential to capture all business rules. Capturing these rules should be done by the business itself, and not by ICT. ICT should make the translation into software systems, but do not have to write the rules. Practice shows that companies that establish their rules well in advance, are 25% faster in the project implementation and reduce cost of failure with 20%!