Until now, we saw that business processes are dynamic. To express the various stages of the business process, the business process life cycle has to be defined. A business process life cycle has to cover the following four phases:

The following figure shows how a process enters this circle and goes through various stages:

Figure 2: Business process life cycle

Process modeling is the phase where process analysts, together with process owners, analyze the business process and define the process model. They define the activity flow, information flow, roles, and business documents. They also define business policies and constraints, business rules, and performance measures. Performance measures are often called key performance indicators (KPIs). Examples of KPIs include activity turnaround time, activity cost, and so on.

Process implementation is the phase where the IT developers (SOA developers), together with process analysts, implement the business process with the objective of providing end-to-end support for the process using IT (applications). The process implementation phase using the SOA approach includes process implementation with executable BPMN, BPEL, decomposition in the services, identification of the service, implementation or reuse of services, and integration.

Process execution and control is the actual execution phase, where the process participants execute the various activities of the process. For end-to-end support in business processes, it is very important that IT drives the process and directs process participants to execute activities and not vice versa, where the actual process drivers are employees. An important part of this phase is process control, where process supervisors or process managers monitor whether the process is executing optimally. If delays occur, exceptions arise, resources are unavailable, or some other anomalies occur, process supervisors or managers can take corrective actions.

Process monitoring, analytics, and optimization is the final, and a very important, phase. In this phase, process owners monitor the KPIs of the process. Process analysts, process owners, process supervisors, and key users examine the process and analyze the process execution metrics. They also need to take into account the changing business conditions. They examine business issues and identify ways to improve business processes to eliminate these issues.

Once optimizations have been identified and selected, the process returns to the modeling phase to apply them. Then the process is re-implemented, and the whole life cycle is repeated. We talk about an iterative, incremental life cycle because the process is improved in each stage.

Efficient process modeling requires a modeling method that provides a structured and controlled approach to process modeling. Several modeling methods have been developed over the years. Examples include IDS Sheer's ARIS methodology, CSC's Catalyst, Business Genetics, SCOR and the extensions PCOR and VCOR, POEM, and so on.

Process modeling also requires a notation. Business Process Model and Notation 2 is the most comprehensive notation for process modeling thus far. It has been developed under the hood of Object Management Group. We will provide a detailed introduction to BPMN in Chapter 3, BPMN for Business Process Modeling.

With version 2, BPMN adds a crucial aspect—support for executable processes. Prior to BPMN 2, business processes were more or less diagrams. With version 2, BPMN has added the ability to execute BPMN process models on a process server. This way, BPMN process models have become even more valuable assets for each information system. The ability to execute BPMN models is nowadays supported by leading process servers, including Oracle BPM Suite. Support for executable processes has brought about another useful feature, that is, the ability to export BPMN process models into the interchangeable XML format, which means that, at least in theory, BPMN business processes are not dependent on a specific tool of the process server.

Until now, we have talked about strictly defined business processes. Such processes are common for scenarios where activities, the order of activities, roles, and other elements of the process are well defined and do not change often. Such processes are commonly used for scenarios where we want to standardize the work and make sure that all follow the same template.

Not all processes can be well defined in terms of strict process models. Business processes that require knowledge, work, and certain expertise usually cannot be modeled in terms of activities and transitions (such models would be too complex). Therefore, the alternative way of modeling such processes has been defined. It is called adaptive case management or advanced case management.

In contrast to traditional, rigid process modeling, in ACM, the activities within an adaptive process are identified. However, the transitions between the activities are not modeled. The transitions are either defined as rules, or it is up to the knowledge workers to identify the right order of activities for a certain case. However, the tools that support ACM should provide the ability to monitor, update, understand, and interpret every activity as it is processed. We will talk more about ACM in Chapter 9, Adaptive Case Management.

The AS-IS process model for each business process consists of the top-level process model, which shows the high-level activities and the flow of these activities, along with the responsibilities of the roles involved in the process. It also includes detailed process maps for each high-level activity, with detailed representations of process activities. The detailed process map may have several decomposition levels depending on the complexity of each high-level activity.

