Hot topics

Within any organisation, communications between the core business operations and the IT group has traditionally been a challenging and adversarial relationship.

Most miscommunications between the two groups result from misunderstandings related to software and other issues. Now, the gap between the business IT layer is beginning to close.

"My programmer doesn`t understand me! This software doesn`t do what I need it to!" The deep sighs from the business side of an organisation are a familiar sound.

Standardised applications are not a perfect fit for the desired business processes, and customised applications are costly and quickly outdistanced by real environmental conditions. Management and departmental criticism of a company`s application software is stirred up regularly due to the high cost of rolling it out, as well as a lack of flexibility for processes, which hampers dynamic business development.

This disconnect can be traced back to fundamental problems in the implementation of technical process requirements in business management applications. For a long time, there was no method with sufficient semantics to represent business processes coherently for professional users that could also meet the technical requirements of mapping the processes in the software.

Now, with service-oriented architectures (SOA), a new chapter is beginning, in which real business processes are taking centre stage in application development. The combination of business process models and SOA will close the gap between business management problems and IT implementation.

In comparison to earlier revs, the new SOA-based application software allows dynamic design and rapid customisation of corporate business processes. Now, business management process models take services to the application system`s physical processes and orchestrate them accordingly. Before discussing SOA and its implications for the future, a recitation on the past is in order.

How can the business management content resident within information systems be represented so that it is independent of concrete information technologies, yet understandable to more than just IT experts? Mutual understanding emerged as a key method that allows those who work with the software to understand and influence it.

In the 1990s, the capacities of business management software were generally described in prose that spoke only to the technically inclined and was barely understandable to non-IT experts. Software engineers recorded user requirements in specifications that were then translated into program logic. This lack of communication between IT professionals and professional users grew explosive over time as the speed of IT innovation increased.

Data models were the first attempt at a common basis for understanding. The advent of data models was intended to create a real-world technical description language that would form the basis of the technical design and also document application systems.

Although data models were an improvement, there were no significant breakthroughs on the path to a formal description language for business management matters.

Data-model documentation helped understand the functionality of a company`s application software and transferred it to the client/server architecture that was growing popular in the mid 1980s. Data models were generally used as a starting point for customisation, but data modelling could not create a common methodological basis to serve business management and technology equally. A data model is an IT-related description and cannot map all of a company`s dynamics.

Process-oriented analysis was the first step in showing an integrated information system`s connections at a business management level. The result of this re-orientation was the ARIS program created by Prof August-Wilhelm Scheer.

In contrast to other architecture and method approaches, ARIS consistently and universally implements the business-management process view as a starting point for all other derivations and views up to the technical implementation.

Although a transfer to executable program or configuration model was considered, the full capabilities of ARIS could not be realised without the co-operation of software manufacturers. Conversions took place manually. And, as with translation between two languages, compromises were made during the transformation where there was no semantic overlap.

Business-process orientation was nevertheless a milestone in the description of business management logic. The wave of business process re-engineering that began in the 1990s and led to a sea change in the perception of companies and their processes played a major role in the popularisation of the topic of processes.

New concepts, such as "time-to-market" and "just-in-time", influenced companies to thin out their internal workflows to make improvements and increase their competitiveness.

The greatest challenge was to overcome purely functional thinking within departmental borders to move to the new paradigm of interdepartmental, integrated processes. Target processes were frequently implemented by introducing a new integrated standard software package for enterprise resource planning (ERP). This implementation was not free of criticism, because the communication gap between the target design and the mapping options within the ERP system required costly modifications to the standard.

Documenting the target processes and the internal software processes with a tool like ARIS at least gave users and IT professionals a basis for discussion that both sides could understand, while allowing the introduction process to be focused on clearly defined, specific business objectives. But there were still no direct links or transformation options between the technological realisation and the primary business-management model description that IT laypersons could understand.

At the time, this linkage was further inhibited by the form of process implementation in ERP systems. This process implementation prevented access to processes from the outside since processors were essentially hard-wired into the program modules and databases.

As the 90s approached, the subject of processes did not diminish in importance. On the contrary; the rise of e-business and the Internet carved a path to process management.

In the past, when a company`s role in the process ended, so did the process. Now, new application scenarios focused on collaboration across companies leading to new inter-company process views and application requirements.

After companies emphasised internal efficiencies within the scope of business process re-engineering, the focus changed to sales channels and supplier processes and the optimisation of the entire value-added chain.

However, each implemented application or instance of internal process modelling could not keep pace with this paradigm change. Therefore, companies introduced new best-of-breed business management software for specific business processes, including customer relationship management (CRM), supplier relationship management (SRM), and supply chain management (SCM) to handle the new tasks.

The lack of integration with ERP systems continued to be a hindrance. New middleware software, such as enterprise application integration (EAI), could make up for this deficiency only at the technical level. Intercompany, transparent descriptions of the process view required analysis and modelling of the business process. Technological advances in software attempted to transfer business management process models to EAI processes, but complete transformation to the software was still lacking.

The paradigm of the service-oriented architecture (SOA) seems to present a suitable candidate for the long-sought "missing link" between the business management and technological views of processes. In the ideal case, a company`s strategic requirements will be transferred to the technical business processes.

These are mapped to the appropriate services without losing any information and thus can be converted to service-oriented process models, which are then finally executed. ARIS add-ons, such as the one supporting the BPEL (business process execution language) standard, allow transparent navigation from business management to service models and the physical configuration of the software - across applications.

SOA`s inherent structure serves as the missing link between business management and software technology. Regardless of its IT orientation, SOA and BPM share the common goal of flexibility through controlling logic via technical description languages. So the process logic is no longer in the source code; rather, it is spread across several services that first connect with each other during execution to make a complex business process. This control typically takes place via (technical) model descriptions.

An SOA approach will seriously change the familiar method of dealing with standard software. In the future, process innovation will begin at the process level and will no longer appear as a bonus in the technological implementation of a new release.

Simultaneously, it will be possible to break open process chains and flexibly reassemble, expand, or swap them out. Protracted rounds of negotiations between the business side and the IT group will become a thing of the past as both entities are supported by a standard, transparent model.

Business processes, described with business management description languages, are the basis for configuring standard software. In terms of linguistics: the syntax is derived from the semantics.

About the author:

Dr Wolfram Jost is the Executive Board Member responsible for products at IDS Scheer. For more information, contact dawiej@cpi.co.za.