Information Technology Reference
In-Depth Information
Scalability considerations
Scalability is something to always consider when defining the internal components of a
BPMS, mainly because it will be used or evolved into middleware that will later on be used
by several other applications in our company, usually exceeding the initially defined re-
quirement for the application. Even if you use it from your applications, the more you end
up needing management in your BPM cycle, the more you need your processes to exist in
an isolated, reusable environment where said life cycle is more controlled and configurable.
Once you reach this plateau where all your processes are managed through a common BPM
system, you will feel the weight of many projects depending on the BPMS. Every applica-
tion that needs to define a process execution and dynamic knowledge creation will at least
consider the possibility of using the BPMS you will be defining now. You need to find a
way to manage an ever growing demand for environment capacity.
Not only this, but also because of the dynamic nature of defining correlations between ap-
plications, the BPMS will have a responsibility to become an application coordinator. This
would put a BPM system in two complex situations: at one side, it should be prepared to
handle multiple requests, and at the same time, it should be able to quickly distribute them
among many other applications without losing performance. This can be quite challenging
if special considerations are not made in advance. The following correlation diagram, re-
gardless of a good management, could transform a BPM system into a bottleneck in the
overall enterprise architecture:
