The term “standard”
A standard can loosely be defined as the agreement that from now on some thing or best practice should always be used, most likely because its success has been proven in the past. This definition is general enough to apply to the standardization of e.g. processes, types of technology, or even dress-code if necessary.
Deck of cards principle
Rules and ComponentsConsidering the set of all architecture standards, two subsets can be distinguished:
- First of all, there is a set of “things” that are mandated to be used in certain situations. Examples are standard tools, platforms, models, and software components.
- The second subset of standards can be thought of as rules: things you should do or properties that systems should have. A typical example here is the fact that sensitive data must be encrypted with certain algorithms and a specific key length.
The specifics of a standard rule are documented in a standard specification. The following example illustrates this. In a standard rule named “data specification” it is asserted that an organizations specific naming convention should be used when making data models. The actual lists of names that are allowed are documented in the standard specification that is associated to that standard rule. There is an extra advantage of separating between the “core” of the standard, as documented in the rule, and the details, documented in a specification. If some detail changes, this change can be processed in the specification without having to put the actual standard through a whole process of revision. We will elaborate on this kind of processes in part 5 of this series.
Some of the standard components are actual tools. We tend not to use these tools “out of the box”, but we configure them in a specific way. Therefore, these configurations may be associated to standard components. For example: the standard component for architecture modeling is a tool called BiZZdesign Architect. This tool can be configured to automatically follow certain naming conventions, layout options etc. That is why a dotted relationship between a configuration and a specification is depicted in the diagram above.
- Enterprise Security Standard:
- Rule: All solutions and applications should comply with the enterprise security standards such as identity management, access management, auditing and monitoring, and information control.
- Details of each of the security domains mentioned could be documented in separate specifications.
- Also relationships to standard components that support the security standards can be created. The standard components refer to physical technology components that the organization chose to adopt.
- The technology components are configured in such way that it meets the security standards and all the detail of it as documented in the various specifications.
- Enterprise Integration Standard:
- Rule: All solutions and applications should comply with the enterprise standards for service oriented architecture (SOA). All interfaces from and to software components should comply with the enterprise standards for interface definition.
- Details and specifics of how the interfaces should be defined can be documented in separate specifications.
- Relationships to standard components can be created. These components describe specific platforms and tools that support the enterprise SOA strategy. For example service repositories and the technology used for routing and transformation (i.e. the service bus).