In his article Demo vs. Production BPM-based Systems Anatoly Belychook sounds a warning that the habit of BPMS solution vendors of presenting their suite as a complete application development solution through 'demo' applications can lead to serious problems for users when they try to product ionise even a single process. I have quoted Anatoly's points in full and annotated them with my thoughts.
- The user portal - web application that starts processes, displays the list of tasks assigned to the user, manage activity forms for these tasks, monitors and administers processes. It will have different design in production and most likely different functionality too. If you’re lucky you will be able to customize out-of-the-box portal but be prepared to rewrite it from scratch at some point. Or to get away from a standalone BPM portal completely and wire process functionality into corporate applications. The reason: users typically do not accept BPMS supplier’s opinion that BPM should be the center of user’s universe. How true. It may be unfair to label the provision of a BPMS-centric portal or application as a fault or failure of the manufacturer ... it would be very hard to sell the product without being able to show an end-end model of implementation. The real failure is for the BPMS solutions to be presented without any clear directions of how they fit into common enterprise technical architectures and then black-boxing the behaviours of the BPMS.
- In particular, you should eventually get rid of “start process” button. From user’s perspective, he doesn’t “start a process” but do something real e.g. accepts the incoming order or submits a request for vacation. The system must start the appropriate process transparently. Insightful ... just like the rest of the IT/IS components the BPMS is a tool that transparently handles a bit of business communication there is no need to bring the terms of bpms (message, process, instance ...) into the end user lexicon.
- Be prepared that activity forms generated by BPMS in few mouse clicks will no longer meet the functionality, usability and design requirements at some point. So it’s better to have an idea how will you eventually develop these forms in terms of tools, labor force and
costs. The importance of this issue can not be overestimated: what good is that the process scheme is depicted in two days if forms development for this process then takes say two months? (I do not play down the importance of rapid prototyping of screen interfaces - it’s the must for BPM, one won’t even come close to production without it.) By the way you probably would like to use the same tools to rewrite the BPM portal. BPMS implementations do not spring into a virgin site, consider how the enterprise views its technical architecture. Perhaps the architecture is layered, with presentation separate from the 'application code' or 'business service" . Then you will want to devise your working surface around the user actions and communicate with the BPMS with messages at the appropriate point. Of course, those messages may contain standard (within the enterprise) objects so choosing a BPMS that forces definition of the message from a form layout will not be a good idea. - Similarly you will no longer be satisfied with out-of-the-box reporting and monitoring tools at some point. Remember that this is about business requirements and a fancy dashboard updated every second showing messages per second by type is not useful beyond the server room. First catch your business requirement, then match it to the offering of the supplier. The most likely solutions will be found in generic reporting mechanisms but you will need to understand the operation of the BPMS to integrate its information about queues, instances in progress etc with information from other enterprise sources (stock on hand etc).
- Demo and pilot processes typically store all data in process attributes, process variables or operands (different systems use different terminology) but only relatively insufficient and/or temporary information will be stored this way in production. Most data will go into a traditional database and only the primary key of the corresponding record will be stored within the process. Considering the process of client purchase order negotiation as an example, the information about the client and the order items are likely to be stored in a database while customer and order identifiers will remain in process attributes together with the deadline date for the call to the client. The reason to act this way is obvious: data which may be of interest after the process instance has ended must be stored so that
they could be accessed independently from the process instance. This also means a separate user interface to this data independent from process screen forms. As for the process screen forms, they should access both process attributes via BPMS API and database fields via DBMS API. This actually requires some significant design consideration. In general, a process is a long running and non-ACID transaction. There may be instances where the information in the process instance represents a (useful) past state of data in a corporate database. - Building on the previous item, most likely the part of the long-term information (but usually not all) already have a room at your existing enterprise applications. Accordingly, the process attributes will store only the identifiers of the appropriate business objects and
process screen forms will access the data stored within the application. (The latter isn’t an absolute requirement - the total integration is often very time-consuming so partial integration may be more justified.) - Similarly, while a demo or pilot most likely will store related documents (usually Word or Excel files) as attachments to a process instance, you’ll have to consider something more solid for production. The reason is the same: if the document may be of interest after the
process instance has ended, then it must be kept independently from the process instances and user access to it must be provided independently from the user interface to the process. However you don’t need the full-blown ECM system: because BPMS takes care about the workflow you need only documents storage functionality with basic interfaces (user’s and programming) and services (search, archiving, security). If you are considering technical architecture components as a whole you have the opportunity of avoiding top-end document management systems which might be chosen for their version control and workflow capabilities because these can be realised in the generic BPMS toolset. However, just because a document management system has workflow capabilities, assuming that every process can be managed through its documents will provide worse problems than assuming that a BPMS suite can generate all the business application solutions. - Users authentication and authorization in a demo or pilot is usually done via independent LDAP directory, database or even a static list stored in the XML file. It is obvious that production system should utilize your existing user directory. But a bad surprise may be
the amount of effort it requires. To start with there are usually several such directories. A typical example: an Active Directory, a separate authorization system within the legacy accounting system and a database keeping the users of remote offices and partner companies. As the project evolves additional requirements may arise e.g. the planned
absence and automatic rerouting of the tasks. It is known that for a company having about a hundred of users Active Directory implementation alone is a non-trivial project and now we are facing more difficult task. As a result as much as 50% of total BPM project costs are spent on authorization and authentication issues at some projects. Imagine for a moment that it happened in your project and you didn’t take it into account in project schedule: you are out of schedule and budget for as much as 100%! The bottom line here is that the BPMS should be considered in terms of the ease or difficulty to implement within a separately chosen Identification and Authentication solution. As the world does not stand still the interfaces for authorization and authentication should be expressed in terms of standards rather than supported products. - For obvious reasons not the most complex business processes are taken for demos and pilot projects. That would be all right but worse than that, they are usually technically implemented as a single process thread. But in reality even the relatively simple employee onboarding process technically consists of several processes communicating with
each other (it’s enough to notice that processing the incoming resumes is not directly related to the publication of vacancies). This is even more true for end-to-end processes that are of greatest interest in terms of business (see “End-to-end Process Orchestration” antipattern and “Internal Order” pattern). Accordingly, you will need more functionality from your BPMS pretty soon - not only the orchestration but also choreography. Modern BPMS are fine with that but if a rudimentary workflow and/or document management built into your accounting system is all you have then you may be in trouble. - And finally, a production system differs from a pilot by reliability, performance, security … but these are standard requirements not specific to BPM. Failures of the BPMS service and the infrastructure that support it have to be handled in the same way as any other operational service (separately from failures of the business process). Recovery from failure is complicated because the state of database that supports the BPMS operation is generally not synchronised other corporate databases and certainly not with invoked services.
