BPM reference model - fragment 08 - The flexibility of your BPM system must be explicitly architected

... continued from fragment 07

1.8   The flexibility of your BPM system must be explicitly architected

1.8.1   The hidden cost

The flexibility of a BPM system is a characteristic which can be elusive and difficult to achieve. The main difficulty comes from the fact that, as already mentioned in 1.4, in a process-centric enterprise, the BPM system covers most of the enterprise business system. Hence it inherits most of the existing problems from different parts of the enterprise and adds new problems of collaboration between those parts. Of course, this brings new challenges in reaching the required level of flexibility, as well as new opportunities. Below, we make those challenges explicit and later explain how we address them via a proper architecture.

Our experience shows that the business usually wants separate requests for change in the IT environment to be implemented quickly. These changes are typically small (from the point of view of the business staff) but unpredictable (from the point of view of the IT staff). The current practices of software development have failed to provide a good solution to this challenge. The usual practice is that an IT application is released with a fixed set of business functions, and then it is maintained to accommodate new business and technological needs until the release of the new application at a later date.

It is thus not surprising that [10]

• "80 % of software lifecycle costs occur during the maintenance phase", and
• "80 % of maintenance is due to unmet or unforeseen user requirements; only 20 % is due to bugs or reliability problems".
  

These values were reported in 1992 as an average for the IT industry; the current situation for some enterprises is worse -- the development and deployment of an application can be only 5 % of the total cost of its ownership. What is also disturbing is that these values are not widely known to many people from the IT industry, and IT staff typically estimate these values completely differently (see figure 1.9).

Figure 1.9   Different estimations of the development/maintenance lifecycle cost ratio

Considering the critical role of the IT services in any modern enterprise, it is obvious that an inability of the existing IT environments to implement quickly unexpected requests for change reduces the speed at which the enterprise can carry out its performance improvement. Meanwhile, improving the speed and quality of software development although necessary is not sufficient by itself, because any IT application has to be tested and deployed, data have to be migrated for this new IT application, the users have to be trained to use it efficiently, etc.

1.8.2   Conceptual integrity

Our experience shows that the best way to address this problem is to architect all existing methodologies and IT technologies in such a way that they work together -- there is no magic wand, only the concerted use of different technologies, knowledge and practice around the BPM discipline.

The biggest difficulty is to have a clear understanding of which piece should be taken from which IT tool in a particular case. It is well known that modern IT tools have a lot of overlapping functionality. Also, many IT staff members naturally want to embed/insert/use their favourite IT tool in as many IT solutions as possible. Furthermore, many IT tools offer some customisation to adapt to business needs, and vendors offer to develop a special extension for your need. As a result, the rationale behind many architectural decisions is "we use this tool because we can". Such decisions should be avoided along the lines of the famous "spandex rule" -- "just because you can doesn't mean you should".

In some senses, this is similar to mastering a chess game, which requires an understanding of how to "play" all chess mates in the right direction and in the right sequence. And this is the essence of what this whole book is about.

1.8.3   Collaboration between the business and the IT

In addition to mastering the combination of methods and tools, the internal collaboration between the business and the IT is essential. It is not a secret that in many enterprises there is a lack of good collaboration. We think that our approach for improvement of BPM systems facilitates the step-by-step establishment of trust and helps to minimize (or ideally eliminate) this collaboration gap. In reality, both the business staff and the IT staff work with different views of the same enterprise business system. In a simplified way we can say that the business staff see the enterprise business system as a coherent set of processes which are under the control of the business. Typically these processes constitute the management model. The IT staff see the enterprise business system as a set of IT services which are under the control of the IT system. Typically, these services constitute the implementation.

Convergence of the business and IT views is within reach. The IT world recently "re-discovered" and accepted the notion of services, and so emerged SOA. But IT is still not very comfortable with processes. Also, how processes and services work together has not been clear, and typically both processes and services are "diluted" in existing monolithic applications. This makes the enterprise business system difficult to evolve as changes to program code are often necessary to effect even minor business changes.

The architectural framework presented in this book provides guidelines and patterns for structuring processes and services in such a way that they can be changed easily, without disproportionate efforts and destructive side-effects.

1.8.4   Common understanding among everyone involved

We have observed that improving a BPM system requires a lot of communication with practically everyone within the enterprise, and everyone should be treated as a stakeholder of the BPM system. Each group of stakeholders has different views, different concerns and a different understanding of the BPM system. The different groups of stakeholders are generally the following:

• top managers
• enterprise architects
• business line managers
• process owners
• super-users
• normal users
• project managers
• business analysts
• IT managers
• IT solutions architects
• IT developers
• IT operators

It is necessary to explain to each group of stakeholders how their concerns will be addressed and how their current working practices will be changed for the better (see also 3.3 and 3.4). (This is a typical duty of the chief architect of the BPM system.) Coherent and clear explanations in the business language are vital for the success of a BPM project. Success is not about saying "Yes" to all requests from the "more important" staff members; it is about building a common understanding and agreement between all stakeholders. This book is intended to help you achieve such success by giving some real examples of communication with the business staff (see chapters 3 and 7).

1.8.5   Coordination at the scale of the whole enterprise

Coordination between artefacts is also important because of the high level of complexity of modern enterprise business systems. There is not only static complexity at the design level, but there is a lot of dynamic complexity during the execution (in the same way that the assembly of a car engine from its parts represents a static complexity, but the car also needs to run with a reasonable performance).

Also the modification of enterprise business systems to accommodate typical changes in policies, priorities, technology, laws, etc. necessitates the evolution of some artefacts, and the relationships between them, simultaneously as a complete system. So, it must be easy to modify all artefacts and relationships without causing any negative effects.

The improvement of any BPM system is a difficult task. It is a transformation

from a system of systems that has grown over years under different influences
   to a coherent, smoothly evolving, enterprise business system which is easy to maintain and develop further
      subject to socio-technical aspects, because how you do something is sometimes more important than what you do; 3.3 covers some of the human-related concerns.

Industry experience has demonstrated that the strategic transformation of an enterprise is more effective and efficient if it is based on an agreed architecture, an "enterprise-wide architecture" [or an Enterprise Architecture (EA) as it has come to be known]. EA (14.3.4) is defined as a coherent and proven set of principles, recommendations, practices, and tools which provides guidance and practical help for the design and evolution of IT and business to achieve enterprise vision and strategy. Thus it is basically the actionable master plan for the enterprise; a comprehensive plan for how to build, to use and to evolve all enterprise artefacts (including the data, business processes, business rules and IT assets).

The concept of using EA is old and has always been appealing for enterprises. But there is a wide-spread perception that a large (and useless) amount of paper work has to be prepared before any results can be obtained. We have experience that it does not have to be this way -- if done correctly, the use of EA can bring significant improvements faster, better and less expensively than the use of any other approach.
EA and a BPM system are both enterprise-wide initiatives, and the best results are achieved by using them together -- in chapter 13 we will discuss how to achieve synergy between them.

... to be continued in fragment 09 ...

Thanks,
AS