Orbweaver’s Position on Digital Standards

Many, however, have survived, and those are the standards that we use today, along with those new standards being developed. All standards are developed with a singular idea in mind: providing a unified means of conversation across multiple computer systems. However, not unlike your Apple adapters (lightning, USB-C, etc.), a new standard typically just means more complexity for companies to support. 

Blockchain is an excellent example of this. Blockchain is a fantastic standard, with a huge amount of applicability in this industry and others. However, it would require an impractical amount of capital and resources to convert all industry communications to Blockchain. Some companies or niche portions of the industry will implement it because it will help them solve a specific problem, but most company-to-company communications will continue on using the protocols and standards that they’ve already implemented, and for good reasons: they work, they’re reliable, and they’re cost-effective.

The good news is that the electronics industry has centered around just a handful of standards. Those are primarily EDI, CXML, and ETL (flat files or export exchange). API is the newest “standard,” although the concept of an API is very open, and merits its own discussion. 

Business models and internal business processes are simply too complex to support a single standard. Take, for example, the challenges of moving a large part catalog along with daily inventory and price positions. The parts list itself could very well be in the millions of parts, and then adding in parametric data, a single part data export could easily be in the tens or hundreds of millions of rows. While possible to fetch this daily, there is tremendous overhead in doing so. However, the pricing and availability data that complements each part is going to need to be refreshed daily (or as needed). 

So how can this be resolved? By applying multiple standards. The part catalog itself can easily be moved via EDI catalog types, or ETL exports, and probably only needs to be refreshed weekly (or perhaps only when parts are changed, added, or removed). The pricing data will need to be fetched in real-time as a purchase decision is being made, and an API is probably the best fit for that to allow for real-time synchronization between trading partners. If an API is not available, then certainly a daily EDI or flat file update for Price and Availability will be necessary.

Even this, the simplest of examples in this industry, requires a complex, multi-standard solution. Now consider purchase orders, change orders, ship notices, forecasts, ship-and-debit, etc., and the complexity continues to grow.

The bottom line for your business is that you must support many standards, not just one. It is also worth noting the high risk and cost of adopting only one standard. Centralizing on one standard would require revising current processes and reintegrating with existing supply chain connections. As previously stated, there is no standard for API transmissions, but they are still faster and more reliable exchange methods than file or document-based methods.

Furthermore, be prepared for the unexpected. Be prepared to see that esoteric version of EDI you haven’t seen for 20 years, or be prepared for an atypical API implementation. Your trading partners are working hard to make that data available for you to use in the best way that they can – it’s your job to meet them in the middle and help them make use of what they have available.

Orbweaver’s position in the industry to to directly facilitate all of these communications, and to help you get integrated into your supply chain. There is not a standard that Orbweaver does not support. It is our job to make the complexity of these integrations as simple as calling your Orbweaver account manager.