In a business world of continually changing products, markets, and economic environment manufacturers are recognizing that business-to-plant (B2P) information technology (IT) systems integration must also change. B2P systems must transform from traditional hard-coded, spaghetti-like point-topoint systems into newer and simpler collaborative framework architectures.

However, accomplishing that objective requires a way to effectively manage changes in both business and technology as a single change process.

Once considered a pipe dream by many technologists, today's extensible markup language (XML)-based enterprise application integration (EAI) software has finally begun to provide an answer to that riddle.

That's because integrating plant and corporate applications into "loosely coupled" systems enables swifter, cost-effective deployments-making it easier to absorb upgrades and technology changes when needed.

Unfortunately, during the last decade, many IT business systems evolved into a complex set of IT infrastructures, cobbled together with brittle point-to-point integration solutions. This application-to-application (A2A) approach typically works until change occurs. Then, chaos ensues-hence, the term "brit- 14 tle solutions."

As many sectors of the economy move to mass customization and contract manufacturing, this A2A approach has not been able to keep up with the pace of process change and integration. More than ever, today's plant operations are continuously modified, with new product lines and production technologies forcing change in business applications. This is in addition to business changes caused by changing market and economic environments.

Old business rules must be easily reconfigured to meet new requirements. Based on my experience, typically 50% of project costs originate in characterizing and programming the business or plant logic, while the other 50% is spent on A2A integration. A2A project costs can be cut in half when the application-to-framework (A2F) of an XMLbased EAI is used to solve A2A issues. That's not evolutionary-it's revolutionary.

To date, the framework for interfacing control, plant optimization, and business applications has been typically based on A2A interfaces via application programming interfaces (APIs), open database connectivity (ODBC), Java database connectivity (JDBC), component object model/distributed component object model (COM/DCOM), etc.

EAI software has been around for a decade in many A2A forms as a tool to centrally manage many interfaces. However, it took XML and Web technologies the past two years to evolve it to its present form. EAI has become an XML-based framework of integration components vital for transforming the manufacturing data model. A need for real-time visibility in supply-chain systems helped propel EAI from an A2A "traffic cop" into a true data inventory and event manager for corporate data transactions.

The AN EAI is a key component when migrating to a truly interconnected supply chain that links raw material and product suppliers to the customer. Yet to date, supply-chain applications and business-tobusiness (B2B) systems have largely excluded plant data. This is the key "lesson learned" by those who actually deployed B2B solutions during the past two years.

Plant capacity and order visibility are essential elements for accurately planning and scheduling customer order fulfillment. In 2001, most enterprise resource planning (ERP) and advanced planning and scheduling vendors interfaced into plant-side systen-is, many using EAI tools such as manufacturing execution systems (MESs) to access order information.

Needed: Real-Time Answers

In today's competitive economy, manufacturers need real-time IT systems in the plant to support continuous improvement and rapid, reliable decision making. XML-based EAI tools improve chances for B2B success because they integrate real-time plant data into corporate and supply-chain applications.

EAI and supply-chain software vendors are now developing tools to extract data from plant optimization systems. These systems typically include MES, laboratory information management systems, finite capacity schedulers, and process control systems.

MES was the first to provide manufacturing product data to supply-chain interfaces. These systems dramatically improved product control by increasing throughput; automating data collection, efficiency, and quality; and providing supply-chain data integrity.

In the AN model, information moves independently among many types of systems and applications, while the framework acts as interpreter and guide. In the A2F approach, companies implement solutions incrementally, allowing the integration framework to grow and change as business dictates.

A major benefit of AN is it abstracts plant and business processes from application-based limitations and puts data modeling first. Companies can therefore make the best decisions for growing revenue and expanding markets without regard to limitations of individual software modules.

In an A2A framework, mapping processes and relevant data between any two points becomes complex when multiple applications from inside or outside the plant and enterprise come into play. For example, A2A integration between most ERP and MES systems is relatively simple. But when the ERP and MES require integration to a third system, such as a product data management system, the required integration points double! Six, not three, points of integration are needed.

This is one reason corporate IT managers have resisted plant-side integration. The number of integration points rises dramatically when moving from 10-15 corporate systems to 20+, including plant systems.

Over time, most manufacturers have added IT and plant technologies to support new functions that make operations more responsive and efficient. Historically, however, a major issue with IT systems is they are task specific and cannot easily share data. This not only compromises the effectiveness of these applications but also means end-toend business processes cannot be supported.

