McVey - April 24th, 2000
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
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
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.
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.
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.
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.