Continued from Part 1.
Part 2: Creating Night and Day
While workflow was getting its start in the 1980’s, enterprise application integration, or EAI, emerged independently for system-to-system integration.
A key player in the early days (and still today) was IBM with their MQ Series messaging, which became a de facto standard for system-to-system communication in many large organizations. Many other vendors entered the market, and a variety of technical architectures for message brokers emerged, but all had the same basic goal: to automate the near-real-time exchange of data between systems, typically mainframe-based transaction processing systems or server-based relational databases.
Even the simple functionality provided by early versions of EAI could reap huge benefits in two areas:
- It was no longer necessary to re-enter data in order to transfer it between systems, reducing data entry efforts and error rates.
- Information could be exchanged between systems in near-real-time, rather than relying on overnight batch updates.
These early EAI systems had no human-facing functionality, since they assumed that the applications being integrated provided all required user interface. In other words, if an error occurred sending data from system A to system B, the data or other problem would be fixed in one of those two systems, not in the EAI system.
Workflow and EAI lived very separate lives during that time, although they are now seen as two ends of the same integration spectrum. Not only were they created by two different camps of vendors (with a few not-very-succesful exceptions), and based on different technologies and standards, but they were sold to two different parts of the customer organization: workflow was typically sold to business units as a departmental solution, where as EAI was sold to IT as an infrastructure component.
Next: workflow meets EAI.