Principles

Operational productivity

Focus on operational productivity by building services that maximise value from resources utilised and ensure quality delivery with minimal waste. Optimise processes for seamless execution, enabling us to do more with the same or less while maintaining standards. 

Effective organisational design

Develop a clear and efficient organisational structure that supports strategic objectives, fosters collaboration, empowers employees to take initiative within their roles, and develops our staff’s talents. Align roles and responsibilities with the University’s services and ensure that decision-making authority is appropriately distributed, fostering professional growth and development.

Transparent data-driven decision making

Ensure data and analytics required to deliver services is accessible and of good quality. Ensure data informs service redesign and can be easily extracted to confirm the effectiveness of these changes and inform future strategic decisions.

Use data and analytics to establish performance indicators for your services and to inform your decision-making process. Be transparent about how this data influences your decisions.  

Ensure that data are designed into processes and staff are trained to understand when data highlights opportunities and issues. 

Cross-Functional operations and communication 

Allow for cross-functional collaboration and communication to ensure the delivery of consistently good quality support and foster a culture of shared problem-solving and innovation. 

Holistic design 
Consider all elements of the operating model when developing services.  

Social responsibility

Prioritise environmentally responsible practices, promote diversity and inclusion, and ensure equal opportunities.

Security, Privacy and Cyber Education

Protect the safety and wellbeing of students, staff and the wider community. Also ensure the protection of sensitive data, systems, and infrastructure from unauthorised access, theft, or damage.

Learning and Adaptability

Develop flexible and responsive services in line with best practice that can adapt to the changing education sector, technological advancements, the demands from an increasingly diverse student and staff body, research funders and unexpected external factors. 

Data are an asset

Data have value to the University and are managed accordingly

Data are an University resource with real, measurable value as they allow the University to create information to enable the day-to-day operations and to aid decision-making.

Accurate, consistent and timely data are critical to ensure a repeatable good outcome for University operations and to ensure accurate, timely decisions.  Corporate assets are carefully managed, and data are no exception.

We must carefully manage data to ensure that we know where they are, that we can rely upon their accuracy, and can obtain them when and where we need to.

Since data are an asset of value to the entire University, data owners must be assigned with accountability for properly managing data.

Data owners must have the authority and means to manage the data for which they are accountable.

The role of the data steward is critical because obsolete, incorrect, or inconsistent data could be passed to University staff and adversely affect decisions or operational activities across the University.

Part of the role of the data steward is to ensure data quality. Procedures must be developed and used to prevent and correct errors in the data and to improve those processes that produce flawed data. Data quality will need to be measured and steps taken to improve data quality including the development of relevant policy and procedures will need to be developed for this as well. 

A forum with comprehensive University-wide data stewardship representation should decide on any suggested process changes.

Data are shared

Users have access to the data necessary to perform their roles and responsibilities; therefore, data are shared across University functions and departments

Timely access to accurate and consistent data is essential to improving the quality and efficiency of University operations and decision-making. It is less costly to maintain timely, accurate data in a single source, and then share it, than it is to maintain duplicative data in multiple sources.

The University holds a wealth of data, but data assets are stored in many, often incompatible, databases. The speed of data collection, creation, transfer, and assimilation is driven by the ability of the University to efficiently share these islands of data across the University.

Shared data will result in improved operations and decisions since we will rely on fewer sources of more accurate and timely managed data for all of our decision-making activities.

This principle of data sharing will continually challenge the principle of data security. Under no circumstances will the data sharing principle cause confidential data to be compromised.

To enable data sharing we must develop and abide by a common set of policies, procedures and standards governing data management and access for both the short and the long term.

For the short term, to preserve our investment in legacy systems, we must invest in systems capable of migrating legacy system data into a shared data environment.

We need to develop standard data models, data elements, and other metadata that defines this shared environment and develop a repository system for storing this metadata to make it accessible.

Metadata management needs to be established and embedded as a capability.

As legacy systems are replaced, we must adopt and enforce common data access policies and guidelines for new application developers to ensure that data in new applications remains available to the shared environment and that data in the shared environment can continue to be used by the new applications.

For both the short term and the long term, we must adopt common methods and tools for creating, maintaining and accessing the data shared across the University.

Data are accessible 

Data are accessible for users to perform their functions

University-wide access to data leads to efficiency and effectiveness for business operations and decision-making.

Data access yields timely response to information requests and improves service delivery. 

Access to data must always be considered from a University perspective.

Staff time is saved and consistency of data and downstream information is improved through well governed data access.

Accessibility involves the ease with which users obtain data.  There is an education task to ensure that all Schools and Units within the University understand the relationship between value of data, sharing of data, and accessibility to data.

