Skip to main content

SystemsArchitect.io

Getting Started​

Introduction

SystemsArchitect.io is:​

  • An opinionated Solutions Architect framework.
  • A resource for researching and comparing solutions.

7 Core Architect workflows​

  1. Solution Workflow (6R)
    • Overall solution process, from project kickoff to post-launch.
  2. User Workflow (6U)
    • Solicit the app's user requirements.
  3. Platform Workflow
    • Domain organization and control planes.
  4. Architecture Pattern Checklist
    • Design patterns to start and organize our architecture.
  5. Design Funnel
    • Monolith, n-Tier, Microservice, Queue, Event-Driven
  6. Services Workflow (UCROPS):
    • Usability, Cost, Reliability, Operations, Performance, Security.
  7. Data Access Patterns:
    • API calls, Schema, DB queries

... and that's it!

The rest of this site:

  1. Fills in the details of each of these core ideas.
  2. Highlights software architect best practices.
  3. Offers resources for researching and comparing solutions.

Main insights of this framework​

This architect framework is User-focused.​

  1. Usability is elevated in importance.
    • Usability is a core technical architecture principle.
  2. User requirements are cataloged in high detail early before technical design.
    • Other architect frameworks offer minimal usability requirements.
  3. All user roles associated with the app are considered in the system design.
    • Other architect frameworks do not fully consider all user roles, external and internal.
  4. User research, requirements gathering, and documentation are included in architect best practices.
  5. Documentation-driven development is a critical architect and developer best practice.

SystemsArchitect.io core​

The framework's core points can be remembered easily with a few acronyms:

1. 6R - Solutions Process Workflow​

6R Pyramid
  • Request
    • the Business User-focused (functional) software request
  • Requirements
    • Business functional document, Estimates/Projections, and Technical Systems (non-functional) proposal.
  • Review
    • reviewing plans and documents with relevant stakeholders and teammates.
  • Resolve
    • resolving differences and balancing solutions with feedback
  • Realize
    • software development process, which still involves the solutions architect ensuring guidelines are being followed.
  • Reassess
    • after launch, reassessing successes and failures and iterating improvements.

2. 6U - User Workflow​

Within the Request category (above) we have 6 User-focused topics to cover on an initial request.

6U User Workflow

This is initially meant only to help inform us in short period of time.

It can also help serve as an outline for a Business functional document in the future.

  • User Pitch
    • What is the app trying to do in a nutshell
  • User Roles
    • Who are the users of the app. This includes both external and internal users.
  • User Qualities
    • What are the characteristics of the users?
  • User Interface (UI)
    • What are the key aspects of the UI?
  • User Experience (UX), User Screens
    • What would be some typical user routes and screens involved?
  • User Projections
    • How will usage change over different time intervals?

3. Platform Workflow​

Logically grouped interactive technologies by "design area":

  1. Application platform
  2. Data platform
  3. Storage platform
  4. Networking platform
  5. Security platform
  6. DevOps platform

4. UCROPS - Tech Composition Workflow​

Evaluate technologies according to cloud solutions for business problems.

Structural Flow
  • U - Usability
  • C - Cost
  • R - Reliability
  • O - Operations
  • P - Performance
  • S - Security

The main difference with other similar frameworks is adding Usability as a topline consideration.

Usability includes frontend architecture, admin usability and developer codebase usability.

These considerations are expansive.

Usability is important enough to warrant being part of this list, in fact we put it at the top of the list.

5. Architecture Pattern Checklist​

Structural Flow
  1. Type of application: The type of software application being developed or deployed (e.g. web application, mobile app, IoT device, etc.)
  2. Architectural design style: The overall approach or pattern used to design the system's architecture (e.g. n-tier, microservices, monolithic, event-driven, etc.).
  3. Organizational requirements: The specific needs and constraints of the organization developing or using the system (e.g. compliance, scalability, security, etc.)
  4. Reference Architectures: Predefined architectural patterns or models that can be used as a starting point for designing a new system
  5. Technology platforms: The underlying infrastructure and tools used to run the system (e.g. cloud, on-premises, containers, etc.)
  6. Technology choices: The specific technologies and tools selected for use in the system (e.g. programming languages, frameworks, databases, etc.)
  7. Technology interaction: How the various technologies and components within the system interact and communicate with one another.

6. Design "Funnel"​

see more: Design Pattern Heuristics

Plans

⚡️ LEVEL 1 - N-TIER​

Small to medium-size apps.

  • Instance: easiest for small teams, low cost, but also less scalable/reliable. Small-medium apps, lower traffic apps. Improve with autoscaling and ELBs.
  • Container: more scalable/reliable, but more complex to setup. Small-medium apps. Improve with ELBs and container orchestration.
  • Managed: combines an easier setup with the managed infrastructure of instances/container. Can be more costly but easier to manage. Use for small-medium apps. Improve with ELBs and container orchestration.

⚡️ LEVEL 2 - API/Microservices​

Small to Large-size apps.

  • Solid usability, scalability, reliability, and cost. Most teams can handle this. Good for larger staffs to work concurrently. For medium-large apps.
  • May require more setup, management, expertise.

⚡️ LEVEL 3 - Queue/API/Microservices​

Medium to Large-size apps.

  • Similar to API/Microservices, but with a queue in front of the API/Microservices, which can increase performance and reliability, but add complexity. Use for large apps with high traffic/activity.

⚡️ LEVEL 4 - Event-driven​

Medium to Largest-size apps.

  • More complex, but highest level of scalability, reliability, and decoupling. Use for large apps with high traffic/activity or with many complex concurrent interactions.

7. Data Model Workflow​

  1. Use Cases
  2. Access patterns
  3. API Design
  4. Data Model

Bonus "PTSD" prevention mnemonic!​

"Responsible architects prevent software development PTSD with..."​

  • P - PRINCIPLED architecture
    • Best practices are followed
  • T - TECHNOLOGY-optimized workloads
    • Workloads are optimized with the correct technologies.
  • S - SAFE architecture
    • It does only what it's intended to do and is reliable.
  • D - DOCUMENTED architecture
    • It's design can be easily understood, maintained and implemented by others.