“Should Polices replace Principles for Architectures?”

So after building a library of Architecture Principles, I started modelling associated Policies – starting with the SU Security Policy, which in turn is influenced by GPDR legislation and other “voluntary” standards like ISO27001 and Cyber Essentials.

In ArchiMate, these were modelled as Requirements (for ISO27001 and Cyber Essentials) – I.e. “SHOULD” and Constraints (a tighter sub type of Requirement) for the Legal  i.e. – “MUST” and “WONT”.   These policies in reality would comprise multiple clauses which would be a mix of Requirement and Constraint Artefacts and these “Realise” the Principles.  IF all clauses are requirements (no hard constraints) then the Policy can be represented as an ArchiMate Requirement, if it contains constraints (as most will), then the Policy is also modelled as a ArchiMate Constraint.

The consequence of this modelling is that Principles are a “broad brush” type of Requirement and Architectures must actually comply with Requirements and Constraints set out in Policies rather than Principles in these cases – e.g. Security,   Accessibility (Disability), Welsh Language, etc.

Following this idea through then leads to the idea that ALL Principles should be realised by Architecture Policies of some kind, and it’s these in turn that shape the Architecture.  So with a complete set of policies realizing all the principles, there leads to an obvious connection with the questions that can be asked during the Outline Business Case process, or any tendering process.  So each Requirement or Constraint leads to some metric to measure a potential solution against.  Other collections of Requirements and Constraints come in with SLAs and OLAs in relation to principles like “Recoverable” (defining the return to service metrics), or “Resilience, Authorised etc.   SLA/OLA could also realise a “Performant” principle.  Noting that this implies that SLA/OLA should be defined before a new Solution is sought.

In the end all these policies, SLAs, Tender documents etc, are all just sets of Requirements and Constraints and it’s these that really dictate what a solution looks like.

So here’s a bit of an experiment in ArchiMate to show these ideas.  It also shows how risks can be represented and related to the constraints, and how a work package (project) fits in to achieve the goal to improve security and remove the risk.

This entry was posted in Enterprise Architecture and tagged , . Bookmark the permalink.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.