Architecture rules

Add a comment

An attempt to articulate basic rules that apply to any kind of architecture.

The objective is to increase awareness and quality, as far as architecture is concerned.

Rules are expressed below, at level 3 of title. Text includes comments (normal paragraphs).

1.1. Quality of representation

1.1.1 An architecture diagram describes a single aspect

Avoid mixing elements form different nature.

According to the “separation of concerns” principle.

Only views can mix several types of things, for a specified need for communication.

1.1.2 Every element of an architecture diagram is unambiguous

Given the aspect the diagram deals with, the nature of all elements of the diagram must comply with the metamodel of this aspect.

The list of elements includes the nodes and the connections.

1.1.3 The existing or necessary connections between the elements are clear

A diagram which just identifies the nodes of the architecture without considering their connections is not sufficient.

Architecture is precisely about the way things are linked together.

1.2. Quality of an architecture

1.2.1 Architecture aims at expelling redundancy

The best architecture is one that designs a system without redundancy.

This statement applies also to the business aspects.

Sometimes, decisions are made to consciously add redundancy in the system. In such cases, the rationale has to be expressed. It can be for performance or security reasons.

1.2.2 Architecture aims at reducing coupling

The optimal architecture is the one that minimizes coupling, while delivering the proper services.

The analysis of coupling encompasses:

  • A quality perspective: numbers and places of dependencies, building up a network that defines the architecture qualitatively.
  • A quantity perspective: frequency and volume of the interactions that occur at the interfaces (mathematically speaking, architecture is a valued graph).

NB: there is a balance to be found between redundancy and coupling, whatever the aspect analyzed.

1.3. Continuity

1.3.1 Any architecture representation is continued through more detailed representations or models

1.3.2 For a given aspect, architecture (the overall view) and design (the detailed view) adopt the same notation

That implies that they rely on the same metamodel (which is more important).

1.3.3 The detailed design obeys the high-level decisions and principles that have been stated through the architecture

Relation between enterprise architecture and solution architecture

This statement implies a certain discipline to be imposed to the projects. Related to EAM (Enterprise Architecture Management)

1.4. Justification

1.4.1 All decisions of architecture have to be documented and justified

1.5. Traceability

1.5.1 All decisions and elements imposed by architecture of a given aspect have to refer back to elements situated in antecedent aspects

1.6. Quantification

1.6.1 Whatever its aspect, level or scope, the documentation of a system includes quantitative information

Without this information, the decision-making comes to be difficult or hazardous.

Some examples:

  • Semantic aspect: number of instances for a given concept or business objects, frequency of change…
  • Logical aspect: volumes of flows through the system as it is designed by the logical architecture graph.
  • Physical aspect: consequences for the data storage, for the networks and the machines.

1.7. Capitalization

More about EAM than architecture description.

1.7.1 The architecture description needs to be progressively consolidated

1.7.2 Every significant project delivers models compliant with the target architecture

1.7.3 These models are poured into a central repository in order to enrich the architectural vision and to get available for he community

This entry is filed under methodology. And tagged with , , , . You can follow any responses to this entry through RSS 2.0. You can leave a response, or trackback from your own site.

  1. No Comments

Please leave these two fields as-is: