Standards give governance an unambiguous basis, because they are accessible (obligations can be understood and planned for) and clear (compliance can be judged objectively).
| Class of standard | Source | How it is managed |
|---|---|---|
| Legal and regulatory obligations | Required by law | Must be met |
| Industry standards | Industry bodies, selected for adoption | Aid interoperation but lie outside the enterprise’s control, so need monitoring |
| Organizational standards | Set internally from business aspirations (for example, standard applications to aid consolidation) | Need exemption and evolution processes |
| Lifecycle state | Meaning | Practical effect |
|---|---|---|
| Proposed | A candidate not yet evaluated | Awaiting evaluation |
| Provisional / Trial | Not yet proven enough to be mainstream | Pilot use only |
| Standard / Active | The mainstream choice | The default |
| Phasing-Out / Deprecated | Nearing the end of its life | Existing components may be re-used; new instances are discouraged |
| Retired / Obsolete | No longer valid | Removal is remedial and handled only within a decommissioning plan |
Standards are reviewed periodically and the impact of any status change assessed. They are organised by metamodel building block and, at the top level, by domain: Business (shared capabilities, role and actor definitions, business-activity security and governance), Data (coding, formats, ownership, replication and access rules), Applications (shared applications, interoperation, presentation and style) and Technology (hardware and software products, development standards). Figure 14.1 shows how the three classes of standard feed the five lifecycle states.
Common trap: A deprecated standard means existing systems must be replaced immediately - only new instances are discouraged; removal comes at the Retired stage, through a decommissioning plan.