Software Development Teams and Architecture: A Complete Guide

Table of Contents

1. Software Team Roles

   • 1.1 Core Team Structure
   • 1.2 Required Skills for All Roles
   • 1.3 The Functional Analyst
   • 1.4 The Lead Developer
   • 1.5 The Solution Architect

2. Architect Personality Traits and Pitfalls

   • 2.1 Essential Personality Traits
   • 2.2 Three Types of Power
   • 2.3 Common Pitfalls for New Architects

3. Software Architecture Fundamentals

   • 3.1 What Is Software Architecture?
   • 3.2 Architecture Requirements Sources
   • 3.3 What Composes Architecture?
   • 3.4 Architecture Goals
   • 3.5 Design Tips

4. Key Architecture Principles

   • 4.1 Primary Goal
   • 4.2 Five Key Principles
   • 4.3 General Guidelines
   • 4.4 Layer Guidelines
   • 4.5 Component Guidelines

5. UML (Unified Modeling Language)

   • 5.1 UML Attributes
   • 5.2 UML Structure
   • 5.3 Seven Popular UML Diagrams
   • 5.4 UML in Architecture Design
   • 5.5 UML Design Strategies

6. Architecture Design Process

   • 6.1 Five-Step Iterative Process
   • 6.2 Iteration Guidelines

7. Architecture Patterns

   • 7.1 Layered Architecture Patterns
   • 7.2 Structural Architecture Patterns
   • 7.3 Presentation Architecture Patterns
   • 7.4 Service Architecture Patterns
   • 7.5 Hybrid Architecture Patterns

8. Choosing the Right Patterns

   • 8.1 The Layered Pattern (Starting Point)
   • 8.2 Pattern Selection Guidelines

9. Designing Layered Architectures

   • 9.1 Layering Strategy Decisions

10. Designing Component Architectures

    • 10.1 General Guidelines
    • 10.2 Layer-Specific Components
    • 10.3 Modular Architectures

11. Designing Service-Oriented Architectures

    • 11.1 REST vs SOAP Services
    • 11.2 Service Design Process

12. Design Quality Attributes

    • 12.1 Conceptual Integrity
    • 12.2 Maintainability
    • 12.3 Reusability
    • 12.4 Testability
    • 12.5 Usability

13. Runtime Quality Attributes

    • 13.1 Availability
    • 13.2 Interoperability
    • 13.3 Manageability
    • 13.4 Performance
    • 13.5 Reliability
    • 13.6 Scalability
    • 13.7 Security

14. Planning for Caching

    • 14.1 What to Cache?
    • 14.2 Where to Cache?
    • 14.3 How to Manage Cache?
    • 14.4 How to Fill Cache?

15. Planning for Exceptions

    • 15.1 Exception Strategies
    • 15.2 Layer-Specific Exception Handling

16. Planning for Deployment

    • 16.1 Deployment Models
    • 16.2 Distributed Deployment Guidelines
    • 16.3 Deployment Strategies

---

1. Software Team Roles

Building great software isn't just about writing code. It requires well-organized teams, clear roles, and smart architectural decisions. Let's explore the key concepts that make software projects successful.

1.1 Core Team Structure

Every software project needs these key roles working together:

• Project Manager - Manages timeline, resources, and coordination
• Solution Architect - Designs technical architecture
• Functional Analyst - Captures and documents requirements
• User Representatives - Represent end-user needs
• Lead Developer - Leads the development team
• Developers - Write the actual code
• QA - Tests the software
• Deployment Manager - Handles software releases
• Trainer - Educates users on the system

1.2 Required Skills for All Roles

• Understanding the Business
• Cross-Domain Understanding
• Multiple Perspectives
• People Skills
• Lifelong Learning

1.3 The Functional Analyst

The Functional Analyst is like a translator between business people and developers.

Responsibilities:

• Responsible for system functionality
• Captures, consolidates, and communicates information
• Constantly asks clarifying questions
• Identifies and resolves conflicts
• Produces Requirements Specification

Key Skills:

• Communication skills
• Attention to detail
• Conflict management
• Precise documentation
• Great listening skills
• Office tools proficiency

