Though it seems like only yesterday that enterprise Web use became commonplace, by tech industry standards, corporate Web architectures have actually had a while to mature. Most enterprises have had several years to experiment with them, and have now deployed Web architectures that serve their core needs.
Connecting an enterprise with its partners, suppliers, and customers via the Web, however, has taken a different path. While enterprises have struggled to create effective patchworks of networking, intranets, extranets, electronic data interchange (EDI) and enterprise application integration (EAI), none of these approaches has taken firm root.
The only thing most enterprises are sure of is that they need to develop strong links between transactional data on one hand and supply data on the other. "Companies see that they've got both EDI and XML e-commerce," says Patrick Condon, senior product marketing manager with WebMethods, a Fairfax, Va.-based integration software provider. "They know that they need to integrate."
As enterprises move steadily toward a world in which Web-based supply chains are common, developers should prepare to work with permeable security boundaries, hugely distributed data sets, and event-driven applications -- all of which are important in an environment where sometimes hundreds of companies must act as one IT team.
As companies have begun outsourcing more of their non-core functions, leaving such complex processes as shipping, inventory management, and parts manufacturing in the hands of outsiders, they've begun to stumble over the limitations in their supply chain infrastructures. When developers and IT managers sit down to address these issues, their perceptions of an appropriate Web architecture often change.
In the past, supply chain systems have made use of hardwired, proprietary EDI technology or custom-coded connections between participants. Designed to tie together companies on a one-to-one basis, these systems frustrated users, whose workflow turned out to be more complex than the system could bear. "People were still using e-mail and faxes [to conduct their transactions]," notes David Gruebele, supply chain operations and logistics consultant for Santa Clara, Calif.-based GlobalFactory.
Custom-coded approaches, meanwhile, offered a more comprehensive picture of data available from each supply chain partner. However, they proved far too expensive to alter quickly if a partner left the relationship, making it nearly impossible to keep data access current, Gruebele says.
Today's Web-based supply chain apps strive for a balance between the durability of costly, rigid custom configurations and lighter architectures that offer only superficial views into scattered databases. Using emerging EAI tools, supply chain friendly middleware, and newly provided hooks into legacy systems, developers are building new, critical supply chain layers over and around their old Web architectures.
To make supply chain development projects work, programmers are being forced to integrate data within key functions such as purchasing and inventory management: Give those different internal functions a view of one another's data, then give the entire enterprise a view into similar data sets controlled by all key partners.
To integrate supply chain data within a back-office function such as purchasing, companies are often using EAI tools, such as the IBM MQ series or Metaserver's Process Integration Engine (see Resources).
"Back office data has to be optimized to support the supply chain model," says Wayne Bearstler, senior vice president with IT professional services firm RCG Information Technology of Edison, N.J. "There's still significant amounts of work needed to ready most back offices to handle collaborative commerce."
To get this done, how will Web architectures have to change? That depends, of course, on what a company has already done with its infrastructure. When it comes down to actual implementation, the level of architectural and developmental challenge will vary greatly by task.
Developers tasked with working in a supply chain environment will certainly find their share of familiar Web approaches in place, notably HTTP, server-side Java, and XML.
Not all of the work involved in supply chain development will involve major changes to Web architecture. Getting started with supply chain development work often involves finding ways to find common ground for data stored in varied file formats. Still, with integration involving everything from ancient legacy systems to the latest high-end database technology, that's a hefty task.
"There is Java and XML integration to be done, but a lot of the work is just slogging through old technology," says Marc Hebert, president of San Jose, Calif.-based Sierra Atlantic, an e-business and supply chain integrator. "There's a lot of data left from flat file ERP [enterprise resource management] systems. Not only that, there's traditional EDI that's all custom-coded. You've got to pull it apart, analyze it, and put wrappers around it to make it talk to an XML engine."
To take documents into their systems, enterprises will be able to make use of existing back-end ERP solutions like SAP AG or customer relationship management systems like Siebel Systems. But they'll probably end up building out their functionality using tools available through integration-tool vendors. Enterprise systems vendors such as Siebel, i2, SAP, and BroadVision, for example, have integrated WebMethods into their platforms.
They'll also find, however, that standard architectures may not look the same when the supply chain development process is complete.
Today, many companies rely on a three-tier architecture (browser-based client, app server, back-end database) to handle their Web needs. This architecture should grow increasingly distributed as companies adapt to the pressures imposed by supply chain needs, which encourage enterprises to move at least some intelligence closer to the partner site.
For example, many emerging supply chain solutions call for development and deployment of distributed/componentized applications to handle communications, placing application servers and extended enterprise data transmission mechanisms within multiple partner sites, says Arif Irfanullah of MindTree Consulting's package implementation/supply chain practice.
Next-generation Web supply chain systems must also keep on top of key transactional events as they occur. To monitor such events -- a delay in a scheduled delivery or cancellation of an order, for example -- developers may end up distributing event tracking logic out beyond their own corporate networks into client, partner, and customer sites.
At the same time, developers will face some stubborn implementation problems, many of which spring from having to manage an extremely complex environment via remote control.
Perhaps the most entrenched problem may come in working with firewalls. Firewall logic was not designed to leave a 24-hour, seven-day-a-week tunnel open to permit the flow of transactional data in and out. Not only that, firewalls aren't flexible enough to deal with live two-way communications, notes Frank Orchard, senior vice president of collaborative strategies for White Plains, N.Y.-based supply chain solutions vendor Optum Inc.
"A lot of proxies in a firewall are set up so that you can only receive a response in XML if you initiate the request," he says. "Also, a lot of firewalls set a two-minute limit for requests to be answered, and we can't always do that."
While supply chains demand such an open channel, existing corporate security considerations and application designs may argue against it. This may lead to the institution of a more layered security architecture than had existed before, forcing developers to adjust future application development accordingly.
Modeling the supply chain prior to build-out
Developers and IT managers know how to create an application blueprint -- that's their job. But when the complexity of the task increases by so many orders of magnitude, taking into account the back-end systems and procedures of dozens (or even hundreds) of other firms, things begin to blur.
In this situation, ordinary procedures may not be sufficient, and may lead to a good deal of wasted time, says Paul Koenig, vice president of marketing and alliances for Mountain View, Calif.-based enterprise integration modeling platform vendor Contivo. "The problem with Web interfaces is that they tend to change once or twice a year," Koenig says. "You get very little reuse."
Contivo's tool allows companies to develop models of the supply chain, including business rules, and let the computer model determine where the links are between different rules. With tools of this kind, Koenig says, it's easier for developers and managers to develop an efficient rules infrastructure.
Another issue that assumes a high profile in supply chain architectures is figuring out how to collect, order, and forward transactional information from a given site when that node is offline.
"Programmers need to figure out where to store information when the network is down, and know how to forward that information in the correct sequence (once the network is up again)," says Orchard. After all, he notes, transactions are interdependent: It doesn't make sense for a company to get a shipment going before a customer places an order.
Keeping decision-makers informed
Given the large number of possible activities and data sources within a chain, keeping users informed as to what's going on is far from trivial. Monitoring events is hard enough; routing information on key events to the right user at the right time is an even bigger challenge.
Some programmers are developing home-grown systems that search the text of e-mails to trigger event reporting to appropriate parties within their enterprises. Others conduct Web queries across the supply chain to check on the status of key events.
One vendor, Categoric Software of Sterling, Va. and London, has developed a platform that pumps such notifications out to appropriate parties' mobile devices via Wireless Application Protocol (WAP) push (see Resources).
Categoric's software contains "initiator" components that work to detect critical events within the chain. If they detect such an event, information is stored in a queue running on the MQ series. Events are then dispatched via a WAP push to wireless devices; this message includes a URL that links to a page containing the information necessary to the user.
Handling business rule updates
Given the complexity of the business relationships between various partners, suppliers, and customers, it's difficult for developers to stay on top of current business agreements.
Contracts that are located somewhere on paper or in locked-up digital form must spell out what each side requires of the other. However, getting those requirements integrated into the business logic of an application, especially as the supply chain grows and changes, can be a formidable challenge.
Vendors have begun to offer tools to help tackle this problem. For example, Fremont, Calif.-based supply chain solution provider WorldChain is offering a workflow monitoring server that extends the supply chain architecture out into partner sites. This server, which runs a set of Java apps that monitor supply data, raises a flag when an exception to client-to-client rules occurs. This way, individual rules can be updated without programmers having to constantly change code across the whole system.
Eventually, the supply chain architectures themselves will be supplanted. While the middleware, XML tools, and EAI options coming out now are not first-generation, they're not completely mature yet, either.
Also, for the time being, supply chains will remain a project of medium- to large-sized companies. Given the armies of integrators required to bring supply chains to life, and the cost of maintenance, supply chains are still not an elegant enough solution for any but the largest and most diversified enterprises.
In the meantime, however, developers will find it well worth their time to explore supply chain issues and the architectural changes they're likely to yield. In coming years, company-to-company integration is only likely to move forward, and developers who understand how this will progress should only be in further demand.
- The IBM MQSeries product integrates more than 35 platforms. Providing the base messaging functions for servers and clients, and assuring once-only message delivery, it can be used alone or with other members of the family.
- Metaserver's Process Integration Engine is the e-business process integration layer of Metaserver's technology.
- CommerceNet provides information on supply chain development issues, including updates on the status of the ebXML standard.
- Jibe has developed a supply chain product based around its peer-to-peer search software.
- Optum Inc.'s TradeStream is a hosted software platform for supply chain synchronization.
- The Procurement and Supply-chain Benchmarking Association, a free association of procurement and supply chain organizations within major corporations, conducts benchmarking studies to identify practices that improve the overall operations of the members.
- Categoric Software offers a platform that allows companies to notify key personnel when important events take place; the software includes an option allowing WAP-based push out to wireless devices.
- For more on the Wireless Application Protocol (WAP), take a look at our Wireless zone here on developerWorks.
- IBM's Patterns for e-business site features a number of reusable assets that can help speed the process of developing applications.

Anne Zieger is a widely published analyst, writer, and speaker whose work has appeared in many of the tech industry's leading journals, including developerWorks, Information Week, Byte.com, InfoWorld, CIO, and Internet World. Zieger is chief analyst and founder of PeerToPeerCentral.com, the leading analyst firm researching the impact of peer-to-peer technology on enterprises. She can be reached at azieger@peertopeercentral.com.