Process-Based Architecture for Back Office: Successful Supply Chain Requires EAI
Competitive Advantage Via IT Architectures
Today there are only two types of enterprises: those that change and those that disappear. New value chain or supply chain requirements have seriously raised the bar. Survival now requires quantum improvements in speed, flexibility, and customer responsiveness, along with a totally open view of the back-office process. These attributes can no longer be achieved by adding or even better integrating applications. The survivors must dig deeper to reshape their IT architectures to preserve the important processes driving their business. The demands for global collaboration, partnerships, virtual manufacturing, and unlimited flexibility require it. Otherwise, the very applications designed to "save" them will actually force these companies to alter the processes that have made them successful.Thus, as companies try to leverage their internal capabilities toward the Internet via e-commerce and Web-based customer portals (front office), the CIO may well hold the company's future in her/his hands as corporate architecture and enterprise systems support the business strategy, especially process re-engineering. Why? Because the essential architecture of traditional application integration strategies is built around the manipulation of data rather than the business processes. The result: data-bound business organizations that cannot effectively compete because they are handcuffed by the massive volumes of data, transactions, etc., required by e-business - and by the difficulty of separating that data from supported applications.
Enterprise Integration and Evolution
Before a company can hope to take advantage of supply chain management or Web-based front office automation, it must address the back office issues. Currently, Enterprise Resource Planning (ERP) captures the lion's share of the CIO's attention as companies attempt to restructure their business around these massive data-centric back office systems. While ERP commands this attention, it cannot hope to cover all back office issues where legacy systems and many other domain specific applications must be orchestrated.The ERP Shock Wave
As a kind of shock wave of ERP expansion moves through the back office, Product Data Management (PDM), Virtual Product Development (VPD) environments, and Manufacturing Execution Systems (MES) are not yet easily included. Workflow management of core business processes, enterprise application integration (EAI), and the growing shift toward Web integration are all adding to the swirl of confusion. Legacy systems must be considered as well, for they will not be replaced quickly enough to ensure the success of most ERP implementations, which assume replacement strategies or massive coding rewrites.Collaboration ad hoc is Good - and Bad
Additionally, the present state of the art does not easily support the collaboration required for supply chain success. Loose integration of applications with the underlying business processes results in collaboration that is mostly ad hoc and devoid of any formal business and workflow logic. Ad hoc collaboration is not in itself a problem. In fact, it's the way people naturally work with each other and in this sense it actually facilitates the functioning of supply chains.Problems arise not from the ad hoc nature of work, but from the inability of data-bound IT architectures to support ad hoc collaboration within the company's natural workflow logic - how the company actually works. The problem worsens when the organization spans a heterogeneous set of companies, geographies, and environments. Add to this the numerous applications within a company or supply chain, and the traditional integration strategies rapidly fail. The enterprise becomes unresponsive and collaboration is limited to point-to-point mechanisms such as fax transmissions or e-mail, or perhaps some sort of access to data repositories. System integration takes on too many direct interfaces and too much "glue-code," and thus does not demonstrate the flexibility required for successful ad hoc interactions.
Change Is Imminent
In a world of change, these massive implementations will often require a significant change in scope before they are ever fully deployed. Change must be planned for and, in fact, the ability to change is the real differentiating core competency in the market place. Best-of-breed "super systems" must be configured, executed, delivered, and managed in an environment that welcomes and supports significant, ad hoc changes to the sets of tools, data vaults, organizations, and core business processes. These "super systems," or "meta-systems," provide a framework for integration, collaboration, change, and business competitiveness.Success in e-business can only occur when you see your business as a rational set of processes, rather than a conglomeration of data to be manipulated. While monolithic "stovepipe" approaches to application coverage are giving way to best-of-breed strategies, a process view, supported by a "meta"-level architecture, is still required for full supply chain success. That's because traditional, data-centric solutions provided by legacy systems, ERP backbones, vertical applications, stovepipes, and even middleware will either slow the company down or cause it to change its processes in order to accommodate the limitations of the solutions themselves.
The Object Management Group (OMG) is a prime example of how industry, both customers and vendors alike, has recognized the need for a standards-based framework to support the plug-and-play integration of many software applications. CORBA (Common Object Request Broker Architecture) is framework architecture that can provide any company with the basic roadmap for creating an effective process-centric "meta-system."
OMG and CORBA, until recently, have lacked the availability of tools that can support the enterprise-scale approaches that are desired. Proprietary approaches are available, yet they may not yield the same market acceptance (COM/DCOM, OAG, proprietary EAI applications). While CORBA-based frameworks are more desirable, Java-based-frameworks, proprietary frameworks (IBM), and EAI application vendors all are projecting their views into the market.
A Liberated Enterprise is a Process-Driven Enterprise
A robust CORBA-based "meta-system" must be process-based, i.e., founded on a flexible framework for the configuration, execution, delivery, and management of core business processes across Virtual Private Networks (VPNs) and the Internet. A framework is more than a collection of object classes; it includes rich functionality and strong interconnections that provide an efficient infrastructure for the "meta-system" builder. In the process-driven environment, supported by process-centric architecture, front office, back office, and supply chain business processes can now be configured for optimal and ad hoc management and execution.The process-centric framework can easily configure and manage any set of enterprise applications, any set of data sources, and any set of participants inside and outside the enterprise -- in other words, across the supply chain. That includes the company's and their partners' front and back offices. How? By decoupling applications and data from business process, the "meta-level" process-centric framework allows just the right combination of data and applications to be delivered, in context, to the person who needs it at any given moment or point in the process. Thus, liberation is possible when any combination of data, applications, and even EAI frameworks can be served on a totally ad hoc, totally flexible basis. This can only happen when the applications and the data that support them no longer have to travel together. We call this "process mail."
