Book Image

Business Process Driven SOA using BPMN and BPEL

5 (1)
Book Image

Business Process Driven SOA using BPMN and BPEL

5 (1)

Overview of this book

Table of Contents (13 chapters)
Business Process Driven SOA using BPMN and BPEL
Credits
Foreword
About the Authors
About the Reviewer
Preface
Index

SOA Approach to Business Processes


The SOA approach differs considerably from traditional approaches, although this may not be obvious at first sight.

SOA introduces technologies and languages that reduce the semantic gap between the business processes (pictures) and the actual applications (code). Particularly important here are BPMN, which is used for modeling business processes, and BPEL, which is used for the execution of business processes. With these two technologies, plus some additional ones (which we will mention later in this chapter), SOA provides:

  • A language—BPEL—for direct execution of business processes

  • Round-trip mapping between the process models in BPMN, and their executable representation in BPEL

With this, SOA considerably reduces the semantic gap between the business processes and application systems. BPMN enables us to draw the representation of a business process, which is then mapped into the executable BPEL code, and executed directly on the SOA platform.

The other major difference in SOA, as compared to the traditional BPM, is the approach to business process automation. SOA takes a path different from the traditional approach which was based on the "big bang" approach, where processes were first modeled, then optimized, and finally the application software was rewritten to support the new processes. SOA has learned from the major mistakes of the traditional BPM approach:

  • Modeling of business processes has taken too long and has not been done in enough detail. Therefore, the business models have not been accurate enough, were usually without exceptional scenarios, and have been a little out of date.

  • The optimization has been done "in the heads" of the analysts. Although optimizations looked good on the model, there has been no proof that they would work in the real world.

  • As there has been no evidence that the optimizations are acceptable, the modifications in the software, which had to be done in order to support the optimizations, have not been justified enough.

  • Finally, the introduction of new optimized processes, together with the modified application software, has often represented a huge change in the operations procedures. This has resulted in changes in the behavior of employees. Such changes, particularly if they have been huge, have often met with resistance from at least a few employees, which ensured that the fragile model did not work anymore.

Major Improvements in the SOA Approach

These are the three major lessons SOA has learned:

  • Business processes are so complex that we could approach them all over.

  • Business processes are too valuable to a company to be merely optimized "on paper" (even if there has been support from tools that enable simulation).

  • Changes in business processes are not simple and particular attention has to be paid to the fact that changes in business processes require changes in people's behavior.

Note

People do not like to change their behavior. Changes to business processes require that people change their behavior. Therefore, the human aspect of process optimization must never be underestimated.

The SOA approach to business process automation therefore relies on the process-by-process approach:

  • First, we identify the business process that we would like to automate. Here, we focus on the business value of the process, the visibility, and other factors. We also asses the real value of process automation and possible optimizations.

  • Then, we model the process. Here we use a visual notation. In this book, we will explain why it makes sense to use BPMN while modeling business processes for SOA. The process modeling for SOA has to be done in detail. It is important that we model the process in detail so that we identify individual activities that are atomic from the perspective of execution. It is also important that we model the exceptional scenarios.

    Note

    Exceptional scenarios define how the process behaves when something goes wrong. In the real world, business processes can go wrong. Therefore, it is important to model processes so that they can react to exceptional situations and recover appropriately. Modeling exceptional scenarios may be even more complex than modeling the regular process flow.

  • Next, we automate the process as it is, without any major modifications. In SOA, this requires mapping the BPMN process model into the executable representation in BPEL, and connecting the BPEL process with partner links, that is, with services. In other words, it is required that we relate process activities to the various services. This step is best carried out if we have a portfolio of existing services that are re-usable and in conformance to other SOA characteristics (which we will describe later in this section). If we do not have existing services, we will also need to implement the services, where we have three options:

    • To implement new services

    • To expose the business logic from existing applications

    • To use user tasks to delegate the activities to employees, and possibly automate these tasks in the future

  • Once we automate the process, we will take up process optimization.

    Note

    The SOA approach to process automation is a step-by-step approach. This is possible, because SOA considerably reduces the development time and complexity, and allows changes to the existing processes to be done quickly and efficiently.

  • The step-by-step approach to optimization is much more efficient and friendly to the people involved in the processes. We have already mentioned that people do not like to change their behavior. Therefore, it is much wiser to implement changes in phases. This is sometimes called the evolutionary approach to business process optimization.

  • The SOA approach has another important advantage. As we have automated the process (as described in bullet three), we can obtain some measurements about the different process activities, and how long in average they need to execute. Such quantitative metrics, which are calculated automatically by modern SOA platforms, can provide valuable information that can be used to decide where to start process optimization: we can focus on activities where we can gain the largest improvements. Gathering quantitative data about process activities is called Business Activity Monitoring (BAM).

