What is *97 Things Every Software Architect Should Know* about?

*97 Things Every Software Architect Should Know* is a curated collection of actionable insights from over 40 leading software architects. Focused on non-technical challenges, it covers communication, stakeholder management, complexity reduction, and balancing business needs with technical decisions. Key themes include prioritizing simplicity, quantifying requirements, and fostering collaboration between developers and stakeholders.

Who should read *97 Things Every Software Architect Should Know*?

Aspiring and experienced software architects, senior developers transitioning to architectural roles, and technical leads will benefit most. The book is ideal for professionals seeking practical advice on managing cross-functional teams, aligning technical decisions with business goals, and avoiding common pitfalls in large-scale system design.

Is *97 Things Every Software Architect Should Know* worth reading?

Yes—it distills decades of real-world experience into concise, actionable essays. Unlike technical manuals, it emphasizes soft skills like leadership and communication, making it a unique resource for architects navigating organizational dynamics. Critics praise its focus on practical over theoretical solutions.

What are the key concepts in *97 Things Every Software Architect Should Know*?

- **Essential vs. Accidental Complexity**: Simplify core challenges while minimizing unnecessary technical debt. - **Quantify Requirements**: Replace vague terms like “scalable” with measurable criteria (e.g., “handle 10K users by Q3”). - **Communication as Leadership**: Clear, stakeholder-focused dialogue prevents misalignment. - **Failure Preparedness**: Design systems assuming components will fail.

How does *97 Things Every Software Architect Should Know* address performance optimization?

The book advocates embedding performance considerations early—e.g., defining response-time thresholds (like “≤1500ms under normal load”) during requirements gathering. It stresses iterative testing and aligning metrics with business outcomes rather than technical vanity.

What frameworks does *97 Things Every Software Architect Should Know* recommend?

- **Simplicity Before Generality**: Solve immediate needs before over-engineering for hypothetical futures. - **Interface-Centric Design**: Prioritize user experience, as “the interface *is* the system” for end-users. - **Technical Debt Management**: Regularly refactor to avoid compounding hidden costs.

How does *97 Things Every Software Architect Should Know* compare to *Clean Architecture*?

While *Clean Architecture* focuses on technical patterns, *97 Things* emphasizes human-centric challenges: stakeholder negotiation, team empowerment, and business alignment. Both stress modularity, but *97 Things* offers broader organizational strategies.

What criticism does *97 Things Every Software Architect Should Know* receive?

Some note its fragmented structure due to multiple contributors, which may lack depth on specific topics. However, this format provides diverse perspectives, making it a practical reference over a linear guide.

소프트웨어 아키텍트가 알아야 할 97가지

리처드 몬슨 헤이플

3.62(779 Reviews)

소프트웨어 아키텍트가 알아야 할 97가지 개요

최고의 아키텍트 플레이북 - Neal Ford와 Michael Nygard와 같은 업계 전설들이 전하는 97가지 핵심 지혜를 담았습니다. 기술은 진화하지만, 이러한 원칙들은 애자일(Agile)부터 도메인 주도 설계(Domain-Driven Design)에 이르기까지 현대 개발 관행을 형성하며 변함없이 유지됩니다. 지금 이 순간, 당신의 팀이 놓치고 있는 아키텍처적 맹점은 무엇인가요?

전달 방식을 선택하세요

한 권의 책, 다양한 듣기 방식.

소프트웨어 아키텍트가 알아야 할 97가지의 같은 아이디어를 담았습니다. 나에게 맞는 목소리, 깊이, 속도를 고르고 언제든 바꿔 보세요.

1장

The Architect's Blueprint: Wisdom for Building Lasting Software

Software architects occupy a unique position in the IT world, straddling the realms of business and technology with one foot firmly planted in each. They are expected to master both domains - no small challenge. This collection of wisdom from software architects worldwide offers invaluable guidance on everything from avoiding common pitfalls to building talented teams. Originally created as an open-source project with contributions from dozens of authors, this book has gained remarkable popularity among tech leaders and aspiring architects alike. In fact, it's become something of a rite of passage in many tech organizations, with senior developers often receiving copies upon promotion to architectural roles. The book's modular approach - with each contribution standing independently while working within the larger collection - has enabled it to succeed where other open-source book attempts have failed, making it a staple on the virtual bookshelves of architects across industries.

2장

The Fundamental Paradox: Balancing Complexity and Simplicity

Essential complexity represents the inherent difficulty in any problem - like coordinating nationwide air traffic in real-time. Accidental complexity, on the other hand, grows from the solutions we build to address essential complexity. Today's outdated air traffic control systems exemplify this problem: they've become too complex to update, victims of their own accidental complexity disease. Many frameworks and vendor solutions suffer from this same affliction. While specific problem-solving frameworks can be useful, over-engineered ones often add more complexity than they solve. As developers, we naturally gravitate toward complexity - it's intellectually stimulating and showcases our technical prowess. But in large-scale software, our primary challenge is removing accidental complexity while effectively solving essential complexity. Consider a simple example: a customer needs a way to track inventory. The essential complexity involves knowing what items are in stock and where they're located. But we might introduce accidental complexity by implementing a sophisticated event-sourcing system with complex state machines when a straightforward database solution would suffice. As architects, we should prefer frameworks derived from working code rather than theoretical ones. We should examine how much code directly addresses business problems versus servicing technical boundaries. And we should be wary of vendor-driven solutions that promise to solve all our problems but introduce their own complexities. Remember that simplicity before generality is a virtue. When choosing between design alternatives, favor simplicity based on concrete needs over intricate solutions that boast generality. Often, the simpler solution proves more general in practice and easier to modify if needed. Speculative generality frequently leads to solutions not anchored in reality, with wrong assumptions and unnecessary options that become permanent baggage. Our duty as architects is to solve essential complexity without introducing accidental complexity - a delicate balance that requires both technical skill and restraint.

들리는 모든 단어를 눈으로 확인하세요

소프트웨어 아키텍트가 알아야 할 97가지의 각 단어가 오디오에 맞춰 실시간으로 강조되어 편하게 따라 읽을 수 있습니다.

3장

People Over Technology: The Human Element in Architecture

Most project failures aren't due to technology choices like Java versus Ruby or Postgres versus Oracle. The real foundation for success or failure is people. When someone seems to be "not doing it right," the technology you need isn't new - it's conversation. Treating people with respect and giving them the benefit of the doubt transforms a smart architect into an effective one. Software architects who dictate specifications from ivory towers often face developer revolts and failed projects. Effective communication through clarity and leadership is essential. Keep things simple at project start, using tools like visual diagrams rather than lengthy documents. Whiteboard meetings effectively convey ideas; always have a digital camera ready to capture and share these sessions via wiki. As a leader, you must gain respect by keeping developers informed about the big picture and the reasoning behind decisions. Creating a collaborative environment where architects validate decisions with developers generates buy-in. Work with developers, not against them, and remember that all team members - QA, business analysts, project managers - require clear communication and leadership. Many architects evolve from technical roles where success came from talking to machines, but as architects, our effectiveness depends on communicating with humans. Even if developers ignore our guidance and management rejects our recommendations, we must "sell" our ideas through effective communication. One simple yet powerful tip: whenever talking to more than one person about your architectural guidance, stand up - especially if everyone else is sitting. Standing automatically communicates authority and self-confidence, commanding the room and reducing interruptions. You'll naturally use more hand gestures and body language, make better eye contact with larger groups, and project your voice with improved tone, volume, and pacing. To increase conversational effectiveness: approach situations as conversations rather than confrontations, manage your own emotions before engaging, and set mutually agreed-upon goals. For example, instead of criticizing someone for dominating meetings, ask them to help increase others' participation by waiting five seconds before speaking. Starting with shared purpose and treating people problems as learning opportunities makes you more effective and ensures you learn something every time.

4장

The Architecture of Failure: Designing for Inevitable Breakdowns

Hardware fails, so we add redundancy, but that increases the likelihood of having at least one failure present at any time. Software fails too, and our monitoring software is just as fallible. Human errors lead us to automate, but automation can only respond to anticipated scenarios, so we add more monitoring - more software that can fail. Networks are inherently fallible and unpredictable, with an essentially infinite state space. Every safety mechanism we add to mitigate one failure introduces new failure modes, like clustering software that can cause "split-brain syndrome" when networks act up. Consider Netflix's Chaos Monkey, which randomly terminates instances in production to ensure their systems can withstand unexpected failures. This approach acknowledges the inevitability of failure and designs for resilience rather than trying to prevent failures entirely. Accept that failures will happen and design your system's reaction to specific failures. Create safe failure modes that contain damage and protect the rest of the system. If you don't design your failure modes, you'll get unpredictable - and usually dangerous - ones that emerge on their own. When faced with "budgetecture" - where sound technology choices are sacrificed for cost-cutting - engineers often make a critical mistake. The project sponsor asks "Do we really need X?" in a paternalistic tone, and instead of firmly answering "Yes. We do," we start explaining trade-offs like engineers. The problem is that while we see this as a collaborative solution-finding exercise, the sponsor sees it as a negotiation. By offering concessions immediately, we lose. The correct response is to counter-negotiate by upping the ante: "Without a second server, the system will crash three times daily, especially during Board demonstrations. We actually need four servers to maintain capacity during maintenance." This shows you're already at the bare minimum configuration and changes the conversation. And if you do get those extra servers, you can use them to improve your QA environment or build process.

소프트웨어 아키텍트가 알아야 할 97가지에서 더 많은 것을 얻으세요

매일 새로운 인사이트를 10만 개 이상의 레슨에서 만나보세요
단어가 강조되어 오디오와 실시간으로 동기화됩니다
내 라이브러리를 저장하고 모든 기기에서 이용하세요

5장

Quantifying the Unquantifiable: Making Architecture Measurable

