Composable Data Interchange Standards 

Consider PIM (Product Information Management) as a standalone business horizontal, similar to DAM (Digital Asset Management), content management (CMS), electronic commerce, search, and various other components. All PIM solutions provide a common set of data and functionality regardless of the specific underlying technology. Beyond those core features, some PIMs provide inventory management functions, some provide support for product and service pricing, and some provide neither.

Each of these capabilities – product information management, pricing, and inventory – can be seen as  an independent business function. Each such business domain has its own set of least common denominator functionality shared between all PIM implementations that support each of those functional domains. CDIS standardizes APIs (Application Programming Interfaces) that provide each of those core business functions.

For example, consider a PIM that you treat as the source of truth for inventory data, which is sourced upstream from an ERP (Enterprise Resource Planning system). Since your inventory data comes from your PIM, all of your applications that consume inventory data access service URLs of that PIM. If your PIM complies with CDIS, then that service URL is the PIM’s implementation of the CDIS Inventory API – OSIRIS’s standardized API for inventory data interchange for composable systems.

Now assume that your company has decided to procure a new PIM that does not support inventory management. If your ERP complies with CDIS, then all you would need to do to preserve your existing inventory functionality formerly dependent on the PIM, is change the URL for those inventory calls to instead point at the ERP. Because the minimally necessary functionality for inventory data interchange is standardized across both systems, no other changes would need to be made to preserve your solution’s functionality.

OSIRIS recognizes that each technology platform must expose unique APIs to provide differentiating features that meet its particular value proposition for customers. Compliance with CDIS standards does not prohibit vendors from implementing custom APIs, especially for non-duplicative functions. 

The key phrase in the previous paragraph is “non-duplicative”. To maintain compliance with CDIS, wherever possible, vendors should use CDIS API extensibility to augment the lowest common denominator functionality defined by CDIS itself rather than implementing APIs and data models that duplicate functionality supported by CDIS standards.

OSIRIS standards are designed for extensibility. You can extend CDIS data models to enable customizations and enhancements without deviating from the standard. Therefore, duplicating functionality or data models defined by CDIS is unnecessary, and would only tighten coupling between customer solutions and vendor platforms, which works against the goals of composable architecture. Organizations that commit to standards should use them wherever possible, without reinventing wheels or implementing proprietary solutions.

Recent CDIS Posts