Contents of an Identity IF

As shown in Figure 17-1, an IF contains three primary kinds of standards:

External standards

Examples might be the kinds of XML standards, such as SAML, that we discussed in Chapter 11.

Software standards

These are software choices that the organization has made. An example might be a decision to support MySQL or Linux.

Hardware standards

These are specific hardware choices that affect interoperability. The organization may set some hardware standards strictly as a purchasing decision. Those would not typically be included in the IF. Inclusion in the IF should be done on the basis of interoperability benefits rather than purchasing power or efficiency.

Each of these may be broken into subareas, as necessary, and in each subarea choices are enumerated and documented. In addition to sections enumerating standards, an introductory section should contain the following information:

An interoperability framework provides the foundation for the policy stack

Figure 17-1. An interoperability framework provides the foundation for the policy stack


Guidelines for use

This section describes how the document is to be used.

Governance

This section describes the governance procedure that created the IF and how the IF can be changed. This section also describes the review cycle for the overall document.

Application

This section describes the scope of the IF and where it should be applied.

Exemptions

This section enumerates any global exemptions and provisions for requesting exemptions.

Each standard in the document will have a status that indicates whether following the standard is mandatory or not. There can be any number of status levels depending on the needs of the organization. The following are adapted from the status levels that we used in the State of Utah to define an IF:

Approved and de facto standards represent areas where there is significant technical or monetary investment. Approved standards are the most powerful designation for creating standard environments and conventions to promote interoperability.

Sustained and sunset standards are generally nearing the end of a lifecycle and should be avoided for new development without extenuating circumstances. There will always be legacy standards in the organization. Those that the IMA intends to support should be designated as sustained. One goal of the IF is to ensure that standards don't outlive their useful period and are retired when convenient for the organization. The sunset designation is the architect's tool for moving the organization away from standards that are no longer serving a purpose and should no longer be used.

Emerging standards show promise and are likely to become approved standards after they have proven themselves in a pilot project or other demonstration. The emerging designation is the architect's tool for calling attention to new standards and encouraging their use.

For each standard, the IF should list the following information:

Description

The description might be as simple as the name of the standard if sufficiently descriptive.

Reference

This would typically be a URL pointing to the location of the standard. For internal standards, the reference could be a URL for the document or other internal ID.

Status

This would give the status of the standard as discussed above.

Review cycle

This notes the recommended review schedule (e.g., annually, biannually, etc.)

Notes

This is the place to list any additional information. Use this section to describe motivation or refer to a larger document that does so. This is also where conditions for use or exceptions can be noted.