EA-PRC-004 – Enterprise Architecture Compliance Review Process


The purpose of the Enterprise Architecture Compliance Review Process is to describe how and when compliance reviews are undertaken, by whom and indicate possible outcomes of the process.


The audience for this procedure is composed of any individual or team, acting in the capacity of a Technical Architect, who is undertaking any area of work, the product of which is likely to change the enterprise architecture of Plymouth University, this includes all architectural domains (business, application, information (including data) or technology domains).



One element of the enterprise architecture function is to ensure continued alignment between solutions implemented within Technology and Information Services (TIS), the enterprise architecture for the organisation and the identified requirements from the business.  This process identifies the points where an architecture review is required, the responsibilities of each party within the process and resultant outcomes.  It is important to understand however, that a statement of non-compliance as a result of this process being undertaken is, in itself, insufficient to stop any given piece of work continuing.  Should such a result occur, a risk will be added to the appropriate risk register to highlight the issue, if the risk is sizeable enough, scoring a total of 9 (3 x likelihood and 3 x impact) on the risk register, the problem will be escalated to the TIS management team, with recommendations as to the future of the work and possible remediation.  This will aid the continued identification of risk to the wider business as the quantity of non-architecturally compliant solutions increase; this risk to the business also increases, manifested particularly when a combination of non-compliant solutions supporting the business are in place.


The purpose of this procedure therefore, is to monitor at identifiable points throughout development, delivery and operation the compliance of any piece of work initiated within Plymouth University which is either delivered and operated by TIS or impacts the underlying architecture of the University.  There are several entry points to this process, these are:

  • Following an architectural development cycle prior to work packages being released from the Technical Architecture Group (TAG)
  • During any piece of work undergoing delivery, where decisions made within the project or other delivery body result in the architecture being delivered deviates from what has been previously agreed and/or assessed.
  • Where a change or improvement initiative, with or without the knowledge of Strategy and Architecture, is likely to result in any change to any underlying architecture domains.

The procedure is intended to protect the stability and understanding of the enterprise architecture at Plymouth University from any unauthorised change to, or deviation from Enterprise Architecture policy, procedures, principles, standards, guidelines, best practice or the architecture itself and allow the future state of IT at Plymouth to be built upon solid known foundations.  As such the review procedure will take into account the following areas during assessment activities:


Depending on the type of work being undertaken or the stage the work has reached, some of the following items may not exist or be named differently; this will be taken into account during the review.

  • Project management plan (or equivalent)
  • Business requirements documentation (always required)
  • Technical and/or functional specifications (always required)
  • Architecture diagram (or equivalent)
  • Work package documentation
  • Any previously issued architectural waivers

Assessment Areas

All work will be assessed on the following four areas and scored appropriately within the context of the type of work being undertaken and the stage at which the work has reached.

  • Overall view of whether the concepts of architecture in the broadest sense have been considered within the work to date
  • The high-level design
  • Other non-functional architecture/design considerations
  • Governance and alignment with the existing enterprise architecture and associated constraints.

Possible Outcomes

There are three possible outcomes from an Architecture Review:

  • Compliant (Approved)
  • Non-Compliant (Not-approved)
  • Non-Compliant (Approved via CIO Waiver)

The Assessment

The following is the step-by-step process for undertaking the Enterprise Architecture Compliance Review:

  1. The Enterprise Architect will be requested by the Technical Architect to undertake the compliance review.
  2. The Technical Architect will provide the Enterprise Architect with all pertinent information to allow review to be performed.
  3. The Enterprise Architect will complete the Architecture Compliance Review based on all available information and store within the Architecture Review bank.  Compliance reviews will be carried out on a weekly basis.
  4. Upon completion, the Enterprise Architect will complete an Architecture Compliance Statement, which will be stored alongside the review and a copy forwarded to the Technical Architect who will liaise with other relevant parties to inform them of the outcome.
    1. If the architecture is found to be compliant, the information will be logged to allow the Enterprise Architecture to be updated at a later date.
      1.  The Enterprise Architect may, if required, find the architecture compliant subject to remedial work, if this is the case, the Technical Architect must provide the reworked architecture as soon as is practical within a calendar month.
    2. If found to be non-compliant, a risk will be added to the appropriate risk register to this effect.
      1. If found to be non-compliant the decision may be escalated via the IT Management team to CIO for approval by waiver, if successful the compliance statement will be updated accordingly.
      2. If the risk score on the register is 9 (3 x likelihood and 3 x impact) the Enterprise Architect may issue recommendations to the IT management team as to the best way forward, which may include suspension of work until the risks have been mitigated.


Enterprise Architecture Review Process Schematic

Compliance Review



Author: Craig Douglas Date: 01/12/2014 Version: 1.0
Document Security Level: PUBLIC
Document Approvals: Technical Architecture GroupHead of Strategy and Architecture 08/12/201412/12/2014
Review Date: December 2015