“Love, Honor, and Obeying…Standards?”
CTCA.info
Following standards can seem to be the best way to build a system, network, or application; however, a more sophisticated answer might be a combination of ‘standards’ and ‘implementation agreements’.
OVERVIEW OF TERMS
First I will define two terms: the term ‘standard’ (which, for a working-definition, I define as an agreement that is crafted and finalized by an agreed-to standards-making body such as the American National Standards Institute), and the term ‘implementation agreement’ (which, for a working definition, I define as a group of vendors, users, and trade associations which determine “HOW” the standard will be implemented in the near-term, such as the North American ISDN User’s Forum, the ATM Forum, etc.). This discussion is going to focus ‘first’ on the challenge of a ‘standard’ then return to the concept of an ‘implementation agreement’
A. STANDARDS
Many people today concerned with infrastructure protection – wanting to make sure that decisions made today will not require costly changes tomorrow. In an effort to reduce uncertainty and risk, some organizations have decided to strictly adhere to “standards”. Where on the surface this appears to be a wise choice (and often is), there needs to also be a more in-depth appreciation as to the strengths and weaknesses of “standards”.
The cost, necessity, and benefits of standards are different for users and vendors. The user seeks the stability and safety of standards, where the vendor seeks to offer their customers variety and uniqueness (and the increase in value and price) of their vendor-specific offerings. This has lead to customers demanding (and vendors showing at least some support for) “standards”. However, a total focus on “standards” might not be in the best interest of the user. At CTCA.info we teach that “you never push the envelope of creativity with a ‘standard'”. Why?
1. Standards Creation: In most standards meetings the proposal which carries a majority of votes is chosen as ‘the standard’. However, to prevent the chaos of losing the industry support of the losing proposals, in “some” standards there are “multiple methods” of implementing the standard. This allows all vendors to say that they are “compliant” with the XYZ standard while at the same time almost undermining the real intent of a standard. In most cases market forces will select the better standard.
2. Standards Complexity: While moving forward with a standard, there are many issues which may be brought to the attention of the standards-making body. Some issues are too complex (or too contentious) to address in the first implementation of a standard. That is why you will see in some final documents a notation that indicates that some issues are ‘for future study’ or ‘to be determined’.
3. Standards Scope: A standard may be created with many attributes and options which can be implemented for increased service/capability. However, to get a product or service to market, some vendors will decide to implement a sub-set of these attributes. Future releases of the product will contain more services and the standard is more fully implemented.
4. Standards vs. Time-to-Market: There are two competing concepts that are at work in these standards meetings. First, there are several companies who which to advance a new service/product/concept. However, the second issue is that every company representative has been tasked with, primarily, getting “THEIR” version of the standard accepted, or, if that fails, to prevent their chief competitors of getting “their” alternative proposals accepted. This means that there is a challenge in getting a standard to market quickly, since all sides have proprietary interest in advancing their own (and retarding their competitors’) market entry.
B. IMPLEMENTATION AGREEMENT
Realizing that not all standards are: a) fully completed on the first try; or, b) fully supported by all users/vendors/trade-organizations, there are formal and informal agreements which help get products and services to market faster named “implementation agreements” or “vendor implementation agreements”. At the beginning of this discussion I mentioned the North American ISDN Users Forum (NIUF) as an example of an “implementation agreement”. Although I’ve chosen this older group one as an example, there are many such agreements worked out in the world of technologies. These ‘agreements’ take on the weight of a standard, even if they do not have the official blessing of a standards body.
“Implementation Agreements” can be given a ‘name’, ‘specification’, or ‘number’ to indicate that there is a common agreement that has been settled. Notably, in the world of communications protocols (read ‘standards’) there are many National and International “standards” which are not complete-enough to bring to market (or are too vaguely-worded to be implemented in products). To overcome the vagaries of the standards world, these implementation fora are convened and the tough work of determining “how” to implement a standard are worked out. As with standards, there are often early versions that have fewer features/capabilities and later there are versions with ‘more’ features/capabilities.
As a side-note, it is often quipped that attendees to the Implementation Agreement fora are “also” tasked with the same two tasks as those at a standards meeting: 1) Get your proposal accepted or 2) prevent your competitor’s proposal from being accepted.
C. FINAL ANALYSIS
It is laudable for users to pursue ‘standards’ for infrastructure protection and interworking with other systems. However, it is also true that “in the absence of a standard” that there are vendor-specific solutions which may be better for an application. To choose to strictly adhere to, or, perhaps, to eschew, standards absolutely is to potentially miss-out on value-adding features or take foolish and unnecessary risks. The alternative is to take measured steps which balance the benefits of standards with the benefits of vendor-specific features. To make ‘that’ level of decision is much harder than to follow standards absolutely, but can provide more features, value, and benefits to a system, network, or application overall.
As with all technology decision, the more you speak the Multiple Languages of Technology (see our article entitled “Polyglots, Plutonians, and Mercurians” for more insight) the better your chances are of getting what you “thought” you were going to get…Good Luck!!!