Frameworks

A simple decision-making framework for system design

This is close to the Design Thinking Process from the interaction design cited below but from a architects view point.

1. Define the problem scope

Problem Comprehension

Understanding the problem completely is critical to the success of being an architect

1. Ask questions to narrow down the scope ( broad & vauge -> narrow and specific)
   • Clarify both functional and non-functional requirements

Below are questions that could be used for functional or non-functions. This is not a complete list of every question that should be asked, but it is helpful starting the process.

Architects Decision Record (ADR)

Log all decisions that are you plan to make in the architects decision record (ADR)

Characteristics of an ADR

• It is critical to keep track of all decisions being made at any time!

• Provide clear detail through context with rationale of each decision with supporting documentation, who requested it, all informed parties, assumptions, etc

• All recorded decisions (AD) are Immutable

• Provide ADR openly to be viewed by everyone including executives, stakeholders, employees of affected areas, etc

• Provide consequences if the decision is not implemented

There are plenty of templates out there, I suggest you download one to start and then customize it to fit your needs.

ADR Templates & Examples
Azure WAF ADR
Google WAF ADR
AWS ADR Process

Functional Side

Here are some questions that should be asked in most situations.

1. State of Project
   • Is this greenfield or brownfield work?
   • Who are our clients or consumers?
   • What are all the systems that we need to communicate with?
   • What is in & out of scope
   • What are the project constraints
   • state the assumuptions to the team and on paper
2. State of System
   • What are all the systems that we need to communicate with?
   • What are the existing pieces of the current system?
     • Are any of these systems being deprecated?
       • If so, when and will this affect the outcome?
   • clarify expectations
   • What are the system constraints
   • state the assumuptions to the team and on paper

Non-Functional Side

• Limitations

• Current limitations of system

• Current Benchmarks?

• Current Landscape diagrams and documentations

• Business Objectives

• Users

  • Experience
  • User Behavior
  • User Security

• Availablity

• Consistency

• Reliability

• Performance

• Security

• Cost

• Data

  • How much data are you ingress and egress now?
  • Hoe much data are you expected to ingress and egress?

• locations of the data currently and expected?

  • Bandwidth Requirements

• Define the contraints

2. Define the high-level system design

Create the most fundemental pieces of the system and how they work together to adhere to the desired functionality

Providing a data flow design helps understand the functional and non-functional specs with the given constraints.

It's all about the data!

To start data design based on the constraints and the given functional and non-function requirements.

This could be API, Flat File, etc. Its important that you determine the ingress and egress data characteristics!

What data requirements do you have?

Define the characteristics of ingress & egress data?

What are all the types of data that are ingress and egress?
Estimate intake rate of data?
What are the communication types of how the data is ingressed and egressed?
Where does the data ingress and egress exactly?

Is some of the data broken up and is sent to multiple places?

If so, what exactly?

Does the design resolve the defined functional requirements within the constraints defined?

3. Deep dive into the design

Examine each of the system components and relationships in more detail.

Explain to the team how non-functional requirements impact the design choices.

Are there security requirements?

If so, how do these requirements affect other functionality and to what extent?

Are the security requirements resolved by this diagram?

Do we require to be global presence?

If so, we should consider redundancy options like availablity zones, multi-regional support, etc

How much data

Are there compliance requirements?

Do these align with our policies in place?
Are there new policies being implemented?

If so, then how would these policies affect other functionality?

Present different Options

Always present different options along with their beneifts and trade-offs between choosing each option! Why one would be preferred over the other.

4. Identify bottlenecks and scaling oppurtunities

Review the system design and consider the conditions such as scalability, availablity, performance and cost.

• Are there any single points of failure?
• What is the throughput-per-second (TPS) rate from end to end?
• What happens if specific components fail?
• How do I recover from these components failing?
• How important is my data if I lose some or all of it?

5. Review and confirm

Sources:
Dam, R. F. (2024, March 1). The 5 Stages in the Design Thinking Process. Interaction Design Foundation - IxDF. https://www.interaction-design.org/literature/article/5-stages-in-the-design-thinking-process

Mimi Phan & Rebecca Linke (2017, Sept 1). Design thinking, explained. MIT Management Sloan School - https://mitsloan.mit.edu/ideas-made-to-matter/design-thinking-explained

Jeanne Liedtka - Design Thinking - Why Design Thinking Works (2018, Sept-Oct) - Harvard Business Review - https://hbr.org/2018/09/why-design-thinking-works