This post distills key insights from my study of "The Complete Guide to Becoming a Software Architect" by Demi Lavi.

View Course On Udemy

The Architect Mindset

Software architects must go beyond technical expertise to understand the company's business aspects deeply, including strengths, weaknesses, competition, and growth strategies. This understanding helps in crafting systems that align with broader business objectives.

It's crucial for architects to view system goals as reflections of business objectives and user needs, rather than just technical requirements. For example, a system designed for mapping criminal incidents should aim to improve public safety and urban living.

Architects should extend their focus beyond immediate clients to the end users. This approach ensures that the solutions developed are beneficial for all stakeholders involved.

Adapting communication to meet different stakeholder needs is vital. For instance, explaining the benefits of new technologies in terms of project management gains, like reduced schedules and budgets, can help align technical decisions with business goals.

The architect mindset involves integrating deeply with business strategies and understanding the end user’s perspective, which enhances the strategic impact of technology solutions in any organization.

Architecture Process

- Understand the System's Requirements
- Understand the Non-Functional Requirements
- Map the Components
- Select the Technology Stack
- Design the Architecture
- Write the Architecture Document
- Support the Team

Working With System Requirements

System requirements are crucial for guiding the design and functionality of a project. These requirements are broadly categorized into functional and non-functional types, each serving a distinct purpose in the system’s architecture.

Functional requirements describe what the system should do. They include:

- Business Flows: The processes that capture routine business activities.
- Business Services: The operations that a system performs to fulfill specific business needs.
- User Interfaces: The points of interaction between the system and its users. These are essential for defining the core operations of any system and ensure that the software meets its intended use.

While functional requirements focus on the actions of a system, non-functional requirements (NFRs) detail how the system performs under various conditions. These include:

- Performance: The speed and responsiveness of the system.
- Load: The maximum operating capacity the system can handle.
- Data Volume: The amount of data the system must manage effectively.
- Concurrent Users: The number of users who can interact with the system simultaneously.
- Service Level Agreements (SLA): The formalized level of service expected from the system. - Planning for extreme cases is vital as these scenarios test the limits of the system’s capabilities and resilience.

Meeting the *-ilities

*-ilities are a group of quality attributes essential for meeting non-functional requirements in software systems. A quality attribute is a technical capability that enhances system performance and usability.

These *-ilities include Scalability, Manageability, Modularity, Extensibility, and Testability—each serving a specific role in improving system design.

The relationship between non-functional requirements and architects is critical: non-functional requirements define the system's operational needs; quality attributes translate these needs into technical capabilities; and architects outline the design and implementation strategies for these capabilities.

Scalability ensures the system can handle increased loads by seamlessly adding resources, such as virtual machines, and integrating them with existing components like load balancers.

Manageability refers to the ease with which a system can be monitored and maintained, ensuring administrators can understand and influence system behavior effectively.

Modularity describes a system's design around independent building blocks, which can be individually updated or replaced without impacting overall functionality.

Extensibility allows for the addition of features or functionality without altering the existing system code, facilitating future growth and adaptation.

Testability is crucial for maintaining code quality, enabling systematic testing at both unit and integration levels to ensure robustness and reliability.

Architecture Components

A software component, often referred to as a "Service," is a piece of code designed to operate within a single process.

Modular systems, which are typically distributed, consist of independent software components. These components are deployed across separate processes (or containers, or servers), enhancing system flexibility and scalability.

These systems are examples of distributed systems, where components or services are deployed independently and interact through specific protocols.

The architecture of components involves managing internal components, facilitating interactions among them, and optimizing the code for speed and maintainability.

The system architecture represents the larger framework, focusing on creating solutions that are scalable, reliable, fast, and easy to maintain.

Design Patterns

While often associated with developers, design patterns also constitute a form of micro-architecture.

Design patterns provide reusable solutions to common software design challenges, aiding developers in creating scalable, maintainable, and efficient code. They serve as blueprints that guide the structuring of code.

These patterns are categorized into three types: Creational, Structural, and Behavioral. Creational patterns deal with object creation mechanisms, Structural patterns concern class and object composition, and Behavioral patterns govern interaction and communication between objects.

In my view, a thorough understanding of design patterns is essential for anyone aspiring to be a software architect.

System Architecture

System architecture focuses on the overarching structure of software systems.

It addresses crucial questions such as:

• - How will the system perform under heavy load?
• - What are the implications if the system crashes at a critical moment in the business flow?
• - How complex is the update process?
• - And more...

Key components of system architecture include:

• - Defining software components (services).
• - Establishing communication protocols between components.
• - Designing system capabilities such as scalability, redundancy, and performance.

These questions can be addressed through concepts such as loose coupling, statelessness, caching, messaging, and robust logging & monitoring systems.

Architecture Document

The architecture document is a comprehensive blueprint that outlines the designed architecture of a system. It serves multiple purposes, helping to validate the system design within the team and ensuring that the customer is fully aware of the proposed solutions.

This critical document covers several key areas:

• Functional and Non-Functional Requirements: It details what the system is expected to do and how it should perform under various conditions.
• Technology Stack: Describes the technologies that will be used to build the system.
• System Background: Includes the system's role, reasons for replacing the old system, and the expected business impact.
• Executive Summary: Provides a high-level, non-technical overview of the architecture, enhancing stakeholders' confidence through the use of charts and diagrams without being repetitive.
• Architecture Overview: Presents a high-level view of the architecture, aimed at giving the team a general understanding without delving into specific components. This section may include a logical diagram that distinguishes between the logical architecture and physical hardware.
• Component Drill-Down: Describes the roles and technology stacks of individual components in detail, including data stores, backend, and frontend specifications. This section should also detail the API, method names, URL roles, response codes, and any relevant comments. Detailed descriptions of the layers are also included here, alongside development instructions that may be relevant for developers.

The document targets all stakeholders involved in the system, such as QA teams, the CTO, project managers, and developers. Its structure can be modeled using UML, although this is often subject to debate.

Overall, the architecture document is geared towards aligning the system architecture with business goals, ensuring clarity and alignment across all stages of development and implementation.

Notes

Understanding various elements such as the types of applications, selecting the appropriate technology stack, and mastering the SOLID principles are crucial. Additionally, skills in exception handling, logging, and managing other types of components are essential. Keep in mind that these are foundational recommendations for starting a career in architecture.

Additionally, other topics can significantly contribute to a well-rounded architectural strategy. Understanding concepts such as microservices, event sourcing, and Command Query Responsibility Segregation (CQRS) enriches an architect's toolkit.