Minimizing cross-functional, inter-enterprise data collisions

Data "diversity:" A major task is to stimulate solutions regarding data model differences, and XML can help, Differing world-views by function: Across functions, perceptions of a particular "thing" (such as a product) is likely to  differ. To sales it may be a widget, to engineering it may be a complex set of design specifications, to manfacuturing it is a set of assemblies and parts. Inter-enterprise data collisions: Different enterprises have different data models, even enterprises using the same software. Also, when enterprise A interacts with Enterprise B, their points of interaction will usually cross functional boundaries (e.g., A's sales and distribution functions are interacting with B's purchasing and plant maintenance functions). Services and information-centered business: as the economy becomes more "intangibles" oriented, data management becomes even more complicated than in the "widget" world. Standards: standards can help, but many pertain only while transactions are in transit. Enterprise A and B may use the same data conventions within their EDI exchanges, but both probably translate "standard" data into and out of their own data models once the transaction crosses into their inner processes. "Imported" data models: to a degree, Enterprise A and Enterprise B may import portions of one another's data models into their internal processes, but since they probably interact with dozens of other entities, the import process creates difficulties of its own. XML contributions: It is arguable whether the more important contribution is likely to be deeper standardization based on XML-expressed standards or, because XML data is fairly "self-describing", so it eases adaptation to non-standard, alien data conventions.

HOME