Qu'est-ce qu'un principe d'architecture ?

[christianfelicite]

https://pubs.opengroup.org/architecture/archimate301-doc/chap06.html

A principle represents a qualitative statement of intent that should be met by the architecture.

Principles are strongly related to goals and requirements #204.

Similar to requirements, principles define intended properties of systems.

However, in contrast to requirements, principles are broader in scope and more abstract than requirements.

A principle defines a general property that applies to any system in a certain context. A requirement defines a property that applies to a specific system as described by an architecture.

A principle needs to be made specific for a given system by means of one or more requirements, in order to enforce that the system conforms to the principle.

For example, the principle “Information management processes comply with all relevant laws, policies, and regulations” is realized by the requirements that are imposed by the actual laws, policies, and regulations that apply to the specific system under design.

A principle is motivated by some goal #206 or driver #205. For example, the aforementioned principle may be motivated by the goal to maintain a good reputation and/or the goal to avoid penalties. The principle provides a means to realize its motivating goal, which is generally formulated as a guideline. This guideline constrains the design of all systems in a given context by stating the general properties that are required from any system in this context to realize the goal.

Principles are intended to be more stable than requirements in the sense that they do not change as quickly as requirements may do.

Organizational values, best practices, and design knowledge may be reflected and made applicable in terms of principles.

[christianfelicite]

http://www.emmanuelgeorjon.com/archimate-les-elements-de-motivation-5684/

[christianfelicite]

https://cio-wiki.org/wiki/Architectural_Principles

[christianfelicite]

https://pubs.opengroup.org/architecture/togaf8-doc/arch/chap29.html

Components of Architecture Principles

It is useful to have a standard way of defining principles. In addition to a definition statement, each principle should have associated rationale and implications statements, both to promote understanding and acceptance of the principles themselves, and to support the use of the principles in explaining and justifying why specific decisions are made.

Name

Should both represent the essence of the rule as well as be easy to remember. Specific technology platforms should not be mentioned in the name or statement of a principle. Avoid ambiguous words in the Name and in the Statement such as: "support", "open", "consider", and for lack of good measure the word "avoid", itself, be careful with "manage(ment)", and look for unnecessary adjectives and adverbs (fluff).

Statement

Should succinctly and unambiguously communicate the fundamental rule. For the most part, the principles statements for managing information are similar from one organization to the next. It is vital that the principles statement be unambiguous.

Rationale

Should highlight the business benefits of adhering to the principle, using business terminology. Point to the similarity of information and technology principles to the principles governing business operations. Also describe the relationship to other principles, and the intentions regarding a balanced interpretation. Describe situations where one principle would be given precedence or carry more weight than another for making a decision.

Implications

Should highlight the requirements, both for the business and IT, for carrying out the principle - in terms of resources, costs, and activities/tasks. It will often be apparent that current systems, standards, or practices would be incongruent with the principle upon adoption. The impact to the business and consequences of adopting a principle should be clearly stated. The reader should readily discern the answer to: "How does this affect me?" It is important not to oversimplify, trivialize, or judge the merit of the impact. Some of the implications will be identified as potential impacts only, and may be speculative rather than fully analyzed.

[christianfelicite]

https://cio-wiki.org/wiki/Architectural_Principles

The Benefits of Architecture Principles[7] Architecture principles epitomize architecture's function: to clearly define the necessary constraints on a system's design without prescriptively defining all the design details. Architecture principles help establish boundaries and priorities without micromanaging how everyone performs their work. A good set of architecture principles offers the following key benefits.

Context for Design Decisions

Principles can clarify priorities and constraints, helping people make consistent, informed design decisions. In fact, I've found they can make abstract ideas such as business goals more accessible and help designers make technical decisions that support them. I'll return to this idea in more depth in a future column.

Justification for Decisions, Cost, and Time

As designers, we often face situations in which the right plan costs more or takes longer than we'd like, but it's difficult to explain clearly and succinctly why it's the right plan. A set of clear principles can provide a basis for that explanation. For example, the principle that all systems must be suitable for high-availability deployment might justify building multinode operation capabilities into all systems, even if this isn't the cheapest option for the immediate future.

Enhanced Collaboration, Communication, and Shared Values

Like many architecture artifacts, principles must be developed by groups, not individuals. This ensures that they're validated early and that the group feels collective ownership of them. Moreover, this helps people collaborate and build shared values, fostering a mutual understanding of what is and isn't important.

[christianfelicite]

https://architecture-center.com/blog/116-the-8-togaf-architecture-principles-you-need-to-know.html

[christianfelicite]

https://pubs.opengroup.org/architecture/togaf8-doc/arch/chap29.html

Qualities of Principles

Merely having a written statement that is called a principle does not mean that the principle is good, even if everyone agrees with it.

