#BPM to reduce IT #complexity

Thanks to the works of Roger Sessions (@RSessions) we know that modern IT systems are very complex and, in general, their complexity should be reduced. Of course, we want to decrease the undesired complexity and better manage the required complexity, as IT systems have to solve more and more complex business problems.

The complexity can be estimated as a function of the number of components (parts of the system) and the number of relationships between them. In the worth case scenario, each component to connected to all others and the complexity has the exponential growth – N x (N-1)/2, where N is the number of components. Often, in a real IT system, it is just impossible to evaluate exactly the number of relationships, because some of them are implicit.

Let us show how BPM (which is a trio of discipline, architecture/practice and BPM suite COTS) reduces the IT complexity. From two detailed blogposts “BPM for developers” http://www.slideshare.net/samarin/bpm-for-developers and “BPM for business analysts” http://improving-bpm-systems.blogspot.ch/2013/07/bpm-for-business-analysist-modelling.html we need the following architectural considerations.

1) In BPM, processes are explicit and executable relationships between many other artefacts: events, services, rules, roles, data, documents, audit trails, KPIs, etc.

2) Processes and services are related in recursive way:

• all our processes are services,
• some operations of a service can be implemented as a process, and
• a process includes services in its implementation.

3) BPM architecture comes with a systematic modelling procedure to identify related artefacts and the latter are implemented (or wrapped) as services.

From those architectural considerations, the use of BPM is:

a) reducing the number of components as the modelling procedure helps different people find similar artefacts in similar situations thus increasing the re-usability;

b) making all relationships explicit as all processes are explicit and executable thus helping to control the number of relationships (typical monolith applications are becoming coordinated sets of services - http://improving-bpm-systems.blogspot.ch/2013/06/enterprise-patterns-eclipse.html), and

c) reducing the number of relationships as within a process, the number of relationships is proportional to N-1, where N is the number of its components (i.e. artefacts) because all except 1 are connected only to the process (also an artefact).

There are also other benefits to use of BPM:

d) BPM penetrates 2,5 levels of the enterprise architecture (business, application, data, technology) and becomes a business-system-forming factor. This considerable simplifies the implementation of agile and flexible business systems (see http://improving-bpm-systems.blogspot.ch/2011/04/enterprise-patterns-peas.html and http://improving-bpm-systems.blogspot.ch/search/label/PEAS).

e) BPM can address some concerns of the information security – see http://improving-bpm-systems.blogspot.ch/2013/10/bpm-enables-cibersecurity-because.html

Thanks,
AS