From d3a78a521f729bd1abe3e6c8676cfd524065dc58 Mon Sep 17 00:00:00 2001 From: Ant McCrea <69901556+antmccrea@users.noreply.github.com> Date: Wed, 21 Aug 2024 14:55:25 +0100 Subject: [PATCH 1/2] Update enterprise-architecture-principles.md Updated EA principles to reflect DFE target architecture --- .../enterprise-architecture-principles.md | 449 ++++++++++-------- 1 file changed, 258 insertions(+), 191 deletions(-) diff --git a/principles/enterprise-architecture-principles.md b/principles/enterprise-architecture-principles.md index 97b6134..def78f8 100644 --- a/principles/enterprise-architecture-principles.md +++ b/principles/enterprise-architecture-principles.md @@ -1,217 +1,284 @@ --- category: Architecture Principles -expires: 2022-12-01 +expires: 2025-08-31 --- - # 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](https://www.gov.uk/service-manual/service-standard) and [Technology Code of Practice](https://www.gov.uk/government/publications/technology-code-of-practice/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](https://www.gov.uk/government/publications/technology-code-of-practice/technology-code-of-practice#share-reuse-and-collaborate): Share, reuse and collaborate -- [SS2](https://www.gov.uk/service-manual/service-standard/point-2-solve-a-whole-problem): Solve a whole problem for users. -- [SS13](https://www.gov.uk/service-manual/service-standard/point-13-use-common-standards-components-patterns): 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](https://gds.blog.gov.uk/category/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](https://www.gov.uk/service-manual/service-standard/point-3-join-up-across-channels): 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](https://www.gov.uk/service-manual/service-standard/point-10-define-success-publish-performance-data): 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](https://www.gov.uk/service-manual/service-standard/point-10-define-success-publish-performance-data): 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](/enterprise-data-architecture-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](https://www.gov.uk/government/publications/technology-code-of-practice/technology-code-of-practice#make-better-use-of-data): Make better use of data - +Enterprise Architecture Principles are general rules and guidelines that inform and support decisions in how DfE should deliver solutions to align with 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. -## 6. Design for accessibility +Discovery, user research and requirements gathering provide user needs and wants which inform what a solution does; principles provide guidance on how solutions should be architected to meet those needs. -__Why?__ +These principles should be applied alongside the UK Government [Service Standard](https://www.gov.uk/service-manual/service-standard) and [Technology Code of Practice](https://www.gov.uk/government/publications/technology-code-of-practice/technology-code-of-practice). -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](https://www.gov.uk/government/publications/technology-code-of-practice/technology-code-of-practice#make-things-accessible-and-inclusive): Make things accessible and inclusive -- [SS4](https://www.gov.uk/service-manual/service-standard/point-4-make-the-service-simple-to-use): Make things easy to use -- [SS5](https://www.gov.uk/service-manual/service-standard/point-5-make-sure-everyone-can-use-the-service): 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__ - -- [TCoP6](https://www.gov.uk/government/publications/technology-code-of-practice/technology-code-of-practice#make-things-secure): Make things secure -- [SS9](https://www.gov.uk/service-manual/service-standard/point-9-create-a-secure-service): Create a secure service which protects users' privacy - -## 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](https://www.gov.uk/government/publications/technology-code-of-practice/technology-code-of-practice#use-cloud-first): 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](https://www.gov.uk/government/publications/technology-code-of-practice/technology-code-of-practice#integrate-and-adapt-technology): 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__ +# The Principles -- [TCoP4](https://www.gov.uk/government/publications/technology-code-of-practice/technology-code-of-practice#make-use-of-open-standards): Make use of open standards -- [SS13](https://www.gov.uk/service-manual/service-standard/point-13-use-common-standards-components-patterns): Use and contribute to open standards, common components and patterns +1. [Business Alignment](#1align-with-business-objectives) +2. [Standardisation](#2standardisation) +3. [Flexibility and Adaptability](3flexibility-and-adaptability) +4. [Security and Compliance](4security-and-compliance) +5. [Cloud First](5cloud-first---rent-before-buy-before-build). +6. [Data Integrity and Quality](6data-integrity-and-quality) +7. [Reuse and Modularity](7reuse-and-modularity) +8. [Design for Operation](8design-for-operation) +9. ["Good Enough” Solutions](9good-enough-solutions) -## 11. Design for portability +--- -__Why?__ +# 1. Align with business objectives +## 1.1. Description +Align and prioritise digital, data and technology (DDT) strategies and deliveries with business +goals and objectives, to maximise taxpayer value. +## 1.2. Rationale +* Changes in ministerial priorities cause volatility in the goals and objectives of the +department. +* Ensuring delivery aligns with departmental goals and objectives improves efficiency, +with better resource allocation and decision-making. +## 1.3. Implications +* To maximise taxpayer value, review deliveries as business and ministerial goals change, +ensuring appropriate investment of effort and money. +* Ensure value by linking delivery metrics to business objectives, which also facilitates +rapid review of relevance when goals and objectives change. +* Work may be deprioritised or stopped as business goals and objectives change. +* Invest in functionality and delivery that has long-term stability through changing +government policies and priorities. +* User needs may not align with DFE business objectives, therefore cost and value of +delivering these capabilities should be weighed against the impact to achieving +departmental objectives -- 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 +# 2. Standardisation +## 2.1. Description +Adherence to DFE standards and patterns promote consistency, simplify the landscape, and +minimise technical debt. + +## 2.2. Rationale +* Use of consistent technologies and platforms facilitates interoperability, reduces +complexity, and simplifies maintenance. +* Quicker onboarding of suppliers and reduced time and cost spent on evaluating +technology options. +* It becomes easier to reallocate resources between deliveries to optimise deliveries and +accommodate changing priorities. +* Consistent technology choices reduce technical debt and proliferation of technology +within the department. +* Streamlined processes, easier integration, and cost savings through economies of +scale. + +## 2.3. Implications +* Productivity of individuals and teams may reduce as they transition to standard tools +and platforms; expect some retraining requirements. +* Pragmatism means one tool or platform may not be desirable or achievable, need to link +to use cases and allow exceptions for unusual scenarios. +* Standards need developing and managing across all areas of DDT. +* Standards need processes and governance to adapt to changing needs and modern +technologies. +* Need ability to experiment with modern technologies to evaluate usefulness. -## 12. Design loosely coupled solutions +--- -__Why?__ +# 3. Flexibility and Adaptability +## 3.1. Description +Design systems that can adapt to changing business needs and technological advancements. + +## 3.2. Rationale +* Ministerial priorities will change. Business environments evolve rapidly; agility is +essential to serve users effectively. +* Reduced risk of obsolescence, quicker response to market changes. + +## 3.3. Implications +* Continuous development is expensive, design solutions to allow for predictable change +without redevelopment. +* Predict the types of change that will affect your solution area and accommodate these +in the design through configuration or replaceable/expandable modules. +* Delivery of flexible and adaptable solutions will be more complex and costly initially, +offset by reduced future cost of change. +* Change may not happen; do not cover every eventuality, only consider changes that +could be expected within the lifecycle of a product. + + --- + +# 4. Security and Compliance +## 4.1. Description +Prioritise security measures and regulatory compliance in architectural decisions. + +## 4.2. Rationale +* Good security practices protect data, maintains trust, and avoids reputational damage, +impact to customers and legal penalties. +* Understanding threats, vulnerabilities and applying mitigations at design stage reduces +cost of delivering secure services and prevents vulnerabilities risking DFE data and +services. + +## 4.3. Implications +* Conduct threat modelling early in a service lifecycle and review as threats and the +service evolve. +* Apply threat modelling to all components and flows in your solution from both external +and internal threat actors and apply appropriate mitigations. +* Threat mitigations should be prioritised in backlogs to prevent exploitation of +vulnerabilities. +* A system is only as secure as its weakest link, therefore all components, modules and +flows should be protected regardless of the sensitivity of data held by that solution. +* Exploitation of weak points can provide a stepping stone into other solutions, platforms, +and data, therefore even if your solution is considered lower risk, protections are +required to prevent your system becoming a back door into sensitive data elsewhere in +the organisation. -- 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 +# 5. Cloud First - Rent before buy before build +## 5.1. Description +Do not build what can easily bought off-the-shelf. Prioritise cloud-based solutions over on- +premises alternatives. + +## 5.2. Rationale +* Commercial-off-the-shelf (COTS) solutions include cost of development, operation, and +best practice their costs and share these between all clients therefore Total Cost of +ownership (TCO) is cheaper for “utility” functionality. +* Leverage scalability, cost-effectiveness, and agility of cloud services. + +## 5.3. Implications +* Conduct an options appraisal before choosing delivery approach. +* Evaluate COTS solutions against “good enough” as they are unlikely to meet all +requirements; they may need façades, configuration, or a hybrid approach to meet user +needs e.g. If a COTS solution delivers 80% of user needs, consider wrapping or +extending the COTS solution for the remaining 20%, rather than building 100% bespoke. +* Avoid customisation of COTs solutions to deliver bespoke functionality, where required +use configuration and integration to tailor the solution to user needs. Adapt business +processes to align with COTS where possible. +* Develop an exit plan before adopting COTS to prevent vendor lock-in. +* Evaluate TCO between COTS and bespoke, including hosting, delivery resource, +support, and platform costs for the lifetime of the product, during options appraisal. +* Prioritise Software-as-a-Service (SaaS) solutions, over Platform-as-a-Service (PaaS) +over Infrastructure-as-a-Service (IaaS), over on-premise, when evaluating solution +hosting options. -__Relates to__ +--- -- [TCoP9](https://www.gov.uk/government/publications/technology-code-of-practice/technology-code-of-practice#integrate-and-adapt-technology): Integrate and adapt technology +# 6. Data Integrity and Quality +## 6.1. Description +Ensure accurate, consistent, and reliable data across DFE IT Landscape. Use master data sources and, when mastering data, make it available to other services through interfaces that ensure data consistency, integrity and quality. + +## 6.2. Rationale +* Reliable data drives informed decision-making and operational efficiency. +* Duplication or poor data management practices reduce user trust, introduce errors, +discrepancies and data quality issues whilst increasing cost and effort of data collation +and analysis. +* By creating and using trusted shared data sources, services can provide consistent +data, improving user experience and trust and reduce data engineering costs in +preparing data for analysis. + +## 6.3. Implications +* Use authoritative data sources without creating copies. +* Authoritative data sources must have availability and scalability to meet service +demands with appropriate support and service levels. +* Embed data management and governance practices in the organisation and for both +operational and analytical data. -## 13. Minimise technical debt +--- -__Why?__ +# 7. Reuse and Modularity +## 7.1. Description +Solve problems once, encourage creation and reuse of components, services and patterns. + +## 7.2. Rationale +* Delivering services and functionality is expensive, by avoiding reinventing the wheel we +can streamline development efforts, reduce duplication and costs. +* By decomposing services into small reusable components teams can consume these +rather than building functionality from scratch. +* Services can be delivered by assembling existing components more quickly, cheaply, +and consistently than duplicating functionality. +* Capabilities cross organisational and service boundaries therefore reuse can break +down the silos that naturally form around portfolio centred teams and create a more +consistent user experience. +* Modularity allows rearrangement of components and functionality when policy or +organisational goals or objectives change. +* Updates to shared components automatically apply to all dependent services; when +making changes only the component changes and therefore can reduce testing +required. +* Measurement of use of components allows better understanding of user journeys to +inform policy and delivery decisions. + +## 7.3. Implications +* Interdependencies between services and teams increase complexity and will slow initial +deliveries. +* Assume that someone will need to reuse any new capabilities you deliver, look for +similarities rather than differences, only build what does not exist already, and make it +reusable. Where there are differences consider encapsulation or abstraction to extend +the base functionality; and make that a service. +* Changes to components need to be non-breaking to avoid failures in dependant +systems. +* Make services small and re-useable, breaking functionality into separate modules or +components with integration capabilities. +* Facilitate synchronous and/or asynchronous integrations as appropriate. +* Separate front-end functionality from back-end components, back-ends should not +depend on front end validation or other functionality to function correctly. +* Design and scale each component for availability and re-use; Consider “circuit +breakers” for latency and non-responsiveness of components but avoid duplication as +mitigation. +* Components need to support all users equally. +* Need capability teams to discover existing components, services and patterns and the +functionality they provide? -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. +# 8. Design for Operation +## 8.1. Description +Architect systems with operational efficiency, reliability and sustainability in mind. + +## 8.2. Rationale +* Smooth operations reduce downtime, enhance reliability and availability. +* Designing for efficient operations, with appropriate availability and scalability without +manual intervention drives reduced TCO. +* The majority of costs for any solution occur post-delivery and therefore architects +should avoid short-term decisions to minimise delivery costs or accelerate delivery +timescales that adversely impact the organisation or stakeholders long-term. + +## 8.3. Implications +* Design systems with appropriate resilience and scalability to meet service needs and +those of any dependent services, where possible automate these to avoid service +impacts in the event of sudden demand or failures. +* Services may need different levels of availability and scalability for each module or +component of their service; overall service availability and scalability is only as good as +its weakest link. Plan and test for DR/BC scenarios and peak loads to ensure service +designs are appropriate. +* Automation and integration of solution operations to common CMDB, service logging +and monitoring platforms promotes easier maintenance, proactive monitoring, and +better support with reduced resource requirements. +* All projects delivering solutions to replace existing services or components need to +include decommissioning of the old system in the project activity and costs to avoid +technical debt. +* Automate delivery pipelines to update CMDB/service catalog to ensure information is +always up to date during delivery phase. +* Evaluate the long-term viability of suppliers and products to prevent tech-debt or risk of +supplier failure. +* Architectural decisions need to factor the expected life cycle of the solution and its +impact on stakeholders, the environment, and total cost of ownership. +* Decisions need to prioritise prevention of technical debt, minimise rework, ensure +future scalability (up and down), and optimise operational resource and cost demands. +* Include full lifecycle people and technical resource costs in TCO comparisons when +evaluating options. -__Relates to__ +--- -- [SS2](https://www.gov.uk/service-manual/service-standard/point-2-solve-a-whole-problem): Solve the whole problem for a users +# 9. “Good Enough” Solutions +## 9.1. Description +Recognize that perfection is not always necessary. Strive for solutions that meet essential +requirements without unnecessary features. Prioritise value over perfection, especially in agile +and iterative contexts. +## 9.2. Rationale +* Balancing pragmatism with quality allows for faster delivery, adaptability and maximises +taxpayer value whilst Minimising delivery costs and allowing resources to pivot to other +deliveries. Pareto rule – 20% of functionality delivers 80% of the value. +## 9.3. Implications +* Architecture needs to reflect the emergent nature of agile delivery and therefore do “just +enough” architecture to enable delivery; this means longer term architecture should still +be done, but at an appropriate level to adapt as detail emerges through delivery. +* Avoid “gilding the lily” or over-engineering, focus on critical features, and iterate based +on feedback. Measure VFM of each feature including costs of delivery resources over +realistic lifetime of the product before adding to backlog. Stop when the service reaches +“good enough”. +* Evaluate cost saving of COTS options with good-enough functionality against bespoke +delivery. +* Ensure compliance with legislative, accessibility and security standards. +* Have a “definition of done”, check regularly whether this criteria has been met From 62f104cb4563674735ba67c61a642ea5f40bdd0c Mon Sep 17 00:00:00 2001 From: luke-slowen Date: Thu, 29 Aug 2024 15:28:26 +0100 Subject: [PATCH 2/2] Content updates following review --- .../enterprise-architecture-principles.md | 366 +++++++++--------- 1 file changed, 190 insertions(+), 176 deletions(-) diff --git a/principles/enterprise-architecture-principles.md b/principles/enterprise-architecture-principles.md index def78f8..7d15fb0 100644 --- a/principles/enterprise-architecture-principles.md +++ b/principles/enterprise-architecture-principles.md @@ -4,281 +4,295 @@ expires: 2025-08-31 --- # Enterprise Architecture Principles -Enterprise Architecture Principles are general rules and guidelines that inform and support decisions in how DfE should deliver solutions to align with 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. +Enterprise Architecture principles are general rules and guidelines that inform and support decisions in how DfE should deliver services, to align with its vision and objectives. -Discovery, user research and requirements gathering provide user needs and wants which inform what a solution does; principles provide guidance on how solutions should be architected to meet those needs. +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. -These principles should be applied alongside the UK Government [Service Standard](https://www.gov.uk/service-manual/service-standard) and [Technology Code of Practice](https://www.gov.uk/government/publications/technology-code-of-practice/technology-code-of-practice). +Discovery, user research and requirements gathering provide user needs (and wants), which inform what a service does. Principles provide guidance on how services should be architected to meet those needs. + +These principles should be applied alongside the UK Government [Service Standard](https://www.gov.uk/service-manual/service-standard) and [Technology Code of Practice](https://www.gov.uk/guidance/the-technology-code-of-practice). --- # The Principles -1. [Business Alignment](#1align-with-business-objectives) -2. [Standardisation](#2standardisation) -3. [Flexibility and Adaptability](3flexibility-and-adaptability) -4. [Security and Compliance](4security-and-compliance) -5. [Cloud First](5cloud-first---rent-before-buy-before-build). -6. [Data Integrity and Quality](6data-integrity-and-quality) -7. [Reuse and Modularity](7reuse-and-modularity) -8. [Design for Operation](8design-for-operation) -9. ["Good Enough” Solutions](9good-enough-solutions) +1. [Business alignment](#1-align-with-business-objectives) +2. [Standardisation](#2-standardisation) +3. [Flexibility and adaptability](#3-flexibility-and-adaptability) +4. [Security and compliance](#4-security-and-compliance) +5. [Cloud First](#5-cloud-first---rent-before-buy-before-build). +6. [Data integrity and quality](#6-data-integrity-and-quality) +7. [Reuse and modularity](#7-reuse-and-modularity) +8. [Design for operation](#8-design-for-operation) +9. ["Good enough” services](#9-good-enough-services) --- -# 1. Align with business objectives +# 1. Align with business objectives + ## 1.1. Description -Align and prioritise digital, data and technology (DDT) strategies and deliveries with business -goals and objectives, to maximise taxpayer value. +Align and prioritise digital, data and technology (DDT) strategies and delivery with DfE's business +goals and objectives, to maximise taxpayer value + ## 1.2. Rationale * Changes in ministerial priorities cause volatility in the goals and objectives of the -department. +department * Ensuring delivery aligns with departmental goals and objectives improves efficiency, -with better resource allocation and decision-making. +with better resource allocation and decision-making + ## 1.3. Implications * To maximise taxpayer value, review deliveries as business and ministerial goals change, -ensuring appropriate investment of effort and money. +ensuring appropriate investment of effort and money * Ensure value by linking delivery metrics to business objectives, which also facilitates -rapid review of relevance when goals and objectives change. +rapid review of relevance when goals and objectives change * Work may be deprioritised or stopped as business goals and objectives change. * Invest in functionality and delivery that has long-term stability through changing -government policies and priorities. -* User needs may not align with DFE business objectives, therefore cost and value of -delivering these capabilities should be weighed against the impact to achieving +government policies and priorities +* User needs may not align with DfE business objectives, therefore the cost and value of +delivering the capabilities should be weighed-up against the impact to achieving departmental objectives --- -# 2. Standardisation +# 2. Standardisation + ## 2.1. Description -Adherence to DFE standards and patterns promote consistency, simplify the landscape, and -minimise technical debt. +Adhere to DfE standards and patterns, to promote consistency, simplify the landscape and +minimise technical debt ## 2.2. Rationale * Use of consistent technologies and platforms facilitates interoperability, reduces -complexity, and simplifies maintenance. -* Quicker onboarding of suppliers and reduced time and cost spent on evaluating -technology options. -* It becomes easier to reallocate resources between deliveries to optimise deliveries and -accommodate changing priorities. +complexity and simplifies maintenance +* Quicker onboarding of suppliers, with reduced time and cost on evaluating +technology options +* It becomes easier to reallocate resources between deliveries, to optimise deliveries and +accommodate changing priorities * Consistent technology choices reduce technical debt and proliferation of technology -within the department. -* Streamlined processes, easier integration, and cost savings through economies of -scale. +within the department +* Streamlined processes, easier integration and cost savings through economies of +scale ## 2.3. Implications * Productivity of individuals and teams may reduce as they transition to standard tools -and platforms; expect some retraining requirements. -* Pragmatism means one tool or platform may not be desirable or achievable, need to link -to use cases and allow exceptions for unusual scenarios. -* Standards need developing and managing across all areas of DDT. +and platforms - expect some retraining requirements +* Pragmatism means one tool or platform may not be desirable or achievable - need to link +to use cases and allow exceptions for unusual scenarios +* Standards need developing and managing across all areas of DDT * Standards need processes and governance to adapt to changing needs and modern -technologies. -* Need ability to experiment with modern technologies to evaluate usefulness. +technologies +* Need the flexibility to experiment with modern technologies to evaluate usefulness --- -# 3. Flexibility and Adaptability +# 3. Flexibility and adaptability + ## 3.1. Description -Design systems that can adapt to changing business needs and technological advancements. +Design services that can adapt to changing business needs and technological advancements ## 3.2. Rationale -* Ministerial priorities will change. Business environments evolve rapidly; agility is -essential to serve users effectively. -* Reduced risk of obsolescence, quicker response to market changes. +* Ministerial priorities will change. Business environments evolve rapidly - agility is +essential to serve users effectively. +* Reduced risk of obsolescence, quicker response to market changes ## 3.3. Implications -* Continuous development is expensive, design solutions to allow for predictable change -without redevelopment. -* Predict the types of change that will affect your solution area and accommodate these -in the design through configuration or replaceable/expandable modules. -* Delivery of flexible and adaptable solutions will be more complex and costly initially, -offset by reduced future cost of change. -* Change may not happen; do not cover every eventuality, only consider changes that -could be expected within the lifecycle of a product. +* Continuous development is expensive - design services to allow for predictable change +without redevelopment +* Predict the types of change that will affect your service area and accommodate these +in the design, through configuration or replaceable/expandable modules +* Delivery of flexible and adaptable services will be more complex and costly initially, +offset by reduced future cost of change +* Change may not happen - do not cover every eventuality, only consider changes that +could be expected within the lifecycle of a service/product --- -# 4. Security and Compliance +# 4. Security and compliance + ## 4.1. Description -Prioritise security measures and regulatory compliance in architectural decisions. +Prioritise security measures and regulatory compliance in architecture decisions ## 4.2. Rationale -* Good security practices protect data, maintains trust, and avoids reputational damage, -impact to customers and legal penalties. -* Understanding threats, vulnerabilities and applying mitigations at design stage reduces -cost of delivering secure services and prevents vulnerabilities risking DFE data and -services. +* Good security practices protect data, maintain trust and avoids reputational damage, +impact to customers and legal penalties +* Understanding threats, vulnerabilities and applying mitigations at the design stage reduces +the cost of delivering secure services and prevents vulnerabilities risking DfE data and +services ## 4.3. Implications -* Conduct threat modelling early in a service lifecycle and review as threats and the -service evolve. -* Apply threat modelling to all components and flows in your solution from both external -and internal threat actors and apply appropriate mitigations. +* Conduct threat modelling early in a service lifecycle and review, as threats and the +service evolve +* Apply threat modelling to all components and flows in your service, from both external +and internal threat actors, and apply appropriate mitigations * Threat mitigations should be prioritised in backlogs to prevent exploitation of -vulnerabilities. -* A system is only as secure as its weakest link, therefore all components, modules and -flows should be protected regardless of the sensitivity of data held by that solution. -* Exploitation of weak points can provide a stepping stone into other solutions, platforms, -and data, therefore even if your solution is considered lower risk, protections are -required to prevent your system becoming a back door into sensitive data elsewhere in -the organisation. +vulnerabilities +* A system is only as secure as its weakest link - all components, modules and +flows should be protected regardless of the sensitivity of data held by that service +* Exploitation of weak points can provide a stepping stone into other services, platforms, +and data - even if your service is considered lower risk, protections are +required to prevent your system becoming a 'back door' into sensitive data elsewhere in +the organisation --- -# 5. Cloud First - Rent before buy before build +# 5. Cloud First - rent, before buy, before build + ## 5.1. Description -Do not build what can easily bought off-the-shelf. Prioritise cloud-based solutions over on- -premises alternatives. +Do not build what can easily be bought off-the-shelf. Prioritise cloud-based services over on-premises alternatives. ## 5.2. Rationale -* Commercial-off-the-shelf (COTS) solutions include cost of development, operation, and -best practice their costs and share these between all clients therefore Total Cost of -ownership (TCO) is cheaper for “utility” functionality. -* Leverage scalability, cost-effectiveness, and agility of cloud services. +* Commercial-off-the-shelf (COTS) services include the cost of development, operation and +best practice in their costs, and share these between all clients. Total Cost of +Ownership (TCO) is cheaper for 'utility' functionality. +* Leverage scalability, cost-effectiveness and agility of cloud services ## 5.3. Implications -* Conduct an options appraisal before choosing delivery approach. -* Evaluate COTS solutions against “good enough” as they are unlikely to meet all -requirements; they may need façades, configuration, or a hybrid approach to meet user -needs e.g. If a COTS solution delivers 80% of user needs, consider wrapping or +* Conduct an options appraisal before choosing a delivery approach +* Evaluate COTS solutions against what's “good enough”, as they are unlikely to meet all +requirements - they may need façades, configuration or a hybrid approach to meet user +needs. For example, if a COTS solution delivers 80% of user needs, consider wrapping or extending the COTS solution for the remaining 20%, rather than building 100% bespoke. -* Avoid customisation of COTs solutions to deliver bespoke functionality, where required +* Avoid customisation of COTS solutions to deliver bespoke functionality. Where required, use configuration and integration to tailor the solution to user needs. Adapt business -processes to align with COTS where possible. -* Develop an exit plan before adopting COTS to prevent vendor lock-in. -* Evaluate TCO between COTS and bespoke, including hosting, delivery resource, -support, and platform costs for the lifetime of the product, during options appraisal. -* Prioritise Software-as-a-Service (SaaS) solutions, over Platform-as-a-Service (PaaS) -over Infrastructure-as-a-Service (IaaS), over on-premise, when evaluating solution -hosting options. +processes to align with COTS where possible. +* Develop an exit strategy before adopting COTS, to prevent vendor lock-in +* Evaluate TCO between COTS and bespoke options during options appraisal. This should include + hosting, platform, delivery resource and support costs, for the lifetime of the product. +* Prioritise Software-as-a-Service (SaaS) services, over Platform-as-a-Service (PaaS), +over Infrastructure-as-a-Service (IaaS), over on-premises options, when evaluating service +hosting options --- -# 6. Data Integrity and Quality +# 6. Data integrity and quality + ## 6.1. Description -Ensure accurate, consistent, and reliable data across DFE IT Landscape. Use master data sources and, when mastering data, make it available to other services through interfaces that ensure data consistency, integrity and quality. +Ensure accurate, consistent and reliable data across DfE. Use master data sources and, when mastering data, make it available to other services through interfaces ## 6.2. Rationale -* Reliable data drives informed decision-making and operational efficiency. -* Duplication or poor data management practices reduce user trust, introduce errors, -discrepancies and data quality issues whilst increasing cost and effort of data collation -and analysis. +* Reliable data drives informed decision-making and operational efficiency +* Duplication or poor data management practices reduces user trust, introduces errors, +discrepancies and data quality issues, whilst increasing the cost and effort of data collation +and analysis * By creating and using trusted shared data sources, services can provide consistent -data, improving user experience and trust and reduce data engineering costs in -preparing data for analysis. +data, improve user experience and trust, and reduce data engineering costs, in +preparing data for analysis ## 6.3. Implications -* Use authoritative data sources without creating copies. +* Use authoritative data sources without creating copies, to ensure data consistency, integrity and quality * Authoritative data sources must have availability and scalability to meet service -demands with appropriate support and service levels. -* Embed data management and governance practices in the organisation and for both -operational and analytical data. +demands, with appropriate support and service levels +* Embed data management and governance practices in the organisation for both +operational and analytical data --- -# 7. Reuse and Modularity +# 7. Reuse and modularity + ## 7.1. Description -Solve problems once, encourage creation and reuse of components, services and patterns. +Solve problems once, encouraging the creation and reuse of components, services and patterns ## 7.2. Rationale -* Delivering services and functionality is expensive, by avoiding reinventing the wheel we -can streamline development efforts, reduce duplication and costs. -* By decomposing services into small reusable components teams can consume these -rather than building functionality from scratch. -* Services can be delivered by assembling existing components more quickly, cheaply, -and consistently than duplicating functionality. -* Capabilities cross organisational and service boundaries therefore reuse can break -down the silos that naturally form around portfolio centred teams and create a more -consistent user experience. +* Delivering services and functionality is expensive - by avoiding reinventing the wheel, we +can streamline development efforts, reduce duplication and costs +* By decomposing services into small reusable components, teams can consume these +rather than building functionality from scratch +* Services can be delivered by assembling existing components quicker, cheaper +and more consistently than duplicating functionality +* Capabilities cross organisational and service boundaries - reuse can break +down the silos that naturally form around portfolio-centred teams and create a more +consistent user experience * Modularity allows rearrangement of components and functionality when policy or -organisational goals or objectives change. -* Updates to shared components automatically apply to all dependent services; when -making changes only the component changes and therefore can reduce testing -required. -* Measurement of use of components allows better understanding of user journeys to -inform policy and delivery decisions. +organisational goals or objectives change +* Updates to shared components automatically apply to all dependent services - when +making changes, only the component changes which reduces the testing required +* Measuring the of use of components allows better understanding of user journeys, to +inform policy and delivery decisions ## 7.3. Implications -* Interdependencies between services and teams increase complexity and will slow initial -deliveries. -* Assume that someone will need to reuse any new capabilities you deliver, look for +* Interdependencies between services and teams increases complexity and will slow delivery +initially +* Assume that someone will need to reuse any new capabilities you deliver - look for similarities rather than differences, only build what does not exist already, and make it reusable. Where there are differences consider encapsulation or abstraction to extend -the base functionality; and make that a service. +the base functionality, and make that a service. * Changes to components need to be non-breaking to avoid failures in dependant -systems. +systems * Make services small and re-useable, breaking functionality into separate modules or -components with integration capabilities. -* Facilitate synchronous and/or asynchronous integrations as appropriate. -* Separate front-end functionality from back-end components, back-ends should not -depend on front end validation or other functionality to function correctly. -* Design and scale each component for availability and re-use; Consider “circuit -breakers” for latency and non-responsiveness of components but avoid duplication as -mitigation. -* Components need to support all users equally. -* Need capability teams to discover existing components, services and patterns and the -functionality they provide? +components with integration capabilities +* Facilitate synchronous and/or asynchronous integrations, as appropriate +* Separate front-end functionality from back-end components - back-ends should not +depend on front-end validation (or other functionality) to work correctly +* Design and scale each component for availability and re-use - consider 'circuit +breakers' for latency and non-responsiveness of components but avoid duplication as +mitigation +* Components need to support all users equitably +* Requires teams to be able to discover existing components, services and patterns, and the +functionality they provide --- -# 8. Design for Operation +# 8. Design for operation + ## 8.1. Description -Architect systems with operational efficiency, reliability and sustainability in mind. +Architect systems and services with operational efficiency, reliability and sustainability in mind ## 8.2. Rationale -* Smooth operations reduce downtime, enhance reliability and availability. +* Smooth service operations reduce downtime, enhance reliability and availability * Designing for efficient operations, with appropriate availability and scalability without -manual intervention drives reduced TCO. -* The majority of costs for any solution occur post-delivery and therefore architects -should avoid short-term decisions to minimise delivery costs or accelerate delivery -timescales that adversely impact the organisation or stakeholders long-term. +manual intervention, drives reduced TCO +* The majority of costs for any service occur post-delivery - avoid short-term decisions to +minimise delivery costs, or accelerate delivery timescales that adversely impact the +organisation or users long-term. ## 8.3. Implications -* Design systems with appropriate resilience and scalability to meet service needs and -those of any dependent services, where possible automate these to avoid service +* Design systems with appropriate resilience and scalability to meet service needs, and +those of any dependent services. Where possible, automate these to avoid service impacts in the event of sudden demand or failures. * Services may need different levels of availability and scalability for each module or -component of their service; overall service availability and scalability is only as good as -its weakest link. Plan and test for DR/BC scenarios and peak loads to ensure service -designs are appropriate. -* Automation and integration of solution operations to common CMDB, service logging -and monitoring platforms promotes easier maintenance, proactive monitoring, and -better support with reduced resource requirements. -* All projects delivering solutions to replace existing services or components need to -include decommissioning of the old system in the project activity and costs to avoid -technical debt. -* Automate delivery pipelines to update CMDB/service catalog to ensure information is -always up to date during delivery phase. -* Evaluate the long-term viability of suppliers and products to prevent tech-debt or risk of -supplier failure. -* Architectural decisions need to factor the expected life cycle of the solution and its -impact on stakeholders, the environment, and total cost of ownership. +component. Overall service availability and scalability is only as good as +its weakest link. Plan and test for Disaster Recovery and Business Continuity scenarios, +as well as peak loads, to ensure service designs are appropriate. +* Automation and integration of service operations to a common Configuration Management +Database (CMDB), logging and monitoring platforms promotes easier maintenance, proactive +monitoring and better support, with reduced resource requirements. +* All projects delivering services that replace existing services or components must +include decommissioning of the old service(s) or component(s) in the project activity and costs, + to actively reduce technical debt +* Automate delivery pipelines to update CMDB / Service Catalogue, to ensure information is +always up to date during delivery phases +* Evaluate the long-term viability of suppliers and products, to prevent technical debt or risk of +supplier failure +* Architecture decisions need to factor the expected lifecycle of the service and its +impact on stakeholders, the environment and TCO * Decisions need to prioritise prevention of technical debt, minimise rework, ensure -future scalability (up and down), and optimise operational resource and cost demands. -* Include full lifecycle people and technical resource costs in TCO comparisons when -evaluating options. +future scalability (up and down) and optimise operational resource and cost demands +* Include full-lifecycle people and technical resource costs in TCO comparisons when +evaluating options --- -# 9. “Good Enough” Solutions +# 9. “Good enough” services + ## 9.1. Description -Recognize that perfection is not always necessary. Strive for solutions that meet essential +Recognise that perfection is not always necessary. Strive for services that meet essential requirements without unnecessary features. Prioritise value over perfection, especially in agile and iterative contexts. + ## 9.2. Rationale -* Balancing pragmatism with quality allows for faster delivery, adaptability and maximises -taxpayer value whilst Minimising delivery costs and allowing resources to pivot to other -deliveries. Pareto rule – 20% of functionality delivers 80% of the value. +* Balancing pragmatism with quality allows for faster delivery, adaptability and maximises +taxpayer value, whilst minimising delivery costs and allowing people to pivot to other +delivery +* Pareto rule – 20% of functionality delivers 80% of the value + ## 9.3. Implications -* Architecture needs to reflect the emergent nature of agile delivery and therefore do “just -enough” architecture to enable delivery; this means longer term architecture should still -be done, but at an appropriate level to adapt as detail emerges through delivery. -* Avoid “gilding the lily” or over-engineering, focus on critical features, and iterate based -on feedback. Measure VFM of each feature including costs of delivery resources over -realistic lifetime of the product before adding to backlog. Stop when the service reaches -“good enough”. -* Evaluate cost saving of COTS options with good-enough functionality against bespoke -delivery. -* Ensure compliance with legislative, accessibility and security standards. -* Have a “definition of done”, check regularly whether this criteria has been met +* Architecture needs to reflect the emergent nature of agile delivery and therefore do 'just +enough' architecture to enable delivery. This means longer term architecture should still +be done, but at an appropriate level to adapt, as detail emerges through delivery. +* Avoid “gilding the lily” or over-engineering - focus on critical features and iterate based +on feedback. Measure the value for money of each feature, including cost of delivery resources over +a realistic lifetime of the service before adding to backlog. Stop when the service reaches +'good enough'. +* Evaluate the cost saving of COTS options with 'good-enough' functionality against bespoke +delivery +* Ensure compliance with legislative, accessibility and security standards +* Have a 'definition of done' - check regularly whether this criteria has been met