My comments on this article are based on my experience as an seasoned IT specialist; they are also expressed in my forthcoming book “Improving business process management systems” (see http://www.improving-bpm-systems.com/)
My years of experience as a provider of IT solutions for complex business problems has created a firm belief that we need executable business processes that can be developed and maintained by the business people (the people who are close to the business).
Let's start from the principal that all enterprises have their own BPM system to help the management to run the enterprise, and most enterprises want to improve their BPM systems. The problem is often that current BPM systems are complex, a “problem” of their history, chaotic, and inefficient. To approach such an enterprise-wide challenge, we need a coherent set (or architectural framework) of rules, models, and recommendations of how to implement flexible enterprise-wide BPM systems with existing software tools, including current BPM suites, SOA, ECM, BR, BI, EA and IT governance.
The implementation of a flexible enterprise-wide BPM system is obviously a collaborative work, because this system has many stakeholders: top managers, line managers, super-users, users, modelers of business processes/business analysts, IT managers, IT architects, IT developers, and IT operators.
The interests and concerns of each type of stakeholder need to be taken into account – for this reason an architectural framework should be used to "explain" to each stakeholder
- how the BPM system will address his/her concerns, and
- how the BPM system will change for the better his/her daily working practices.
I have developed my own architectural framework to address these issues for improving BPM systems, and will explain in detail below how it addresses each of the "seven fallacies".
Fallacy #1: Business analysts model their processes from a systems' point of view
This is a popular assumption by IT developers and is not a “defect” of BPM. Of course, business analysts need to express the flow of both manual and automated business activities since this is extremely valuable information (and is also essential from a quality management perspective). Furthermore, it is essential to express such information formally and to validate it.
<quote>
At most, the business analyst's understanding of a system is a screen which really amount to an electronic version of a paper form (to view or enter information).
</quote>
I witnessed a difficult BPM project in which the business analysts were obliged by the IT to provide use cases in place of business processes. Later in the project we had to restore (or reverse-engineer) the actual business processes from these use cases!
Fallacy #2: Business users can easily learn BPMN and use all its features.
I know of a number of cases where the business users easily learnt BPMN to great effect. We did not try to teach the users all features; rather we prepared a number of recommendations (a diagramming style, several practical patterns, a list of artefacts to be collected, and a modeling procedure) for working with BPMN, and thus empowered them to use BPMN to model their business processes.
My experience shows that many of the existing standards are too “rich” (maybe this is a side effect of consensus building).
Fallacy #3: Business analysts should be able to create executable solutions from process models
I would add “to some extent”. The goal is to help business analysts to model executable business processes as part of a joint work to develop implementable business processes. So we want to have a formal and validated description of the business process. Usually, business analysts create an executable model/prototype/skeleton (with testing scenarios) which is to be instrumented later with real services by the IT. This may be achieved in a few iterations.
I think the problem is not a "general purpose engine", but rather a proper architecture which guarantees the flexibility of the solution and an agile approach for its implementation.
Fallacy #4: If we add a magical BPMS that create solutions directly from business analysts inputs we would not need to develop any of integration with existing systems nor to change existing systems of record nor to do any QA.
I agree, and I think that this is just marketing talk. I think that modern BPM suites are very good, but don't forget that they are just one of the tools to be used along with other tools. (When I started playing chess I used mainly the queen; later I learnt how to use all the chess pieces together.)
Fallacy #5: Business Process Execution must be centralized
I agree with the author that business processes are just services which transform (by adding value) input to output. Usually these inputs and outputs are parts of the process “work package” which comprises many business objects. So, we have to ask the business analyst to think about the transformation of these business objects – similar to the production of a physical object (e.g. cut the wood, make a hole, glue the pieces, etc.).
A properly trained business analyst should produce a BPMN diagram (see below) which is different from figure 5 and very close to figure 4.
The use of colours for BPMN constructions is as follows:
- brown (or orange) – orchestration or execution-related gateways, events and activities;
- cyan – important events, e.g. start and finish, and check-points;
- blue – automated activities;
- green – human intellectual activities;
- yellow – human validation activities;
- red – human administrative activities;
- grey – groups or activities of undefined / mixed nature.
It's like magic – with a BPM suite and good modeling practices, a business analyst can produce a service (implemented via a process) which is similar to an IT composite application! Of course, the process work package is full of dummy business objects and it is passed to dummy services. But the skeleton of the process is validated and the IT can enhance this process further (business objects, real services) without changing its skeleton.
All business logic and all business objects (their internal life-cycle) are outside this process, so no BPEL tweaking is necessary – it's only necessary to change the services which are coordinated by this business process. Some of these services can be also implemented as processes in BPEL with the use of SCA and SDO or as state machines.
It is well-known that direct accessing to low-level interfaces, e.g. CRUD, from business processes is not the way to do BPM. I recommend (see the figure below and http://www.improving-bpm-systems.com/pubs/article-ebizq-AS.pdf) to use two extra layers between the business process execution and data access.
Fallacy #6: Business Process Execution semantics can be derived easily from existing programming concepts
The business world understood a long time ago (see, for example, the numerous articles on Business Process Re-engineering, and Quality Management Systems) that processes and services are the backbones for most business systems. The IT world recently “re-discovered” and accepted the notion of services, and so emerged SOA. I think, that IT is still not very comfortable with processes – in particularly, how processes and services work together.
Typically, both processes and services are “diluted” in existing monolithic applications. This makes the business difficult to evolve – changes to program code are often necessary to effect even minor business system changes. To achieve very high flexibility in the business system we want processes and services to be separated, versionable and composable, i.e. easy-to-evolve artefacts.
We observed that processes and services relate to each other in the same way that in physics light is both a particle and a wave at the same time:
- any process can be a service and
- most services can be implemented as processes.
As a result the business system is a complex dynamic mixture of processes and services. The composition and the structure of this mixture are unique for each enterprise, but the structures share hierarchical, multi-layer and fractal characteristics (or patterns).
Fallacy #7: Bruce Silver concludes his post by saying that "the collaborative implementation paradigm, in which executable design is layered on top of the BPMN model, is the way to go."
I agree with Bruce. I employed a similar approach (although BPMN did not exist yet) to build a production system comprising about 3 000 complex products per year, 50 persons, about 50 different tasks, 3 production chains, 6 repositories, and 40 IT services. The system has been in place for a number of years, and the maintenance and evolution of this production system required considerably less resources than "usual". Furthermore, several successful (and easy to do) migrations were undertaken.
This system also satisfied to the four requirements for <quote>Composite Solution</quote> (maybe without words “six sigma”).
The result (see the figure below) is that the Total Cost of Ownership (TCO) for flexible BPM solutions is much less than that for traditional IT solutions (considering that 80 % of software life cycle costs occur during the post-release maintenance phase and 80 % of necessary maintenance is due to unmet or unforeseen user requirements). Of course, to guarantee future flexibility it is necessary to expend additional effort in order to learn how to build flexible systems, but this extra effort more than pays for itself in the long run.
Thanks,
AS
Posts
