Personal tools
You are here: Home Book Introduction


Whether you are a business owner, a chief officer, or an enterprise or business architect, you are faced with a fundamental challenge, that of how to make an enterprise more competitive. There are three main factors which contribute to this challenge.

  • The first is that IT systems are typically old-fashioned environments based on yesterday’s needs; they are not well adapted to (or adaptable for) the needs of the modern quickly-changing world.
  • The second is that enterprise business process management (BPM) systems are usually the result of evolution of the parts rather than of the whole, and are therefore often complex, chaotic and inefficient.
  • The third is the current speed of evolution of IT systems, which often constitutes a major obstacle for the advancement of business.

One approach to this challenge is to streamline the critical business processes of the enterprise by automating their management, eliminating work which does not add value, integrating existing applications around the business needs and evolving information systems in an architected and coordinated manner. But how can such ideas be implemented within existing disparate and complex IT systems, within the day-to-day operations, and at the same time targeting the whole company and its partners?

With all this complexity, it is not obvious how and where to start significant improvements such as modernisation of enterprise systems, simplification of business processes and unification of the IT environment. It is necessary to be pragmatic and to use technology to solve problems expediently; not to play architecture astronaut, building technology for technology's sake.

We approach this complex challenge by using an architectural framework for improving enterprise BPM systems. The architectural framework combines the business and IT aspects to provide a coherent approach for the implementation of the enterprise’s systems development. Our goal is to build a city in accordance with a city master plan, and not just to add a few buildings. The architectural framework uses a systemic approach for constructing this “city” in such a way that it is highly adaptable for practically all organisational aspects: policies; priorities; existing data; IT systems; business processes; differing sizes of the problems to be addressed; available budgets; culture; etc.

This architectural framework is not about how to make your products better, different and more attractive for the market place – this is for you to decide. What we offer is to help you reduce the overheads in doing so – your flexible BPM system will become an enabler for your business innovations.

The main obstacle to overcome is the existing gap between the business needs and the IT needs. It is rooted in the current duality that exists between the two: the business needs an approximate qualitative description, whereas an IT implementation needs an exact quantitative description. These two descriptions do not have a perfect fit, are often prone to “translation” errors and evolve at different speeds.

In our approach, to eliminate the gap, these two descriptions are considered to be just different views, with different levels of detail, of the same thing. So, the solution lies in the architecting, designing, and engineering of business processes in such a way that they are at the same time a management model for the business and an implementation for the IT. In this case they will be easy to validate and easy to evolve.

This book comprises four parts which are written for a slightly different audience. The first part (chapters 1 and 2) introduces the architectural framework – the issues addressed by it, its models and the results achieved using it. This part covers mainly “soft” issues which are normally discussed amongst the management and decision-making people, and is a prerequisite for the second to fourth parts (each of which can be read separately, although we hope that the reader will be stimulated sufficiently by the information contained in one part to read the other parts also).

The second part (chapters 3 to 5) covers the architecting of different aspects of BPM systems – these different aspects are necessary to understand a particular situation at a particular enterprise and to adapt the architectural framework to a particular case. This part is designed for people who will themselves architect BPM systems as the chief architect. In our vision, these people should be able to talk comfortably with both the business staff and the IT staff. The commonest challenge in both cases is to understand many specific details and to explain to different stakeholders how a BPM system will address these details.

The third part (chapters 6 to 9) addresses mainly business process modelling issues, including a set of guidelines for developing implementable business processes by modelling them as executable processes. We use the Intalio BPM suite to illustrate and implement business processes. This part is designed for people who are business process architects and business process engineers (we consider these roles to be the natural evolution of the traditional business analyst role towards BPM).

The fourth part (chapters 10 to 13) addresses mainly technical issues, including recommendations on how to implement BPM systems which are easy to evolve. This is one of the most important but least visible features of this architectural framework – ensuring flexibility of delivered BPM systems. This part is designed for enterprise architects enterprise solutions architects and solutions architects.

Since this book is aimed at people performing different roles it may be difficult at first sight to understand the connection between the various recommendations. In some senses this is unavoidable as the subject matter is not only complex but covers a range of disciplines which until now have not been collected together under a single approach. But do not be put off! In the same way that an inexperienced chess player can learn by watching a complex chess game, you will hopefully learn (and increase your rating) by reading this book.

This book is the product of about ten years of experience of the author in different businesses. Almost everything in this book is the result of different work experiences and discussions with many different people. For this reason, the author frequently uses “we” in the recommendations to acknowledge the contribution of his former colleagues.

Further information related to this book (examples, explanations, etc.) is available at

Document Actions