__1장. 들어가며<br/>____이해관계자, 시점, 관점<br/>____이 책의 구성<br/>____이 책의 대상 독자<br/>____편집 관례<br/><br/>1부. 아키텍처 기초<br/><br/>__2장. 소프트웨어 아키텍처 기본 개념<br/>____소프트웨어 아키텍처<br/>____아키텍처 요소<br/>____이해관계자<br/>____아키텍처 명세서<br/>____핵심 개념 사이의 관계<br/>____정리<br/>____더 읽을거리<br/><br/>__3장. 시점과 뷰<br/>____아키텍처 뷰<br/>____시점<br/>____핵심 개념 간의 관계<br/>____시점과 뷰를 사용하는 이점<br/>____시점의 함정<br/>____시점 목록<br/>____정리<br/>____더 읽을거리<br/><br/>__4장. 아키텍처 관점<br/>____품질 속성<br/>____아키텍처 관점<br/>____뷰에 관점 적용<br/>____관점 적용 결과<br/>____핵심 개념 사이의 관계<br/>____관점 활용에 따른 이점<br/>____관점의 함정<br/>____관점과 시점의 비교<br/>____관점 목록<br/>____정리<br/>____더 읽을거리<br/><br/>__5장. 소프트웨어 아키텍트의 역할<br/>____아키텍처 정의 프로세스<br/>____아키텍트의 역할<br/>____핵심 개념 사이의 상호관계<br/>____아키텍처 전문화<br/>____조직 맥락<br/>____아키텍트의 기량<br/>____아키텍트의 책임<br/>____정리<br/>____더 읽을거리<br/><br/>2부. 소프트웨어 아키텍처 프로세스<br/><br/>__6장. 소프트웨어 아키텍처 정의 프로세스 소개<br/>__7장. 아키텍처 정의 프로세스<br/>____핵심 원칙<br/>____프로세스 산출물<br/>____프로세스 맥락<br/>____보조 활동<br/>____아키텍처 정의 활동<br/>____프로세스 완료 조건<br/>____소프트웨어 개발 수명주기상의 아키텍처 정의<br/>____정리<br/>____더 읽을거리<br/><br/>__8장. 관심사항, 원칙, 결정<br/>____문제 중심 관심사항<br/>____해결책 중심 관심사항<br/>____기타 실무적인 제약사항<br/>____좋은 관심사항의 조건<br/>____아키텍처 원칙<br/>____아키텍처 결정사항<br/>____원칙을 활용한 관심사항과 결정사항 연결<br/>____점검 목록<br/>____정리<br/>____더 읽을거리<br/><br/>__9장. 이해관계자 파악과 유치<br/>____이해관계자 선정<br/>____이해관계자 유형<br/>____예제<br/>____대리 이해관계자<br/>____이해관계자 집단<br/>____이해관계자의 책임<br/>____점검 목록<br/>____정리<br/>____더 읽을거리<br/><br/>__10장. 시나리오 식별과 활용<br/>____시나리오의 종류<br/>____시나리오 활용<br/>____시나리오 식별 및 순위결정<br/>____시나리오 수집<br/>____좋은 시나리오의 조건<br/>____시나리오 적용<br/>____효과적인 시나리오 활용<br/>____점검 목록<br/>____정리<br/>____더 읽을거리<br/><br/>__11장. 스타일과 패턴 활용<br/>____설계 패턴<br/>____스타일, 패턴, 이디엄<br/>____패턴과 아키텍처 전술<br/>____아키텍처 스타일 예제<br/>____아키텍처 스타일 활용 시 이점<br/>____스타일과 아키텍처 설명<br/>____설계 패턴과 언어 이디엄 적용<br/>____점검 목록<br/>____정리<br/>____더 읽을거리<br/><br/>__12장. 아키텍처 모델 수립<br/>____모델의 중요성<br/>____모델의 유형<br/>____모델화 언어<br/>____효과적인 모델 도출 지침<br/>____애자일 팀에서의 모델화<br/>____점검 목록<br/>____정리<br/>____더 읽을거리<br/><br/>__13장. 아키텍처 명세서 작성<br/>____효과적인 아키텍처 명세서의 속성<br/>____용어집<br/>____ISO 표준<br/>____아키텍처 설명 내용<br/>____아키텍처 설명 제시<br/>____점검 목록<br/>____정리<br/>____더 읽을거리<br/><br/>__14장. 아키텍처 평가<br/>____아키텍처 평가 필요성<br/>____평가 기법<br/>____시나리오 기반 평가 기법<br/>____소프트웨어 수명주기 중의 평가<br/>____기존 시스템의 아키텍처 검증<br/>____평가 결과 기록<br/>____평가 접근법 선택<br/>____점검 목록<br/>____정리<br/>____더 읽을거리<br/><br/>3부. 시점 목록<br/><br/>__15장. 시점 목록 소개<br/>__16장. 맥락 시점<br/>____관심사항<br/>____모델<br/>____문제점 및 함정<br/>____점검 목록<br/>____더 읽을거리<br/><br/>__17장. 기능 시점<br/>____관심사항<br/>____모델<br/>____문제점 및 함정<br/>____점검 목록<br/>____더 읽을거리<br/><br/>__18장. 정보 시점<br/>____관심사항<br/>____모델<br/>____문제점 및 함정<br/>____점검 목록<br/>____더 읽을거리<br/><br/>__19장. 동시성 시점<br/>____관심사항<br/>____모델<br/>____문제점 및 함정<br/>____점검 목록<br/>____더 읽을거리<br/><br/>__20장. 개발 시점<br/>____관심사항<br/>____모델<br/>____문제점 및 함정<br/>____점검 목록<br/>____더 읽을거리<br/><br/>__21장. 배치 시점<br/>____관심사항<br/>____모델<br/>____문제점 및 함정<br/>____점검 목록<br/>____더 읽을거리<br/><br/>__22장. 운영 시점<br/>____관심사항<br/>____모델<br/>____문제점 및 함정<br/>____점검 목록<br/>____더 읽을거리<br/><br/>__23장. 여러 뷰 사이의 일관성 확보<br/>____뷰 사이의 관계성<br/>____맥락 뷰와 기능 뷰 일관성<br/>____맥락 뷰와 정보 뷰 일관성<br/>____맥락 뷰와 배치 뷰 일관성<br/>____기능 뷰와 정보 뷰 일관성<br/>____기능 뷰와 동시성 뷰 일관성<br/>____기능 뷰와 개발 뷰 일관성<br/>____기능 뷰와 배치 뷰 일관성<br/>____기능 뷰와 운영 뷰 일관성<br/>____정보 뷰와 동시성 뷰 일관성<br/>____정보 뷰와 개발 뷰 일관성<br/>____정보 뷰와 배치 뷰 일관성<br/>____정보 뷰와 운영 뷰 일관성<br/>____동시성 뷰와 개발 뷰 일관성<br/>____동시성 뷰와 개발 뷰 일관성<br/>____배치 뷰와 운영 뷰 일관성<br/><br/>4부. 관점 목록<br/><br/>__24장. 관점 목록 소개<br/>__25장. 보안성 관점<br/>____뷰 적용성<br/>____관심사항<br/>____활동: 보안성 관점 적용<br/>____아키텍처 전술<br/>____문제점 및 함정<br/>____점검 목록<br/>____더 읽을거리<br/><br/>__26장. 성능 및 확장용이성 관점<br/>____뷰 적용성<br/>____관심사항<br/>____활동: 성능 및 확장용이성 관점 작용<br/>____아키텍처 전술<br/>____문제점 및 함정<br/>____점검 목록<br/>____더 읽을거리<br/><br/>__27장. 가용성 및 복원성 관점<br/>____뷰 적용성<br/>____관심사항<br/>____활동: 가용성 및 복원성 관점 적용<br/>____아키텍처 전술<br/>____문제점 및 함정<br/>____점검 목록<br/>____더 읽을거리<br/><br/>__28장. 진화성 관점<br/>____뷰 적용성<br/>____관심사항<br/>____활동: 진화성 관점 적용<br/>____아키텍처 전술<br/>____문제점 및 함정<br/>____점검 목록<br/>____더 읽을거리<br/><br/>__29장. 그 밖의 관점<br/>____접근성 관점<br/>____활동: 접근성 관점 적용<br/>____개발 자원 관점<br/>____국제화 관점<br/>____위치 관점<br/>____규제 관점<br/>____사용편의성 관점<br/><br/>5부. 총정리<br/><br/>__30장. 소프트웨어 아키텍트로 일하기<br/>____과제 수명주기상에서의 아키텍처<br/>____다른 유형의 과제 지원<br/><br/>__A. 그 밖의 시점들<br/>____크루첸 ‘4+1’<br/>____RM-ODP<br/>____지멘스(호프마이스터, 노드, 소니)<br/>____SEI ‘뷰와 그 이상’ 뷰<br/>____갈런드와 앤서니<br/>____IAF<br/>____전사적 아키텍처 프레임워크<br/>____그 밖의 전사적 아키텍처 프레임워크

★ 저자 서문 ★

이 책의 초판을 집필하던 10년 전과 비교하면 IT 업계의 지형이 엄청나게 달라졌습니다. 세상은 한결 더 연결된 공간이 됐고, 컴퓨터와 인터넷이 집에서나 일터에서나 많은 이들의 일상적인 삶에서 큰 부분을 차지하게 됐습니다. 이로 인해 사용자들과 이해관계자들 사이에서 시스템 기능이 풍부하고 완결되며, 사용하기 편하고 탄탄하며 확장하고 쉽고 안전하기를 기대하는 정도가 훨씬 더 커졌습니다. 우리는 아키텍트가 이런 목표를 이루는 데 중요한 역할을 담당하고 있다고 느낄 뿐 아니라 이런 시각이 소프트웨어 개발 전문가들과 고위 사업 책임자 및 기술 책임자들 사이에서 상당히 널리 수용되고 있다는 사실에 힘이 났습니다.

1판에 보내준 실무자들과 아키텍트 지망생들과 학계의 긍정적인 반응에 많이 고무됐습니다. 이 책의 독자들이 유용하고 빈틈없으며 정보가 가득하다고 여긴다고 생각했습니다. 하지만 아키텍처는 끊임없이 변하는 분야인 터라, 2판에는 1판을 출간한 뒤에 우리가 실무에서 갈고 닦은 성과를 반영해 넣었습니다. 더불어 독자들이 보내준 매우 유용한 의견과 제안도 많이 넣었는데, 이 부분이 특히나 만족스럽습니다.