"EAI is critical because it enables data flows that support entire business processes, something that no single software application is likely to cover," said Julie Fraser, a principle analyst with Industry Directions. "It also supports the changes to business processes that can create competitive advantage."

Some companies have integrated key applications with one-stop shopping from an ERP vendor. But often such integration breaks down in the face of change because it is based on hard-coded integration software or the point-to-point integration schemas.

Supply-chain applications existing in an A2A framework that uses "many-to-many" integration points makes real-time integration very difficult, as well as fragile and high maintenance. Not only is it expensive to maintain, but its inability to provide accurate data for day-to-day decision-making operations creates a high opportunity cost.

When a new application is required, the integration road map of an A2A IT infrastructure gets increasingly complex and offers no clear exit strategy. From the plant to the boardroom, processes become increasingly fragmented, eventually breaking down among all required integration points.

The A2F framework uses a hub-and-spoke architecture. This isolates application-specific data from interaction with other applications, integration logic, or overall business process logic. A major problem with previous EAI generations was spoke-to-hub connections required hub-created logic in the same format as the underlying application. This causes the implementation to become just a series of point,to-point integrations.

Today's A2F approach abstracts and isolates data from different systems, avoiding the pitfalls of being wound into underlying applications. The result is an extremely stable IT infrastructure unaffected by version changes, wholesale application changes, or new applications. Importantly, reconfiguring underlying plant or business processes is easily absorbed, allowing continuous process improvement across a supply chain and plant.

"Adapters' Simplify Process

The key to the AN approach is isolating small units of work into "adapters." It greatly simplifies the entire integration process by placing the integration effort into logical units of work and segregating the processes from the integration details of any specific application. The core of the AN approach is found in the makeup of the EAI adapter.

These adapters ultimately enable all applications to share a unified data view. Application-specific data and program calls required to exchange data with its application reside on the application side of the adapter.

The first adapter section is the API connector that uses a well-defined interface (e.g., OBDC, JDBC, COM/DCOM, or a transport such as HTTP, TCP/IP, or IBM MQSeries) with its application API. An adapter's API connection is designed to receive data.

The second section translates that application-specific data into a generic XML message or document that other adapters can receive, transform, and share with their specific applications. XML documents or messages are created and then imported into the EAI framework repository. This "publishes" the data to the framework for use. On the framework side, the adapter uses a generic data model in XML formats that are specific to the EAI software.

Many Standards Bodies

There are numerous standards bodies for the API and the XML areas whose sole purpose is to create generic, industry-specific data models for data exchange. Some of these include RosettaNet (a predominant presence within the electronics industry), Open Applications Group, Global Commerce Initiative, and Data Interchange Standards Association. Once the data model of an adapter is identified on the framework side, the individual elements of the model are represented as "standard documents."

The EAI framework server executes business process logic and data flow, while the actual applications send or receive data in support of these EAI processes for downstream applications. The form, type, and frequency of the data are freely manipulated to meet the needs of the business logic and served out to requesting applications.

Within the EAI Framework Server, all logic is created and executed using standard XML documents and includes conversion of one standard document to another.

Via an adapter, data is routed to or from applications without needing to change underlying integration logic. Adding new applications as business needs change becomes simple and incremental. Version updates, or even a complete change of applications, are manageable because all required work is isolated in the adapter. The connection between adapters and the framework server typically supports a number of thirdparty message transports, such as secure hypertext transport protocol, backweb authoring language interface, TCP/IP, Microsoft message queue, or IBM's MQSeries.

Some vendors leading this effort are iWork, Verano, Mercator, Microsoft with BizTalk Server, WebMethods, and See-- Beyond.

Today's EAI embodies critical data in a manageable form to accurately model plant and business processes associated with exchanging data among systems. They accomplish this by presenting a standard view (inventory) of the data or resources.

This common XML view then enables the framework and its adapters to publish data in raw or processed form to any company, supplier, or customer application. For the first time, adapter/XML EAls allow companies to migrate their legacy systems to a B2B framework in a cost-effective manner. Plant-side visibility and interaction will become the key differentiator for most of your customers.

Today's XML-based EAI technology addresses real-world needs for B2B supplychain velocity and accuracy by establishing real visibility into your plant applications,. That's more than simple evolution for most manufacturers-it's a revolution.