Is J. D. Edwards’ xtr@ Ordinary?

  • Written By: Steve McVey
  • Published: April 24 2000

Is J. D. Edwards' xtr@ Ordinary?
S. McVey - April 24th, 2000

Event Summary

Last month in Las Vegas, IBM convened a meeting of executives to discuss current trends in today's digital marketplace and best practices for success. The IBM Supply Chain Executive Conference provided forums for participants from the user community and featured presentations by vendors and partners.

Michael Schmitt, senior vice president of B2B e-commerce at J. D. Edwards & Company, spoke on strategies for using trading communities to gain competitive advantage. One of his central themes concerned the inability of "traditional ERP and supply chain planning solutions" to support a collaborative business model. Schmitt contrasted these solutions with J. D. Edwards' supply chain planning product, xtr@, and its underlying Distributed Object Messaging Architecture (DOMA). Although his bias is forgivable, Schmitt's example is not. It fails to meet one of the most important criteria for collaborative solutions: openness.

Market Impact

DOMA, the messaging architecture originally developed in 1996 by Numetrix from its Modeling View Control toolset, is proprietary. It was created to alert users of situations requiring their attention such as when forecasts, delivery dates, or replenishment requirements cannot be met. Though notifications can be created for external distribution (e.g., e-mail), DOMA is powerless to influence if and how collaboration partners take action on the alerts. For instance, DOMA can generate an e-mail to a supplier demanding a replenishment of a particular part, but once the e-mail is transmitted there is little for the user to do but follow-up with a phone call to make sure the part is sent.

An ideal development approach would be to design and build applications using an open messaging architecture. This would be all but impossible in practice, however, as a truly common architecture would effectively expose fundamental information about a vendor's applications to its competitors, a move that would limit the vendor's ability to differentiate its products and discourage innovation.

Most packages use application program interfaces or APIs for sharing data with other applications that may have different architectures, platforms, and functions. These interfaces allow data to be packaged in a format that allows it to travel beyond an enterprise where it can be incorporated into the planning architectures of the other applications to produce alerts, trigger production orders, decrement inventory, etc., but do not compromise the proprietary attributes of the application.

The problem for collaboration is that APIs are primarily useful for connecting different applications within a single company, but do not readily enable connection to other companies. DOMA suffers a similar limitation. Collaborative planning problems are best addressed via XML technology in conjunction with a collaborative protocol such as CPFR (collaborative planning forecasting and replenishment), neither of which is provided by DOMA.

User Recommendations

Of course, the fact that DOMA is a proprietary architecture has no bearing on J. D. Edwards' supply chain planning capabilities. Numetrix was regarded as a leader in technology innovation and xtr@ reflects this. The point to remember is that, as useful as DOMA may be for collaborators that have Numetrix, it is not particularly helpful for collaborators that have other packages. Unless users intend to champion xtr@ to every one of their suppliers and customers and solve the technological problems of sharing data across corporate boundaries, DOMA will be of limited value in enabling collaboration.

comments powered by Disqus