@DanLebrero.

software, simply

Book notes: Fundamentals of Software Architecture

  • Wed, 17 Nov 2021

Book notes on "Fundamentals of Software Architecture" by Mark Richards and Neal Ford

These are my notes on Fundamentals of Software Architecture by Mark Richards and Neal Ford

A solid introduction to software architecture.

Key learning: “it is really easy to fake it as an architect” .

A good companion to the book is Mark Richards’ Software Architecture Mondays.

Key Insights

  • Architecture of the system is the sum of:
    1. Structure.
    2. Architecture characteristics (- ilities):
      • Define the success criteria of a system.
    3. Architecture decisions.
    4. Design principles:
      • Guidelines, not rules.
  • Architect: Breath instead of depth.
  • Almost every decision an architect makes will be challenged.

Everything is a trade-off. First law of software architecture.

Why is more important than how. Second law of software architecture.

  • Architecture Thinking:
    1. Collaboration with teams to do architectural work.
    2. Technical breadth.
    3. Analysis trade-off.
    4. Understanding business drivers.
  • Architecture is the stuff you can’t Google.
  • Never shoot for the best architecture, but rather for the least worst one.
  • Architecture Katas.
  • Once you have identified the architectural characteristics try to drop one (or two).
  • Layered Architecture Style:
    • Sinkhole anti-pattern:
      • If most (> 50%) of the layers is a simple pass-through without logic.
  • Service-based Architecture Style:
    • Typically, shared DB and UI.
    • One of the most pragmatic architecture styles.
  • Event-Driven Architecture Style:
    • Two topologies:
      1. Broker topology:
        • No central event mediator, but a chain of events.
      2. Mediator topology:
        • Mediator manages and controls workflow.
      • Trade-off table.
      • Choice between topologies comes down to workflow control/error handling vs performance/scalability.
  • Orchestration-Driven Service-Oriented Architecture Style:
    • Doomed to irrelevance.
  • Making an architecture decision involves:
    1. Gather enough relevant information.
    2. Justify the decision.
    3. Documenting the decision.
    4. Communicating if effectively to the right stakeholders.
    • Anti-patterns:
      1. Covering your assets.
      2. Groundhog day.
      3. Email-Driven architecture.
  • Asses risk per architecture characteristic per quanta.
  • Unknown or unproven technologies are always high risk.
  • Presentations: Insert blank slide to focus attention on speaker.
  • Signs dev team is too big:
    • High process loss.
    • Pluralistic ignorance.
    • Diffusion of responsibility.
  • Leverage on checklists.
  • Demonstration defeats discussion.
  • Negotiating with developers:
    • Always provide a justification, state it first.
    • Once a person hears something they disagree with, they stop listening.
    • If a dev disagrees with a decision, have them arrive at the solution on their own.
  • Spend 20 mins first things in the morning (before reading work email) on learning.

Architecture Style score cards

The authors score all architecture styles by architecture capabilities. Here there are all together:

Best architecture style is Microservices with 40 stars, worst is Orchestration-Driven Service-Oriented (aka ESB) with 22 stars.

Just joking! Context is king!

TOC

Chapter 1: Introduction

  • Architecture of the system is the sum of:
    1. Structure:
      • Refers to the type of architecture style.
    2. Architecture characteristics (- ilities):
      • Define the success criteria of a system.
    3. Architecture decisions:
      • Rules of how the system should be constructed.
      • Variance == break rule. Reviewed/approved by architecture review board or chief architect.
    4. Design principles:
      • Guidelines, not rules.
  • Core responsibilities of an architect:
    1. Make architecture decisions:
      • To guide, rather than specific technology choices.
    2. Continually analyze the architecture:
      • Viability of current architecture, specially if older than 3 years.
    3. Keep current with the latest trends.
    4. Ensure compliance with decisions.
    5. Diverse exposure and experience.
      • Breath instead of depth.
    6. Have business domain knowledge.
    7. Possess interpersonal skills.
    8. Understand and navigate politics.
      • Almost every decision an architect makes will be challenged.

Everything is a trade-off. First law of software architecture.

Why is more important than how. Second law of software architecture.

Part I - Foundations

Chapter 2: Architectural Thinking

  • Seeing from an architectural point of view.
  • 4 aspects:
    1. Collaboration with teams to do architectural work.
    2. Technical breadth.
    3. Analysis trade-off.
    4. Understanding business drivers.
  • Architect must be part of the dev team to:
    1. Mentor/coach.
    2. Keep architecture and design in sync.
  • Architecture is the stuff you can’t Google.
  • The answer to every architecture question is “it depends”.
  • Every architect should code:
    • Not in the critical path.
    • Proof of concepts.
    • Tooling.

