Architecture Fundamentals

 A list of tips and practices that are fundamental to good software architecture:

• Start with the customer and work towards implementation, not the other way around.
• The best software architects need experience working as engineers building software.

Architecture Approaches

Waterfall Approach to Architecture

Traditional architecture operated in a waterfall approach that was top down with all decisions being up front by a high level architect that then hands down the requirements to low level programmers.  This approach is bad for several reasons:

• the design gets outdated
• a centralized architect slows down the development process as a bottleneck
• increases the risk of building the wrong thing

Agile Approach to Architecture

The system is built incrementally, delivering a solution little by little, receiving feedback frequently that's integrated into the next iteration.

• changes are delivered frequently
• architecture is everyone's responsibility
• an Architect is a servant leader that helps to support others who are also able to make architectural decisions
• Architect don't give solutions but provide options to help inform the decisions of the engineers

Daily Tasks

Some tools and techniques that help to facilitate team decisions

• facilitate working sessions
• dot voting on options
• event storming

Mentoring

• helping engineers to bring ideas to the group
• guild meetings to facilitate consensus and learning amongst a variety of members

Artifacts

• System architecture

Conway's Law

Mel Conway: "Any organization that designs a system...will inevitably produce a design whose structure is a copy of the organization's communication structure."

If teams are silo'd then the systems will also be silo'd.  The result is an N-tiered system where the tiers reflect the communication patterns of the teams that built them.  Collaboration is tedious and software development is slow.

An alternative is to approach work as thin slices.  Each slice includes parts of each layer.  Because the layers are all tackled together delivery is much faster.   This type of development is implemented using cross-functional teams.

Agile-friendly architectures include architectures like microservices.

Agile Architectural Approach

• Systems are architected incrementally.
• Utilizes Domain Driven Design (DDD) developed by Eric Evans
• the structure of the code matches the structure of the domain
• differs from traditional architecture that's oriented around the technology
• a bounded context separates different contexts from each other
• bounded contexts map directly on to modules of systems/components
• communication between contexts is much more restricted than communication within a context
• Often a single team/group is responsible for a particular domain.

Process

The process involves several steps that can be performed linearly or in parallel.

1. Write a Problem Statement
1. several sentences that define the problem
2. Write a User Story
1. should be short
2. can fit on a single sticky note
3. does NOT say how
3. Refine the user story into narrow "slices" that can be delivered in quick increments, each adding value.
1. This can be accomplished by "narrowing" stories by finding the most direct paths through the activity path.

Event Storming

A great process for figuring out agents in a system, which might be entities or services.

Steps

1. Sticky out the events (one color sticky)
1. map them out in time sequence from left to right
2. Sticky out the actions/work (different color)
1. what happens when the events happen
3. Now map the agents
1. agents do the actual work
2. every agent operates within a bounded context 

Keys Concepts

• Business people must drive
• The domain gives a context to the architecture
• As a result, there's an implementable system
• Definitions
• Events
• Actions
• Agents/Entities

System Architecture Versus Enterprise Architecture

Enterprise Architecture

Enterprise Architecture: "The organizing logic for business processes and IT infrastructure reflecting the integration and standardization requirements of the company's operating model." -- MIT

What it is:

• describes the structure of the business
• describes how things get done (processes)

Where it goes wrong:

• sometimes creates single monolithic company systems that represent particular domains
• often requires standardization across the entire enterprise
• results in complexity and slowness

Broad Architectural Patterns

• Monoliths
• Homogenous structure
• Downsides
• Long to test and deploy
• Notoriously hard to deal with
• Dependencies are everywhere
• small changes are avoided b/c implications aren't known
• BBM - big ball of mud
• Monoliths are generally costly and should be replaced
• MicroKernel
• also known as a plug-in architecture
• the kernel handles the core capabilities like memory and files
• other components plug into the kernel
• older kinds of MicroKernal are operating systems
• newer examples are Azure Service Fabric or AWS
• Pros
• plug-ins are independent and can be update without impacting other plug-ins
• Downsides
• changes to the kernel APIs can potentially impact or break many plug-ins
• Message-based
• can link independent systems that aren't naturally linked
• systems can be fitted with adapters that link to the messaging system
• types
• pub-sub architecture
• strengths
• systems can be decoupled
• weaknesses
• slower
• can grow very complex
• Microservices
• a larger system is broken into smaller microservices 
• each microservice
• is small
• independently deployable
• is fully autonomous
• hides its implementation details
• generally supports an unreliable network so must address failures
• highly observable
• is built around a business context
• upsides
• changes can be quick
• downsides
• common HTTP approach is real-time
• design and runtime complexity
• slower compared to other architectures
• 
  
• Reactive & choreographed
• upstream processor doesn't have any idea about downstream processors
• the upstream processor publishes an event that downstream processes respond to
• strengths
• decoupled
• easier to maintain
• downstream processors can operate in parallel

Design Patterns

Provide standard solutions to common problems.  Provide a common vocabulary.

Examples

• Singleton
•