Pros: Key role with lots of interactions
Cons: Must work with difficult users, expect conflicts, receives blame when functionality is missing

1.4 The Lead Developer

The Lead Developer is like a team captain for programmers.

Responsibilities:

• Leads and mentors developers
• Assigns tasks to developers
• Details and partitions work
• Ensures all developers succeed

Key Skills:

• Programming skills
• Mentoring skills
• Values-driven approach (Precision, Elegance, Reusability, Efficiency)
• Build & configuration management
• Debugging and troubleshooting

Pros: Path to Solution Architect, involves coding, can choose interesting tasks
Cons: Squeezed between architect and developers, requires lifelong learning, vulnerable to offshoring

1.5 The Solution Architect

The Solution Architect is the master planner.

Responsibilities:

• Responsible for technology decisions
• Converts functional requirements to technical architecture
• Balances patterns, requirements, elegance, and concepts
• Researches key technologies
• Deep understanding of design patterns
• Motivates development team
• Ensures Lead Developer succeeds

Key Skills:

• Functional understanding
• Leadership skills
• Technical knowledge
• UML and design tools
• Experience with code generators

Pros: High-value position, great salary, visible role, safe from outsourcing
Cons: Difficult to stay current, can receive bad requirements, first to receive blame

2. Architect Personality Traits and Pitfalls

2.1 Essential Personality Traits

• Steadfast: Patient and resilient to adapt to change
• Trustworthy: Conveys credibility through experience and results
• Confident: Believes in ability to perform with passion for success
• Persuasive: Skilled diplomatic negotiator who can balance "better, faster, cheaper"

2.2 Three Types of Power

• Implicit Power: Organizational recognition of the role
• Personal Power: Individual credibility and relationships
• Granted Power: Formal authority given by management

2.3 Common Pitfalls for New Architects

2.3.1 Lead Developer Loses Trust

Problem: Endless discussions, implementation deviates from architecture
Solutions: Empower LD, present united front, be open to feedback, change architecture if needed

2.3.2 Functional Requirements Are Invalid

Problem: FA has no engagement with User Representatives
Solutions: Find the reason, restore FA's personal power, escalate if needed

2.3.3 Planning Is Too Optimistic

Problem: PM operates in isolation, pressures LD and QA
Solutions: Bring PM closer to dev team, identify root cause, coach or restructure as needed

2.3.4 Architect Role Holds No Power

Problem: Organization doesn't understand architect role
Solutions: Educate executives, team up with other roles, become process owner, leave if necessary

3. Software Architecture Fundamentals

3.1 What Is Software Architecture?

A structured solution that meets all requirements while optimizing quality attributes like performance, security, and manageability.

3.2 Architecture Requirements Sources

• User Requirements: What users need
• Business Requirements: What business needs
• IT System Requirements: What technology needs

3.3 What Composes Architecture?

• Structural elements and interfaces
• How elements behave in collaboration
• Composition into larger subsystems
• Architectural style guiding composition
• Covers functionality, usability, resilience, performance, reuse, comprehensibility, economic constraints, and tradeoffs

3.4 Architecture Goals

• Document high-level structure
• Avoid implementation details
• Minimize complexity
• Address all requirements
• Be compatible with all use cases

3.5 Design Tips

• Build to change, not to last
• Use models only to analyze and reduce risk
• Use visualizations for communication
• Identify and research critical failure points

4. Key Architecture Principles

4.1 Primary Goal

Minimize complexity by separating design into different areas of concern

4.2 Five Key Principles

1. Separation of Concerns
2. Single Responsibility Principle
3. Principle of Least Knowledge
4. Don't Repeat Yourself
5. Minimize Upfront Design

4.3 General Guidelines

• Use consistent patterns in each layer
• Don't duplicate functionality
• Prefer composition over inheritance
• Establish code conventions

4.4 Layer Guidelines

• Separate areas of concern
• Define communication between layers
• Use abstraction for loose coupling
• Don't mix component types in a layer
• Use consistent data formats within layers

4.5 Component Guidelines

• No component should rely on internals of another
• Don't mix roles in single components
• Define clear contracts
• Abstract system-wide components

5. UML (Unified Modeling Language)

5.1 UML Attributes

• Visual, Abstract, Descriptive, Standard
• Supports code generation and reverse engineering

5.2 UML Structure

• Models: Business System Model, IT System Model
• Views: External/Internal (Business), Static/Dynamic (IT)
• Diagrams: Various diagram types

5.3 Seven Popular UML Diagrams

5.3.1 The Component Diagram

• Shows components and interfaces
• Shows implemented and required interfaces
• Components can be nested

5.3.2 The Class Diagram

• Shows classes, methods, and fields
• Shows associations, generalizations, cardinality

5.3.3 The Sequence Diagram

• Shows call sequences
• Shows calling class, method, return types
• Can depict loops

5.3.4 The State Diagram

• Shows states or activities
• Shows allowed transitions
• Can be nested with internal activities

5.3.5 The Activity Diagram

• Shows processes or workflows
• Can be nested and show concurrent actions
• Can have swim lanes

5.3.6 The Layer Diagram

• Non-standard, invented by Microsoft
• Shows areas of concern and references
• Can be validated

5.3.7 The Use Case Diagram

• Shows actors and use cases
• Binds actors to use cases
• Can show generalizations

5.4 UML in Architecture Design

Architecture Element	UML Diagram
Functional Requirements	Use Case Diagram
Structural Elements, Composition	Class Diagram, Component Diagram
Structural Elements, Collaboration	Sequence Diagram, Activity Diagram, State Diagram
Areas of Concern	Layer Diagram

5.5 UML Design Strategies

• UML as Sketch: Quick conceptual drawings
• UML as Blueprint: Forward/reverse engineering with code generation
• UML as Validation: Validate implementation against diagrams

6. Architecture Design Process

6.1 Five-Step Iterative Process

6.1.1 Create/Adjust Objectives

• Identify architecture scope
• Estimate time investment
• Identify audience
• Identify constraints (technical, usage, deployment)

6.1.2 Identify Key Scenarios

Key scenarios have:

• Significant unknown/risk
• Significant use case (business-critical, high impact)
• Intersection of quality/function
• Tradeoffs between attributes

Create Use Case Diagrams

6.1.3 Create Application Overview

• Determine application type
• Identify deployment constraints
• Identify architecture patterns
• Determine technologies

Create Layer Diagram

6.1.4 Identify Key Issues

Quality Attributes: System/Runtime/Design/User
System-wide Concerns:

• Authentication & authorization
• Caching
• Communication
• Configuration management
• Logging & exception management
• Validation

6.1.5 Create Candidate Solution

• Create baseline architecture
• Create candidate architecture
• Develop architectural spikes

Create Activity, Sequence, State, Component Diagrams
Create Class Diagram if needed

6.2 Iteration Guidelines

• Don't introduce new risk
• Mitigate more risk than baseline
• Meet additional requirements
• Enable more key scenarios
• Address more key issues
• Start communicating when you exceed 50% coverage

7. Architecture Patterns

7.1 Layered Architecture Patterns

7.1.1 Client/Server Pattern

Structure: Distinct client and server separated by network
Pros: Very secure, simple communication, centralized control, easy to manage
Cons: Requires network, difficult to scale out, single point of failure, hard to debug

7.1.2 Layered Pattern

Structure: Strict areas of concern, layers communicate only with adjacent layers
Pros: High abstraction, high isolation, structured communication, easy to scale out
Cons: Deep call chains, can hide complexity, may harm performance, lowest layer must cover all use cases

7.1.3 N-Tier Pattern

Structure: Layers deployed to servers, usually 3 tiers, network communication
Pros: High abstraction, high isolation, structured communication, easy to scale out
Cons: Network point of failure, network may be slow, coarse interfaces, hard to debug

7.2 Structural Architecture Patterns

7.2.1 Component-Based Pattern

Structure: Modular building blocks grouped into areas of concern with clear interfaces
Pros: Easy deployment, allows 3rd parties, promotes modularity, few unanticipated interactions
Cons: Coarse building blocks, can be expensive, slow initialization, harder to develop & maintain

7.2.2 Object-Oriented Pattern

Structure: Uses classes grouped into areas of concern with inheritance and composition
Pros: Easy to understand, promotes reuse, easy to test & debug, highly cohesive
Cons: Inheritance hard to get right, many unanticipated communications, too detailed

7.3 Presentation Architecture Patterns

7.3.1 MVC Pattern

Structure: View (output), Model (data), Controller (interaction)
Pros: Strict separation of concerns, scales well
Cons: High overhead, scattered code, hard to data-bind

7.3.2 MVVM Pattern

Structure: View (output), Model (data), View Model (binding source)
Pros: Strict separation of concerns, scales well, easy to data-bind
Cons: High overhead, scattered code, controller not separated

7.4 Service Architecture Patterns

7.4.1 Service-Oriented Pattern

Structure: Discrete business services using network communication (HTTP, XML, SOAP)
Pros: Business domain alignment, high abstraction, discoverable/resilient, allows 3rd parties, cross-platform
Cons: Must handle slow/offline network, coarse interfaces, may harm performance, security issues

7.4.2 Microservice Pattern

Structure: Services calling services, can use fast private network, multiple server deployment
Pros: Modular, reduced abstraction, discoverable/resilient, can use fast network, less coarse interfaces
Cons: Must cope with slow/offline network, more unanticipated communications, hard transactions/testing/debugging/deployment

7.4.3 Message Bus Pattern

Structure: Services connected to shared data bus using messages for communication
Pros: Easy to extend, simple communication, very flexible, easy to scale, easy discovery/failover
Cons: Bus is single point of failure, coarse communications, can be slow, hard to test/debug

7.5 Hybrid Architecture Patterns

7.5.1 Components in Layers

Layers containing components - benefits of both plus structured communication, isolation, easy scaling & testing

7.5.2 MVC in Presentation Layer

Presentation layer with MVC - benefits of layers plus separation of concerns and presentation scalability

7.5.3 Objects in Components

Components containing objects - benefits of components plus cohesion & extensibility

8. Choosing the Right Patterns

8.1 The Layered Pattern (Starting Point)

Create 3 basic layers:

• Presentation Layer
• Business Layer
• Data Layer
• Service Layer (if exposing API)

8.2 Pattern Selection Guidelines

8.2.1 Presentation Layer

• Use Components for: containers, reuse, 3rd parties, declarative rendering
• Choose MVC for large UIs
• Choose MVVM if technology supports databinding

8.2.2 Business Layer

• Use Components for: modular functionality, plugin support, business entity abstraction, declarative configuration
• Use Object-Oriented if components aren't needed

8.2.3 Data Layer

• Use Components for: diverse data sources, increased abstraction, declarative configuration

8.2.4 Service Layer

• Use Components for: contract management, containers, declarative configuration
• Choose Microservices if system is mostly interlocking APIs
• Choose Message Bus if services alter state on common message

9. Designing Layered Architectures

9.1 Layering Strategy Decisions

9.1.1 Choose Separation Type

• Logical Separation: Same process/server
• Physical Separation: Different servers (tiers)

9.1.2 Remove & Merge Layers

• Applications without API can merge layers
• API applications might merge Business & Data layers

9.1.3 Determine Layer Interactions

• Loose Interactions: Layers can skip intermediate layers
• Strict Interactions: Layers only communicate with adjacent layers

9.1.4 Identify System-wide Concerns

Create system-wide layer for cross-cutting concerns like caching, logging, security

9.1.5 Define Layer Interfaces

• Public Interfaces: Direct access to components
• Façade Component: Single entry point per layer
• Alternatives: Singletons, Command Pattern, Dependency Injection, Message-based

10. Designing Component Architectures

10.1 General Guidelines

Components must be SOLID:

• Single Responsibility
• Open/Closed
• Liskov Substitution
• Interface Segregation
• Dependency Inversion

Plus: Highly cohesive, no knowledge of other component internals

10.2 Layer-Specific Components

10.2.1 Presentation Layer Components

• UI components, Presentation Logic, Views, Controllers, View Models
• Optional: Presentation Entities

10.2.2 Service Layer Components

• Services, Service Interfaces, Message Types
• Optional: Service Broker

10.2.3 Business Layer Components

• Business Façade, Business Logic Components, Workflows, Business Rules
• Business Entities (populated through ORM or Data Objects)
• Business Events

10.2.4 Data Layer Components

• Data Façade, Data Source Adapters, Service Adapters
• Optional: Data Objects, Command & Query objects

10.3 Modular Architectures

Support plugins with/without UI using Plugin Framework across all layers

11. Designing Service-Oriented Architectures

11.1 REST vs SOAP Services

11.1.1 REST Service

• Operations: CRUD operations on entities
• Formats: JSON/XML/HTML/Markdown
• Communication: Request/Response, low overhead
• Pros: Low overhead, simple
• Cons: No discovery & routing, incomplete standard

11.1.2 SOAP Service

• Operations: Any operations, not limited to entities
• Formats: XML
• Communication: Request/Response, Fire & Forget, Bi-Directional, high overhead
• Pros: Standard discovery & routing, world standard
• Cons: High overhead, complex

11.2 Service Design Process

11.2.1 Define Data & Messages

• Request/Response, Fire & Forget, or Bi-Directional
• Command, Query, Document, Entity, Event, Message types
• Avoid large messages
• Add expiration & diagnostic info
• Create Class Diagram

11.2.2 Define Service Contracts

• CRUD or RPC
• Stateful/Stateless
• Transaction Management
• Handle invalid calls: timeouts, duplicates, out-of-order calls
• Create Component Diagram

11.2.3 Plan Exception Handling

• Only catch what you can handle
• Use meaningful messages (business explanation, technical info, retry instructions)
• Return fault metadata
• Log everything
• Notify exception subscribers

11.2.4 Define Business Entity Transforms

Transform Methods:

• Reference Business layer directly
• Use Object Mapper
• Use Object-Relational Mapper
• Use Transform Language
• Custom-built

Considerations:

• Narrowing/Widening transforms
• Flattening/Elevating transforms
• Reversible transforms

11.2.5 Define Business Abstraction

Business Layer Abstractions:

• Call Façade directly
• Call Business Components
• (Re)Start Workflow
• Log Business Event

Considerations:

• Long-running workflows
• State management
• Transactions

12. Design Quality Attributes

12.1 Conceptual Integrity

• Isolated layers and components
• Application Lifecycle Management
• Healthy team collaboration
• Design and coding standards
• Break from legacy: Façade Pattern, wrap as service, rebuild from scratch

12.2 Maintainability

• Isolated layers and components
• Structured communication
• Consider plugin system
• Rely on platform features
• Use system-wide layer
• Add unit tests
• Documentation

12.3 Reusability

• Component-based architecture
• Adhere to standards
• General-purpose code
• Allow 3rd parties
• Use plugin system
• Use system-wide layer

12.4 Testability

Design for testing with:

• Unit tests
• Integration tests
• Functional tests
• Load tests
• Security tests
• Acceptance tests
• Allow mocking
• Cover all layers
• Automate case studies

12.5 Usability

• Elegant & simple UI
• Implements all case studies in minimal interactions
• Clear multi-step workflows
• Intuitive feedback
• Non-technical language

13. Runtime Quality Attributes

13.1 Availability

• Tier failover
• Use rate limiter
• Short-lived resource locks
• Recover from exceptions
• Update-friendly architecture
• Handle network faults: offline support, buffered proxy

13.2 Interoperability

• Data transformation
• Keep systems separate
• Adhere to standards: SOAP, REST, XML/JSON

13.3 Manageability

• Health monitoring, logging, diagnostic tracing
• Consider plugin system
• Declarative configuration
• Add diagnostic tools: live tracing, diagnostic notifications, runtime log inspection, in-situ debugging

13.4 Performance

• Buffered proxy
• Async responses
• Load-balanced tiers
• Caching
• Load tests
• Minimize throughput: rate limiting, coarse interfaces, minimize cache misses

13.5 Reliability

• Self-healing architecture
• Use store and forward
• Use alternative system if primary is offline/slow/invalid
• Replay messages when external resources return

13.6 Scalability

Tier Scaling:

• Scale up (more powerful hardware)
• Scale out (more servers)

Handle Load Spikes:

• Async responses
• Store and forward
• Allow stale data

13.7 Security

• Authenticate & authorize clients
• Validate input & output
• Encrypt sensitive data
• Protect against: spoofing, malicious input/output, malicious use, data theft, DDoS attacks

14. Planning for Caching

14.1 What to Cache?

By Layer:

• Presentation: UI pages & components
• Service: Service output
• Business: Business Entities & State
• Data: Data & Configuration

14.2 Where to Cache?

• Local memory
• State server
• File system
• Database
• Use standard solutions: .NET Cache, Redis, Memcached

14.3 How to Manage Cache?

Expiration Strategy:

• Time-based
• Event-based

Flush Strategy:

• Manual
• Automatic: Least Recently Used, Least Frequently Used, Priority

14.4 How to Fill Cache?

Proactive Loading:

• Static data
• Known update frequency
• Known size

Reactive Loading:

• Volatile data
• Unknown lifetime
• Large data volume
• Fast caching medium

15. Planning for Exceptions

15.1 Exception Strategies

• Allow to Propagate: Let it bubble up
• Catch and Re-throw: Log while retaining stack trace
• Catch, Wrap, and Throw: Add metadata, expose consistent types
• Catch and Discard: Handle completely

15.2 Layer-Specific Exception Handling

15.2.1 Presentation Layer

• Strategy: Display, Alert, Retry, Failover
• Catch, display, and discard
• Attempt retry
• Switch to secondary system
• Alert by Email, SMS, Slack
• Use meaningful messages

15.2.2 Service Layer

• Strategy: Log, Retry, Failover
• Catch and re-throw
• Attempt retry
• Switch to secondary system
• Log exception and input message

15.2.3 Business Layer

• Strategy: Log, Provide Context, Rollback, Broadcast
• Catch, wrap, and throw
• Use custom exception types
• Provide business context
• Rollback transactions
• Log exception and input args
• Broadcast to subscribers

15.2.4 Data Layer

• Strategy: Log
• Catch and re-throw
• Log exception and input query

16. Planning for Deployment

16.1 Deployment Models

• Monolithic: All layers on same server (simple, limited scaling)
• Distributed: Layers on different servers (complex, scalable)

16.2 Distributed Deployment Guidelines

• Minimize blocking calls: async calls, one-way calls, buffering
• Use distributed transactions
• Use coarse-grained interfaces
• Manage state: stateless (scalable) vs stateful (supports workflows)

16.3 Deployment Strategies

16.3.1 Deploy for Performance

• Business/Data layers scale out
• Can detect failed tiers
• Stateless design preferred
• Stateful requirements: Shared State Server, Session Affinity

16.3.2 Deploy for Reliability

• Secondary tier takes over when primary fails
• Requires 2x hardware
• Synchronization considerations: sync when secondary activates or allow stale data

16.3.3 Deploy for Scalability

• Data replicated on multiple tiers
• Replication breaks consistency and atomicity
• Consistency options: delayed sync, allow stale data, partition data

16.3.4 Scale Up vs Scale Out

• Scale Up: Easy with VMs, limited results
• Scale Out: Requires layered design, partitioned data, potentially unlimited

---

Key Takeaways

1. Team success depends on clear roles and good communication between team members
2. Great architects balance technical skills with leadership and communication abilities
3. Software architecture is about making smart tradeoffs between competing needs
4. UML diagrams help communicate complex ideas in simple visual ways
5. Choose architecture patterns based on your specific needs, not what's popular
6. Quality attributes like performance and security must be planned from the start
7. Real-world systems need careful planning for caching, errors, and deployment

Remember: the best architecture is not the most complex one, but the one that solves your specific problems simply and effectively. Focus on understanding your requirements first, then choose the simplest approach that meets your needs.