Enterprise Architecture principles
7. Reuse and modularity
- Last reviewed
- 8 June 2026
- Owner
- Head of Architecture
Solve problems once, encouraging the creation and reuse of components, services and patterns.
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 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 which reduces the testing required.
Measuring the of use of components allows better understanding of user journeys, to inform policy and delivery decisions.
Implications
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.
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 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.