"Fast" is not a requirement. Neither is "responsive" or "extensible." These vague adjectives provide no objective way to measure success, leaving architects at the mercy of capricious users and obsessive programmers. Every quality attribute can be quantified with simple questions: How many? In what period? How often? How soon? Increasing or decreasing? At what rate? Uncertain criteria must be given as ranges: the least, nominal, and most acceptable values. If these ranges cannot be provided, the requirement isn't understood. As architecture unfolds, it can be checked against these criteria. If no one cares enough about "performance" to pay for performance trials, then performance likely doesn't matter. Focus architectural efforts on aspects worth paying for. A proper requirement looks like: "Must respond to user input in no more than 1,500 milliseconds. Under normal load, average response time must be between 750-1,250 milliseconds. Response times below 500 milliseconds aren't distinguishable by users, so we won't pay to go below that." While business users primarily specify functional requirements, architects must address non-functional aspects like performance and resiliency. Yet performance testing is often delayed until late in development cycles - a critical mistake. Performance testing should begin as early as the third iteration. This approach provides crucial benefits: you can identify exactly when performance degraded, focus troubleshooting on recent changes rather than the entire architecture, establish baseline metrics, validate architectural choices against requirements early, and incrementally build your testing environment. Early performance testing prevents the expensive scramble that occurs when issues are discovered late. By tracking performance trends from the beginning, you gain vital diagnostic information and can validate that your architectural decisions will meet requirements before it's too late to change course.

6장

Context is Everything: There Are No Universal Solutions

Architects must continuously develop and exercise "contextual sense" - the knowledge of what is reasonable within a given context. As Eberhardt Rechtin described, skilled architects accumulate this sense through education, experience, and examples, typically requiring about 10 years before they're entrusted with system-level problems. A major problem in our young software industry is that people are often responsible for solving problems requiring more contextual sense than they've accumulated. Common examples include failing to apply domain-driven design when appropriate, over-designing solutions beyond essential needs, and making irrelevant suggestions during performance crises. The most important knowledge about software patterns is knowing when to apply them and when not to. There is no one-size-fits-all solution; architects must develop and exercise contextual sense in both formulating and troubleshooting their architectures. Despite what many believe, switching infrastructure products rarely solves performance problems. When vendors trumpet 25% performance improvements, the real-world impact is minimal if the underlying architecture is inefficient - a one-millisecond advantage matters little in a fundamentally flawed design. Similarly, merely "tuning" software infrastructure by adjusting memory allocations, connection pools, or thread pools won't fix an application insufficiently architected for its expected load. All vendor products and architectures face the same constraints of distributed computing and physics: applications run on computers with limited capacity, communicating via protocols with nonzero latency. Application architecture, not infrastructure brand or tuning, primarily determines performance and scalability. Meaningful improvements require the hard work of careful (re-)architecting, not silver-bullet solutions. Software architecting extends beyond technical activities like modularization and interface definition to include balancing stakeholder interests with technical requirements. While architects must address security, usability, and performance, they must equally consider organizational priorities.

들리는 모든 단어를 눈으로 확인하세요

소프트웨어 아키텍트가 알아야 할 97가지의 각 단어가 오디오에 맞춰 실시간으로 강조되어 편하게 따라 읽을 수 있습니다.

7장

The Balancing Act: Navigating Competing Priorities

For a software-as-a-service business, priorities might include meeting contractual obligations, generating revenue, ensuring customer satisfaction, containing costs, and creating valuable technology assets. These translate to departmental priorities like functionality, quality attributes, team productivity, and product longevity. The architect's job is to balance user needs with business interests, operational concerns, and maintainability. This balance may temporarily tilt toward specific priorities, but must maintain proper equilibrium over time, considering factors like software lifespan, business criticality, and organizational culture. Effective architecting means finding the appropriate balance for each unique context. When developers check in code without running automated tests and immediately leave - the "commit-and-run" crime - they break the build and halt team flow. This disrespectful practice wastes others' time as no integration can proceed until someone reverts the broken changes. This common problem typically stems from slow build times or lengthy test cycles. As an architect, you must create an architecture that supports fast automated testing. When tests run quickly, developers run them more frequently and avoid leaving colleagues with broken code. Re-engineer tests to use mocks, stubs, or in-memory databases rather than external systems. Invest in making the system fast to work with by creating simulators, reducing dependencies, or modularizing the system. This increases flow, discourages siloed work, and ultimately enables faster development by removing any excuse for commit-and-run behavior. System builders are often surprised that one data model, message format, or architectural component won't serve all business needs equally well. While technical domains allow forced uniqueness, business domains reflect the messy, inconsistent real world. One response is to impose a single solution by fiat, spawning enterprise data teams that spend expensive time attempting to create unified representations. But reality always reasserts itself as the business evolves. A better approach is accepting multiple, inconsistent, overlapping representations. The key insight comes from data warehousing, where denormalized data marts present different views than underlying databases without causing problems. This works because sufficiently different non-functional properties create natural boundaries across which managing inconsistent representations becomes tractable.

8장

The Business Drives the Architecture, Not Vice Versa

In enterprise application development, architects must bridge business and technology communities, representing each party's interests to the other while allowing business objectives to drive technology decisions. The architect must understand the desired ROI to avoid outspending the opportunity's value. They must create transparency through feedback loops like big visible charts and frequent software releases. When business fails to provide direction, developers end up making business decisions by default. The architect must provide context for developers' decisions by communicating business objectives. Ultimately, the long-term interests of the development team are best served when business drives the technology decisions. A good architect should lead by example, capable of fulfilling any position within their team - from network configuration to writing unit tests. Without deep technical understanding, an architect becomes merely a project manager. Team members should have confidence that their architect comprehends the technology. Like an airline pilot, the architect constantly monitors the situation using years of experience, while the project manager handles day-to-day management. Architects should demonstrate solutions hands-on, work directly with the team from the earliest project stages, and be experts in at least one tool of their trade. Without demonstrating hands-on ability, architects struggle to gain team respect, limit team learning, and impede delivery. The "big bang" build event in project development is obsolete. Architects should promote continuous integration (CI) methods and tools for every project. CI combines automated builds with testing at frequent intervals on dedicated integration servers. This practice targets the critical integration point between source code and running application, replacing the old "build early and often" risk-reduction technique with a more comprehensive approach. A CI implementation includes automated builds triggered by schedules or code changes, pulling the latest source code, building, testing, and sending notifications about results. This provides a more stable development effort that makes teams more effective and efficient. Projects often fail when schedules are altered mid-stream without proper planning. While adjusting timelines or increasing resources isn't typically problematic, attempting to do more work in the same timeframe or shortening schedules without reducing workload creates serious issues. The misconception that shortened schedules reduce costs or speed delivery leads to dangerous practices like mandatory overtime or sacrificing "less important" tasks like testing. Architects must remind stakeholders that rushed design leads to poor documentation and acceptance problems, rushed coding increases bugs, and rushed testing leads to production issues - all ultimately increasing costs rather than reducing them. When facing schedule pressure, architects should speak up early to maintain the original timeline or negotiate moving non-critical functionality to future releases.

소프트웨어 아키텍트가 알아야 할 97가지에서 더 많은 것을 얻으세요

매일 새로운 인사이트를 10만 개 이상의 레슨에서 만나보세요
단어가 강조되어 오디오와 실시간으로 동기화됩니다
내 라이브러리를 저장하고 모든 기기에서 이용하세요

9장

The Data Foundation: Building on Solid Ground

Your database is the permanent home of your most valuable asset - your data. While user interfaces and business logic evolve rapidly, data structures and relationships tend to remain stable. Therefore, establishing a solid data model from the beginning is critical. The agile movement has led many to believe that designing applications on the fly is preferable, but this approach is dangerous for your data layer. Migrating schemas in place is difficult, time-consuming, and error-prone. Database bugs can corrupt your data permanently. A fortress-like data model guarantees security through referential integrity, domain constraints, and appropriate keys. It acts as the final gatekeeper against application-layer bugs. The database should reject invalid data and prevent nonsensical relationships. Well-designed schemas are self-documenting and persistent, surviving application logic changes. Trust your database to trap bugs from other application layers, and it will never disappoint. When faced with two design options, the most important thing isn't choosing between them - it's recognizing the uncertainty itself as a design driver. Use uncertainty to determine where you can defer commitment and where you can partition and abstract to reduce the significance of design decisions. Following Grady Booch's definition that "architecture represents significant design decisions that shape a system, where significant is measured by cost of change," an effective architecture reduces the significance of design decisions rather than amplifying them. Instead of debating options A and B, ask: "How do I design so the choice between A and B becomes less significant?" Respond to uncertainty by creating separation or encapsulation that isolates decisions from dependent code. Avoid the pressure to make premature decisions - sometimes the best decision is not to decide yet. Architecture and process are intertwined, which is why architects should favor empirical development lifecycles that elicit feedback and use uncertainty constructively to divide both the system and schedule. Every software project has issues that cause more problems than expected. Often, a small part of the team identifies these issues early, but the majority dismisses them until it's too late. Several forces contribute to this pattern: issues that seem trivial early become critical later; individuals face resistance when others don't share their knowledge; most developers are optimists who underestimate problems; team members have different priorities; and everyone has blind spots. To counteract these forces, establish an organized approach to managing risks - track them like bugs, with anyone able to identify risks that are then prioritized and reviewed regularly. When going against the majority, find ways to help others understand your concerns. Recognize "bad smells" and look for simple tests to provide supporting facts. Constantly test your understanding against the team and customer. And find trusted people who will tell you hard truths about your blind spots.

10장

Reuse is a People Problem, Not Just a Technical One

Even the most beautiful, elegant, and reusable architecture or framework will only be reused by people who know it's there, know how to use it, and are convinced it's better than doing it themselves. Without proper communication and education, developers will default to building things themselves. You need to actively "push" information about reusable components through documentation, training, or direct communication. Your team needs to understand how to use these elements through proper documentation or training. And finally, you need to convince developers - especially younger ones who may prefer to write their own solutions - that using existing components is more efficient than rebuilding. Developers need to know that reusable elements exist and where to find critical information about them. People won't look for things they don't believe exist. Success with reusable elements requires "pushing" information through methods ranging from wiki pages with RSS feeds to email announcements or even shouting across the office in small teams. Whatever your process for communicating about reusable elements, ensure you have one - don't leave it to chance. Understanding how to reuse elements depends on skills and training. While some "resonate" with coding and design naturally, most team members need to be taught. Developers might not know particular design patterns or inheritance models used in frameworks. Provide easy access to up-to-date documentation or, better yet, training to ensure everyone understands how to properly reuse components. Developers typically prefer solving problems themselves rather than asking for help. "Better than doing it themselves" means different things to different people - young developers often want to write things themselves to appease their egos, while experienced team members are more likely to accept others' solutions. If your team doesn't know where to find reusable artifacts or how to reuse them, they'll naturally build everything themselves - and you'll pay for it. While there technically is an "i" in architecture, it's lowercase and fits neatly within the word - just as architects should work within their teams. Ego can be an architect's worst enemy, leading to thinking they understand requirements better than customers, viewing developers as mere resources, or getting defensive when ideas are challenged. This happens because of past success building confidence, respect from others silencing critical questions, and our human nature to take criticism personally. To avoid these traps: let requirements drive architecture, focus on the team as collaborators rather than resources, check your work through testing, and constantly watch yourself for defensive behaviors or dismissal of others' ideas.

들리는 모든 단어를 눈으로 확인하세요

소프트웨어 아키텍트가 알아야 할 97가지의 각 단어가 오디오에 맞춰 실시간으로 강조되어 편하게 따라 읽을 수 있습니다.

11장

The Evolving Architecture: Embracing Change Over Time

Over time, many passionately argued patterns, frameworks, and paradigms end up being irrelevant. What can history teach us about creating lasting architectural solutions? As architects, we often believe we can't influence what we're asked to do, but usually we can. The danger lies in solving the wrong problem - no matter how diligently we work, our efforts are wasted if we don't address what's truly needed. A good solution to the right challenge will outlast all others. We say "keep it simple" but rarely follow through, justifying complexity with claims of agility, elegance, or future-proofing. When you revisit your work after time away, you'll wonder why you made those choices. Time makes us look silly - learn what simplicity truly means through the lens that only time can provide. Architects constantly search for the "one true way" - methodologies or frameworks that provide predictability and clear answers. But your guiding principles will change over time, leaving you looking at designs that don't match your current expectations. Learn to embrace your old work rather than feeling compelled to "fix" it. Judge solutions by whether they appropriately solved the problem at hand, not by today's standards. A disappointing trend has emerged in software development: attempting to professionalize software architecture to match classical Architecture. Despite software development being a relatively nascent field, some architects seem eager for legitimization beyond peer recognition. Software architecture is a craft requiring practice and discipline, but we don't know enough about it yet to adequately professionalize it. Practitioners already enjoy considerable compensation for highly creative work with lower barriers to entry than fully professionalized fields like law or medicine. The title of software architect has only lowercase a's - and we should be content with that. Scope defines a project's size, functionality, difficulty, and constraints. While architects love big, complicated projects, expanding scope dramatically increases failure probability - doubling a project's scope can increase failure risk by an order of magnitude. Communication overhead grows non-linearly with team size, and estimation is notoriously imprecise. To manage scope effectively: understand real customer needs based on measurable value, divide work into smaller independent chunks, prioritize requirements to deliver the most important ones first, and deliver results quickly to get valuable feedback. Building "the simplest thing that could possibly work" often results in simpler architecture and improved odds of success. When architects join projects, they naturally want to prove their worth, but some mistakenly pursue showmanship - dazzling teams with technical brilliance. This is counterproductive. True architectural leadership comes through stewardship - taking responsible care of another's property. Architects must act in the customer's best interests rather than pandering to their own egos. Software development requires compromise, balancing implementation complexity against available resources. Like investment brokers, architects play with their clients' money and must yield acceptable returns. Complex systems sporting the latest frameworks or buzzwords often come at the company's expense. Never forget you're playing with other people's money.

12장

The Ethical Dimension: Architecture Has Consequences

Software architecture has ethical dimensions beyond obvious cases like civil rights or malicious software. Successful programs affect thousands or millions of users, either positively or negatively. Every architectural decision determines what users can and cannot do, in ways more inflexible than law. Consider the multiplier effect: a simple decision like making fields required might save development time but forces countless users to gather more information before starting their tasks, resulting in lost data and frustration. It's unethical to worsen others' lives, even slightly, just for your convenience. As an architect, you should be willing to bear large burdens to ease those of your users. While software engineering is often compared to civil engineering, there's an important lesson in how buildings are constructed. The hardest part isn't designing a structure that will stand when finished, but planning the construction process where the unfinished structure must remain stable throughout. Traditional "big bang" software deployments are like throwing beams in the air expecting them to form a building. Instead, we should deploy one component at a time, which spreads technical risk over a longer period and allows hardening each component independently. This approach forces well-defined interfaces between components. The natural evolution of computer technology has enabled polyglot programming - using multiple languages in a single software system. While not new, text-based protocols have made heterogeneous development far more viable than ever before. XML/SOAP, RESTful architectures, and other text-based formats have eliminated the need for arcane binary protocols, allowing architects to combine tools across different programming paradigms. This creates a combinatorial increase in architectural possibilities, letting us select the right paradigm for each problem domain. As technology silos crumble and we face serious challenges like the multicore era, embracing this diversity becomes essential. Your job as architect is to think outside the stack and leverage this new heterogeneity. Performance is as critical as any other system criterion, yet many designers place it last. A system must consider multiple performance aspects: productivity of the implementation team, performance of human interactions, and performance of non-interactive components. Productivity directly affects cost and schedule. Human interaction performance includes not just response time but interface intuitiveness and gesture efficiency - measuring task completion time rather than just system response. Non-interactive performance matters too - a "nightly" batch run that takes more than 24 hours is useless, and disaster recovery speed is critical. When designing systems, architects must always prioritize performance across all these dimensions. System diagrams often represent programs as simple rectangles connected by arrows, but those arrows hide tremendous complexity. That single line labeled "XML over HTTP" or "SKU Lookup" actually represents a substrate filled with network cards, switches, firewalls, message queues, and more. A critical "Fulfillment" arrow might actually involve twenty different steps across multiple systems. As an architect, you must understand both the static and dynamic loads these connections must carry - not just the protocol, but request frequency, response time requirements, error handling, version compatibility, and recovery procedures. Engineering these "white spaces" between components is essential to creating robust systems.

★★★★★

소프트웨어 아키텍트가 알아야 할 97가지 완독을 축하합니다

100만 명 이상의 학습자가 사랑합니다

“23일째 매일 사용하고 있어요. 이제 제 일상의 한 부분이 되었습니다.”

jayallen

소프트웨어 아키텍트가 알아야 할 97가지의 핵심 주제

accidental complexity
technical leadership
stakeholder communication
architectural trade-offs
human-centric design

소프트웨어 아키텍트가 알아야 할 97가지의 명언

Simplicity before generality is a virtue.
The real foundation for success or failure is people.
When someone seems to be 'not doing it right,' it's conversation.
Accept that failures will happen and design your system's reaction.
Our duty as architects is to solve essential complexity.

소프트웨어 아키텍트가 알아야 할 97가지의 등장인물

Richard Monson-HaefelAuthor and compiler of the architectural wisdom

저자 소개

97 Things Every Software Architect Should Know의 저자인 리처드 몬슨-헤이플(Richard Monson-Haefel)은 저명한 소프트웨어 아키텍트이자 엔터프라이즈 Java 개발 분야의 베스트셀러 권위자입니다. 26년 이상의 경력을 보유한 그는 Apache Geronimo와 OpenEJB의 공동 창립자로서 업계 표준을 정립해 왔으며, Java Community Process(JCP) 전문가 그룹의 일원으로 활동했습니다.

그의 저서는 소프트웨어 아키텍트를 위한 실무적인 통찰력을 집약하고 있으며, 이는 Enterprise JavaBeans 및 Java Message Service(O’Reilly)를 포함한 그의 다섯 권의 기술 서적의 핵심 주제인 Java EE, JMS 및 웹 서비스에 대한 깊은 전문성을 반영합니다.

Burton Group(현 Gartner)의 전직 수석 분석가였던 몬슨-헤이플은 실무 개발 경험과 전략적 분석 능력을 겸비하고 있습니다. 그는 Jakarta EE 및 React Native에 관한 호평을 받은 Pluralsight 강의를 제작했으며, 수천 명의 학습자로부터 평균 4.4/5점의 평점을 받았습니다.

그의 업적은 Apache 및 Oracle과 같은 기관에서 권장되고 있으며, 그가 만든 프레임워크는 전 세계 엔터프라이즈 시스템의 근간을 이루고 있습니다. 97 Things Every Software Architect Should Know는 실행 가능한 조언으로 인정받아 여러 언어로 번역되었으며, 이 분야의 중대한 자산이 되었습니다.

이 책의 간결하고 원칙 중심적인 접근 방식은 복잡한 개념을 개발자가 쉽게 접근할 수 있는 도구로 변환하는 몬슨-헤이플의 명성을 잘 보여줍니다.

소프트웨어 아키텍트가 알아야 할 97가지 요약 다운로드

소프트웨어 아키텍트가 알아야 할 97가지 요약을 무료 PDF 또는 EPUB으로 받으세요. 인쇄하거나 오프라인에서 언제든 읽을 수 있습니다.

다른 사용자들도 좋아한 책

Software Architecture in Practice

Len Bass

Clean Architecture

Robert C. Martin

A Philosophy of Software Design, 2nd Edition

12 sources

Software Architecture Demystified

Soft Skills

John Z. Sonmez

Essential Skills That Make or Break Software Engineers 책 표지

The 5 Most Important Software Engineering Skills - HackerRank Blog

6 sources

Essential Skills That Make or Break Software Engineers

Software Engineering Deep Dive: Timeless Wisdom 책 표지

7 sources

Software Engineering Deep Dive: Timeless Wisdom

Effective Programming

Jeff Atwood

Master Communication as a Developer 책 표지

6 sources

Master Communication as a Developer

이 책에 대한 FAQ

더 알아보기

학습 계획

Architecting for Scale: The Interview Playbook

This playbook is essential for software engineers aiming for senior or staff-level roles at top-tier tech companies. It provides a structured methodology to tackle the high-pressure system design interview by focusing on data scalability and the art of the trade-off.

1 h 30 m•3 섹션

학습 계획

The Architecture of Choice

In an era of information overload, understanding the hidden forces behind our decisions is a critical superpower. This plan is ideal for professionals, investors, and students looking to bridge the gap between abstract logic and the messy reality of human behavior.

2 h•4 섹션

학습 계획

Architecting Features for Scale

This plan is essential for developers moving beyond basic coding into high-level system design. It bridges the gap between feature ideation and scalable execution, making it ideal for engineers preparing for senior roles or high-traffic environments.

2 h•4 섹션

학습 계획

The Diagnostic for Tool Enshittification

As software platforms increasingly prioritize monetization over utility, developers must learn to identify predatory technical patterns. This guide is essential for software architects and engineers who want to build resilient stacks and avoid becoming locked into decaying ecosystems.

1 h 30 m•3 섹션

학습 계획

Designing and Programming Software

This comprehensive path is designed for developers looking to transition from writing scripts to engineering robust, production-ready systems. It provides the essential bridge between basic syntax and complex architectural decision-making required in modern tech roles.

5 h 53 m•4 섹션

학습 계획

How to build habits.

In an era of constant distraction, mastering behavior architecture is the ultimate competitive advantage. This plan is designed for professionals and individuals seeking to replace friction with flow by leveraging neuroscience and systematic design.

4 h 57 m•4 섹션

학습 계획

Master Conceptual Tech for Expert Vibecoding

This plan is designed for developers who want to move beyond syntax and master the underlying philosophy of software creation. It is ideal for engineers seeking to bridge the gap between technical execution and high-level architectural intuition.

5 h 59 m•4 섹션

학습 계획

Programming

This comprehensive path bridges the gap between basic syntax and professional system architecture. It is ideal for aspiring developers who want to master both the practical skills of coding and the high-level design patterns used in top-tier tech companies.

5 h 1 m•4 섹션

샌프란시스코에서 컬럼비아 대학교 동문들이 만들었습니다

LOVED BY

1,000,000+ curious minds.

4.7

avg rating

1M+ learners

"Instead of endless scrolling, I just hit play on BeFreed. It saves me so much time."

@Moemenn

"I never knew where to start with nonfiction—BeFreed’s book lists turned into podcasts gave me a clear path."

@Chloe, Solo founder, LA

117

"Perfect balance between learning and entertainment. Finished ‘Thinking, Fast and Slow’ on my commute this week."

@Raaaaaachelw

"Crazy how much I learned while walking the dog. BeFreed = small habits → big gains."

@Matt, YC alum

108

"Reading used to feel like a chore. Now it’s just part of my lifestyle."

@Erin, Investment Banking Associate , NYC

254

"Feels effortless compared to reading. I’ve finished 6 books this month already."

@djmikemoore

"BeFreed turned my guilty doomscrolling into something that feels productive and inspiring."

@Pitiful

4.5K

"BeFreed turned my commute into learning time. 20-min podcasts are perfect for finishing books I never had time for."

@SofiaP

"BeFreed replaced my podcast queue. Imagine Spotify for books — that’s it. 🙌"

@Jaded_Falcon

201

"It is great for me to learn something from the book without reading it."

@OojasSalunke

"The themed book list podcasts help me connect ideas across authors—like a guided audio journey."

@Leo, Law Student, UPenn

483

"Makes me feel smarter every time before going to work"

@Cashflowbubu

웹에서 BeFreed가 어떻게 논의되고 있는지 더 보기

샌프란시스코에서 컬럼비아 대학교 동문들이 만들었습니다

LOVED BY

1,000,000+ curious minds.

4.7

avg rating

1M+ learners

"Instead of endless scrolling, I just hit play on BeFreed. It saves me so much time."

@Moemenn

"I never knew where to start with nonfiction—BeFreed’s book lists turned into podcasts gave me a clear path."

@Chloe, Solo founder, LA

117

"Perfect balance between learning and entertainment. Finished ‘Thinking, Fast and Slow’ on my commute this week."

@Raaaaaachelw

"Crazy how much I learned while walking the dog. BeFreed = small habits → big gains."

@Matt, YC alum

108

"Reading used to feel like a chore. Now it’s just part of my lifestyle."

@Erin, Investment Banking Associate , NYC

254

"Feels effortless compared to reading. I’ve finished 6 books this month already."

@djmikemoore

"BeFreed turned my guilty doomscrolling into something that feels productive and inspiring."

@Pitiful

4.5K

"BeFreed turned my commute into learning time. 20-min podcasts are perfect for finishing books I never had time for."

@SofiaP

"BeFreed replaced my podcast queue. Imagine Spotify for books — that’s it. 🙌"

@Jaded_Falcon

201

"It is great for me to learn something from the book without reading it."

@OojasSalunke

"The themed book list podcasts help me connect ideas across authors—like a guided audio journey."

@Leo, Law Student, UPenn

483

"Makes me feel smarter every time before going to work"

@Cashflowbubu

"Instead of endless scrolling, I just hit play on BeFreed. It saves me so much time."

@Moemenn

"I never knew where to start with nonfiction—BeFreed’s book lists turned into podcasts gave me a clear path."

@Chloe, Solo founder, LA

117

"Perfect balance between learning and entertainment. Finished ‘Thinking, Fast and Slow’ on my commute this week."

@Raaaaaachelw

"Crazy how much I learned while walking the dog. BeFreed = small habits → big gains."

@Matt, YC alum

108

"Reading used to feel like a chore. Now it’s just part of my lifestyle."

@Erin, Investment Banking Associate , NYC

254

"Feels effortless compared to reading. I’ve finished 6 books this month already."

@djmikemoore

"BeFreed turned my guilty doomscrolling into something that feels productive and inspiring."

@Pitiful

4.5K