Chapter 3: Modularity

  • Module:
    • Standardized or independent units that can be used to construct a more complex structure.
  • Measuring modularity:
    • Cohesion:
      • Attempting to divide a cohesive module would only result in increased coupling and decreased readability.
      • LCOM: Lack of Cohesion in Methods:
        • Methods not using the same fields.
        • The sum of sets of methods not shared via sharing fields.
    • Coupling:
      • Afferent or efferent.
    • Distance from the main sequence:
      • D = | A + I - 1 |
      • A = abstractness = sum(abstract elements) / sum(concrete elements)
      • I = instability = efferent coupling / (efferent + afferent)
        main sequence
    • Connascence:
      • Two components are connascent if a change in one requires a change in the other.
      • From more desirable (weaker connascense) to less desirable (stronger connascense):
        1. Name: agree on name.
        2. Type.
        3. Meaning or Convention: meaning of particular values.
        4. Position: order of values.
        5. Execution: order of execution.
        6. Timing: timing of threads.
        7. Values: several values must change together.
          • Distributed transaction.
        8. Identity: reference same entity.
      • Jim Weirich:
        • Rule of Degree: convert strong forms into weaker forms of connascense.
        • Rule of Locality: as the distance between software elements increase, use weaker forms of connascense.

Chapter 4: Architecture Characteristics Defined

  • Architecture characteristic == non functional requirements:
    • Implicit or explicit.
    • Architect should choose the fewest architecture requirements.
    • Criteria:
      • Influences design.
      • Is critical for success.
    • List in page 58.
  • Never shoot for the best architecture, but rather for the least worst one.

Chapter 5: Identifying Architectural Characteristics.

  • Translate domain stakeholders concerns:
    • Examples:
      • Time and budget -> Simplicity, feasibility.
      • User satisfaction -> Performance, availability, fault tolerance, testability.
      • Time to market -> Agility, testability, deployability.
      • Merger and acquisitions -> Interoperability, scalability, adaptability, extensibility.
  • From requirements and inherent domain knowledge.
  • Architecture Katas.
  • Once you have identified the architectural characteristics try to drop one (or two).

Chapter 6: Measuring and Governing Architecture Characteristics

  • Governance:
    • Evolutionary architectures and fitness functions.
    • Conformity, Janitor and Security monkeys.

Chapter 7: Scope of Architecture Characteristics

  • Scope is per architecture quantum, not the whole system.
    • Architecture quantum:
      • An independently deployable artifact with high functional cohesion and synchronous connascense.
      • DB is part of the quantum.

Chapter 8: Component Based Thinking

  • Component:
    • Physical manifestation of a module.
    • Lowest level than an architect interacts directly with.
  • Top level partitioning; either
    • Technical partitioning: layered architecture.
    • Domain partitioning: modular monolith, microservices.
      • By workflow or domain.
  • Component identification flow:
    Component identification flow
  • Entity trap anti-pattern:
    • Entity manager == components.
  • Discovering components:
    1. Actor/Actions: use case diagrams.
    2. Event storming.
    3. Workflow approach.

Part II - Architecture Styles

  • Architecture style: overall structure of how the code is organized.
  • Architecture pattern: specific solutions within an architecture style.

Chapter 9: Foundations

  • Fallacies of distributed programming:
    1. The network is reliable.
    2. Latency is zero.
    3. Bandwidth is infinite:
      • Stamp coupling:
        • Returning more data than required in a REST endpoint.
        • Fixes:
          • More specific endpoints.
          • Field selectors in contract.
          • GraphQL.
    4. Network is secure.
    5. Network topology never changes.
    6. There is only one administrator.
    7. Transport cost is zero.
    8. The network is homogeneous.

Chapter 10 - Layered Architecture Style

  • Typical layers:
    • Presentation, business, persistence, database.
  • Leverage technical expertise.
  • Lack of overall agility.
  • Business domain is spread through all layers.
  • Does not work well with DDD.
  • Architecture sinkhole anti-pattern:
    • If most (> 50%) of the layers is a simple pass-through without logic.
    • Move to another architecture style.
  • Good for small apps.
  • Layered are == monolith.
  • Cost and simplicity degrade quickly when app gets bigger/more complex.

Chapter 11 - Pipeline Architecture Style

  • Encourages compositional reuse.
  • Usually deployed as a monolith.

Chapter 12 - Microkernel Architecture Style

  • Aka plug-in architecture.
  • Core can be layered or modular monolith or another process.
  • Typically, point-to-point communication between core and plugins.
  • Compile time or runtime (OSGi) plugins.
  • Eclipse, Jenkins, Jira, Chrome/Firefox.

