Grüezi,
In the last entry I explained 3 roles and the way they interact with the Intalio suite. In this entry, I will explain a bit more how the project starts and how the two first roles interact.
The Business Analyst (BA) is a functional specialist. She/he is responsible for creating a process specification. As this specification becomes very complex very rapidly, it is important to adopt an approach that I’ll baptize eXtreme Process Definition (XPD). Like eXtreme Programming, the idea is to make prototypes that are tested and validated very often, adding new functionality very quickly.
From the project management point of view, this corresponds to choosing a life-cycle named “Evolutive Prototyping”, where the previous core functionality is preserved, and new functionality is added; this has as advantage the capacity to always deliver a product, creating an optimal result for everybody at almost any situation (risk, cost, priority can make your project stop, and you always have something to deliver). A number of rules must be adopted, in order to make the evolution towards a final product agile.
The BPMS Designer enable this approach since the Rapid Prototyping of new functions is made possible even for non-technical guys. How? Well, the specification of Business Processes (BPs) is made by the business guys themselves:-O, using a language that is natural to them since it is just like flow diagrams: the Business Process Modeling Notation or BPMN. No programming (Zero Code) is the motto.
Besides the process itself, the BA must also create the screens that users of the system will see when they will interact with it. Of course, a bit of more technical knowledge is required here, but the path to a first prototype screenshot is really fast.
Just imagine, Intalio Designer makes possible to adopt agile methods at affordable or no cost in the Business Process dimension!!
The Process Assembler (PA) is the one that will make this specification ready-to-execute. His first task is to interact with the BA in order to verify the semantics, in what concerns conditional execution, iterations, the selection of one/many parallel paths (fork, rule-based execution, among many others) and for identifying the information required to compute each rule (for the conditions/predicates of each execution path). Next, the definition of contexts is required: sub-processes, transactional contexts, etc.
Concerning the screens for the users, the PA is responsible for adding the constraints that can be applied to the user interaction: the validation is automatic and declarative, only the predicates that should be respected are required.
A very particular duty of the PA is to connect the web-services and other providers to the BP specification. Now, this can be put off since the agile way does not compell the team to make the system fully executable. The most important issue here is to make a good spec. How to choose the good path towards a complete BP? by following the best-practices in the software engineering field, I propose you to do the pretty standard Work-Breadown Structure (WBS):
- first, the normal case, where everything goes OK,
- second, the alternative paths to the normal case, or the processing planned for special cases (starting by the 1-3 most common)
- third, the error cases, i.e. the cases when things go wrong and special measures and even backtracking should be done
The core functionality is generally respectful of Pareto principles: it applies to 60-70% of cases, letting the remaining 20-30% pending. If your BP has a section with more than 3 alternative paths, you may start thinking about isolating it into a sub-process. We’ll see how to do that in the near future.
I’m aware of the fact that the approach as presented here is not necessarily applicable to many cases. I will soon give details about the document-centered approach that is normally required in order to deal with the complexity of exchanges. I will also then describe how the Process Data should be designed. Bis bald!