Special attention should be placed on the exception-handling diagram. When modeling a business process, it is very important that we don't end up modeling only the optimal process flow (happy flow). We must not forget to identify the possible exceptions that might occur and specify how these exceptions are handled. An exception-handling diagram shows exactly this.

A well-designed process model should define at least:

When modeling business processes, our objective should be to develop sound process models. Soundness of the process models can be achieved if we follow a few basic principles:

Using these and a few other, more specific principles will help make our process models better and more usable over a longer period of time. We should, however, be aware that modeling processes is not easy although it might look easy at first sight. Therefore, in the next section, we will list common problems that we are likely to face.

When modeling business processes, we will face several challenges. We have identified some of these in the following paragraphs.

Modeling business processes should be aligned with the overall business strategy. If the objective of process modeling is not related to specific business goals, then it is a waste of time for all people involved. Therefore, it is crucial that we define, from the beginning, what the goals of process modeling are. The goal can be, for example, to provide end-to-end IT support for a specific process. The goal can also be to improve the efficiency of the process. It is, however, important that we do not stick to such high-level goals. We should precisely articulate the specific goals of the company. We should know the exact process for which we want to develop end-to-end support, where we want to improve the efficiency, and by how much. Without clearly defined goals with measurable outcomes, we should not start process modeling.

When we start process modeling, we should clearly define the responsibilities. In process modeling, people from different organizations participate. They must see value in participating, otherwise, they will not be willing to dedicate their time. Communicating the benefits of process modeling is, therefore, important. Even more important is to have support from the top management. Only the top management can order all employees to participate in the project.

We should define teams that will participate in the process modeling. Here is one possible structure of the team, which has proven to be efficient:

We also have to define measurable goals to assess whether process management has been done the right way and what the benefits have been.

An important part of business process modeling is communicating the models to all interested parties. This includes company management, unit management, supervisors, employees, quality assurance, and all other interested employees, all of whom can use the process model to better understand what is going on within the organization. They can also use the process model as work instructions.

Publishing the process model and communicating it to all interested employees is also important because, this way, we can gather feedback on the process and improve it even further. Publishing a process on the company's intranet is usually a good way to give visibility to process models.

Feedback on process models can improve quality and can be a good source of ideas for improving and optimizing the process. This is the first step in building continuous awareness about processes and their optimization among process owners and all others involved in the process.

Oracle BPM Suite 12c provides rich process reports that can be used not only for documentation and analysis, but also for communication. We will show how to use process reports later in this book.

One of the key elements of process control is BAM. The key objective of BAM is to provide a complete overview of business process execution within the company. The management and other people who are responsible for development and operations of the company use this data. The most important component of BAM is time. Time is crucial because BAM shows actual, near real-time information on process execution. This allows the company to react quickly and efficiently to the changes reflected through process execution.

Whatis.com defines BAM as follows:

To provide information for decision making, BAM first has to gather data. This data is gathered from business processes and is related to process activities, resources utilized in these activities, such as employees, and so on. The more the data gathered, the better and the more statistically relevant the derived information. The BAM tools have to gather the data and calculate interesting information that can help in decision making. BAM can process the gathered data in different ways:

BAM is not only a system that displays interesting information about processes; it consolidates data gathered from different, often independent, sources too. Connecting this data with past data enables BAM to identify critical situations in process execution or even automatically or semi-automatically solve some frequent critical solutions.

Monitoring the processes closely is essential, and we use KPIs to specify what we wish to monitor. KPIs are financial and nonfinancial metrics used to help an organization define and measure process efficiency. Monitoring KPIs in real time is nothing but BAM. KPIs should be related to the strategy of a company.

Examples of a KPI are the average revenue per customer, average time for response to a customer call, average order amount, and so on. KPIs differ from company to company. Therefore, the first step in using KPIs is to identify them.

We identify KPIs for a selected business process, which has to be specified well. We must also have clear goals and performance requirements for that process. When we define KPIs, we should follow these SMART rules:


When identifying KPIs, we should apply considerable thought to them because, in practice, KPIs have a very long lifespan. After we have defined them, it is difficult to change them because, if we change them, we lose the comparisons to performance in the previous years or periods.