Chapter 13 - Service-based Architecture Style

  • Coarse-grained services with typically a shared DB and UI:
    • Split by domain.
    • Services do not talk to each other.
    • Maybe an API gateway.
      Service-based Architecture Style
  • DB can be split logically by providing domain specific libraries, so it is easier to find out which service is going to be impacted by a DB schema change.
  • One of the most pragmatic architecture styles:
    • Good modularity.
    • No distributed orchestration/choreography.

Chapter 14 - Event-Driven Architecture Style

  • Two topologies:
    1. Broker topology:
      • No central event mediator, but a chain of events.
      • Usually broadcast of events.
      • Good practice: event processors to advertise what they did, even if no other event processor cares right now. (Really?)
    2. Mediator topology:
      • Mediator manages and controls workflow.
        Mediator topology
      • Communication between Event Mediator and processors is sending commands point-to-pint with queues.
      • Processors do not broadcast their actions.
  • For simple processing: Apache Camel, Spring Integration.
  • For hard: BPEL product (Apache ODE).
  • For complex, long running transactions that require manual intervention: BPM.
  • Recommendation: initial processing by simple mediator that can forward the event to complex/hard depending on event complexity classification.
  • Trade-off table:
    Advantages Disadvantages
    Broker Highly decoupled event processor Workflow control
    Highly scalability Error handling
    High responsiveness Recoverability
    High performance Restart capabilities
    High fault tolerance Data inconsistency
    Mediator Workflow control More coupling
    Error handling Lower scalability
    Recoverability Lower performance
    Restart capabilities Lower fault tolerance
    Better data consistency Modeling complex workflows

  • Choice between topologies comes down to workflow control/error handling vs performance/scalability.

  • Workflow event pattern for error handling:
    1. Event consumer forwards bogus event to the workflow processor and continues with next event.
    2. Workflow processor tries to repair event and forwards it to the event consumer’s original queue.
    3. From event consumer point of view is a new event.
    4. If event cannot be repaired, workflow processor forwards it to some dashboard for manual intervention.
  • Preventing data loss:
    1. Producer: synchronous sent + persistent queue.
    2. Consumer: client acknowledge mode.
  • Request-reply implementations:
    1. Correlation ID.
    2. Temporary queue for the response.
Request-based model Event-Based model
Certainty and control over workflow is needed Flexibility
Responsiveness, scalability
Complex and dynamic processing

Chapter 15 - Space-Based Architecture Style

  • Usage of data grids to avoid DB bottlenecks.
  • Highly scalable, elastic, performant.
  • Async writes to DB through persistent queues.
  • Hazelcast, Apache Ignite, Oracle Coherence.
    Space-Based Architecture Style
  • Message grid:
    • Nginx or HA proxy.
    • Routing of request.
  • Data Grid:
    • Nowadays implemented within the processing unit.
    • It is essential that each processing unit contains exactly the same data.
  • Processing grid:
    • If orchestration is needed between different processing unit types.
  • Deployment manager:
    • Manages number of processing units depending on load.
  • Data collision due to replication lag:
    • Collision rate formula: N * (UR2 / S) * RL
      • N = number of instance.
      • UR = update rate in milliseconds.
      • S = cache size.
      • RL = replication latency.
  • Can deploy processing units, virtualized middleware and data pumps to cloud, and reader/write and DB on-premise.
  • Distributed cache:
    • When:
      1. Data to be cached is big (> 100 Mb).
      2. High write rates.
      3. Collisions are not acceptable.
  • Recommended with very spiky apps and high number of concurrent users (> 10k).

Chapter 16 - Orchestration-Driven Service-Oriented Architecture Style

  • Doomed to irrelevance.
  • Aim is reuse by technical partitioning:
    Orchestration-Driven Service-Oriented Architecture Style
  • Enterprise Service Bus (ESB).
  • Business services:
    • No code.
    • Defined by business users.
  • Enterprise services: Reusable.
  • App Services:
    • App specific logic.
    • Not reusable.
  • Infrastructure Services: Monitoring, logging, …
  • ESB:
    • Bureaucratic bottleneck.
  • Distributed monolith.

Chapter 17 - Microservices Architecture

  • Primary goal is high decoupling.
    • At the cost of duplication and distributed architecture.
  • Size, consider:
    • Purpose.
    • Transaction boundaries.
    • Choreography.
    • Data isolation.
  • Sidecar pattern.
  • Service mesh.
  • Microfrontends, either:
    • Choreography: service call other services as needed.
    • Mediator: new service that pulls data from several other services.
  • Don’t do distributed transactions, fix granularity instead.
    • Saga pattern:
      • Mediator to coordinate.
      • Compensating transactions to rollback.
      • More than double the complexity.

