Fundamentals of Software Architecture Ch. 1

Fundamentals of Software Architecture Ch. 1

Architecture

Fundamentals of Software Architecture

by Mark Richards & Neal Ford

I'm starting to read Fundamentals of Software Architecture by Mark Richards & Neal Ford and plan to document my main takeaways on this blog. Today we're starting with Chapter 1.

Chapter 1

What is Software Architecture?

It's good to think about it having four dimensions. We will get more into these later on in the book, but they are architectural characteristics, architectural style, logical components, and architectural decisions.

  • Architectural Characteristics
    • These define the capabilities of the system, and can be abbreviated/thought of as "-ilities" and the criteria for its success. They are things like availability, reliability, testability, scalability, deployability, etc. They aren't exclusively "-ilities" though, as they also include things like fault tolerance, performance, and security.
  • Logical Components - While characteristics define a systems capabilities, logical components define its behavior. This includes the domains, entities, and workflows of the application.
  • Architectural Style - Choosing a style involves finding the easiest implementation path for a given set of requirements.
  • Architecture Decisions - These define rules for how a system should be constructed. They form the constraints of the system and direct the development teams on what is and isn't allowed.

Laws of Software Architecture

  1. Everything in software architecture is a trade-off.
  2. Why is more important than how.
  3. Most architecture decisions aren't binary but rather exist on a spectrum between extremes.

Expectations of a Software Architect

Make Architecture Decisions

This is about defining the architectural decisions and design principles that should guide technology decisions within the team. Guide is the key word here. Architects should guide rather than specify. For example, rather than specifying a team should use React.js for frontend development, and architect should instruct the development teams to use a reactive-based frontend for web development, guiding them to consider Angular, Vue, or React and let the team make the technical choice that is best for them. This can be tricky, as technical decisions sometimes do have to be made in order to preserve a particular architectural characteristic, and a balance must be found.

Continually Analyze the Architecture

An architect should continually analyze the architecture and current technology environment and recommend solutions for improvement. Vitality assesses how viable an architecture that was defined three or more years ago is today, given changes in both business and technology.

Keep Current with the Latest Trends

Architectural decisions tend to be long lasting and difficult to change. Understanding trends helps to make decisions that will remain relevant into the future.

Ensure Compliance with Decisions

Continually verifying that development teams are following the architecture decisions and design principles defined, documented, and communicated by the architect.

Understand Diverse Technologies

Architects should focus on technical breadth rather than technical depth. You're not expected to be an expert in every framework, platform, or language, but you should at least be familiar with a variety of technologies. It's better for an architect to be familiar with the pros and cons of 10 different products than to be an expert in only 1 of them.

Know the Business Domain

The business domain is the business problem, goals, and requirements that a system is intended to solve. It's important to understand the business reasons for an application, otherwise it's impossible to design an effective architecture.

Possess Interpersonal Skills

Leadership is a huge component of being a good software architect. The job involves leading development teams through implementing architecture. Being a great technologist but struggling to lead teams and communicate effectively can cause a lot of problems.

Understand and Navigate Politics

Again, similarly to the previous expectation, interpersonal skills are important. Negotiation is a key part of a software architects job, as the goal is the guide teams smoothly rather than make too many decisions for them and cause friction. Architects make broad and important decisions, they are often challenged, and must be able to back and justify them.

Roadmap

This book will consist of 3 parts: Foundations, Architectural Styles, and Techniques & Soft Skills. That's it for Chapter 1, with an overview of how to think about software architecture and expectations of an effective software architect. Chapter 2 will begin the Foundations part of the book, and I look forward to seeing what is in store!