Update Principle definition to clearly identify it as a governance instrument
The current definition of Principle and its associated narrative fails to reflect the true nature of this concept. The use of the term “statement of intent” positions this concept as some sort of goal, and as such therefore, as some sort of planning element. Whereas the true nature of a principle is as a governance instrument, control or rule - none of these words appears in the definition. It follows that principles are the responsibility of governors to set, not business planners.
The most important aspect of principles is that they should be set as an independent governance activity, at the earliest time, based on the context of the enterprise. TOGAF addresses this well, recommending principles be defined whilst establishing an architecture practice in the Preliminary Phase. TOGAF goes on to suggest they are stable, enduring, and few in number.
Regarding relationships, a principle/rule acts primarily as an Influencer over plans and systems, with its influence strength varying according to context. In reverse it could be said that plans and systems must comply with principles otherwise they will not be fit for purpose. Compliance in this case can be represented by the Realization relationship. System elements will actually realise them via requirements, as suggested in the current definition. But Plan/motivation elements should directly realize principles (the reverse of what is currently permitted). In the initial specification introduction 6.3 the suggestions get very awkward. “Data consistency” seems much more like a Principle than a goal; “Data should be stored once” sounds more like a business rule than a principle; and “use a single CRM System” seems more like a constraint than a requirement.
Referring to a principle as a “property” is confusing. A principle is an entity in its own right exerting important influence. Properties are usually thought of as attributes, and as such would not be modelled in diagrams. Although there is a role for properties/attributes that will be explained shortly.
The revised proposed definition is partly based on the TOGAF Framework, the Business Motivation Model (which has also influenced this subject in the Specializations section 15.2.5) and also on the BCS Enterprise and Solution Architecture Reference Model (https://www.bcs.org/media/1937/sd-esa-reference-model.pdf).
The proposal is we rename this element “Directive”. Its main definition is “A Directive is a governance instrument or control which guides and shapes motivation, strategy and system elements.”
The following narrative is suggested…
“Directives exist to ensure systems takes account of enterprise missions and plans, strategy initiatives, external constraints (particularly legislation), current systems and technology, and emerging industry trends. Failure of any element to abide by directives (either directly or indirectly) could result in it not being fit for purpose.
Directives are established as part of architecture governance activity. They should be stable and enduring, though capable of very occasional updating if circumstances demand. Most importantly, Directives have influence over ALL systems.
The main relationship of directives is that they Influence motivation, strategy and system elements. To represent compliance with directives, motivation and strategy elements can realize Directives directly. System elements will realize them indirectly via Requirements, which in turn realise directives.
A directive has a “Control Type” attribute which can assume the following three values:
- “Principle”: this is a general form of Directive, possibly not directly actionable (i.e. abstract), and they are likely to be few in number (the TOGAF Framework identifies 21 principles). Principles may well enact corporate values, or establish areas where governance is particularly needed, i.e. “Maximise benefit for the Enterprise”, “Data is an Asset”, “Everything we do must be Secure”
- “Policy”: a policy, or “business policy” exists to provide guidance or interpretation of principles. Policy-making is a recognised activity, often to ensure governance obligations are clearly recognised, i.e. “Access to all data must be controlled”, “Staff must receive formal training on their security responsibilities”
- “Rule”: a rule, or “business rule” is a way to directly constrain or limit. It is the most fine grained way to assert governance, i.e. “Roles must be identified that are allowed access to data”, “all staff will undertake a security assessment annually”, “Data must be encrypted to a level commensurate with its sensitivity”. An important quality to bear in mind about rules is that they are enacted via requirements so that the rule can be asserted in a context-sensitive way. So possible requirements might be “this commercially sensitive data will be encrypted to 256k level”, “this commercially sensitive data can only be viewed by senior managers”.
It follows from the examples above that there can be a hierarchical relationship between Principles, with policies as guides, and rules to precisely constraint, although there is no strict imposition of this in the specification. The granularity of architecture could mean that Enterprise architects deal mainly with Principles and perhaps Policy; Solution or capability architects may deal with policies and rules.
Regarding iconography, a principle is identified by a single exclamation, policy a double exclamation and a rule a triple exclamation icon. Backward compatibility can be maintained by making sure that any existing "Principle" elements are shown as a Directive with the "Principle" attribute selected.”