Designing the System

Designing the System refers to the strategic practices involved in planning and implementing the software architecture. This includes choosing appropriate patterns, practices, and technologies to create a scalable, maintainable, and efficient system.


The purpose of designing a system is to ensure the software architecture supports both the current and future needs of the product, facilitates easy maintenance and scalability, and optimises performance.


Industry Context

Products are never done. They are always evolving, and the pace of change is accelerating. This means that the architecture of the software must be flexible and adaptable to meet the changing needs of the business and its customers.

ZeroBlockers Context

Teams are autonomous from idea to satisfied customer so they need to own the architecture for their part of the product because they are the ones who will be maintaining and evolving it.


Architectural StylesThe fundamental structural choices that determine the system's overall design and behaviour.
  • Monolith
  • Microservices
  • Modular
Communication ProtocolsThe rules and mechanisms (connectors) that enable components and services to communicate and exchange data.
  • GraphQL
  • gRPC
Integration InfrastructurePractices for achieving seamless system interoperability, emphasising adaptability and extensibility.
  • Enterprise Service Bus (ESB)
  • Webhooks
  • Service Mesh
Data Persistence StrategiesMethods for efficiently storing, retrieving, manipulating, and persisting data across various storage solutions.
  • SQL databases
  • NoSQL databases
  • In-memory caches (Redis)
Embedding Security Best PracticesOngoing security practices such as regular audits, threat modeling, and adopting a security-first design philosophy.
  • OAuth
  • Secure coding standards
Fitness FunctionsAutomated tests and checks that ensure the system meets its non-functional requirements.
  • Scalability (load balancing)
  • Reliability (fault tolerance)
  • Usability (responsive design)


  • Big Ball of Mud: A haphazardly structured system that lacks a perceivable architecture, making it difficult to maintain and extend.
  • Overengineering: Adding unnecessary complexity to the architecture, including features or layers that are not required, making the system harder to understand and maintain.
  • Cargo Cult Programming: Blindly following practices, patterns, or tools without understanding their purposes or considering the context, leading to inappropriate or ineffective solutions.
  • Not Invented Here (NIH) Syndrome: Rejecting external solutions in favour of internally developed solutions, even when the external solutions are more efficient or suitable.
  • Ivory Tower Architecture: Designing the architecture without considering practical constraints or the input of the development team, leading to a disconnect between design and implementation.

Case Studies

Was this page helpful?

Continuous Delivery Principles
© ZeroBlockers, 2024. All rights reserved.