What is a standard made of?

Everyone knows what a standard is, right?  It's got a schema, and some XML and some UML diagrams.  Somewhere there are references to some fundamental pieces, and there's a set of services that are being defined.  Well, uhm, yes, maybe, or maybe no.

Here's a short list of things that you might find in a standard, or which appear as a standard.

• Actors
• Collaboration
• Conformance Statement
• Data Types
• Domain Analysis Model
• Implementation Specification
• Implementation Guide
• Information Model
• Interaction Model
• Logical Model
• Glossary
• Schema
• Service Specification
• Use Cases

Which of these are standards and which of these are parts?  It's a trick question.  Every one of these has been the principle component of some form of standard or another.  And I'm also missing a bunch of parts.

Understanding the parts, and how the pieces fit together, and how "your" standards community uses them is one of the biggest challenges for new standards developers.  

There are two failure modes that commonly crop up with new standards participants:

• Assuming that because they have something to teach, you have nothing to learn.  If you cannot speak in the language of your students, how will you connect with them?  Especially if you aren't already in a traditional teacher/student set of roles, but rather in the role of equals?  This is especially a problem with experienced developers who are just being introduced to a new body of work or an SDO for the first time.
• Learning the vernacular, buying into the methods, and forgetting to look beyond it.  There's never just one way to do things. This happens more often with less experience developers. Once you get it, see how you can apply it to something else, and alternately, how you can apply other things to it.  If you think your method is perfect, think again.  It isn't.  At least as far as I have seen in any SDO I've been engaged with.

Interestingly enough, those same two failures crop up pretty often in the old guard as well.

Here is my suggestion for how to approach this: 

1. (Pretend to) throw away what you know. 
2. Learn the vernacular of the body that you are working with. 
3. Internalize and incorporate it into what what you know and vise verse.

Lather, rinse and repeat as often as necessary.