Cabinet Office Architecture Principles
The Cabinet Office Architecture Principles are a set of rules and guidelines that apply across the Cabinet Office. They exist to help projects and programmes realise the wider technology-related objectives for the Cabinet Office, and hence enable and support the CO business goals. They should be used to guide project decision-making within relevant teams.
The purpose of these Architecture Principles is to consider the Cabinet Office as a whole, functioning business-value delivering Enterprise. Delivery activities represent the discrete step changes, both adding to and removing from the operational technology environment that we operate in Cabinet Office.
You should use these principles in conjunction with the other related Cabinet Office principles, policies and strategies in the areas of concern. These include the Service Acceptance Principles and the Cabinet Office Hosting Principles and Strategies, Data Strategies and Technology Strategies which provide a more focused and detailed set of implementation guidance and governance for specific technology subsets or domains.
These principles are in alignment with the Technology Code of Practice, Government Design Principles, GOV.UK Service Manual, NCSC Cloud Security Principle and Cloud First Policy. They are intended to consider the Government-wide content and apply them to the context of the Cabinet Office.
Using These principles
These architecture principles are general rules and guidelines and reflect a level of consensus across the enterprise and embody the spirit and thinking of those within and working with the enterprise architecture function.
The principles inform and represent the approach for digital and technology activities within the Cabinet Office such that the immediate project needs can be aligned with the longer-term vision and sustainable operations for the wider Cabinet Office. They reflect a level of consensus across the enterprise and embody the spirit and thinking of those within and working with the enterprise architecture function.
As part of technology seeking technology input, reviews, and assurance processes, we expect projects and programmes to be able to relate their plans and activities to these principles, and capture that knowledge for sharing across Cabinet Office.
1. Maximise the Cabinet Office business goals
We should make decisions that provide the greatest benefit to the entire enterprise. This means looking beyond the immediate project goals and considering the broader context and impact on the Cabinet Office (CO) of what has been developed and what has been replaced.
Technology investments should only be made if they clearly contribute to the business objectives of the CO and align with its long-term technology direction.
Your team should: * Begin each project by understanding the business objectives, stakeholder requirements, contexts, and constraints. * Ensure all projects have a business case with measurable outcomes aligned with the Cabinet Office’s direction. * Assign a person responsible for measuring, reporting, and realising the stated business benefits.
This approach ensures that all decisions and investments are strategically aligned with the overarching goals of the Cabinet Office, fostering a coherent and unified enterprise direction.
2. Apply risk-based proportionate governance and assurance
Governance measures should align with the scale, complexity, and risk of the project or activity. This ensures governance practices are effective and efficient, providing essential oversight and control without excessive or redundant procedures.
Establish a governance structure that incorporates checkpoints to guide the project in the right direction and manage risks. This framework should facilitate stakeholder engagement and feedback to ensure alignment and responsiveness to their needs.
Governance and assurance must strike a balance with other project requirements, including team dynamics, deliverability, and costs.
Additionally, use the governance structure to monitor and ensure alignment between dependencies, such as other projects that provide necessary functionality. Track resource, delivery, and operational alignment, and maintain convergence of goals and outcomes. This ensures a clear governance trail exists, enabling timely corrective actions when necessary.
3. Share, reuse and collaborate
We should seek to reuse elements from other projects, and share elements of your project with the other teams in the Cabinet Office and other government organisations. These elements include user research, design and technical components.
We can reduce risk, learn from each other and deliver projects quickly and efficiently by building on other projects and reusing components. We should collaborate to reduce duplication of effort.
We should maximise the reusability of the service and technical components, for example, break down the software development into reusable components use open standards to define interactions share your work openly when appropriate
4. Evaluate total cost of ownership
We should consider the Return on Investment in the business case when making a decision on change of technology or evaluating technology options. We should take into account the benefits and total costs of ownership of the decision.
We should understand the contexts, dependencies and requirements end-to-end and as a whole. We should investigate the technology landscape and options available to solve the defined problem.
We should evaluate the total cost of ownership of the options to inform technology decisions, including
- build
- ongoing support
- maintenance
- cost of dual running if applicable
- Migration
- decommissioning
- other subsidiary costs in making technology decisions.
We should use architecture reviews, assurance and spend controls processes to validate and iterate the total cost of ownership of the project. We should understand the assumptions, risk and dependencies that affect the sensitivity of the projection.
5. Make use of data insights to inform decisions
We should use insights to inform our decision making, while being mindful of the potential bias that exists in data.
We should strive to be a data-driven department and make the best use of data as a key part of Government Digital Strategy.
We should use data to inform evidence based decisions, support management and governance of our business activities; and use data to evaluate our deliverability, the effectiveness of the policies and drive changes.
We need to develop our expertise in understanding how bias in data collection and analytics could affect the analytical results and storytelling; and factor these considerations into decision making.
6. Make data a shared asset
We should be an exemplar of data handling and control, and ensure data are shared for deriving data insights.
We should develop best practices around data handling and control, considering some data handled in the Cabinet Office can be very sensitive.
We should be aspired to provide mechanisms to make data shareable to other parties to inform data-driven decisions and insights.
Everyone in the Cabinet Office must follow the Departmental Data Protection policies and make sure we protect our shared data assets appropriately in our day-to-day activities.
7. Secure the data and service appropriately
We should understand our risks and protect our data assets, services and technology against attacks and unintended audiences.
We should engage with the Cyber Security Team, information assurance team and Senior Security Advisor (SSA) early and throughout the project to make sure risk assessments are updated.
We should design security controls into the solutions before software development work begins and consider cyber security when iterating the design.
When evaluating and designing security controls, we should balance risk mitigation with productivity, seeking to minimise the impact on people’s work.
Relates to:
8. Design for interoperability
We should use and design software and hardware that conform to open standards to promote interoperability of data, applications, and technology.
Apply appropriate standards give us these benefits: ensure consistency, which improves the ability to manage systems and give better user experience protect existing IT investments, which can maximize return on investment and reduce costs. ensure support from multiple vendors for their products, and facilitate supply chain integration.
We should build standards (e.g. API standards) into our technology design from the beginning of the project. We should document interfaces appropriately and aim to make interfaces discoverable.
The interoperability components and the interfaces should be thoroughly tested and supported. We should factor the scalability and reliability of the individual components and the interaction into the design.
Relates to:
9. Design to manage technology dependencies
We should design our technology solutions to manage our dependency on specific technology and vendor choice, so that we can operate on and use a variety of technology platforms and tools. We would expect different vendors to differentiate their products for customer benefit, and we do want to leverage these benefits, rather than missing opportunities through a ‘lowest common denominator’ approach.
Technology is subject to continual obsolescence and vendor dependence. We should be aware that the technology rather than the user requirements can become the driver for a project if we do not consider the lock-in of the solution and exit strategy from the beginning. This principle applies to both in-house developed software and Commercial Off-the-shelf technologies.
We should balance the costs and benefits of achieving this principle and 4. Evaluate total cost of ownership when evaluating technology options.
Relates to:
10. Balance technology diversity with specialised needs
On one hand, we should control technology diversity to minimise the cost of maintaining expertise in and integration between multiple tools and environments, and achieve economies of scale in procurement.
We should limit the number of supported components when we can, and choose to reuse technology to simplify maintainability and reduce costs.
On the other hand, we should consider the value-adding benefit that a specialised tool can provide. We should allow for deviation of individual needs.
This analysis and any trade-off decisions, should be made transparent and visible to project stakeholders and governance. You will need to ensure that these decisions can be re-evaluated throughout the operational lifetime of the service as ultimately delivering the CO Business Goals is our ultimate objective.
11. Experiment, learn and improve
We should design our solutions incrementally to help develop our understanding of a problem and test hypotheses.
We should be brave to experiment and innovate to improve and explore technology advancement and options. We should be prepared to learn from our successes and mistakes; taking forward projects that can maximise the Cabinet Office value, and leave behind the projects and experiments that have not proven their value for money.
We should do proof of concepts and prototyping to evaluate the solutions in practice. We should do desk research to build on what others have done, and to extend our horizons beyond our immediate teams, organisations and countries.
We need to embed a learning mindset throughout the conception, design, delivery and operation of the services we deliver for the Cabinet Office.
Change log
| Version | Date | Change |
|---|---|---|
| 1.0 | May 2022 | First release |
| 1.1 | Aug 24 | Change CDIO to Cabinet Office |
| 1.2 | Nov 24 | Port content to Github Page |