Page 2 of 2   « previous page

In the Past: Prosaic IT Documentation
How can the business management content resident within information systems be represented so that it’s 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 explain 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 customization, but data modeling 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.

1980s: Process Models Stimulate Understanding
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. ARIS 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 an executable program or a configuration model was considered, the full capabilities of ARIS could not be realized without the cooperation of software manufacturers. Conversions took place manually. And, as with the translation between two languages, compromises were made during the transformation so there was no semantic overlap.

Business-process orientation was nevertheless a milestone in the description of business management logic. The wave of business process reengineering 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 popularization 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 without its critics, 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 realization 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 processers were essentially hard-wired into the program modules and databases.

1990s: Collaborative Business Models Emerge
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 intercompany process views and application requirements. After companies emphasized internal efficiencies within the scope of business process reengineering, the focus changed to sales channels and supplier processes and the optimization of the entire value-added chain.

However, each implemented application or instance of internal process modeling 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 modeling 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.

Today: Processes and Software Meet
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 the 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.

SOA’s inherent structure serves as the missing link between business management and software technology. Regardless of its IT orientation, SOA and business process management share the common goal of flexibility by 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.

In the Future: One Model, One Language, Greater Vitality
A 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.

Page 2 of 2   « previous page