"BeFreed turned my commute into learning time. 20-min podcasts are perfect for finishing books I never had time for."

@SofiaP

"BeFreed replaced my podcast queue. Imagine Spotify for books — that’s it. 🙌"

@Jaded_Falcon

201

"It is great for me to learn something from the book without reading it."

@OojasSalunke

"The themed book list podcasts help me connect ideas across authors—like a guided audio journey."

@Leo, Law Student, UPenn

483

"Makes me feel smarter every time before going to work"

@Cashflowbubu

"Instead of endless scrolling, I just hit play on BeFreed. It saves me so much time."

@Moemenn

"I never knew where to start with nonfiction—BeFreed’s book lists turned into podcasts gave me a clear path."

@Chloe, Solo founder, LA

117

"Perfect balance between learning and entertainment. Finished ‘Thinking, Fast and Slow’ on my commute this week."

@Raaaaaachelw

"Crazy how much I learned while walking the dog. BeFreed = small habits → big gains."

@Matt, YC alum

108

"Reading used to feel like a chore. Now it’s just part of my lifestyle."

@Erin, Investment Banking Associate , NYC

254

"Feels effortless compared to reading. I’ve finished 6 books this month already."

@djmikemoore

"BeFreed turned my guilty doomscrolling into something that feels productive and inspiring."

@Pitiful

4.5K

"BeFreed turned my commute into learning time. 20-min podcasts are perfect for finishing books I never had time for."

@SofiaP

"BeFreed replaced my podcast queue. Imagine Spotify for books — that’s it. 🙌"

@Jaded_Falcon

201

"It is great for me to learn something from the book without reading it."

@OojasSalunke

"The themed book list podcasts help me connect ideas across authors—like a guided audio journey."

@Leo, Law Student, UPenn

483

"Makes me feel smarter every time before going to work"

@Cashflowbubu

웹에서 BeFreed가 어떻게 논의되고 있는지 더 보기

지금 바로 학습 여정을 시작하세요

12장

소프트웨어 아키텍트가 알아야 할 97가지

개요소프트웨어 아키텍트가 알아야 할 97가지 개요

한 권의 책, 다양한 듣기 방식.

The Architect's Blueprint: Wisdom for Building Lasting Software

The Fundamental Paradox: Balancing Complexity and Simplicity

들리는 모든 단어를 눈으로 확인하세요

People Over Technology: The Human Element in Architecture

The Architecture of Failure: Designing for Inevitable Breakdowns

소프트웨어 아키텍트가 알아야 할 97가지에서 더 많은 것을 얻으세요

Quantifying the Unquantifiable: Making Architecture Measurable

Context is Everything: There Are No Universal Solutions

들리는 모든 단어를 눈으로 확인하세요

The Balancing Act: Navigating Competing Priorities

The Business Drives the Architecture, Not Vice Versa

소프트웨어 아키텍트가 알아야 할 97가지에서 더 많은 것을 얻으세요

The Data Foundation: Building on Solid Ground

Reuse is a People Problem, Not Just a Technical One

들리는 모든 단어를 눈으로 확인하세요

The Evolving Architecture: Embracing Change Over Time

The Ethical Dimension: Architecture Has Consequences

소프트웨어 아키텍트가 알아야 할 97가지 완독을 축하합니다

소프트웨어 아키텍트가 알아야 할 97가지의 핵심 주제

소프트웨어 아키텍트가 알아야 할 97가지의 명언

소프트웨어 아키텍트가 알아야 할 97가지의 등장인물

저자 소개

소프트웨어 아키텍트가 알아야 할 97가지 요약 다운로드

다른 사용자들도 좋아한 책

이 책에 대한 FAQ

What is 97 Things Every Software Architect Should Know about?

Who should read 97 Things Every Software Architect Should Know?

Is 97 Things Every Software Architect Should Know worth reading?

What are the key concepts in 97 Things Every Software Architect Should Know?

더 알아보기

1,000,000+ curious minds.

1,000,000+ curious minds.

한 권의 책, 다양한 듣기 방식.

The Architect's Blueprint: Wisdom for Building Lasting Software

The Fundamental Paradox: Balancing Complexity and Simplicity

들리는 모든 단어를 눈으로 확인하세요

People Over Technology: The Human Element in Architecture

The Architecture of Failure: Designing for Inevitable Breakdowns

소프트웨어 아키텍트가 알아야 할 97가지에서 더 많은 것을 얻으세요

Quantifying the Unquantifiable: Making Architecture Measurable

Context is Everything: There Are No Universal Solutions

들리는 모든 단어를 눈으로 확인하세요

The Balancing Act: Navigating Competing Priorities

The Business Drives the Architecture, Not Vice Versa

소프트웨어 아키텍트가 알아야 할 97가지에서 더 많은 것을 얻으세요

The Data Foundation: Building on Solid Ground

Reuse is a People Problem, Not Just a Technical One

들리는 모든 단어를 눈으로 확인하세요

The Evolving Architecture: Embracing Change Over Time

The Ethical Dimension: Architecture Has Consequences

소프트웨어 아키텍트가 알아야 할 97가지 완독을 축하합니다

다른 사용자들도 좋아한 책

더 알아보기

소프트웨어 아키텍트가 알아야 할 97가지 개요