System Architecture Design

Whether building a single application or a large application suite, designing the appropriate system architecture is a critical step.  It is not just a technology selection or a collection of system component diagrams or flows; rather a result of decisions based on business, technical and operational requirements that impact the quality, maintainability, performance and successful implementation of an application or application suite.  In more than a decade’s worth of designing architectures for various systems, I’ve found the following key guidelines necessary in the design process, regardless of how you approach system design:

  • Define key requirements and constraints
  • Identify key scenarios
  • Application overview
  • Identify risk areas and potential issues
  • Communicate key architecture decisions

Define Requirements and Constraints

Defining clear and specific requirements up front creates boundaries necessary so you can focus on creating a design that solves for specific objectives.   It is important that these are specific, e.g. “System must be able to retrieve data from systems A and B” versus “System must be able to interface with existing systems.” Nonspecific objectives can take your design down a rabbit hole of designing for a very broad use case.  Constraints must be accounted for in the architecture design in order to prevent surprises down the road that can potentially result in significant time and/or cost.

Identify Key Scenarios

It is also important to identify the key scenarios that are architecturally significant.  These are the scenarios that define what the architecture needs to support and doesn’t necessarily delve into the actual flow for each objective.  Examples of these could be:

  • Login
  • Lookup Inventory Information
  • Update Inventory Details, etc.

App Overview DiagramApplication Overview

At this stage, a high level diagram of the application can be defined.  This should be at a level that exposes the interaction between the different pieces, e.g. where the user interacts with the application, how the application interacts with the various backend systems, etc.   It should also show where the different crosscutting concerns apply to the interacting components in the architecture.  These may include authentication/authorization, logging and instrumentation, configuration, and caching among others.

Identify Key Risk Areas and Potential Issues

Most of the mistakes made during the design of the architecture happen when the designers fail to evaluate the proposed architecture against risk areas and/or potential issues that may occur after the design is implemented.   Some of the questions may include “can we handle a million users”, “can we swap out software X with Y”, “how quickly can we change business rules”, “how do we audit user authentication”, etc.   Asking questions like these ultimately define decisions for the architecture “abilities” (extensibility, flexibility, reliability, security, etc.).  This may introduce additional requirements but it is cheaper to revisit them at this stage than later.

Communicate Key Architecture Decisions

All of the key decisions about the architecture must be documented and communicated to everyone involved with the development of the application.  When all the stakeholders understand the key decisions and the rationale for those decisions, it helps align expectations and enables them to make better decisions for improving the application.  Communicating architecture decisions to developers empowers them to build the application aligned to those decisions and the QA organization can focus on the high-risk areas identified by this design.

There are several ways of going about designing system architecture, and every system and application is different. Our experience has shown that accounting for the above mentioned guidelines during the design process gives a clear direction where everyone is on the same page on how the architecture fits within the business requirements, and how it should influence the final product.  It is important to remember that a sound architecture is one that is built for change, and by adhering to these guidelines you should have a solid foundation to build future changes on.