Chapter 18 - Choosing the Appropriate Architecture Style

  • Design criteria:
    • Domain.
    • Architecture characteristics that impact structure.
    • Data architecture.
    • Organizational factors.
    • Processes, teams, and operational concerns.
    • Domain/architecture isomorphism:
      • Some domains match the topology of the architecture.
  • Decide on:
    1. Monolith vs distributed.
    2. Where should data live?
    3. Async vs sync communication:
      • Use sync by default, async when necessary.

Part III - Techniques and Soft Skills

Chapter 19 - Architecture Decisions

  • Making an architecture decision involves:
    1. Gather enough relevant information.
    2. Justify the decision.
    3. Documenting the decision.
    4. Communicating if effectively to the right stakeholders.
  • Anti-patterns:
    1. Covering your assets:
      • Avoid or delay making a decision out of fear of making the wrong one.
      • Overcome by:
        1. Waiting until the last responsible moment.
        2. Continually collaborate with dev teams to avoid blind spots and ensure feasibility of implementation.
    2. Groundhog day:
      • Decision is discussed over and over because people do not know why of the decision.
      • Both technical and business justification is required.
    3. Email-Driven architecture:
      • People lose, forget, or don’t even know an architecture decision due to poor communication.
      • Improve effectiveness of comms:
        1. Email should not contain any details of decision, only a link to the system of record.
        2. Only email people that care about the decision.
  • Architecture Decision Records (ADRs):
    • Allows to place more emphasis on the why rather than the how.
    • Consequences section: add trade-off analysis.
    • Authors suggest two more sections:
      1. Compliance:
        • How the decision will be checked.
      2. Notes:
        • Metadata: author, approval date, …

Chapter 20 - Analyzing Architecture Risk

  • Risk = impact (1 to 3) * likelihood (1 to 3):
    • High risk >= 6, medium >= 3.
  • Asses risk per architecture characteristic per quanta.
  • Risk storming:
    • Architects + some devs.
    • Ideally one storming session per architecture characteristic.
    1. Identification:
      • Individual activity.
    2. Consensus.
    3. Mitigation.
  • Unknown or unproven technologies are always high risk.

Chapter 21 - Diagramming and Presenting Architecture

  • Representational consistency: always show relationship between parts of an architecture before changing views/drilling down.
  • Solid lines indicate synchronous communication, dotted lines async.
  • Insert blank slide to focus attention on speaker.

Chapter 22 - Making Teams Effective

  • It is really easy to fake it as an architect.
  • Architect personalities:
    1. Control freak:
      • Tight boundaries that causes frustration in the dev teams.
    2. Armchair architect:
      • Loose boundaries that cause confusion in the dev team.
    3. Effective architect: not too hot, not too cold, but just right.
  • Elastic leadership.
  • How much control depends on:
    • How long/well the team members know each other.
    • Team size.
    • Overall experience.
    • Project complexity.
    • Project duration.
  • Signs dev team is too big:
    • High process loss:
      • Potential productivity - process loss == actual productivity.
      • Example: merge conflicts.
    • Pluralistic ignorance:
      • When everybody agrees to a norm, but privately rejects it because they think they are missing something obvious.
      • Fear to speak up.
    • Diffusion of responsibility:
      • As team increases, communication gets harder.
      • Example:
        • Confusion about responsibilities.
        • Things getting dropped.
  • Leverage on checklists:
    • The Checklist Manifesto.
    • Don’t worry about stating the obvious in a checklist. It is the obvious stuff that is usually skipped or missed.
    • 3 typical checklists:
      1. Developer code completion list:
        • “Definition of done”.
      2. Unit and functional testing checklist:
        • More unusual and edge cases.
        • Not automated stuff.
      3. SW release checklist.
    • To make devs use checklists:
      1. Explain importance, show effectiveness, ask devs to read The Checklist Manifesto.
      2. Hawthorne effect:
        • If people believe they are observed or monitored, they will change their behaviour.
        • Tell devs that checklist compliance will be monitored.

Chapter 23 - Negotiation and Leadership Skills

  • Negotiation with business stakeholders:
    • When all else fails, state things in terms of cost and time.
    • Leverage the “divide and conquer” rule to qualify demands or requirements.
  • Negotiation with other architects:
    • Demonstration defeats discussion.
    • Avoid being too argumentative.
    • Calm leadership.
  • Negotiating with developers:
    • Always provide a justification, state it first.
    • Once a person hears something they disagree with, they stop listening.
    • If a dev disagrees with a decision, have them arrive at the solution on their own.

Chapter 24 - Developing a Career Path

  • Spend 20 mins first things in the morning (before reading work email) on learning.
  • Personal Technology radar.
Did you enjoy it? or share!

Tagged in : Architecture book notes