Enterprise Architecture Principles
Principles are general rules and guidelines that inform and support the way in which the DfE fulfils its vision and objectives. They are intended to be enduring and seldom amended. They reflect a level of consensus across the organisation (our ‘enterprise’) and embody the spirit and thinking of the enterprise architecture.
Discovery, user research and requirements gathering provide user needs and wants; principles provide the guidance to meet those needs.
Throughout these principles, we refer to specific points of the UK Government Service Standard and Technology Code of Practice, that underpin use of these principles.
1. Re-use services and components
Why?
Duplication of services or components adds cost and complexity for the organisation.
How?
- When re-using components and services, projects are likely to need to assemble several components / products to meet end-to-end requirements and not just look for single solutions
- Where no approved service or component exists, any new service or component should be designed to maximise re-usability
- Services or components should be delivered at the smallest possible granularity to facilitate re-use
Relates to
- TCoP8: Share, reuse and collaborate
- SS2: Solve a whole problem for users.
- SS13: Use and contribute to open standards, common components and patterns
2. Align technology choices with cross-Government strategy
Why?
Components and services should be aligned with government strategies to increase reusability, minimise cost and improve consistency of user experience across Government services. Cross-Government components include Gov.UK Notify and Gov.UK Pay - read more about Government as a Platform on the GDS blog.
How?
Projects delivering new products or services should assess alignment with cross government strategies, and aim to deliver re-useable components and services which can be used at cross-Government level
Relates to
SS3: Provide a joined up experience across all channels
3. Link technology decisions to DfE goals
Why?
Technology investment should only be made where it demonstrably contributes to DfE goals or drivers
How?
- All projects should have a business case with measurable business outcomes aligned to DfE goals and objectives
- All projects should assign a person accountable for measurement, reporting and realisation of stated business benefits
Relates to
- SS10: Define what success looks like and publish performance data
4. Evaluate Total Cost of Ownership
Why?
- Expenditure of public money should always look to deliver the best value for the taxpayer
- Ongoing support and maintenance of services form a major part of the total costs and therefore should inform technology decisions
How?
- All projects must be supported by a well-evidenced business case, ensuring that overall solution costs have been considered for value for money.
- An Architecture Lead must assess the total cost of ownership for the service and challenge where appropriate
- Where a duplicate service or component is proposed, total cost of ownership should include costs of running both/all duplicated services
- Investment must justified by supporting evidence
- Design must consider longer-term costs and support of any solution(s) delivered
Relates to
- SS10: Define what success looks like and publish performance data
5. Data is a shared asset
Why?
We are striving to be a data-driven department: data is the golden thread that supports seamless, user-centric user journeys. Data enables evidence based decisions to be made, supports management and governance of our business activities, is used to hold us to account for delivery and allows us to assess the effectiveness of our Departmental policies.
Read more about our Enterprise Data Architecure principles
How?
- Data must be sharable – solutions should adhere to Departmental Data Standards, working with the DfE Data Governance team to extend those standards if necessary.
- Data must be shared – services should provide methods of sharing data with other services to support other user journeys, and with the Enterprise Data & Analysis Platform to support reporting, analysis and Data Science.
- Data must be protected – services must take care during both development and operational phases to adequately secure live data, including but not limited to data containing Personally Identifiable Information (PII). Architects must follow the Departmental Data Protection policies held by the DfE Data Governance team to ensure they are protecting our shared assets appropriately.
Relates to
- TCoP10: Make better use of data
6. Design for accessibility
Why?
We must ensure there is a ‘level playing field’ for all users of a service - that services are inclusive of all users’ needs. Services and systems must adhere to current government accessibility regulations.
How?
- Seek input from DfE Accessibility Advisers on how designs might need amending to improve accessibility
- Include accessibility testing as part of any project delivery
Relates to
- TCoP2: Make things accessible and inclusive
- SS4: Make things easy to use
- SS5: Make sure everyone can use the service
7. Deliver a secure service
Why?
The department’s information assets must be protected to ensure that they are not inadvertently exposed to an unintended audience.
How?
- Early engagement with the Information Security team will ensure that risk assessments are completed and appropriate security controls are designed into solutions before development has begun
- Security controls must be proportionate, to ensure it is still possible for authorised users to access and share data seamlessly
Relates to
8. Deliver cloud-native solutions
Why?
- The scale of public cloud services enables the delivery of highly scalable, cost effective, secure services. Consumption based billing and rapid provisioning supports the Government ICT strategy.
- A service can be configured and built using a SaaS product, without bespoke customisation and vendor lock in
How?
- Choose Software as a Service (SaaS), before Platform as a Service (PaaS), before Infrastructure as a Service (IaaS)
- Check hosting arrangements and data sensitivity when selecting cloud solutions
- Design the exit strategy before entering cloud agreements
- Design solutions to take advantage of cloud features, such as elastic scaling and automated spin-down
Relates to
TCoP5: Use cloud first
9. Design for interoperability
Why?
Interoperability enables sharing of capabilities and data between systems
How?
- Service Oriented Architectures and microservice architectures maximise interoperability and re-use
- Interfaces should be discoverable and self-describing or self-documented
- Interoperability can affect the demands on solutions, therefore designs may need to be scalable to cope with other usage
Relates to
- TCoP9: Integrate and adapt technology
10. Use open standards
Why?
- Avoidance of vendor lock-in
- Lays the foundation for delivering interoperability
- Open standards facilitate interoperability and data exchange among different products or services.
How?
Where open standards do not exist, create one or find the best fit with least lock in
Relates to
- TCoP4: Make use of open standards
- SS13: Use and contribute to open standards, common components and patterns
11. Design for portability
Why?
- Avoidance of vendor lock-in
- Moving to a new platform is simpler and requires less engineering (and cost)
How?
- Design must be platform agnostic
- Minimise use of platform specific features
- Will require an exit strategy
12. Design loosely coupled solutions
Why?
- Loosely coupled components can be replaced with alternative implementations that provide the same services.
- Components in a loosely coupled system are less constrained to the same platform, language, operating system, or build environment.
How?
- Projects must ensure any additional coordination protocols needed are in place
- Projects must ensure consistent data synchronisation aligned with DfE Data guidance
Relates to
- TCoP9: Integrate and adapt technology
13. Minimise technical debt
Why?
Replacing or superseding a component or service without removing existing components or services increases technical debt
How?
- Any project delivering a technology component or service designed to supersede or replace an existing component or service must remove the existing service as part of that project
- Project budgets need to include cost of decommissioning existing solutions or include total ongoing cost of both systems in the business case.
Relates to
- SS2: Solve the whole problem for a users