The way data are accessed and displayed must be sufficiently adaptable to meet a wide range of University users and their corresponding methods of access.

Access to data does not constitute understanding of the data. Staff should take caution not to misinterpret information. 

Improved documentation of data definitions is required to prevent misinterpretation.

Access to data does not necessarily grant the user access rights to modify or disclose the data. This will require an education process and a change in culture, which currently supports practices of possession, ie, believing data ownership means data belong to individuals or local functions. Electronic records management and retention policies, procedures and systems need to be defined and implemented.

Data are quality assured

Each data element has at least one recognised role accountable for data quality

One of the benefits of a well architected ecosystem is the ability to share data across the University. As the degree of data sharing grows and colleagues rely upon common data, it becomes essential that there is a clear ownership of data and information assets.

Since data can lose its integrity when it is entered multiple times, the data owner will have sole responsibility for data entry, which eliminates redundant human effort and information storage resources.

A data owner is different from a data steward - a data owner is responsible for accuracy and currency of the data, while stewardship responsibilities are broader and include data standardisation and definition tasks.

Real ownership allows the data to be available to meet all users' needs.

The data owner will be responsible for meeting quality requirements levied upon the data for which the owner is accountable.

It is essential that the data owner has the ability to provide user confidence in the data based upon attributes such as "data source". 

It is essential to identify the true source of the data in order that the appropriate data owner can be assigned this ownership responsibility. This does not mean that classified sources will be revealed nor does it mean the source will be the data owner.

Data should be captured electronically once and immediately validated as close to the source as possible. Quality control measures must be implemented to ensure the integrity of the data.

As a result of sharing data across the University, the data owner is accountable and responsible for the accuracy and currency of their designated domains and/or sub-domains, and, subsequently, must then recognise the importance of this ownership responsibility.

Data are protected

Data are secured from accidental or malicious access (or alteration) by unauthorised users, whether in transit, at rest or in storage; and data are made available for legitimate need through authorised processes

Open sharing of data and the release of data (whether for legislative purposes or otherwise) must be balanced against the need to restrict the availability of classified, proprietary, and sensitive data or information.

Existing laws and regulations require the safeguarding of University security and the privacy of data, while permitting free and open access.

Pre-decisional (work-in-progress, not yet authorised for release) data or information must be protected to avoid unwarranted speculation, misinterpretation, and inappropriate use.

Data are valuable to University business and unapproved access to data – either accidentally or with malicious intent, puts both the data and University’s reputation at risk.

Aggregation of data both classified and not, requires review and declassification procedures to maintain appropriate control.

Data owners and/or functional users must determine if the aggregation results in an increased classification level.

Appropriate policies and procedures to handle the review and  declassification of data are required.

Access to data based on a need-to-know policy will force regular reviews of corporate data assets.

The current practice of having separate systems to contain different classifications needs to be rethought.

Data are reused

Data are more valuable if they can be reused or used for more than one purpose. NOTE: The reuse of personal data, as defined by the Data Protection Act 2018, for a secondary purpose which is incompatible with the purpose for which data were originally collected, is unlawful.

Data are defined by a common vocabulary

Data are defined consistently throughout the University, and definitions are understandable and appropriately published

The data that will be used in the development of applications must have a common definition throughout the University to enable sharing of data.

A common vocabulary will facilitate communications and it is required to interface systems and exchange data.

Information created from data only has value if the data are consistently defined.

Having a systems administrator or dba is not enough to deliver this principle although functional data administration responsibilities must be assigned.

The University must establish the initial common vocabulary for the business (ie, the corporate glossary). The definitions will be used uniformly throughout the University.

Whenever a new data definition is required, the definition effort will be coordinated and reconciled with the corporate glossary of data definitions. The University function with responsibility for Master and Meta Data Management will provide the necessary co-ordination with support from other relevant functions such as Information Assurance and Planning.

Ambiguities resulting from multiple local definitions (usually business domain specific) of data must give way to accepted University-wide definitions and understanding.

Multiple data standardisation initiatives need to be coordinated or standardisation needs to be achieved through relevant projects and programmes.

All data elements have an owner

Every data element has a named owner and ownership persists regardless of the use of that data

Data without an owner is likely to fall into disuse, to be replicated in alternate systems and even to be lost.

Without an owner, it is difficult to evaluate the currency, accuracy and validity of data.

Without an owner, it is unlikely that new systems will be aware of the un-owned data.

Without an owner data silos build up that are difficult to break-down.

Formally identify owners for all data elements in a project.

Embed a change-management process to manage data ownership.

Ensure data owners are involved in projects that their data.

All data elements have a master (a Single Source of Truth)

Every data element has a single, known source (a Master data source) rather than multiple (potentially inconsistent) sources of the truth

