Currently I am developing software using a BPM Suite. I've found that several practices used in traditional software development remain valuable when using modern BPM suites. Although these suites promise to give business people a tool to support their own business processes themselves, reality shows business people find it hard to cope with the growing complexity of the solution they create themselves. The reason for complexity to grow is obvious: the real world situations the BPM software supports are complex and since the models created in the BPM software are executable, they are likely to become complex too. Although most suites offer support to assess the impact of a change, structure is needed for this to really work. To cope with growing complexity, one has to create overviews and keep a clear structure. Neglecting structure will result in erroneous process support and in badly maintainable assets, ultimately leaving business people with badly supported processes.
Traceability options of a BPM suite showing a navigable diagram with upward and downward traces
When we focus on the created software elements we see that in the end the complexity in delivering a project is not in understanding the tool or programming language itself, but in understanding the structure of what makes up the application: the class structure, the used libraries, the services structure and so on. For delivering a BPM software solution this is not different. The artifacts are a bit different though, we now have process flows, user interfaces, task flows, domain classes etc. It is quite easy to make a mess of these artifacts. To name some good ways to do just that:
In the past I have used quite some tools and programming languages to develop software. What always kept me "alive" is to follow good software engineering practices like keeping focus on ubiquitous language, on maintaining high coherence of assets and low coupling between assets, on continuously refactoring, on domain driven design and so on.
I've found that similar practices are needed to successfully deliver software with a BPM suite. In line with good old programming, `good modeling practices´ are required to maintain a clear structure of the software assets and obtain a maintainable solution that can keep business value for the years to come.
IT personnel are trained in maintaining structure; it is what they like, it is in their genes. For business people structure has not their first focus, and it shouldn’t have, as they should focus on keeping the business run smoothly. So I suppose business people and IT personnel have to walk hand in hand for a little while longer...
Traceability options of a BPM suite showing a navigable diagram with upward and downward traces
When we focus on the created software elements we see that in the end the complexity in delivering a project is not in understanding the tool or programming language itself, but in understanding the structure of what makes up the application: the class structure, the used libraries, the services structure and so on. For delivering a BPM software solution this is not different. The artifacts are a bit different though, we now have process flows, user interfaces, task flows, domain classes etc. It is quite easy to make a mess of these artifacts. To name some good ways to do just that:
- Bad naming of any object makes it hard to be found or reused.
- Unreadable process flows due to large flows or flows on different detail levels make it hard to get an overview of what's going on.
- Domain classes that don't resemble objects in the real world are likely to change often whenever a user makes a new request for functionality.
- Micro flows that don't show the intent are hard to maintain.
In the past I have used quite some tools and programming languages to develop software. What always kept me "alive" is to follow good software engineering practices like keeping focus on ubiquitous language, on maintaining high coherence of assets and low coupling between assets, on continuously refactoring, on domain driven design and so on.
I've found that similar practices are needed to successfully deliver software with a BPM suite. In line with good old programming, `good modeling practices´ are required to maintain a clear structure of the software assets and obtain a maintainable solution that can keep business value for the years to come.
IT personnel are trained in maintaining structure; it is what they like, it is in their genes. For business people structure has not their first focus, and it shouldn’t have, as they should focus on keeping the business run smoothly. So I suppose business people and IT personnel have to walk hand in hand for a little while longer...
