1. Involve the team
Chat to the Enterprise Architecture team as soon as you start exploring an idea. We’ll support you and get it ready for review.
Enterprise Architecture principles
| Name | Description | Category |
|---|---|---|
| Net Zero | Knowing the social, financial and environmental impact of all our solutions is a key requirement for progress and design, and we will effectively manage this. | Business |
| Reduce complexity | We should have the minimum number of processes, systems and applications required to deliver the requirements of the University community. We should use industry standard out-of-the-box systems and configurations where possible. We should exploit strategic platforms rather than putting in additional applications. | Business |
| Don't value engineer out things you have to do later | When creating a new solution, be it a building or a digital system, don't value engineer out essential components that then need to be retrofitted to bring the solution up to standard. | Business |
| Avoid interim solutions | Unless there is a hard business requirement, avoid the creation of interim solutions and focus time and resource on a permanent solution. | Business |
| Value for money | We should ensure that all procurements, and ongoing contracts, represent value for money. | Business |
| Innovate | We should be agile, fail fast and learn fast. We should create environments that encourage innovation, and seek to exploit platforms and capabilities that we can use as unique selling points for our organisation. | Business |
| Data is an asset | Data is an asset that we should seek both to protect and exploit for the good of the University community. | Business |
| Business sets outcomes, IT sets technology | The business should define the outcomes, and the IT function should determine the best technology to deliver those outcomes. | Business |
| Security by design | Cyber security is a key priority for the University, and as well as developing a culture of security we will ensure that all new technology developments contribute to improved security at the University. This will need to be demonstrated at all stages, from concept and design through to delivery. | Business |
| Usable & Accessible | Our applications must be easy to use, accessible, understandable and available to the intended audience, regardless of geographic location whilst meeting accessibility standards. | Applications |
| Lifecycle Management | The lifecycle of an application must be defined and managed from inception to retirement as a continuous process, rather than discrete phrases. | Applications |
| Buy Before Build | Where possible, applications are to be purchased off-the-shelf rather than developed internally. | Applications |
| Software as a Service (SaaS) | Software as a Service (SaaS) will be prioritised, unless there is a clear business case for a self-hosted solution. | Applications |
| Design to allow the addition of new capabilities and functionality | Make it easy for application developers or system administrators to understand, modify, and extend the application over time. | Applications |
| Personalise don't customise | The ability for our customers to personalise their experience, and for us to deliver a consistent branding across services, is a positive. Customisation of off-the-shelf solutions should be minimised in line with "reduce complexity". | Applications |
| Source applications with diversity in mind | Application selections will be from vendors that represent diversity in the community. | Applications |
| Availability | University users must have access to the services they need, when they need it from any device. | Applications |
| DevOps | Internally developed solutions will follow all the principles of DevOps, including version control, automated testing, CI/CD and monitoring. | Applications |
| Co-design and UX | We will use UX and co-design when creating applications. | Applications |
| Every application must have an owner | Every application (SaaS, hosted or developed) must have a business owner and a technical owner. | Applications |
| Single, trusted source of truth | Central repository for key data from underlying systems. | Data |
| Ethical data | Collect, handle and store data ethically. | Data |
| Legal, transparent and secure | Use transparent and legally compliant data practices. | Data |
| Active data quality | Actively manage, review and improve data quality. | Data |
| Reduce, reuse, recycle | Make data readily obtainable, and use data multiple times to maximise value - collect once and reuse where the purpose is compatible. | Data |
| Right retention, right backup | Data is backed up regularly and held securely - managed in line with data retention principles. | Data |
| Common language | Adopt common data standards across datasets, apply common terms and definitions. | Data |
| Join the dots | Promote dataset linkage. | Data |
| Trusted reporting | Publish data and analysis via approved routes. | Data |
| No live data in test | The use of live/production data in test should be avoided wherever possible. If it cannot be avoided a DPIA must be approved by the DPO, the test system must have an equivalent level of security controls as the production system, and all efforts must be taken to avoid external actions from the test system. | Data |
| Self-service | Wherever possible, access to data should be possible via self-service mechanisms, allowing customers to ask questions of the data. | Data |
| Cloud First | The cloud is considered first when assessing where technology should be built and hosted. | Technology |
| Scalable & Available | Technology is suitably scalable in both directions and is highly available; designed to meet the needs of the business. Solutions should be able to tolerate any single component failure. | Technology |
| Reduce Technical Debt | We will be proactive with legacy technology and ensure systems in production are fully supported. Existing technical debt will be well managed, with a view to eliminate future technical debt. | Technology |
| Repeatable & Testable | Technology will be developed and deployed in a repeatable, continuous manner with appropriate automated test suites built around it. | Technology |
| Proactive monitoring | All services must be monitored for availability and performance, and every opportunity for proactive monitoring should be considered. False positives must be minimised. | Technology |
| AI positive | The University supports the use of "artificial intelligence" technology, including generative AI, and seeks to use it effectively, innovatively, responsibly, legally and ethically. | Technology |
| Govern, Protect, Detect, Defend and Respond | Through pragmatic and implementable policy and standard we will work with the University to understand our assets, assess the risks and apply appropriate controls to detect and defend against cyber security events, and in the event of an incident we will lead the investigation and response to support timely recovery. | Security |
| Secure by Design | Establish the operating environment that that drives security requirements into the service/system design. Security is a two way street, we need input/contribution from users/owners. Security should be designed to be as unobtrusive to the user where possible. | Security |
| Secure by Default | Make compromise difficult through procedural, technical and personnel measures. | Security |
| Resilience | Make disruption difficult through protecting the valuable assets and reducing attack surface. | Security |
| Detect and Alert | Make actual or suspected compromise detection easier through centralised logging, correlation, detection and alerting. | Security |
| Limit the blast radius | In the event of compromise we want to reduce the impact. | Security |
| Know your onions | We have an clear definition of our estate which is documented and updated. | Security |
| Service currency and lifecycle management | Our services must be able to apply security industry best practice as technology updates and we plan for limitations when known. We operate in-support services, which are receiving security updates and have schedules for maintenance or decommissioning before end of life. | Security |
| Supply chain security | Security needs to be included from tender, through to delivery, operation and decommissioning, applying all the principles. | Security |
Explore the full Enterprise Architecture approval process
2. Check the guiding principles
Use our Enterprise Architecture principles to inform your design decisions and strengthen your proposal.
3. Request approval
Once we agree your proposal is ready, submit it to the Technical Design Authority (TDA) for review and final sign-off.