Eliminates dispute over which copy of a data item is correct.

The master defines the actual value in all cases.

All databases or storage systems must have a master that acts as the home of the data.

The data owner is responsible for defining the master for each data item.

All changes must ultimately be applied to the master and from there replicated to all copies.

It must be possible to rebuild all copies from the master.

The master should be at least as available as the copies.

The master must be recoverable from backups.

AP01

Build services not applications

Applications will be built as a collection of services that expose an Application Program Interface (API) enabling them to be combined to deliver users what they need.

This facilitates reuse, interoperability and the ability to scale by reducing tight dependencies between components

Cloud-services and SaaS products are expected to have well-defined APIs. When designing a new service for an application, it will need to cover Supplier Management, Availability Management, Capacity Management, Information Security Management and Service Continuity Management.

AP02

User interfaces should be browser-based.

User interfaces shall be delivered as applications.

Ensures that applications are independent of underlying platforms and are easy to use. This enables accessibility across different devices and decreases maintenance and deployment effort.

Applications are web-based as reasonably possible.

Exceptions may arise for functions and services that are constrained by the selected platform, for example mobile apps, or hardware-linked software.

AP03

Pilot new applications and services

Build a prototype, test it with users and learn from it.

It is impossible to accurately predict everything upfront. A try before you buy approach validates investment plans, designs and technologies. Prototypes enable users to provide early feedback about the design of the solution.

Projects must be open to investing and testing new products and services on a small scale in order to de-risk large scale delivery projects. Consultation with Service Management is necessary to aid transition planning for service operation. This is only required for validated solutions that are being recommended for further development.

AP04

Loose-coupling interfaces

Interfaces have loose coupling, are self-described, and offer low impact.

Loose-coupling interfaces are preferable, because when interfaces between independent applications are highly coupled, they are less generic and more susceptible to causing unwanted, secondary effects when they are changed.

Loose coupling means that the services (APIs, for example) are conceived with no affinity to a certain service consumer.

Therefore, the service is completely uncoupled to a service user. However, the service user is dependent of the service (that is, contains references for service interfaces).

The service is also responsible for exception treatment. The result is a low-coupling architecture.

AP05

Minimise customisation

Customising applications should be reduced to a minimum extent as it negatively impacts business agility and operating costs. If customization needs to be implemented, then those customizations must be approved by the BDA Technical sub-group.

Those customizations must adhere to design and implementation standards adopted by the organization.

As applications become more customised, it often leads to difficulty in performing upgrades and can lead to technical debt.

Seek approval for large customisations.

Implement customisation using standard guidelines for design and development. Any customisations must be fully documented including the original reason for customisation.

AP06

Hide internal details

Hide the internal details of services from users to avoid creating dependencies on internal structures and logic that may change. Handle errors and exceptions where they occur to prevent 'cascading errors syndrome’

Keeping the internal structures and logic of services private from consumers of the services frees them to use and combined services in the way that best suits the business of the University.

When implementing applications, focus should be made on user interfaces to ensure any underlying technology or error reporting is not visible.   Technical error reporting should occur directly to technical teams, with useful and directive messages to end user.

AP07

Complementary applications

New applications should always be able to not only interoperate with existing applications, but also compliment them functionally and technically.

As more applications move to SaaS, functional and technical economies of scale may exist by utilising applications from within the same group hosted on the same platform.

Consider existing applications and their hosting arrangements (SaaS, PaaS etc) and whether the new application may have complimentary functionality if housed alongside an existing application.  Also consider and document exit strategy and data portability when choosing complimentary applications.

TE01

Use Open Standards

Open standards must be used in all solution designs to enable interoperability.

Closed proprietary standards restrict reuse, reduce interoperability and can create vendor lock-in that leads to unforeseen financial costs

Evaluate the standards used by technology before selection and implementation. Open standards can reduce complexity and ensure easier interoperability and transferability of applications and data.

TE02

Exploit the Cloud

Solutions will be assessed to determine the benefits of migration to Cloud-based service models for infrastructure, platform and software.

Assessment of architectures, workloads, finance, business risks, operations and security will determine if a solution can be replaced (SaaS), rebuilt (PaaS), re-hosted (IaaS), or refactored as a hybrid solution.

Not every service will be appropriate for delivery via the cloud. Evaluation criteria need to be created to provide the basis for an assessment model that can be used to justify architecture decisions. Cloud Service Providers must evidence the ITSM best practices, security and data protection standards followed. HE Service Management must include change management of SaaS based subscriptions to ensure that costs are controlled effectively.

TE03

Virtualise where possible

Applications and services should be deployed in a virtual environment.

