Over the last decade, supply chains have evolved to keep pace with changing business dynamics. This is especially true in high-tech electronics, where companies depend on an extended value chain of component suppliers, outsourced manufacturers, and logistics partners - not to mention B2B-integrated customers - to coordinate vital inter-company design and manufacturing processes. Adding to this complexity, business decisions are more centralized, while outsourced supply networks are increasingly distributed and global.

As a result, extended supply chains face the challenge of being adaptable while integrating with distributed companies in real time to provide advanced decision support. Several new technology developments have been inspired by these challenges; the most notable is managing complex processes using Web services for real-time application-to-application integration.

Advanced Supply Chains Require New Software Architectures
Exchanging information across a distributed network of partners requires a new type of enterprise architecture based on Web services to deliver application-to-application integration. This new architecture relies on a loosely coupled collection of services to achieve the vision of real-time, seamless interaction across multiple companies.

The dynamic nature of this industry, which involves processes and suppliers changing on a regular basis, requires systems to rapidly adapt and respond to changes. The service-based architecture is built on the concept of flexibility, using a system of discovery to search and find the desired services. Service-oriented architectures (SOAs) allow Web-based applications to interact with other Web applications using open standards with little intervention.

While traditional application architectures can address multi-party processes, the custom, tightly coupled nature of the architecture captures the process at a specific moment in time. This approach often requires extensive and time-consuming re-work to address any process changes or additions, limiting its extensibility outside a few key customers or suppliers.

In contrast, a service-based architecture built on defined inter-company processes allows the specifics of the processes to be addressed in a way that acknowledges the dynamic nature of the industry. As such, there is a movement toward adopting services to gain visibility to new data and integrate it into existing inter-company processes. Tie in UDDI to deliver a global directory of services that can handle a particular business signal, provide normalization rules, and new business signals can be used without physically having to re-architect.

Inter-company process management spans multiple layers, including partner integration through B2B messages, process models and exception workflows, information aggregation and visibility, and human collaborations through highly specialized portals. The new architecture enables changes to a specific layer without having to go through a long upgrade cycle that impacts other layers in the software stack. For example, to add an exception workflow for managing shipment delays or stock-outs in a vendor-managed inventory (VMI), the process would not require a costly upgrade. Instead, a set of configuration changes to that specific layer keeps the overall process fairly unaffected, thus enabling rapid delivery. The result is a cost-effective model for dealing with changing business processes or large, technologically diverse supply networks. Furthermore, this approach allows companies to leverage their existing back-end ERP, by adding services that can extract and normalize the data.

Developing an SOA to extend the supply chain requires a series of specific services to form the core engine; but additional services can be easily added as needs arise. Typical services that must be connected together include: B2B Gateway Service, Validation Service, Transformation Service, Process Service, Event Service, and Metrics Service. For service providers, all core services must be tied into the Security Service and Monitoring Service.

A simple explanation of the architecture illustrates this concept. From the network edge, the service includes a protocol gateway that can deliver messages to a business process engine where they are expressed, validated, and transformed. However, the same engine that does validation is not ideally suited to model business processes such as demand/supply planning or VMI. These should be expressed as separate services to provide flexibility for change as the business requirements evolve - especially if the business process has been modeled using interoperable descriptions such as BPSS and BPEL. Expressing advanced business processes as services allows for that business process to evolve via configuration (by uploading a new description) or by replacing the service with one that meets the new requirements.

In addition to accepting (Validation Service), processing (Transformation Service), and delivering B2B messages (Process Service), services are also required to manage, tune, and check the system. The operational infrastructure for this architecture leverages traditional routers, switches, and VLAN fabric, but also incorporates advanced monitoring and security systems to ensure the safety and protection of the confidential process information being exchanged. Furthermore, if a monitoring system is going to correlate information and distinguish between security issues and bugs, it needs to be receiving signals from the security system.

SOA can also extend this infrastructure to cost-effectively manage the on-boarding and testing processes. Since each component is loosely coupled via interfaces, well-defined intercept points exist where test and quality services can be inserted. During the development and on-boarding cycles, these services are used to minimize the amount of human support needed and to allow self-boarding and testing. These services are also leveraged once the system is in production to provide visibility to the quality of the business signal. These signals are picked up by the Metrics Service to provide reports on how well partners are conforming to the business process, thereby allowing improvements to be identified and easily incorporated.

It is important to address the B2B Service, which may be looked upon as redundant. The reality is that business signals are coming from a variety of systems via any number of standards - including RosettaNet, EDI-VAN, EDI-INT, FAX, FTP, e-mail, and custom XML - and require a mechanism to tie them together. The type of signal determines the location of the B2B Gateway Service in the overall architecture - on the edge of the enterprise, on the edge of the network, or as part of the overall core service components. When connecting a legacy system, it may be necessary to co-locate a bridging technology that can extract the data from the system, thus locating the service on the enterprise edge. Once done, the business signal can be normalized for the business process and injected into the overall message flow, thus supporting the vision of inter-company process management.