A good set of principles will be founded in the beliefs and values of the organization and expressed in language that the business understands and uses. Principles should be few in number, future-oriented, and endorsed and championed by senior management. They provide a firm foundation for making architecture and planning decisions, framing policies, procedures, and standards, and supporting resolution of contradictory situations. A poor set of principles will quickly become disused, and the resultant architectures, policies, and standards will appear arbitrary or self-serving, and thus lack credibility. Essentially, principles drive behavior.

There are five criteria that distinguish a good set of principles:

• Understandable: the underlying tenets can be quickly grasped and understood by individuals throughout the organization. The intention of the principle is clear and unambiguous, so that violations, whether intentional or not, are minimized.
• Robust: enable good quality decisions about architectures and plans to be made, and enforceable policies and standards to be created. Each principle should be sufficiently definitive and precise to support consistent decision-making in complex, potentially controversial situations.
• Complete: every potentially important principle governing the management of information and technology for the organization is defined. The principles cover every situation perceived.
• Consistent: strict adherence to one principle may require a loose interpretation of another principle. The set of principles must be expressed in a way that allows a balance of interpretations. Principles should not be contradictory to the point where adhering to one principle would violate the spirit of another. Every word in a principle statement should be carefully chosen to allow consistent yet flexible interpretation.
• Stable: principles should be enduring (i.e. durable ...), yet able to accommodate changes (... ET POURTANT capable de s'adapter aux changements). An amendment process should be established for adding, removing, or altering principles after they are ratified initially.

[christianfelicite]

https://cio-wiki.org/wiki/Architectural_Principles#cite_note-6

Categories of Architecture Principles

Business Principles - Provide a basis for decision-making throughout the business

• Principle 1 – Primacy of Principles
• Principle 2 – Compliance with Statutory Obligations
• Principle 3 – Maximise Benefit to the Enterprise
• Principle 4 – Information Management is

Everybody’s Business

• Principle 5 – Business Continuity
• Principle 6 – Common Use Applications
• Principle 7 – IT Responsibility

Data Principles - Provide guidance of data use within the enterprise

• Principle 8 – Data Security
• Principle 9 – Data is an Asset
• Principle 10 – Data is Shared
• Principle 11 – Data is Accessible
• Principle 12 – Data Trustee
• Principle 17 – Data will be Analysable

Application Principles - Provide guidance on the use and deployment of all IT Applications

• Principle 13 – Technology Independence
• Principle 14 – Ease of Use
• Principle 18 – Purchase rather than Develop

Technology Principles - Provide guidance on the use and deployment of all IT Technologies

• Principle 15 – Requirements-Based Change
• Principle 16 – Control Technical Diversity

[christianfelicite]

https://pubs.opengroup.org/architecture/togaf8-doc/arch/chap29.html

Developing Architecture Principles

Specifically, the development of architecture principles is typically influenced by the following:

• Enterprise mission and plans: the mission, plans, and organizational infrastructure of the enterprise.
• Enterprise strategic initiatives: the characteristics of the enterprise - its strengths, weaknesses, opportunities, and threats - and its current enterprise-wide initiatives (such as process improvement and quality management).
• External constraints: market factors (time-to-market imperatives, customer expectations, etc.); existing and potential legislation.
• Current systems and technology: the set of information resources deployed within the enterprise, including systems documentation, equipment inventories, network configuration diagrams, policies, and procedures.
• Computer industry trends: predictions about the usage, availability, and cost of computer and communication technologies, referenced from credible sources along with associated best practices presently in use.

[christianfelicite]

Exemples :

https://pubs.opengroup.org/architecture/togaf8-doc/arch/chap29.html

[christianfelicite]

https://docs.microsoft.com/en-us/dotnet/architecture/modern-web-apps-azure/architectural-principles

"If builders built buildings the way programmers wrote programs, then the first woodpecker that came along would destroy civilization."

Gerald Weinberg

[christianfelicite]

JAVA Design Patterns: Principles

[christianfelicite]

https://www.larousse.fr/dictionnaires/francais/stable/74409

Stable, définition

Qui repose solidement sur sa base et dans une position d'équilibre bien assurée : Fondations stables.

Qui se maintient durablement dans tel ou tel état : Une monnaie stable.

Se dit de quelqu'un dont la conduite est marquée par la constance, la permanence : Avoir une humeur stable.

Chimie

Se dit d'un corps qui ne peut être décomposé que par une forte élévation de température, ou sur lequel les réactifs chimiques ont peu d'action.

Physique

Se dit d'un équilibre présenté par un système qui, écarté de sa position d'équilibre, y revient.

Pyrotechnie

Se dit d'une substance explosive qui ne s'altère pas spontanément.