Virtualisation promotes flexibility, allows more efficient use of hardware resources and physical space, and reduces energy consumption.

Where possible, virtualisation should be considered for any new requests for services with exceptions recorded alongside rationale.

TE04

Manage technical debt

The future state IT for the University must make changes easier. Any tactical decisions that introduce technical debt (quick but messy solutions) will only be endorsed if there is a recognised actionable plan to address both of them technically and financially.

Unaddressed technical debt increases the unnecessary complexity and costs of maintaining ICT making it harder to upgrade software, transition services and deliver solutions that meet users’ needs

Reducing technical debt must become part of the University’s culture so that the current accrued debt in the IT estate can be addressed. Dispensations for short term technical debt to meet tactical business imperatives can be granted. Applications and services need to be designed and delivered to be as technology independent as possible.

Software and hardware ICT assets must be recorded and managed in a configuration management system.

Regular reviews of technical debt must be carried out.

TE05

Control Technical Diversity

Technological diversity is controlled to minimize significant costs related to the maintenance of expertise and connectivity between several different environments.

There is a real and significant cost related to the infrastructure required to support alternative technologies

for processing environments.

Limiting the number of supported components simplifies and reduces maintenance and management costs.

A smaller number of software packages represent a greater ease and lower integration costs.

Business advantages of minimum technical diversity include:

• Standard Component Packaging;

• Predictable Implementation Impact;

• Predictable returns and validations;

• Defined tests; and

• Greater flexibility to accommodate technological advances.

Policies, standards, and procedures that regulate the acquisition of technology or contracting with new suppliers must be directly bound to this principle whether via non-functional requirements or internal standards.

This principle does not require freezing the technological baseline. Technological advances are welcome and included into the standards and technological blueprint a when they are compatible with current infrastructures, are likely to improve operating efficiency, or there is a need to increase capacity.

SE01

Identify information risk

Understand what the information classification is, and there is a risk process which takes this into account.

This is in place so that we can take the appropriate measures to secure the information and its access. It also allows us to make sure the right legal frameworks are in place.

Look for guidance on the information classification, and from there if any DPIA is required. Understand the risks to the information and ensure that the right protection mechanisms are in place. Have certifications to back up the security stance.

SE02

Secure by design

Ensure that the system is secure in the design process, by using the applicable tools and approaches to design and development

Used to ensure that security is included in the whole design process, and not just added on at the implementation phase.

Include testing throughout the design process, to ensure that things like input validation is covered. Refer to tools such as those provided by OWASP to provide secure design. Implement testing throughout design and then prior to implementation. Ensure things like vulnerability scanning and penetration testing are completed.

SE03

Attack surface is reduced

Reduce the available attack surface of the system at all points.

By reducing the attack surface, we restrict the amount that needs to be secured and tested.

Consider reducing the number of services that are available, Implement least privilege approaches to all accounts. Ensure all accounts are authenticated and authorised at the right levels. Do not trust input from users or services.

SE04

Defence in depth

Ensure that there are levels to security, so that if one fails, there is another level of protection.

Using layers of security increases the level of effort required by an attacker to gain unauthorised access to a system or application. Controls should be layered such that if one layer of control should fail, there is another different type of control at the next layer that will prevent a security breach.

Build in firewalls (traditional and web application) at the right levels. Consider a three-tier model (presentation / middleware / database) with safeguards at each level. Implement anti-virus at the server level. Use Intrusion Detection and perhaps Intrusion Prevention (as per the risk). Systems should fail secure (don’t mix this with fail safe). Use encryption to protect data at the last resort.

SE05

Resilient by design

Incidents will happen, ensure the system and surrounding processes are resilient.

By having a resilient approach, we can recover quickly from incidents that happen. This should be in line with the risk process.

Have a written and tested disaster recovery / business continuity plan. Have an incident response plan that has been exercised. Ensure that the system is built to consider outages for patching and can be scaled to cover increases in demand (user or network)

SE06

Security by default

The security requirements of a system or application should be considered as part of its overall requirements and must be embedded in every step of the process.

By documenting the security design and building in default behaviours it means that exceptions are not the norm.

Have policies and procedures in place for common security standards (like password complexity, encryption etc). Ensure that these governance documents are encoded by technology (for example the system will not allow passwords which don’t conform to the password policy). What training do users and developers get to maintain security.

SE07

Log, monitor, alert

To ensure that the security is working as intended, logging should be enabled so that security can be monitored and alerted when something goes wrong.

By enabling the right logs, we can ensure that a system remains secure during its lifespan.

Consider the SLAs and KPIs that should be in place, logging covers things such like the software versions and uptime, as well as more traditional things like intruder alerts and defensive systems. Ensure that the logs are examined and actioned.