Note

BAM, which is a part of modern SOA platforms, provides valuable quantitative data about process execution, which can then be used to decide on the point from which process optimization should start.

We can see that the SOA approach to business process automation is iterative and incremental, as shown on the figure below:

When done properly, the usual duration of one circle (iteration) is three to four months. In other words, the SOA approach can produce new automated processes or optimized versions of already automated processes in approximately three- to four-month intervals. This is very important, because the SOA approach delivers results in relatively short intervals. This way, the whole company will recognize that IT delivers useful results. This can improve the position of IT, particularly if IT has not been efficient enough in the past.

There are other important benefits to the SOA approach:

  • It allows step-by-step identification of important business processes, and the in-advance assessment of the benefits of process automation and optimization.

  • It allows the in-advance assessment of costs and benefits, and ROI (Return on Investment) calculation. It also allows continuous monitoring of total costs throughout the process.

  • Owing to the reduced semantic gap between the business and IT, the communication of requests to IT becomes more precise and efficient, thus minimizing misunderstandings.

  • The systematic approach to process optimization requires less adoption for the employees, who therefore, becomes more amenable to changes.

  • The real-time monitoring of process performance (through BAM) provides valuable insights into the efficiency of the current processes, and helps in identifying points of optimization.

  • With SOA, IT becomes more flexible and can respond faster to changes in business. This makes the whole company more agile, which improves its competitive position, reduces its response time to market changes and reduces competitive threats. It also allows the company to react faster to new opportunities.

Focus on Content, Not Technology

We have seen that SOA focuses on business processes. The business processes are the content of the business. This means that SOA shifts the focus of IT from technology to business content. This is good, because the technology should be seen merely as an enabler. The less we are aware of the technology itself, the better it serves its purpose.

In the traditional IT approaches that are in common use today, the focus has been more on technologies than on content, as shown in the following figure:

The Improvements in the performance of computers have allowed us to think about software development at higher levels of abstraction. This has started with the shift from assembler to higher -level programming languages and has since then continued with the introduction of new layers, which have simplified the development and made it less complex.

SOA continues this journey with an important addition. It raises the level of abstraction in the direction of the business content, and away from the technologies. Although some technology-oriented IT people may not like this scenario, businesses may find it useful as they can now focus more on their business' content. The following figure shows how SOA has changed the focus of IT:

SOA, therefore, puts focus on the content of business.

Note

Who in the company is responsible for the business content? Is it the IT department? Usually not! SOA shifts the focus of IT from technology to business. SOA is not the domain of the IT department alone.

This brings us to the conclusion that SOA is not the domain of the IT department alone. As the focus is on business processes, it is important for SOA to outgrow the boundaries of IT departments and involve other departments as well. For success, we should involve the whole company, starting with the management.

Management Support

SOA is about business content, business processes, aligning IT with the business, and optimizing the business processes.

For an SOA project to succeed, it is very important to gain management's support. Without support, it is unlikely that we will be able to implement all of the required changes. Particularly problematic are the changes relating to the behavior of employees. Often, such changes are possible only if approved by the top management.

The other important reason why management support is necessary is that IT alone does not have the required knowledge about how business processes work in a company. It has to obtain this knowledge from the employees, who have to provide information on how the processes work.

Finally, SOA is also about business process optimization. The IT department usually does not have the authority to decide about changes in business processes. Therefore, process owners have to be involved in the SOA project. For this, orders have to come from the management.

SOA Competency Centre

We have seen that because of its focus on business content, SOA requires the involvement of not only IT, but also the other departments in a company. We have already mentioned that management and process owners have to be involved. Employees with knowledge about the business processes, the so-called key users, should also be involved.

Nevertheless, as the SOA projects usually arise from the IT departments, we could face some organizational barriers that prevent the people mentioned below from working together efficiently. Therefore, SOA will most likely require organizational changes.

The solution to these challenges can be a new organizational unit, called the SOA Competency Center. The SOA Competency Center should involve the following people:

  • SOA project leader

  • Business process analyst

  • Process owner

  • Key user

  • Technical architect

  • Process developer

  • Service developer

  • Integration and test expert

  • Representative for SOA governance