Standards differ from policies in that they are defined by an external organization, whereas policies are defined internally.
While I often have to battle counterproductive policies, standards are usually more supportive of my design efforts.
I recommend that this chapter contains a table with the following columns:
| Standard | Description | Design notes |
|---|---|---|
| Country codes (ISO 3166-1 alpha-2) | Service contracts use field type definitions that ensure that field value conform to the standard. | |
| Currency codes (ISO 4217) | Service contracts use field type definitions that ensure that field value conform to the standard. | |
| ArchiMate | Modeling standard popular amongst architects. | Since many readers of this solution architecture document are unfamiliar with the ArchiMate standard, and to save time on documentation, the standard is either followed loosely, and many diagrams are more inspired by the UML standard. All illustrations are accompanied by text, which relieves the reader of having to know any underlying modeling standards. |
Some types of businesses choose to adopts domain specific standards – here are a few examples:
- ARTS – A set of standards for the retail domain.
- GLEIF – A standard (and technology) for registering financial organizations.
Some business domain standards can be quite counterproductive to the design work. Many tend to be overly theoretical, overwhelmingly detailed, poorly documented and not well-supported. So you may end up spending too much time learning the standard, only to realize later that no-one has made that same effort, making your documentation and code difficult to understand by others.