Youıve got to love it. After all the technology and hype surrounding client/server application development, the "killer apps" these days are packaged, not custom. To many developers this is a change in paradigm as well as in process. I see it as a trade-off in the types of problems both application architects and developers are solving these days. Itıs a trade-off, unfortunately, of technology and opportunity.
The reasons for the rise in packaged applications are obvious. First of all, organizations share many of the same business processes and services. Accounts receivable and accounts payable processing, for example, donıt vary much from company to company.
Second, we can finally reuse common services through common applications. Letıs face it folks, weıve done a poor job thus far in sharing objects, functions, and components. While we talk a good game, most application development projects simply reinvent the wheel.
Finally, there is a reduction in the time to delivery and the number of quality problems when working with packages. You simply canıt deliver a custom application in the time it takes to install and configure a package.
Still, packages are not perfect ı they have limitations as well as opportunities. You must take what the package has to offer or spend a great deal of money customizing it using proprietary languages and tools. Moreover, you must accept the architecture of the package regardless of whether or not it fits into your enterprise. As the enterprise resource planning (ERP) packages (such as those offered by SAP America Inc., Baan Co., and PeopleSoft Inc.) move into the information infrastructures of most of the Fortune 1,000, we are beginning to understand the obstacles ı as well as the opportunities.
The gauntlets that organizations are running may be summed up in a single world: integration. Although ERP and other applications seem to work well as an island of automation unto themselves, they lose value quickly when companies attempt to link services and data with external systems. Thus, itıs difficult to share resources between ERP application brands as well as ERP packages and custom applications.
So why do we care about linking disparate ERP systems together? Because of the new focus on supply-chain integration. The supply chain (or value chain, as itıs sometimes called) is the flow of goods and services from their points of origin to their ultimate destination, the consumer. For instance, a steel company produces raw sheet metal. This is sent to an automobile manufacturer, which processes the sheet metal into panels and assembles the car. The car is then shipped to the dealer, where it is sold to the customer. The sheet metal plant, the auto maker, the dealer, and the customer are all members of the supply chain.
Although weıve had supply chains since our economy began and have built systems to automate each supply chain member, weıve done a poor job of sharing information and processing among the members (so far). There is a great value in integrating all the supply-chain member systems. For instance, and using my previous example, a number of customers purchase a certain model of automobile, which increases the demand for that model. The dealer system is able to spot this trend and automatically order more of the popular cars from the auto manufacturer. The auto manufacturer system receives the larger order and is automatically able to step up production of that model by ordering all the component parts required to manufacture more cars, schedule additional workers for overtime, and of course, order more sheet metal.
Once upon a time, the process of having demand increase supply took weeks, even months. Not so today. A fully integrated supply chain can react to consumer demand in a matter of minutes, automatically making the majority of the operational decisions. The result is the ability to react systematically to higher consumer demand by building and selling more cars, making more money for every member of the chain. As you can see, the integration of supply-chain systems is a high-value opportunity for most businesses. Thatıs why youıve been reading so much about it lately.
Today, however, most members in a supply chain operate as single separate units. This means that they donıt share information by design or canıt share information because of the limitations of the systems (namely, proprietary systems). Typically, these systems are traditional ERP systems that do a good job within an enterprise but donıt provide the plumbing required to share processes and data with other ERP installations or custom enterprise applications. Therein lies the problem.
There are three ways to integrate supply chains: conformity, middleware, and specialized integration software (SIS). For the purposes of this column (they only give me a few pages, you know) letıs limit our discussion the ERP applications and the supply chain. [Editorıs note: In our next issue, Dave will revisit this subject in "Integrating Enterprise Applications".]
Conformity is the easiest to understand but the most difficult to implement. Itıs the process of going to all the supply chain members and convincing them to use the same application, even the same physical system and database. The idea is that if everyone uses the same system application services, database schema, and data, then integration is not an issue. There would be nothing to integrate.
The downside of conformity is cost and culture. Most organizations arenıt willing to toss out their existing systems and eat the cost of implementing new ones. Count on as much as $10,000 per user for most system changeover projects considering the amount of software, hardware, and services required. Whatıs more, most organizations simply donıt want to share data easily with other organizations. Thatıs a cultural barrier that is difficult to work around. While conformity is a good idea for postmerger systems integration, itıs simply too radical for most supply chains today.
Middleware is the most difficult solution to implement, but it allows the members to maintain their fiefdoms. Itıs the process of tying together disparate ERP systems through a common middleware layer that spans all member platforms. Typically, this means using the APIs that most ERP applications provide (such as SAPıs BAPI) as a point of integration and middleware to translate and carry the information from one system to the next. Virtual system middleware layers such as IBMıs MQSeries message-oriented middleware or BEA Systems Inc.ıs Tuxedo TP monitor are good solutions.
The downsides to a middleware solution are complexity, cost, and scalability. Because middleware itself does not know how to make connections between two or more ERP systems, youıll have to create custom programs that use a middleware layer as the lowest common denominator. This means youıll be facing a large development project to create plumbing applications that can make API calls on one system and that must gather and send information to another system using yet another API. If that sounds like a nightmare, it is. You have to keep track of what service is bound to what data, and how application services and data map from one system to the next.
While the database may be an easier point of integration for some systems, you have to be careful with ERP applications because the data is often bound to application services. Thus itıs dangerous to read or update the database without a complete understanding of how the data is handled by the services.
The middleware solution, of course, leads to a significant cost to integrate the member systems (depending on the amount of integration required). This solution is further complicated by the fact that the convoluted architecture created by loosely coupling the systems may have so many bottlenecks that it does not have the capacity required to support all member organization users. Iıve seen this happen at least four times in the last two years.
SIS is the latest rage in the ERP arena. SIS is software thatıs designed from the ground up to allow different ERP and other distributed systems to share processes and data as if they were a single system. The value of SIS is that the mapping between the application services and the data is done for you, so you donıt have to create the links and mappings yourself.
SIS can communicate with most packaged applications present in an enterprise and can define how processes and data are shared among them. SIS applications do this by creating an infrastructure that allows applications to access most services and data encapsulated in different ERP systems to interact as though they share a single API. This not only allows ERP systems to communicate, but it allows other distributed and legacy systems to share information and services as well.
The premier company providing SIS is CrossRoads Software Inc. CrossRoads was established by a consortium of investors, including the major ERP vendors, to offer a specialized integration solution thatıs many steps above the traditional middleware-integration solution.
CrossRoads creates a link between two or more applications, located either at the same or different sites, and allows them to interact as though they shared a single API and a single data model. CrossRoads is able to pull this off by matching the underlying APIs that drive similar services such as an update to inventory or an increase in sales activity.
The core of CrossRoads is an integration engine known as the InterChange Server. The InterChange Server provides the runtime environment for collaboration applications and application connectors. (See Figure 1.) Collaboration applications are application-independent modules that are able to implement business services spanning several applications. Application connectors are software modules that connect collaboration applications to an enterprise applicationıs API, representing a single point of integration between enterprise applications. CrossRoads provides application connectors for most popular packages including those of Baan, PeopleSoft, SAP, Scopus Technology Inc., Trilogy Software, and The Vantive Corp.
The InterChange Server is Java-based and supports COM, CORBA, and proprietary interfaces. The InterChange Server provides all the services youıll need to integrate applications within a distributed system environment such as an integrated data repository, an object request broker, data transformation services, error handing services, a security subsystem, and a driver-adapted message layer supporting MQSeries, among others. InterChange Server is Windows NT-based, so there is no requirement to purchase and maintain a high-end server.
CrossRoads provides a simple, point-and-click user interface for connecting systems. Itıs just a matter of selecting a sending application (such as SAP) and a receiving application (such as Baan). Then by simply selecting the process that you would like to link from the sending application, CrossRoads presents the equivalent process for the receiving application. Itıs a simple process of creating the link between the processes and facilitating the transparent flow of information between the two applications. You donıt need to understand the API sets for each application, nor do you need to purchase a middleware layer (unless you need one to link to other systems that CrossRoads does not support).
Clearly, the interest in ERP packages is on a steady rise. Fortune 500 companies have seen the value of buying instead of building, and thatıs just good business. However, businesses arenıt going to accept the package defaults. Consultants are becoming rich through the customization of packages such as SAP and Baan. We are getting good at package customization and have plenty of tools and experience to throw at such problems.
The next wave of the packaged application explosion is the integration of packages so they appear as a single monolithic application. The problem of supply-chain integration is that, although such integration provides the most value, company mergers or leveraging existing systems offer possibilities as well.
CrossRoads, in my opinion, is just the first wave of a number of SIS products that are heading down the pike. Once middleware vendors catch wind of the money to be made here, you can count on most providing one solution or another. Most middleware vendors already know how to connect to packaged applications through add-on products, but they have yet to solve the problem of mapping services and data among applications.
CrossRoads, however, has a long way to go. It does not yet support all packaged applications. So if you need to link to an unsupported system youıll have to build the link yourself. Moreover, CrossRoads does not yet provide industrial-strength features such as support for redundant servers. Iım not sure if Java is the right platform for an application such as this, considering its performance and scaling limitations (the platform, not the language). I know Iım being nitpicky, but these features will become important as products like CrossRoads break into the enterprise.
| Vendor Information |
|---|
|