하지만 원래 전하고자 했던 근본적인 메시지는 변함이 없습니다. 가장 초점을 뒀던 부분은 이해관계자를 위한 서비스로서의 아키텍처와 정보 시스템이 이해관계자의 요구를 충족시켰는지 확인할 방법이었습니다. 이해관계자가 이해할 수 있는 방식으로 아키텍처의 복잡성을 나타내기 위한 방편으로서 뷰의 본원적 중요성을 강조하는 것 역시 변함이 없습니다. 또한 시스템이 정적인 구조와 동적인 구조를 정의하는 작업은 물론이고 확장용이성, 복원성, 보안성 같은 요구된 품질 속성을 어떤 식으로 제공할지 정의하는 작업을 아키텍처를 통해 해야 한다는 믿음과, 관점이 이런 작업을 하는 데 있어서 매우 효과적이라는 신념에도 전혀 변함이 없습니다.
이 책은 아키텍트 수련생이나 지망생을 주된 독자층으로 잡았지만, 그 밖에도 아키텍트와 함께 작업하는 다른 정보기술 전문가나 언젠가 아키텍트 자리에 있는 자신을 발견할지도 모를 학생들도 읽어보면 쓸모가 있으리라 봅니다.

개정2판에서 주로 바뀐 내용은 다음과 같습니다.

■ 맥락 시점이라는 새로운 시점을 추가했습니다. 맥락 시점에서는 시스템과 주변 환경(시스템이 상호작용하는 사람, 시스템, 외부 개체 등) 사이의 관계, 의존성, 상호작용을 설명합니다. 1판의 8장에서 비교적 짧게 설명했던 범위와 맥락에 관한 설명을 확장하고 정규화 및 표준화해놓았습니다.
■ 2부에서 아키텍처 역할의 다른 측면에 대한 논의를 확장해놓았습니다.
■ 기존의 시점 및 관점 정의를 거의 대부분 재검토했고, 특히 기능 및 동시성 뷰와 성능 및 확장용이성 관점을 다시 정리했습니다.
■ 대부분의 장에서 참고문헌과 ‘더 읽을거리’ 절을 재검토하고 확장했습니다.
■ (IEEE 1471 표준을 승계한) 새로운 국제 아키텍처 표준인 ISO 42010에 나오는 개념과 용어에 맞춰 내용을 갱신했습니다.
■ UML 2.0에 들어간 변경 내용을 반영해 UML 모델링 조언과 예제를 갱신했습니다.

이 개정판이 1판을 좀 더 쓸모 있게 개선하고 확장한 결과임을 알아주길 바라며, 소프트웨어 아키텍처 관련 추가 자료를 살펴보거나 이 책에 대한 의견을 개진하기 위해 연락하고 싶은 분들은 우리 웹사이트 www.viewpoints-and-perspectives.info를 찾아주기 바랍니다.

★ 역자 서문 ★

소프트웨어 아키텍처라는 것에 매력을 느끼는 개발자라면, 유능한 소프트웨어 아키텍트가 돼서 훌륭한 소프트웨어 아키텍처를 갖춘 위대한 시스템을 만들고 싶다는 포부를 한 번씩은 품어봤으리라 생각합니다. 저희들도 그렇습니다. 그래서 일에서는 물론이고 일상에서도 대상의 본질적 가치를 꿰뚫어보고, 한 가지 측면만 바라보기보다는 여러 측면에서 살피며, 무언가 얻는 것이 있다면 잃는 것도 반드시 생기게 마련이니 균형점을 찾아서 올바른 절충을 해내기 위해 노력하는 자세를 견지하게 됩니다.

정보기술 시스템을 중심으로 한 소프트웨어 아키텍처를 수립하는 방법을 다룬 이 책을 번역해서 세상에 내놓는 일도 마찬가지였습니다. 소프트웨어 시스템의 아키텍처 설계에 관심이 있는 독자들에게 이 책이 제공할 수 있는 본질적인 가치가 무엇인지 파악하고, 그들이 좀 더 쉽고 편하고 깊이 있게 그 본질적 가치를 향유할 수 있도록 번역하는 일 또한 어찌 보면 아키텍트의 자질을 발휘하고 능력을 쌓는 일과 근본적인 차이는 없어 보입니다.

하지만 이 책을 내는 작업에 있어서 아키텍팅architecting은 그다지 성공적이지 못했습니다. “아키텍처 명세서를 만드는 목적은 그 문서를 사용하는 이들의 요구를 충족하는 데 있지, 시스템 이해관계자에게 전혀 실질적 혜택을 주지 못하면서도 엄청나게 많은 자원을 쏟아야 완성할 수 있는 완벽한 문서를 만들고자 노력하는 데 있지 않다.” 이 책 7장, ‘아키텍처 정의 프로세스’ 부분에 나오는 이야기입니다. 아키텍처 명세서를 만드는 일을 이 책을 펴내는 일과 비유해본다면, 저희 역자들이 지난 ‘몇 년’간 다들 엄청나게 많은 시간과 노력을 쏟으며 번역 작업에 매달렸음에도, 그만큼 출간이 지연되면서 이 책에 관심 있는 이해관계자들에게는 실질적 혜택을 전혀 주지 못했으니 말입니다.

기왕 시작했으니, 비유를 좀 더 끌고가 보겠습니다. 이 책의 출간 작업과 관련한 이해관계자를 살펴보면, 최종 사용자인 잠재적인 독자들과, 이 책을 낼 수 있도록 후원해주는 출판사, 이 책의 원 저자들이 있습니다. 저마다 다른 관심사항을 가지고 저희 역자들에게 요구와 기대와 압박을 전합니다. 더불어, 저희 역자들 스스로가 (매우 비중 있는) 이해관계자들입니다. 그리고 마치 같은 시스템을 개발하는 개발자들이 저마다의 처지와 입장에 따라 관심사와 욕구가 다르듯, 당연히 저희 역자들 역시 저마다 다양한 입장과 의견을 지닙니다. 또한 해당 전문 분야의 실무자들이 투박한 번역 솜씨로 옮겨 펴내는 전문서적들에 대해 신랄하게 비판하는 서평자들도 비중 있는 (또는 치명적인) 이해관계자로 존재합니다. 그리고 이 책이 출간된 후에 나올 여타 소프트웨어 아키텍처 번역서의 역자들과 독자들 또한 무시할 수 없는 간접적인 이해관계자입니다.

