Closing the Gap Between Business and IT
Mutual understanding benefits organizations in the long run
By: Wolfram Jost
Dec. 31, 2007 11:15 AM
In the Past: Prosaic IT Documentation
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
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
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
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
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.
Reader Feedback: Page 1 of 1
SOA World Latest Stories
Subscribe to the World's Most Powerful Newsletters
Subscribe to Our Rss Feeds & Get Your SYS-CON News Live!
SYS-CON Featured Whitepapers
Most Read This Week