KPIs should also be defined in a way that will enable comparison with other similar companies. Therefore, KPIs should not be unduly confined to a company's internal specifics.

In the real world, measuring KPIs efficiently and accurately is a major challenge. SOA, together with BPM, offers huge advantages over previous IT architectures because most SOA platforms provide KPI measurements as a built-in function of process monitoring and control.

Process optimization is the final phase in the BPM cycle. The objective of this phase is to develop the optimized process models called TO-BE models.

Developing the TO-BE process model is a challenging task because we must balance different factors. First, we have to define the objectives that we want to realize through process optimization. The most obvious objective can be that the process performs faster with less utilization of resources and people. The other objective can be to improve visibility into the process execution. Knowing the stage at which the process execution currently is can be helpful to the management as well as to the customers, who might even be able to track the process online. The objective of optimization can also result in improvements in the quality of products/services, better working conditions for employees, reduced impact on the environment, and so on.

Then, we have to identify where to start the optimization. To identify this, we use the data gathered in the process execution and control phases. The data gathered by BAM tools can be very helpful in identifying process bottlenecks in real time and in identifying activities or sets of activities that would be suitable for optimization.

Another way of identifying process optimization points is process simulation, which we mentioned earlier in this chapter. It is important to understand that BPM provides tools that propagate the data from BAM (process execution and control) into the process-modeling tool, where this real data can be used for process simulation. This is important because the tedious work of estimating process runtime parameters (activity execution, resource utilization, number of requests in a given period of time, and so on) is eliminated. At the same time, data gathered through BAM is much more accurate than estimates.

An important aspect of process optimization is new ideas. In closed organizational structures, the people involved in process optimization may be blinkered and may lack the ability to look at the process from a broader perspective. It would, therefore, be useful to recruit external consultants or other people from outside the organization, who can generate fresh ideas. Only in this way can we realize the full potential of process optimization.

However, when we gather new ideas, we should be careful to assess each new idea and find out whether it is realizable. We have to find a balance between new ideas and the level of changes a company's existing organizational structure can accommodate.

As employees do not like changes, we have to be careful in deciding how much change we want to introduce at one go. Ideally, we could change the process model considerably and try to implement changes in one large step. However, in many organizations, this has proved to be a failure because employees were unable to accommodate such changes overnight. If we do not invest enough time in communication with employees, they could start showing resistance to the changes. Therefore, it is often better to optimize in smaller steps and reach complete optimization over several stages.

On the other hand, we also have to be aware that process optimizations require modifications in the applications. Software modifications can be costly and they require time and resources. Therefore, from the IT perspective, it might be better to modify the applications at one go, that is, to optimize all at once.

Process optimizations often require changes in a company's organizational structure. We have to think about these changes too and obtain the necessary support from the top management. Otherwise, we will not be able to change the organizational structure.

Finally, we have to check whether the optimizations have been successful and whether we have achieved our goals. We do this by process simulation before it goes into production and after the process has been deployed to production through process control and monitoring.

Process optimization is not an easy task. The following are some common problems that you might face during optimization:

With this, we have concluded our discussion on the BPM life cycle.

SOA can improve the agility of IT by enabling the development and adaption of business processes quickly and efficiently using the composition of business services, that is, through programming in the large. As business services are designed for reuse and integration, the design, development, and test efforts are considerably reduced. SOA promotes reuse, which leads to increased standardization and compliance at the enterprise level. SOA also minimizes the business-to-IT gap.

SOA is concerned with the development of loosely-coupled information architectures, which shield business processes and services from changes and function independently of versions, locations, or technical details of applications systems. SOA also enables easier and less painful migration from legacy systems, consolidation of duplicated resources, master data management, multichannel access to applications, and the flexibility to develop variants of processes from the same base. Loose coupling enables IT assets to develop and evolve without the limitations imposed by interdependencies and point-to-point integrations.

