Overview

This is a Korean translation of Oliver Goldman’s book on effective software architecture. The translation presents practical guidance for designing, evolving and governing software systems, covering context, change, process, design, decision-making, practices, communication, architecture teams, and product development organizations.

Table of Contents

1. Software Architecture
   • 1.1 Fundamental structure
   • 1.2 Systems
   • 1.3 Components
   • 1.4 Relationships between components
   • 1.5 Relationship with the environment
   • 1.6 Principles that govern design
   • 1.7 System evolution
   • 1.8 Summary
2. Context
   • 2.1 Concepts
   • 2.2 Reliability
   • 2.3 Architecturally significant requirements
   • 2.4 Product lines
   • 2.4.1 Single product, multiple platforms
   • 2.4.2 Product line
   • 2.4.3 Product family
   • 2.4.4 Cross-platform - 2.5 Building a platform - 2.6 Standards - 2.7 Summary
3. Change
   • 3.1 Stages of change
   • 3.2 Types of change
   • 3.3 Product-driven change
   • 3.4 Technology-driven change
   • 3.5 Simplification
   • 3.6 Investment mindset
   • 3.7 Incremental deployment
   • 3.8 Architectural evolution
   • 3.9 Summary
4. Process
   • 4.1 System documentation
   • 4.2 Working toward a vision
   • 4.3 Writing change proposals
   • 4.4 Backlog management
   • 4.5 Considering alternatives
   • 4.6 Doing nothing
   • 4.7 Urgency and importance
   • 4.8 Re-documenting the system
   • 4.9 Summary
5. Design
   • 5.1 How architecture improves design efficiency
   • 5.2 Design impact on architectural change
   • 5.3 Decomposition
   • 5.4 Composition
   • 5.5 Composition and platforms
   • 5.6 Incremental approaches
   • 5.7 Parallelism
   • 5.8 Organizational structure
   • 5.9 Open work
   • 5.10 Abandoning
   • 5.11 Finishing
   • 5.12 Summary
6. Decision Making
   • 6.1 Is more information helpful?
   • 6.2 What has happened so far?
   • 6.3 How many decisions are we making?
   • 6.4 What is the cost of doing nothing?
   • 6.5 Can we absorb the change?
   • 6.6 What is the cost of a wrong decision?
   • 6.7 How much more certain can we be?
   • 6.8 Is this decision my responsibility?
   • 6.9 Is it consistent?
   • 6.10 Can it be documented?
   • 6.11 Summary
7. Practices
   • 7.1 Backlog
   • 7.2 Catalog
   • 7.3 Templates
   • 7.4 Reviews
   • 7.5 Progress status
   • 7.6 Velocity
   • 7.7 Focus time
   • 7.8 Summary
8. Communication
   • 8.1 Mental models
   • 8.2 Documentation
   • 8.3 Conversation
   • 8.4 Information architecture
   • 8.5 Naming
   • 8.6 Glossary
   • 8.7 Listening
   • 8.8 Summary
9. Architecture Team
   • 9.1 Specialization
   • 9.2 Team structure
   • 9.3 Leadership
   • 9.4 Responsibility
   • 9.5 People
   • 9.6 Diversity
   • 9.7 Organizational culture
   • 9.8 Meetings
   • 9.9 Seminars and summits
   • 9.10 Summary
10. Product Development Organization
    • 10.1 Work by development methodology
    • 10.2 Collaboration with product management
    • 10.2.1 Helping
    • 10.2.2 Multiple outcomes
    • 10.2.3 Boundaries of scope - 10.3 Collaboration with UX teams - 10.4 Collaboration with program management - 10.5 Collaboration with engineering teams
    • 10.5.1 Engaging to the end - 10.6 Collaboration with testing teams - 10.7 Collaboration with operations teams - 10.8 Summary

Appendix — Conclusion

• A.1 Vision
• A.2 Architectural recovery
• A.3 Organizational change
• A.4 Change process
• A.5 Closing remarks