이런 이해관계자들을 꼽아보고, 저마다 다른 관심사와 요구를 조율해 원래 목표했던 가치를 끌어내는 작업은, 그 자체로 아키텍팅이라 할 수 있습니다. 하지만 그 일은 녹록지 않았으며, 그중에서도 가장 큰 어려움은 저희 아키텍트들의(그리고 곧 개발자들의) 부족한 역량과 일천한 경험이었습니다. 문장을 하나씩 옮기면서 기능적인, 아니 내용적인 부분을 만족시키는 것은 기본적인 가치로서, 노력과 성실성이 주로 필요한 부분입니다. 하지만 총 30개 장에 걸쳐 무려 원서 700페이지에 육박하는 분량으로 서술된, 소프트웨어 아키텍처 기본 개념, 이해관계자 파악, 아키텍처 정의, 아키텍처 평가 등의 프로세스 전체와, 각각의 뷰, 시점, 관점들을 하나하나 상세히 소개하는 방대한 한 권의 책을 용어와 내용, 문장과 문체가 일관되고 잘 읽히게 만드는 일은 여간 어려운 작업이 아니었습니다. 더욱이 셋이 함께 작업하는 일이라, 버전 관리와 산출물 통합 또한 신경 써야 했습니다.

특히나, 역자들이 평소에 고민했던, 영어 음독 표기로 점철된 소프트웨어 아키텍처와 소프트웨어 공학 분야의 각종 개념어와 전문용어를 되도록 친근한 우리말로 바꿔서 쓰는, 국어 순화라는 까다로운 품질 속성도 일을 더 어렵게 만드는 요인이었습니다. 가령, 업계에서는 ‘트레이드오프tradeoff’라는 개념을 매우 즐겨 사용합니다. 이 개념은 한 가지 이득을 얻고자 무언가를 선택하면 다른 뭔가에서 손해를 보는 상황 또는 그 상황에서의 선택 행위를 말하는 것으로, 서로 상충하는 품질 속성들 중에서 더 어렵고 더 중요한 것을 얻기 위해 덜 어렵고 덜 중요한 것을 포기, 타협, 교환하는 행위를 가리킬 때 주로 쓰입니다. 예전에 『소프트웨어 아키텍처: 이론과 실제』(2판)을 번역해서 낼 때는 별다른 대안을 생각해내지 못해 그냥 음차를 해서 ‘트레이드오프’라고 옮겨 적으며 아쉬움이 컸습니다. 이 책도 소프트웨어 아키텍처를 전방위적으로, 그리고 동시에 매우 깊이 있게 다루기 때문에 ‘트레이드오프’에 대한 언급이 매우 많이 등장하는 터라, 지난 번의 아쉬움을 극복하기 위해 ‘교환’, ‘등가교환’, ‘타협’, ‘절충’ 등을 두고 매우 오래 고심하다가결국 ‘절충’이라는 용어를 선택했지만 그 이후에도 고민은 끊이지 않았습니다.

이렇게 부족한 능력과 경험에도 불구하고, 매우 다양한 이해관계자가 개입해 있는 데다가 방대한 분량의 시스템에 매우 까다로운 품질 요구와 목표까지 있으니, 이 책의 번역 작업은 예사롭지 않은 험난한 과정의 연속이었습니다. 이미 벌인 일인지라 오기도 생기고 포기할 수도 없으니, 결국 납기가 마구 ‘희생’되는 것으로(절충이 아니라) 귀결됩니다. 이는 소프트웨어 시스템도 마찬가지여서, 제대로 절충을 하지 않으면, 원치 않는 무언가가 희생되고 맙니다. 그나마 다행인 것은 이 책이 단기적인 유행을 타는, 그래서 한두 해 지나면 의미가 퇴색되는 그런 책이 아니라 (적어도 다음 판이 나오기 전까지는) 쭉 가치를 빛낼 내용을 담고 있다는 점입니다. 역자들로서는, ‘실질적 혜택을 주지 못하면서 끝없는 노력과 시간을 쏟아야 완성할 수 있는 완벽한 문서를 추구하는’ 우매함을 깨우쳐 이 책을 드디어 펴낼 수 있게 된 것만으로도, 긴 시간 한결같은 가치를 발휘할 이 책의 편린을 맛본 셈이라 하겠습니다. 독자 여러분도 이 책을 통해 큰 가치를 찾아내기를 기원합니다.

