BPMS in production environment

I couldn’t find a better topic than “BPMS (Activos 6.1) in production” to close up the whole series.
Although  ActiveVOS is certainly a cool product there is as usual a space for future improvements. Production environment is something special and as something special it should be treated. If the production environment is down there is simply no business. Empowering the business is the main objective of BPMS, isn’t it? So technology should be ready to cope with that kind of situations. To cut a long story short. Every feature which supports maintainability, reliability, security and sustainability in day-to-day life is highly appreciated.
During the development life-cycle it can be hard (especially in the early stage of the development) to foresee  how the system will be maintained, what the standard procedures looks like, etc. The goal is to mitigate the probability of a process, human or a technical error as low as possible  taking into consideration an ease of problem detection as well.
The following pieces of functionality were found as highly desirable. Some of them are possible to avoid or at least lower the impact  during the design time. For the rest of them some developers’ effort need to be taken into consideration.
  • Different modes of Console – there are no distinct modes neither for development nor production environment. This comes in handy when you need to grant an access to operations for their  day-to-day routine and you don’t wanna let them modify all server settings. For example you just wanna restrict the permission to deploy new processes, start and stop services.
  • Reliable fall over – maybe this question is more on the side of infrastructure. As BPMS fully lives in a DB typical solution consists of cloning a production DB to a backup DB instance. In case of a failure, this instance is started.  If some kind of inconsistency gets into the DB during the crash of a main instance then it is immediately replicated to a backup instance. Does it make sense to start a backup instance?
  • Lack of data archive  procedures – the solution itself doesn’t offer any procedure how to archive completed processes. Because of legal restrictions specific to business domain you are working in you cannot simply delete completed processes.  As your DB grow in size  the response time of BPMS grows as well. You can easily get into trouble with time-out policy. Data growth 200GB per month is feasible. You cannot simply work this problem out by using some advanced features of the underlaying DB like partitioning because you wanna have processes which logically belongs together in one archive. You will be struggling to find out  such a partitioning criteria which could be used in practice and fulfills mentioned requirement.
  • Process upgrade – one of the killer features,  process migration of already running processes to an upgraded version works only in case of small changes of  the process. More over what if your process consumes an external WS which lives completely on its own? What if someone enhance that service and modify that interface? Yea, versioning of the interfaces comes to attention. Having process upgrade feature without versioned interfaces is almost nonsense or at least need a special attention while releasing. Even with versioned interfaces it is not applicable in all situations, eg. sending new data field which presence in the system is not guaranteed.  In large companies this feature is a must. Otherwise it is hard to manage and coordinate all the releases of all connected application.
  • Consider product road map – actually this item belongs to project planning phase where we make decisions about what technology to use. In some environment like banking, insurance etc. there can be legal requirements to have all products from production environment supported by a vendor. If the vendor’s release strategy is a new major version every half a year and support scope is current major version plus two major back than this could pose a problem for a product maintenance team during product life cycle. Migration of all non terminated processes may not be a trivial thing and as such this represents an extra cost.