BPM + SOA = Agility

By Joerg Klueckmann, IDS Scheer

The success of a company is increasingly determined by how quickly it can react to changing market conditions with adequate products and services.

Here, Joerg Klueckmann, IDS Scheer, reports on how you can increase that business agility through service oriented architectures.

Many companies already use active business process management (BPM) to increase their operating agility. However, while the functional description or adaptation of business processes can be significantly accelerated using special process design and analysis tools, there are often significant delays when implementing business processes in the supporting IT landscape.

The fixed connections of applications and process workflows on a monolithic application structure, as propagated in recent years, is extremely time-consuming and costly to modify. Missing documentation and non-transparent IT landscapes have also helped IT act more as a brake than an accelerator. This is one of the reasons why the market for business application software is on the brink of a technological paradigm shift.

Service oriented architectures (SOA) should revolutionise the use and benefits of software in companies. The dream of a software that supports agile corporate management should become a reality. By 2010, according to forecasts by analysts at the Gartner Group, at least 65 percent of large companies will have switched more than 35 percent of their application portfolios to an SOA. In the next five years, the biggest global companies are expecting savings of up to US$53 billion through SOA, as predicted by the Aberdeen Group in a current IT benchmark report.

However, it is a widely held misbelief that SOA, on the one hand, is synonymous with web services and, on the other hand, can be purchased as a product. The opposite is in fact true; SOA is primarily a management and architecture concept, which requires an IT infrastructure that responds flexibly to changing requirements in the corporate environment. The associated system architecture concept breaks the corporate business software into functional units, which are executed by small software components. These functional components can be flexibly adapted to the corporate requirements through model-based configuration without significant programming effort. When these functional units are automated through corresponding standard-based technologies, they are called ‘services’.

The XML-based language BPEL (Business Process Execution Language) is becoming increasingly important in this context. It can be used to orchestrate services for more complex business processes. As the functional scope of services and their chronologically-logical workflow is defined by processes, a business process design is crucial for the successful development of an SOA. The functional process description also determines the granularity of the services to be used or developed and thus answers the first key question en route to SOA: how should technical services be designed? The functional process requirements are the specifications for the technical services. Business process management is thus the basis for designing and implementing an SOA.

Business process architecture as a prerequisite
With ARIS, the BPM software by IDS Scheer AG, business processes are usually modelled in a multi-level procedure. Starting with the top process hierarchy of a company, the processes are detailed consecutively. This detailing is usually carried out over three to five hierarchy levels. While the functional processes are compiled in a top-down approach, the existing services are orchestrated into technical processes in a bottom-up approach. The connections between the two hierarchies are illustrated in Figure 1.

The business processes are broken down to a granular level that allows for a operational function to be executed by a technical service. This technical enrichment of the process description through an event-driven process chain (EPC) means that automatic transformation of the functional process into a technical BPEL process is possible.

After the transformation has been executed at level one in the business service hierarchy, these processes can be considered as technical ‘business services’ at level two. A business service can call up or combine contextually completed processes from level one. This nesting of technical processes means complex functional processes can be executed later.

At level three of the business service hierarchy, all processes from levels one and two are combined in a superordinate process. The close integration of the functional processes and the technical services fulfils one of the main aims of an SOA: – the flexible and fast adaptation of IT to the continuously changing business processes in an organisation.

One repository for business and IT logic
All of the above-mentioned elements of an SOA work together – starting with the functional process model, to the derived technical services, or the UML-based development of new service. If the functional process is modified, this has a definite impact on the orchestration of the technical services. If the technical service calls are changed for the worse, the value-added of the corresponding business department is hindered. Time delays in synchronisation between the functional process model and technical execution quickly lead to inconsistencies and thus to economic problems. It is therefore advisable to concentrate all elements of an SOA in a central repository (see Figure 2).

By merging the functional and technical SOA levels in ARIS, reciprocal dependencies become transparent and can be controlled. By a single mouse click, you can find out which service is used in which process. If a service fails, you can quickly check which business process is affected and who has to be notified in the business department and in the IT department. In ARIS, a comprehensive, semantic service repository is established. The largely automatic transfer of ARIS process models to executable BPEL models also makes synchronisation between the functional model and technical executions much easier.

Summary
An SOA begins and ends with a company’s business processes. By deriving technical workflows from business process structures and using a standardised repository for business and IT logic, the gap between the business department and the IT department is closed. The IT infrastructure corresponds to the business reality and thus leads to a high level of user acceptance. At the same time, companies are able to implement innovative business strategies and the underlying processes quickly and flexibly.