Tuesday, September 2, 2025

Product use of Standards

The third kind of contract I’m well-suited for involves working directly with product developers—whether client or server-side—to ensure their solutions optimally leverage existing standards. This role is often overlooked in traditional standards development but is critical for real-world adoption. While it may seem like a large engagement, it often resembles a small contracts, focused contract. I’ll explore that nuance more in the next blog post.

Government Mandated Standards

A product can be compelled to be compliant with a standard or Implementation Guide (IG). This is common nowadays around the globe with regulation requiring that products and the organizations that use them be compliant with a given standard or IGs. These government efforts are trying to move their realm beyond some point, with the goal of having a better outcome after the standards are deployed.

A good example of how a government required standard can dramatically improve that realm that government controls is electric socket, light socket, or lately USB-C. In these cases, without standardization there were many alternatives that the consumer must be burdened with. By mandating a standard, the products all align on that standard, the consumers don't need to think about that anymore.

Purchase Power

A product may choose to implement a standard because market pressures (customers) demand it. In this case it is the power of the purchase ($$$) that forces the use of a standard. An important perspective here is where the first vendor works with the purchaser to define that which all later must implement. In the case of early Health Information Exchanges, and Radiology Exchanges; this was the dominant method for standards to become required. That is to say those purchasing products demanded that a given IHE-Profile must be used, and that drove mandates. This was the success story for IHE, in that it was a collaboration between those with purchase power in the radiology departments that wanted ONE standard to mandate, and the vendors that knew that one standard would be less overall work. Unfortunately, this story has been lost to time

Implement Once, Innovate Beyond

The overall benefit to using standards that those developing products that need that standard can now be assured that their efforts to use the standard will be reusable over and over; thus, that product development group can focus more on the features and value of the product. A good standard is one that one can implement once and not spend more time on (realistically it takes some maturing to get here). The point is that by using a standard one does not need to constantly adjust how one communicates with peers. 

This use of standards overall benefits everyone. 

What help do you need?

The fact that a regulation picks a standard or IG does not mean that developing a product to that standard is easy. The standard might not be all that easy to read, most standards are hard to read. The needs that the product have might not be expressed in the standard, so some interpolation needs to be done. There are often things that are needed to be implemented that the standard doesn't mention, most of the time it is in an area where the standard wants to be lenient, so one must understand a range of possibilities.

Postel's Law

When I work with your team, I will stress multiple times a day a principle that is credited for the success of the TCP/IP internet. Often called Postel's Law. It has two very different things to say. To those about to send some content to another, be as compliant as you possibly can be. To those receiving some content from another, be very robust and lenient in how you interpret that content. Many people have a problem with this second part as they feel that receivers should be strict, rejecting anything that is not compliant. The problem with this is that it is very fragile and doesn't recognize reality. Reality that often comes along with revisions of the standard over time.

Conclusion

Let me be your thoughtful, experienced guide in the often murky world of standards implementation. 

No comments:

Post a Comment