SOA introduces a new dimension to application development with a major consequence—that of better aligning business with IT. SOA raises the level of abstraction from technologies to business services. SOA introduces business vocabulary to IT, which simplifies the connection between the IT and business people and enables them to better understand each other. Above all, SOA talks about applications in terms of business processes. Therefore, it does not require a complex mapping of requirements to represent the actual software. Further, SOA provides the ability to achieve two-way mapping between the business process model and the executable processes (and services). This guarantees better alignment between business and IT in the long run—even after several maintenance and upgrade cycles.

As SOA is related to BPM, it will encourage companies to think about business processes and achieve better collaboration between business analysts and IT. The business will discover that the SOA architecture is agile enough to adapt to requirements quickly, and IT will better understand the needs of the business. This will lead to business process optimizations and improvements and overall process excellence, which will have important impacts on the overall efficiency of the company.

SOA has been evolving over the years and expanded its reach beyond services, orchestrations, mediations, business rules, and human tasks. One of the major enhancements is business events, which are a part of event-driven architecture (EDA). The EDA approach allows us to trigger services by events and not by explicitly invoking operations. This leads to even more loosely-coupled architectures, where a service component can trigger an event and several other components can subscribe to the event.

In addition to simple, event-based relations, events can also represent a means for integration with the Internet of Things (IoT) devices. In such cases, devices will generate large numbers of events, which need to be processed in real time or near real time. In such scenarios, we are not interested in individual events but often need to find patterns in event streams. This brings us to complex event processing (CEP).

The number of events and other data generated by business processes, composite applications, and services opens the opportunity for analysis of this data. This is where SOA connects to big data. Big data is particularly interesting for analyzing great amounts of data, which can be nonstructured or semistructured. Sometimes, this data needs to be analyzed in real or near real time, which brings us to fast data.

Furthermore, SOA has been designed around XML, web services, WSDL, and SOAP. Lately, another type of web service has emerged, RESTful services, or REST for short. REST services differ considerably from SOAP services. Instead of interface with operations, REST services use resources, which map URIs to specific actions. They also utilize HTTP methods. Although REST services can use XML format for payloads, it is more common that they use JavaScript Object Notation (JSON), which is simpler and easier to parse. Introducing REST to SOA has been a challenge lately and has been successfully solved on several SOA platforms, such as Oracle SOA Suite.

REST enablement is important for integration of BPM/SOA solutions with mobile devices and with modern client-side web development HTML5/JavaScript web pages, which are also known as one-page applications.

Mobile enablement is one of the key steps towards multichannel and omnichannel support. In contrast to multichannel support, where different channels for clients exists, possibly all leading to the same business logic in the backend, omnichannel support also provides true integration between channels on the backend, which means that a client can switch channels while retaining the session.

Although SOA is an integration architecture, new challenges have emerged to the integration with the cloud. As more applications use the SaaS model, integration with cloud applications and services needs careful consideration. Cloud integration can be solved with adapters or with Integration Platform as a Service (IPaaS). The cloud also provides new opportunities for integration and process support directly in the cloud.

The cloud is also related with the way applications are packaged and deployed. Traditionally, applications, even if designed and developed according to SOA, are packaged and deployed as single monolith archives (such as SAR, EAR, WAR, and JAR). Scaling such applications in the cloud is, however, not efficient. Therefore, modern applications are built following the microservice architecture that defines autonomous microservices as self-contained building blocks. Microservice architecture considerably improves flexibility and scalability and enables easier migration to new technologies and versions.

Finally, the emphasis on services and their interfaces has become even more important. As the number of APIs is growing, it is not only governance that matters, but the whole API management life cycle. Successful management of APIs is the key to the API economy and will become very important not only for Internet companies, but for all enterprises. The importance is denoted by the API economy.

In this book, we will use Oracle SOA Suite 12c, which provides a comprehensive platform for SOA. Oracle SOA Suite provides full support for SOA and also addresses the new aspects of SOA. It provides Oracle Event Processing for EDA and CEP. It provides support for REST services, integration with the cloud, analytics integration, and even tools for API management. For more technical information on Oracle SOA Suite, please refer to www.oracle.com/technetwork/middleware/soasuite/.