Business processes are essential for every company—large or small. Companies rely on business processes. Let us look at what business processes are.
Note
A business process is a set of coordinated activities that are performed either by humans or by tools with an objective to realize a certain business result.
A business process consists of a set of coordinated activities that accomplish a particular business goal. The order of these activities and the efficiency of those who perform the activities determine the overall performance of a business process. It is very much in the interest of every company to have business processes that are efficient and include only necessary activities, because this will allow them to work faster.
As business processes define the order of work, they are related directly to the efficiency and effectiveness of a company. The better the business processes are defined, the more efficiently a company can operate. In today's competitive market, the efficiency of a company is a key criterion for success, because in addition to innovation, operating efficiency is key to improving the company's competitive advantage in the market.
Knowing and understanding the details of business processes is important, because this gives us the opportunity to identify the bottlenecks and optimize business processes. Optimizing business processes make them more efficient, our customers happier, will reduce the workload on the employees, and will reduce the utilization of resources.
Managing business processes is, therefore, very important. Each company should know how its business processes are defined, who is involved in the various related activities, and how long it takes to execute a certain process.
We have already mentioned that the objective of IT is to support and automate business activities using application systems. On the one hand, this reduces the load on the employees, and on the other, it guarantees that the activities and tasks are performed efficiently as compared to manual tasks and activities.
The focus, therefore, has to be on the process itself. The level to which a business process is optimized is directly related to efficiency of such a process. Today, having highly-optimized business processes is one of the most important priorities of companies.
Note
Optimized business processes are increasingly important for companies as they provide the company with a competitive advantage. With SOA, companies can optimize business processes easily, with less effort, and in a shorter time than with previous approaches.
However, it's not only the competitive advantage that matters; companies also need to react to changes in the global market, to new opportunities, and to threats from other companies. They react with modifications to their business processes.
The more efficient business processes a company has, the more efficient its operations will be. This will allow the company to have a competitive advantage over other companies and possibly become a leader in a certain area. Many of you might say that this is trivial to understand. Indeed, it is. But if we put emphasis on these topics, you will see that optimizing business processes is not easy, and not all companies define a systematic approach to business process optimization. Optimizing processes is also related to information systems. Each change in the process requires changes in application systems.
Note
Often, business processes are classified into internal or private business processes, and public or global business processes. Internal business processes are related to a single company. Global business processes connect two or more companies. Both types of processes are important and can be modeled and automated by SOA.
Before we dig into these topics, let us first look at some examples of business processes. Some examples of common business processes are supply, marketing and sales, procurement, and so on. Such processes take place in almost every company. They are called support processes.
However, the most important thing for each company is its "core" business processes—those processes that are directly related to the core business activities of the company. For example, a marketing company that manages advertisement boards relies on efficient processes that start with an order for advertising, and end when the advertisement is published on boards throughout the country or abroad. The faster the company can realize the orders, and the faster it can react to new requirements from customers, the better it is.
Note
Business processes are always specific to a company. This is particularly true for core business processes. Companies, therefore, cannot buy IT support for these processes in the market, but have to custom develop it to address their specific needs.
A company that produces car seats requires an efficient production process. Such a process can be automated, starting with the cutting of leather, continuing with the gluing of seat pillows, assembly of the seat carrying construction, and so on. In addition to production tasks, we can also automate other related tasks. Production can also be linked to the supply, which will open up new opportunities for supply chain management and help reduce stock levels. It is obvious that we are limited only by our own creativity.
A clothing company's core processes are design, production, and sale of clothes. The faster the turnaround between design and production, the more flexibility the company has to react to customers' wishes, and the better it can adapt to new opportunities. The better the connection between production and sales, the better the company can adjust its production to actual demand in the market.
A stockbroker company provides services related to buying and selling stocks. It also provides capital management services. Using the Internet, the company can develop applications that will allow customers to observe price changes in real-time and place orders online. This will change the processes dramatically and provide new opportunities for services that such companies offer their clients. At the same time, it will allow tighter integration with clients and closer observation of their needs. IT can help business processes change in order to get the maximum value from new technologies.
Note
SOA introduces new horizons in business processes optimization, where the only limit is our creativity. Business processes can provide an important competitive advantage.
In some industries, best practices related to business processes have been gathered and published. Such business process frameworks can be used for various reasons:
To standardize business processes in an industry
To ease integration between different companies from the same industry/sector
To use them as benchmarks to compare our own processes
To follow and improve our processes
Some experts are of the opinion that the best practices represent the average state in the industry. If our company is benefiting from such processes, it means that our processes are no better than average. Usually, companies that are above average keep their business processes confidential, because they know that their business processes reflect their true competitive advantage.
In the telecommunication sector, a well-known business process framework is Enhanced Telecom Operations Map (eTOM). eTOM defines best practices process frameworks for different aspects related to telecommunication business, such as:
Customer relationship management
Marketing fulfillment
Order handling
Problem handling
Customer SLA/QoS management
Invoice management
Service management
Service configuration and activation
Problem management
Resource management and operations
Resource provisioning
Partner relationship management
Marketing and offer management
Sales development
Service development and retirement
Supply chain development and management
Human resources management
Financial and asset management
We could find many more examples. However, the fact is that business processes are always specific to a single company, and are quite complex. A birds-eye view of the processes (as provided above) only tells half the truth. We can get a complete understanding of a business process only when we look at the details. It's in these details that the complexity hides.
When a company is established, its business processes are often not defined in a systematic way. Rather, they arise in a spontaneous way. It is the employees who often define the various activities and tasks. As the company grows, more and more people get involved in the processes, and processes become more and more complex. Processes in a large company differ from the processes in a small company.
In the real world, however, no single person can give a complete overview of an organization's business processes. The knowledge about how a process works is usually in the heads of employees and very often each person only knows about his or her own part of the process. The management does not motivate employees to think about the process, or even to think of optimizing it. Therefore, processes remain unchanged and are far from optimal.
If we agree with this, we can very simply conclude that if there is no single person in the company who could give an overview of the whole business process, then how can we know whether the company's operations are optimal. The management definitely wants to have the answers for the following questions:
Are the tasks and activities of a process organized in an optimal way?
Which tasks and activities require the most time to complete?
How are the activities and tasks distributed among employees?
How efficient are the employees?
We need to understand the business process in order to answer these questions. First, we should understand how business processes work. To do this, the usual approach has been business process modeling, which uses graphical (visual) languages to represent process flows, roles, and related documents. Business process modeling is not something very new. It has been around for quite a while and is a matured and well‑understood discipline.
We can model business processes in a variety of visual languages; the most widely used are EPC (Event Process Chain), eEPC (Extended Event Process Chain), UML Activity Diagrams, and recently BPMN.
We use business process models to understand the processes. This gives us the opportunity to modify and improve them, and to optimize them. Business process optimization and re-engineering are very important and it is up to our imagination to improve processes and integrate them to gain synergic benefits, and use other approaches to optimize them. We will not go into the details of business process optimization right now, because we will come back to this topic later in this chapter, and will discuss it again in the next chapter.
However, we will emphasize that business process re-engineering and optimization are related to several important topics that should not be overlooked. We will mention just three here:
Changing business processes requires changing the way people work. And people do not like change. Therefore, in order to be successful, we need to be careful how we apply the changes to the real world, and how we motivate the employees to change their way of working. Otherwise, a theoretical process, even if highly optimized, will not work in the real world.
Changing business processes does not mean changing only the behavior of the employees, but requires changing the IT support and related application systems. This topic is of particular interest for us, and we will look at it in detail in the next section.
Finally, changing the business processes only once is not the key to long-lasting success. If a company wants to have long-lasting success, it should develop an environment where business processes can be continuously optimized. This is a particularly difficult task, because continuous change in business processes also requires continuous change in the way employees work, and in the way IT supports the business.
We have defined business processes as a set of coordinated activities. We have also seen that most often employees perform these activities. Usually employees use applications to support their work. Sometimes, these applications fully support some activities, and the employee's intervention is not required.
With each new application that is introduced into a company, more activities become supported by IT. In other words, business processes are highly dependent on these applications, and vice versa. In addition, applications gradually start to impersonate business processes.
Note
Usually, business processes are tightly coupled with applications. Companies rely on IT applications in order to function. IT not only provides support for business operations, but has actually become an essential part of every business.
Today, businesses depend on IT. Can you imagine a business without IT? Can you imagine how any major company would operate, if IT does not function for one day?
Up to here, everything looks good. Nevertheless, we have not thought about the fact that business processes change over time. If the business processes are constant, we can afford to tightly couple them with application software. The fact, however, is that business processes are not constant and need to change. They need to be flexible. Therefore, IT also has to be flexible. In the next section, we will look at IT flexibility.
If each change in a business process requires a corresponding change in the IT system and in one or more applications, then the crucial question is: How quickly can we modify the applications?
The fact is that the time needed to modify the applications is crucial. In the eyes of the managers, this is 'lost' time, because the company needs to wait until the IT system is modified, before it can start using the new processes. Moreover, new processes might be better equipped to offer new or modified products or services. Therefore, the management will always put IT under pressure to do the modifications as quickly as possible—to minimize the IT gap.
To get a better understanding, let us look at a few examples. If an insurance company wants to offer a new insurance product, it has to upgrade the IT system before it can launch this new product in the market. The insurance company has to modify all the applications related to offering/ordering insurance products. This includes the applications on the office counters, the applications on the notebooks of insurance agents, the web site where insurance products can be bought online, in the call center for phone orders, and so on. Next, the applications for invoicing have to be modified. Various reports have to be modified too, in order to obtain information on how well the new product sells, who buys it, and how satisfied the customers are.
If a telecommunication operator introduces a new service or modifies an existing service, does this require changes to the IT applications? Yes, it does. It requires changes similar to those discussed earlier. In a telecommunication company however, such changes might also require modification in the software that runs the network. Today, there are many businesses where the IT support has infiltrated so deep into the company operations, that not only do support services rely on the application systems, but the whole core business operation has become dependent on the software.
Therefore, it is quite understandable that the management requires its IT systems to be flexible.
On the other hand, we know that IT systems in companies are usually very complex. We also know that complex systems require time to change. We can easily see that we are talking about two contradictory forces. One is the requirement from the management that changes should happen as quickly as possible. The other is the requirement from engineers, who require time to change complex systems.
In the real world, the request from management is usually of higher priority. This is why engineers are forced to change applications in a short time. Therefore, they do not have enough time to plan and design the changes. Even worse, they often need to apply modifications to software under pressure of time. In such conditions, they might be able to implement the changes, but changes may be done in a manner that negatively influences the overall software architecture and the entire information systems.
When such changes happen repeatedly, the overall software architecture becomes less robust. The changes get more difficult to implement, and hence require more time. This becomes a vicious circle. At a certain point, the architecture might even get so fragile that changes can compromise the integrity of the whole system. The dependencies and relations between the various software parts become almost unmanageable, and it takes so long to apply changes that it cannot fulfill the business requirements any more.
This is related to other impact factors, including:
The heterogeneous architecture of a typical information system
The usage of traditional software life cycles, which have not anticipated change
A typical information system today consists of a mix of heterogeneous application systems that have been developed over time. The application systems in a company are usually a mixture of:
Self-developed solutions
Custom-built, but outsourced solutions
Commercial systems such as ERP, CRM, SCM, and similar solutions
These systems use different architectural styles (client/server, multi-tier), different technologies, and languages (C++, Java, C#, Visual Basic, COBOL, and so on). It is quite unlikely that this mix of different systems was designed in a unified manner—it just grew, and will continue to grow. The fact is that companies rely on these systems and cannot afford to turn them off overnight.
Over time, some integration was achieved between the application systems, but it was not properly designed. This resulted in point-to-point integrations and the use of several different integration middleware products, including RPC, message brokers, distributed object models, proprietary integration servers, and in the recent years, web services.
Point-to-point integrations are very problematic, because as the number of involved systems starts to grow, the number of connections starts to grow exponentially. As point-to-point integrations are tightly-coupled integrations, they are very difficult to maintain. Changes in one system provoke a 'domino effect', whereby changes have to be applied in all related systems. Often, the complexity of maintaining the integrations becomes very high, and so does the cost.
To get a feeling for the number of necessary connections, let us presume that several applications have to be connected to each other. We will count only unidirectional connections, that is, if application A has to be connected to B, and B to A, then these are counted as two connections. With fifty applications, we would need an unbelievable 2,450 connections if we integrate applications on a point-to-point basis. To be honest, in the real world, we will probably not need to connect each application with the others. However, this does not change the fact that we will have to manage and maintain a large number of individual connections.
These issues are manifested while dealing with:
Combinations of monolithic, client/server, and multi-tier applications
A mix of procedural and object oriented solutions
A mix of programming languages
Different types of database management systems (relational, hierarchical, and object)
Different middleware solutions for communication (message oriented middleware, object request brokers, remote procedure calls, web services, and so on)
Multiple information transmission models, including publish/subscribe, request/reply, and conversational models
Different transaction and security management middleware
Different ways of sharing data
Possible usage of EDI, XML, and other proprietary formats for data exchange
All of these issues make applying changes to information systems even more difficult and time consuming, thus increasing the IT gap even further.
Existing applications have most likely been developed using traditional software life cycles. These consist of various stages, including:
Requirements specification
Analysis and design
Implementation
Testing
Deployment
Depending on the development process, these stages are either sequential, partially parallel (Waterfall model), or iterative-incremental (Rational Unified Process). No matter which development process is used, they all are based on the following two facts:
The requirements are specified in advance. These requirements should be specified as precisely as possible, because the architectural design depends on the requirements. Real-world experience, however, shows that in most of the cases, it is difficult to define the requirements in advance. It is also very common that the requirements change, even throughout the development.
Traditional software development processes were not designed for continuous change. Rather, they relied on certain precise requirements. Modifications to the requirements need to be run through the whole development cycle again (because requirement gathering is usually the first stage), which is very time consuming. This is not aligned with business expectations, which require quick changes.
With this, we do not want to say that requirement specifications are not necessary. In contrary, it is very important to specify the requirements. The key is to develop a software architecture that will anticipate change and be flexible to change. Only such an architecture can fulfill the requirements of the next generation of information systems—information systems that will provide end-to-end support for business processes. Existing software architectures have not fulfilled these expectations.
Service Oriented Architecture (SOA) is the architecture of the next generation of information systems. It provides answers to the problems identified in the existing software architecture. SOA enables the development of applications that are more flexible, and more adaptable than applications built using traditional architectures. SOA applications are, therefore, much easier to modify and adapt.
SOA also enables better alignment between the business processes and the applications. As we will see later in this chapter, SOA minimizes the semantic gap between the business process models, and the actual application software. SOA achieves this with the introduction of new technologies and languages, most importantly, BPEL.
All of this is in line with our primary objectives:
To minimize the IT gap, and the time required to modify the information system in response to the changes in business processes
To make the information system more flexible and adaptable to change through a loosely-coupled approach
To provide end-to-end support for business processes
Finally, to make the company more agile, more flexible, and to allow it to adapt more easily various forces, such as competitive pressures, new opportunities, changes in the global market, and so on
The fact is that in the past there have been several attempts to make software architectures more flexible. There have also been several attempts to align business process modeling with software development (and vice versa). However, the fact is that the problems continue to exist even now.
To be able to answer this question, we will first look at the business processes, and how they are managed today. We have already identified that:
Business processes in a company usually emerge in a nonsystematic way
Business processes are dynamic and change over time
Often there is no single person who has all of the details of all of the business processes in a company
The classical approach to BPM foresees the cataloguing of all business processes and drawing the exact specifications of each business process. The output of such projects are "nice pictures" of processes. We have used the phrase "nice pictures" because capturing a business process can only result in a snapshot of a process at the time when the snapshot was taken. However, business processes are dynamic and change over time. Therefore, such pictures of processes cannot correspond to the real processes for more than a limited period.
Larger companies usually face two additional problems:
Modeling business processes (specified as one-time projects), can take quite a while. It can happen that even before we complete the project, some process specifications might be out-of-date (this is particularly true for processes that have been modeled at the beginning of the project).
Business processes are also usually quite complex. While specifying them, the most difficult part is to provide in-depth specifications. The complexity usually hides in the details. Therefore, we might get high-level process specifications. However, such specifications may be very simplistic, and may not include important details. This could influence our understanding of the processes. Very often, process specifications do not include exceptional scenarios, and do not foresee how to react to such scenarios.
The following figure provides an example of a process specification:
Even if we succeed in modeling business processes in detail, and in a relatively short span of time, there is another huge problem we have to face with the traditional approach – the business process activities and tasks are performed by the employees and the software. There is a huge semantic gap between what goes on in the information systems and the process model diagrams. This semantic gap exists because it is very difficult to relate the changes in the processes with the changes required in the information systems, and vice versa. Therefore, it is also very difficult and time-consuming to maintain the business process models in-sync with the actual software. This is very time-consuming because it has to be done manually, and is therefore not done in real-world environments, where time is valuable.
Part of the problem is hidden by the fact that enterprise systems are still developed at a relatively low level. Even if we use modern software platforms, such as Java EE or .NET, we are still required to develop in languages such as Java and C#. These are object-oriented languages, which use concepts such as classes, objects, inheritance, delegation, and so on. These concepts are not synchronized with business processes. Java, C#, and similar languages are still relatively low-level, compared to business processes. Therefore, we sometimes refer to them as 'programming-in-the-small'.
SOA has introduced several new approaches to software development that we will look at, in the next section.