“Forgettable” Principle

Added a “Forgettable” principle on the back of the GDPR “Right to be forgotten” and some exploration of the need for backups in Office 365 – which lead to retention policies and version and recycling bins etc.

This principle will need to be realized by Requirements in Policies that any personal data can be deleted on request.

In practice this may be easy (as in no personal data stored), to hard.  General File Stores (File Shares, OneDrive, SharePoint) likely being the worse to deal with – locating the documents, actually deleting them, remembering various recycling bins – both user and system, and battling against any other retention policies.  Then for most of systems there’s the problem of re-applying the delete should a full system restore be required.  Backups may still contain “forgotten” personal data…

Posted in Enterprise Architecture | Tagged , | Leave a comment

Architecture Principles Policies and Tenders

Obviously Architecture has a key role to play in the tendering process.  So starting with the Tender document – this is the specification for a solution.  Much like policies and SLAs it is set of requirements and constraints many (all?) of which in turn realise the Architectural principles.    So the categories of requirements and constraints in a tender look like this…

  1. Requirements and Constraints from existing policies and SLA/OLAs appropriate to the solution.
  2. Requirements and Constraints which will form the SLAs/OLAs for the new solutions.
  3. Functional requirements and constraints.

The first category will always exist, but categories 2 and 3 will vary depending on the extent to which the solution sought is a plug in replacement versus a solution for a new service.

I’m going to try this approach with the Role Based Access (RBAC) Project.  This project aims to add Role Based Access functionality to an environment which already has an long established Identity Management service. Having talked and see demonstrated a number of RBAC solutions, we now have a fairly good idea of the art of possible and leads to two possible sets of tender requirements.

One set of requirements aims to augment the existing IM solution, the other replaces the existing IM solution.  Several architectural principles comes in to play here:  “Reuse”, “Single Master” and “Standardize”.  

In the “Augment” model, the existing IM solution is reused and continues to deal with identities.  However, unless the RBAC solution comes from the same supplier as the IM, we will end up with duplicate solutions in contravention of the “Standardize” principle.  We also likely end up in contravention of the “Single Master” principle if we essentially have two identity databases which can’t be synchronised.  Based on what we have discovered from suppliers this model can only result in the same supplier option.    This assumes that the existing IM solution has been assessed against architectural principles and policies already and not found wanting.  In our case, this is yet to be done as the Architecture Policies, OLAs, and SLAs are still being developed.

In the “Rip and Replace” model we start ticking the boxes if looking at the final solution as both IM and RBAC are the same system.  But at what cost?  We are “Ripping” out a complex system which connects to multiple other systems, having to pay for re-implementing the same workflows etc.  So this solution could easily fail the “Viable” principle.  

So we have an interesting conflict between procurements normal – “Tender to a set of requirements” and an architecture approach which has the ability to decide between two models based on alignment to principles and some initial quotes.  Our procurement department has, in the past, tolerated single supplier purchases on the grounds of compatibility, but external financial polices limit this.  

Posted in Enterprise Architecture | Leave a comment

“Supported” Principle Added

Added a “Supported” Technology Principle. It also applies to security as a principle. It’s aim is to require solutions to have support from vendors available to the University. This is to ensure that if security vulnerability or problems arise there is fast access to fixes and help.

Having support for a 3rd party product is key to providing a reliable and available service.  It is rare that the University has the skills or knowledge to fix a product directly.  Although often an internet search will reveal a fix or a mitigation, it’s only the vendor or authors who can really fix it.   

So support is akin to AA/RAC membership, you really don’t want to pay for it or use it, but there is one day when your rear diff dies on a family holiday – you’re so pleased you were a member!

Obviously there are many models for support depending on the vendor.  Key for core infrastructure is time to fix.  It’s no good having to wait for the open source author to find the time to get around to fixing something, a critical problem needs a fast fix.  At the other end of the scale, a bleeding edge research project could sacrifice fix speed or even security for functionality in some specialist software.

The key implications for infrastructure are:

  • Open Source software needs to have proper support.  This limits the choice of open source software for which such mechanisms exist.  Typically, these are “Enterprise” versions of open source software such as RedHat Linux, Nagios Enterprise, etc.  There’s other advantages with the Enterprise SKUs in that they are typically supported by other Enterprise software – e.g. Hardware monitoring agents, asset management, VMware tools.
  • There is a proper process for rolling out fixes in a timely manner.  The process should be able to try out a fix in a test environment before deployment.  This gives confidence in being about to apply these fixes to the live production environment even during important times in the University calendar such as clearing, enrollment.
  • Running solutions which are no longer supported is not an option, or it if it a necessity (no replacement available, required to keep to access legacy data, etc.), then suitable mitigations are in place – e.g. isolation.
Posted in Enterprise Architecture | Tagged | Leave a comment

“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.

Posted in Enterprise Architecture | Tagged , | Leave a comment

Architecture Principles

Always, it seems EA’s start by coming up with the Architecture Principles a la TOGAF, so I’ve explored this area and have produced some for Swansea University.

I started out looking at a number of other organisations principles, some had just taken theirs pretty much straight from the TOGAF book, others had their own ideas.  One particular (Birmingham University) caught my eye as they had used ArchiMate’s “Principle” Artefact and could therefore tie principles to other Artefacts – Goals, and Drivers.

I also read some of Gerben Wierda’s advice that principles should describe “Good Architecture” and that if a Principle has a lot of exceptions then it is not a good principle.

In general I tried to select single word names for the Principles in order to help with the use of Archimate.

As I started analysing various principle ideas, it became apparent that…

  1. Some principles appeared to apply to the process of running an Architecture Practice, or even other Business Processes rather than the Architectures itself.  e.g. “Information is Everybody’s Business”.  So these were NOT Architecture Principles.
  2. Principles can be faddish or not universal enough resulting in lots of exceptions – e.g. “Cloud First” or “Service Orientation”, or “Agile.   So Agile may apply to some I.T. Services processes, but not in say HR or Finance.  “Cloud First” implies solutions may not be “Best Fit” for all the requirements.
  3. Principles don’t always fit into the TOGAF four layers that well, e.g. many “Data” principles seem to be security focused, and therefore could equally apply to Business, Application, Technology  layers.
  4. Because Principles generally are described by short phrases or simple names, there was plenty of scope for ambiguity – e.g. “Data should be shared” which comes across to me as public availability of data, rather than the intended “single source of truth”.

So I added a few rules to follow…

  1. Principles describe what good Architecture Looks like.
  2. Principles should apply to the majority of architectures.
  3. Principles should be timeless. “Eternal Verities”.

These types of principles can be used to assess the existing Architecture as well as design new ones.

Swansea University Principles are on the iServer Portal

However, having come up with a fair number (probably too many) principles and looking for more within the GDPR world, I realized that many were connected to University Policies, which were in turn underpinned with Principles.  And these in turn were constrained by Legal Requirements many of which start out with Principles.  Obviously, Policies can have much more detail in them that the more abstract Principles.

So the question arises “Should Polices replace Principles for Architectures?”

Posted in Enterprise Architecture, Uncategorized | Tagged | Leave a comment