이처럼 긴 시간이 걸려 번역돼 나온 이 책의 특장점이라면, 역시나 균형과 절충의 미덕이 담겨 있다는 점입니다. 소프트웨어 아키텍처 이론 위주의 서적을 읽을 때면 구체적인 사례가 부족해 소프트웨어 개발과 유지 보수에 적용하기에는 왠지 어려울 것 같은 공허함을 느끼기 쉽습니다. 반면에 특정 도메인 아키텍처 위주의 서적을 읽을 때는 뭔가 지식 체계로 기억할 만한 중요한 이론적 체계의 부재로 인한 아쉬움을 느끼곤 합니다. 이 책은 지금까지 발표된 아키텍처 이론 중 자연스럽게 실무에 잘 활용할 수 있는 내용만 모아 실제 사례와 함께 소개하고 있어, 학계와 업계 관계자 모두에게 도움이 줄 수 있으리라 기대합니다. 소프트웨어의 상세한 세부사항보다는 ‘큰 그림’을 그리며 각 구성요소들의 전체적인 조화, 단순함, 자연스러움이 깃든 생명력이 긴 명품 소프트웨어를 만들고자 하는 분들께 이 책을 추천해드리고 싶습니다.

★ 이 책에서 다루는 내용 ★<br/><br/>■ 이해관계자들의 다양한 요구를 반영해 균형 잡힌 아키텍처를 설계하고 설명하는 방법<br/>■ 성능, 복원성, 지역성 등 간과하기 쉬운 영역을 비롯해 아키텍처적으로 중요한 설계적 측면에 초점을 맞추는 방법<br/>■ 시나리오와 패턴을 활용해 아키텍처를 만들고 검증하는 방법<br/>■ 연관된 뷰들을 묶어서 아키텍처를 문서화하는 방법<br/>■ 시스템과 주위 환경 사이의 상호작용을 문서화하는 ‘시스템 맥락 시점’<br/>■ 아키텍처 원칙에 대한 논의를 확장한, 아키텍처 의사결정에 대한 추적용이성과 근거를 제공하는 방법<br/>■ 애자일 개발과 아키텍처를 융합할 수 있는 방안<br/>■ 과제 맥락 내에서 요건과 아키텍처 활동의 위치 선정<br/>■ 아키텍처 검증을 위한 가볍고 새로운 방법론 <br/><br/>★ 이 책의 대상 독자 ★<br/><br/>이 책은 분명히 기성 소프트웨어 아키텍트와 소프트웨어 아키텍트 지망생이 관심을 보일 만한 책이다. 이 책에는 이미 친숙한 개념도 많지만 아직 낯선 개념도 다수 담겨 있다. 이 책을 통해 아키텍트의 역할을 명확히 설명하고 역할의 경계를 분명히 하며 독자들의 업무 방식이 개선되기를 기대해본다. 경력이 많은 아키텍트라면 일상적인 업무에서 3부와 4부에 담긴 정보를 참고용으로 활용하기에 유용하리라 본다.<br/><br/>또한 이 책에는 아키텍처 이해관계자들이 관심을 보일 만한 부분도 있다. 시스템 개발 과제에서 요구하는 쪽 입장으로 아키텍트와 협업하는 후원자와 고위 관리자라면 1부 전체, (각각 시점과 관점을 다루는) 3부와 4부의 도입장, 5부를 읽어보면 좋다.<br/><br/>소프트웨어 개발자(특히 설계자)와 지원 및 유지보수 인력도 이 책에서 유용한 자료를 많이 얻을 수 있을 텐데, 주로 3부와 4부를 집중해서 살펴보면 흥미를 끌 만한 아키텍처 정의 프로세스상의 여러 측면을 더 잘 이해할 수 있을 것이다.<br/><br/>★ 이 책의 구성 ★<br/><br/>1부에서는 책 전체에서 사용되는 기본적인 개념인 이해관계자, 아키텍처 문서, 시점, 뷰, 관점을 소개 및 검토하고 소프트웨어 아키텍트의 역할을 설명한다.<br/><br/>2부에서는 아키텍트로서 해야 하는 가장 중요한 활동인 과제 범위 합의, 이해관계자 식별 및 참여, 시나리오 및 패턴 활용, 모델 생성, 아키텍처 문서화 및 검증 같은 작업을 설명한다.<br/><br/>3부에서는 아키텍처 문서를 만들 때 쓰이는 가장 중요한 맥락, 기능, 정보, 동시성, 개발, 배치, 운영의 7가지 시점을 차례로 설명한다.<br/><br/>4부에서는 정보 시스템 관점 중에서 가장 중요한 보안, 성능 및 확장용이성, 가용성 및 복원성, 진화, 위치, 개발 자원, 국제화 관점을 차례로 설명한다.<br/><br/>5부에서는 이 모든 개념을 모아서 실무에 적용할 때 쓸 방안을 설명한다.<br/>