이제 SOA는 기업에서 보편적으로 고려할 아키텍처 사상이다. 최근 가트너에 따르면 SOA는 기술의 라이프사이클에서 검증단계를 지나 점차 IT 시스템에 적용되는 단계에 이르렀다. 이 책은 보편화된 서비스 중심의 아키텍처(SOA)를 엔터프라이즈 아키텍처를 고려해 구현할 수 있는 실천적 방법론을 제공한다. IT프로젝트 및 기업에서 업무분석과 설계, 프로젝트관리 역할을 하는 IT담당자나, 기업의 IT 기획과 전략을 고민하는 독자들에게 좋은 지침서가 될 것이다.


[ 소개 ]

정보기술/서비스 지향 아키텍처
서비스 지향 아키텍처를 실행에 옮기기

이 책은 SOA를 구축하는 엔터프라이즈 아키텍트가 반드시 소장해야 하는 책이다. 이 책은 실전 예제를 들어 비즈니스 요구사항, 비즈니스 프로세스 설계, 서비스 아키텍처 사이의 관계를 설명한다. 또한 SOA의 구현을 비즈니스 가치에 직접적으로 연결시켜, 지속적인 성공과 재정 지원을 확보할 수 있는 해답을 제공한다.
- 마야 티블링 / 콘웨이(Con-Way) 사의 수석 엔터프라이즈 아키텍트

아키텍처와 ESB, SOA 등 관련 기술을 구현하는 책이 있기는 하지만, 그 중에서도 유일하게 지식과 실생활의 경험을 포착하는 책이다. 이 책에서는 요구사항과 비전을 견고하고 반복 가능하면서도 가치를 더한 아키텍처로 변환하는 과정을 보여준다. 진심으로 이 책을 추천하는 바이다.
- 마크 웬섹 / 울티모 소프트웨어 솔루션 사의 컨설팅 서비스, 연합 부문 수석부사장

폴 브라운은 그의 첫 저서 『Succeeding with SOA』에서 기업의 목표를 달성하려면 비즈니스 프로세스와 정보시스템은 반드시 토탈 아키텍처(total architecture)의 한 부분으로 같이 설계되어야 한다고 설명했다. 두 번째 책인 『SOA 구축: 엔터프라이즈 아키텍처를 고려한』에서 폴은 프로젝트 단위와 엔터프라이즈 수준에서 모두 성공적인 토탈 아키텍처를 설계하고 개발하는 전체 과정을 안내한다. 그 자신의 광범위한 경험을 바탕으로, 서비스를 생성하고 그 서비스로 견고하고 유연한 SOA 솔루션을 생성하는 데 활용하는 베스트 프랙티스를 제공한다.

엔터프라이즈 아키텍처를 정의하거나 개별 SOA 프로젝트를 진행하는 경우에도 업무를 완수하는 데 실용적인 지침을 얻을 수 있다.


[ 이 책에서 다루는 내용 ]

■ 프로젝트 단위로 끊임없이 비즈니스 가치를 창출하면서 엔터프라이즈 아키텍처를 고려한 SOA 구축
■ SOA의 기초 지식과 분산 시스템, 주요 아키텍처 이슈, 그리고 이들을 다루는 설계 패턴
■ 프로젝트 아키텍트와 엔터프라이즈 아키텍트의 역할을 구별하고 SOA를 구현하기 위한 상호 협력 방법
■ 비즈니스 프로세스와 사람, 데이터, 인프라스트럭처를 포괄하는 토탈 아키텍처 방식의 필요성
■ 정교하면서도 안전하고, 성능과 가용성이 높은 솔루션을 구현하는 데 필요한 전략과 트레이드오프(tradeoff)
■ 비즈니스 프로세스 관리(BPM)와 비즈니스 프로세스 모니터링을 엔터프라이즈 아키텍처에 추가하는 방법


[ 이 책의 구성 ]

이 책은 9부로 구성되어 있다. 1부는 아키텍처와 서비스, 토탈 아키텍처 통합 방법론(total architecture synthesis methodology)에 대한 기본적인 개념을 설명한다. 2부에서 8부까지는 아키텍처 설계 문제와 비즈니스 프로세스 이해, 아키텍처의 모니터링과 테스트에 대해 설명한다. 9부는 앞에서 진행된 논의를 복잡한 비즈니스 프로세스와 워크플로우가 포함된 어려운 주제에 대해 설명하고 엔터프라이즈 아키텍처 그룹의 역할을 정리한다.
2부에서 8부까지 각 아키텍처 주제는 두 가지 측면, 즉 개별 프로젝트 측면과 전사 아키텍처 측면에서 설명한다. 각 부에서는 먼저 개별 프로젝트 아키텍트가 전사 아키텍처를 아무 것도 없는 상태에서 설계할 때 발생하는 설계 문제에 대해 논의한다. 각 부의 마지막 장은 여러 프로젝트가 병행 진행되는 환경에 대한 해결책으로 엔터프라이즈 아키텍처 그룹의 역할, 즉 토탈 아키텍처(total architecture)를 적용하는 방법을 설명한다. 이렇게 구분하는 이유는 개별 프로젝트 아키텍트와 엔터프라이즈 아키텍트가 잘 협업하여 역할을 조정해야 한다는 것을 강조하려는 취지다. 9부에서는 이런 작업을 엔터프라이즈 아키텍처 그룹이 관리해야 한다는 점을 강조한다.

[ 저자 서문 ]

기업의 서비스 지향 아키텍처(SOA)를 담당하는 아키텍트라면 지금 많은 과제를 안고 있을 것이다. 아키텍처는 아키텍트의 의도와는 상관없이 비즈니스 프로세스에서 데이터 스토리지까지 다양한 수준의 기업 구조를 정의한다. 또 아키텍처는 조직 단위와는 비즈니스 시스템 사이의 영역을 정의한다. 아키텍처는 서비스의 정의뿐만 아니라 비즈니스 프로세스의 오케스트레이션(orchestration)을 통한 비즈니스 연속성을 제시하기 위해 복잡하게 분산된 시스템의 설계에 대한 실질적인 해결책을 제공해야 한다. 아키텍처는 수많은 프로젝트와 아키텍트의 정확한 가이드로 오랜 시간에 걸쳐 구축된다.

나는 이 책에서 성공적인 SOA 도입에 필요한 기업의 관심, 아키텍트의 의무, 올바른 조직 구성에 대해 설명할 것이다. 아울러 프로젝트와 엔터프라이즈 수준의 서비스 지향 아키텍처를 정의하는 프로세스를 설명하려 한다. SOA를 구현하는 현직 아키텍트나 아키텍트를 지망하는 엔지니어로서 좀 더 많이 배우고 싶은 분들에게 이 책을 바친다.

잘 구축된 SOA는 많은 혜택을 준다. SOA를 성공적으로 구축하게 되면 기업은 재사용 가능한 비즈니스와 기반 서비스를 갖추게 된다. 기업은 이 서비스를 효과적으로 재조합하여 비즈니스 요건을 민첩하게 해결할 수 있다. 반면에 SOA가 제대로 구현되지 않은 경우, 기업은 유연성이 떨어지고 빈약한 컴포넌트로 인해 경쟁력을 잃는다. 이런 결과는 원하지 않을 것이다. 이 책에서 나는 베스트 프랙티스뿐만 아니라 필수사항도 기술함으로써, 성공적인 SOA 구현을 위한 기준을 제시하겠다.


[ 저자 소개 ]

폴 브라운 (PAUL C. BROWN)
엔터프라이즈 소프트웨어와 서비스에서 세계적 리더 기업인 TIBCO(www.tibco.com)의 수석 소프트웨어 아키텍트이다. 그의 모델 기반 툴 아키텍처는 프로세스 통제 인터페이스에서 NASA 위성 임무 기획에 이르는 다양한 애플리케이션의 기초가 된다. 브라운 박사의 엔터프라이즈 시스템에 대한 폭넓은 경험 덕분에 그의 첫 책 『Succeeding with SOA』(Addison-Wesley, 2007)에서 소개된 토탈 아키텍처(total architecture) 개념이 만들어질 수 있었다. 브라운은 렌셀러폴리테크닉 대학교(Rensselaer Polytechnic Institute)에서 전산학 박사학위를 받았다.


[ 옮긴이의 말 ]

가트너가 서비스 지향 아키텍처(이하 SOA)를 소개한 지 꽤 오랜 시간이 흘렀다. 나는 SOA가 국내에 도입된 초기부터 SOA의 개념, 서비스 도출 방법, 개발 방법론, SOA Governance 등 SOA와 관련된 개념 정립과 실제 구축, 관리를 위한 다양한 일을 해오고 있다.

SOA가 처음 도입되던 시점이 기억난다. 처음에는 ‘SOA는 이전 IT와 완전히 다르다’, ‘SOA는 새롭다’라는 느낌을 받았다. 새로운 것에 상기된 동료들과 같이 공부하고 치열하게 토론하던 그 때를 생각하면 지금도 가슴이 설렌다. 특히 서비스의 크기(Granularity)에 대한 토론 과정은 혼돈을 불러일으키면서도 큰 즐거움이었다.

그러나 SOA에 대한 개념이 어느 정도 정리되었다고 자부(!)하고 실제 고객을 접하게 되자, 곧 여러 가지 난관이 따랐다. 우선 고객은 대세라고 불리는 SOA를 이해하기 위해 많은 노력을 쏟으며 힘들어 했다. SOA를 전파하는 입장에서도 막상 구축 시점에서, ‘완전히 다르다’는 SOA 기반으로 애플리케이션을 개발하려면 개발 절차도 달라야 한다는 강박에 시달리곤 했다. 즉 SOA 기반의 애플리케이션 실제 구축 단계에서 아이디어 부재를 느끼며 힘들어 했다.
실제 구축을 통해 이런 난제들을 거치며 고객들은 말한다. ‘SOA는 좋은 것 같은데, 너무 어렵다’, ‘SOA는 ROI 계산이 힘들다’. 조금 지나 SOA 거버넌스(Governance) 부재가 이유임을 깨닫지만, 이 또한 모든 문제를 해결해주지는 못한다는 사실을 느끼게 된다.

SOA는 왜 이렇게 도입하기가 힘든 걸까? 새로운 개념의 아키텍처라서 그런 걸까? 단순히 벤치마킹할 대상이 없어서 그런 걸까? 역자는 그렇지 않다라는 생각이 든다. 우리가 SOA의 순결성(전통적인 IT와 전혀 다르다는) 또는 전지전능함에 지나치게 집착하기 때문이라고 생각한다. 번역을 진행하며, 저자의 생각을 하나씩 읽어갈수록 이런 생각이 더 확고해졌다.

이 책은 제목 그대로 SOA의 실제 구축 단계를 설명한다. 특히 SOA를 구축하는 아키텍트의 역할에 많은 관심을 기울인다. 처음 번역을 진행하며 ‘SOA를 말하는 책인데 좀 평범하다’는 생각이 들었다. 애플리케이션 개발 과정이 그랬고, 아키텍트의 역할이 또한 평범했다. 다른 SOA에 관련된 책들은 새로운 용어, 조금은 선정적인 새로운 문구를 전면에 내세워 출간되는데 이렇게 평범해서야 책이 팔릴까라는 고민도 잠시 했다.

하지만 번역 작업을 할수록 저자의 의도를 정확히 알 수 있었고, 앞에서 얘기한 질문의 답을 얻게 됐다. 즉 SOA란 무엇인가(What is SOA)도 중요하지만 그에 못지 않게 하우투 SOA(How to SOA)가 정말 중요하다는 사실이다. 실상 SOA의 개념만을 설명하고 끝나는 책은 이미 많다.

애플리케이션 개발 주기(Application Development Lifecycle)에는 분석, 설계만 있는 것이 아니라 실제 개발, 테스트, 디버깅, 배포가 포함되어 있는데도 말이다.

이제 SOA는 보편적으로 받아 들여지는 아키텍처 사상이다. 가트너의 최신 하이프 사이클(Hype Cycle)을 보면 SOA는 초기 관심이 치솟던 단계, 즉 환상이 사라져서 바닥으로 떨어지는 단계를 지나 깨달음의 단계(Slope of Enlightenment) 시점에 와 있다. 개념에 대한 검증은 끝나고 점차 IT 시스템에 적용되는 단계다. 구글 트렌드(Google Trend)에서도 이런 현상에 대한 증거를 엿볼 수 있다. 구글 트렌드에서 SOA를 검색해보면, 아직도 SOA를 찾아보는 사람이 많다.

SOA의 참신함, 순결성만 강조하다 전통적인 IT를 배척하는 우를 범해서는 안 된다. 오랜 기간 최적화되고 검증된 기존 IT를 포용할 때 SOA는 성공할 수 있다. 그런 의미에서 이 책은 SOA를 도입하는 기업의 IT 아키텍트에게 특별한 가치를 제공한다. 즉 최신 IT인 SOA와 전통적인 IT를 잘 조합하여 SOA 도입을 성공시킬 방안이 담겨 있다.

하이프 사이클의 곡선이 갖는 두 가지 의미를 뒤늦게 깨닫는다. 하나는 최신 기술/트렌드의 발전 경로이고 다른 하나는 이를 수용하는 사람의 의식 발전 경로인가 보다. 이를 일찌감치 깨달은 저자의 혜안에 감탄한다.


[ 옮긴이 소개 ]

공상휘
고려대학교 이과대학과 서울대학교 보건대학원을 거치면서 노동자의 직업병 예방을 위한 공부를 했다. 과거 D그룹 비서실에서 대기업 노동현장을 좀 더 건강하게 만드는 일을 담당하던 중, 산업현장에 더 가까이 가는 방법으로 당시 유행하던 MIS 개발에 발을 들여놓았다. 이후 지금까지 10여 년 동안 IT 분야에서 일하고 있으며, 근래 5년 동안 티맥스소프트에서 BPM, ESB, Application Framework, SOA 전략에 대한 프로젝트와 컨설팅업무를 수행해 왔고, 국내에서는 덜 알려진 S/W Product Management에 대한 활성화와 조직운영에 많은 관심을 기울였다. 최근 (주)엔코아에서 Real-time BI와 BAM 분야 컨설팅업무를 수행하고 있다.

최종일
경희대학교 환경학과를 졸업했다. 지난 15년간 IT 분야에서 IT 아키텍처, 솔루션 컨설팅을 하고 있다. 특히 다양한 산업 영역에서 SOA 컨설팅과 구축 경험이 있고, 현재 한국 오라클 미들웨어 사업부에서 SOA, BPM, Mobile computing 관련 컨설팅을 담당하고 있다.

이주영
국민대학교 정보관리학과와 동대학 경영대학원 e-ERP MBA 과정을 졸업했다. 서버 & 네트워크 엔지니어, ERP 구축 컨설턴트, 정보전략 및 IT 아키텍처 컨설턴트로 지난 10년 이상을 여러 IT 분야에서 일했다. 국내 SOA에 대한 관심이 가장 높았던 2006~8년 당시 티맥스소프트에서 SOA 관련 솔루션 및 컨설팅업무와 SOA 기반의 SW 개발방법론 구축 업무에 참여했다. 현재는 General Motors(International Operation 소속)에서 Regional IT Contract Manager로 재직 중이며, SLA 기반의 IT Oursourcing 계약 수립과 거버넌스 업무를 담당하고 있다.

목차

• 1장 SOA와 엔터프라이즈
  • 토탈 아키텍처
  • 아키텍처는 목적이 있는 구조다
  • 끊임없는 변화
  • 토탈 아키텍처 구성
  • 우리의 기업에서 토탈 아키텍처 작업 수행하기
  • 핵심 질문
    
• 2장 아키텍처 일반
  • 구조적인 구성
    • 컴포넌트
    • 하위컴포넌트
  • 기능적인 구성
    • 공유 자원
    • 변경 요건의 대응
    • 편리함의 유혹
  • 협업 기능
    • 액티비티
    • 객체
    • 통신
    • 비즈니스 프로세스
  • 토탈 아키텍처
  • 비기능 요건
  • 정련
  • 아키텍트의 역할
  • 엔터프라이즈 아키텍처
    • 아키텍처 스타일
    • 패턴
  • 요약
  • 아키텍처 기본사항에 대한 핵심 질문
  • 추천 문헌
    
• 3장 서비스
  • 서비스란
    • 오퍼레이션
    • 참조 객체
    • 소유된 객체
    • 관계의 소유
    • 캐시정보 관리
  • 서비스 인터페이스
    • 일반적 접근 기술
    • 공통 데이터 표현 기술
    • 일반적인 데이터 문법
    • 일반 오퍼레이션
    • 인터페이스 보편성 수준의 결정
  • 서비스 사용의 근본적인 이유
    • 서비스 재사용
    • 인터페이스 안정성
    • 서비스의 진화
  • 요약
  • 서비스 기본사항에 관한 핵심 질문
  • 추천 문헌
    
• 4장 서비스의 사용
  • 서비스 상호작용 패턴
    • 동기식 요청- 응답
    • 비동기식 요청- 응답
    • 구독 신청
    • 요청하지 않은 결과의 통지
    • 상호작용 패턴 요약
  • 서비스 호출
    • 서비스 직접 호출
    • 서비스 직접 호출의 변수
    • 직접 호출의 제약사항
    • 메시지 기반의 서비스 호출
  • 호출 제어
    • 정책 관리 지점
    • 프록시의 호출 제어
    • 중계 서비스를 사용한 호출 제어
  • 서비스 요청 라우팅
    • 부하 분산
    • 위치 기반 라우팅
    • 콘텐츠 기반 라우팅
  • 서비스 조합
    • 강결합 조합
    • 내재된 조합
    • 캐시를 사용한 조합
  • 서비스의 위치 정하기
  • 서비스 구현을 위한 엔터프라이즈 아키텍처
  • 요약
  • 서비스 사용에 대한 핵심 질문
  • 추천 문헌
    
• 5장 SOA 개발 프로세스
  • SOA 개발은 무엇이 다른가?
  • 개발 프로세스 개요
  • 아키텍처 태스크
  • 전체 속에서의 아키텍처
  • 토탈 아키텍처 통합
    • 초기 범위 선정
    • 요구사항 정의
    • 비즈니스 프로세스 아키텍처의 설계
    • 시스템 아키텍처의 설계
    • 아키텍처 평가
  • 프로세스처럼 보이는 것을 찾아라!
  • 리스크 관리: 반복적으로 아키텍처 구성하기
  • 요약
  • 개발 프로세스에 관한 핵심 질문
  • 추천 문헌
    
• 2부 비즈니스 프로세스 전반
  
  
• 6장 프로세스
  • 연관 프로세스
  • 프로세스 성숙도
  • 연속 프로세스
  • 구조적 프로세스
  • 요약
  • 프로세스에 대한 핵심 질문
  • 추천 문헌
    
• 7장 초기 프로젝트 범위 설정
  • 비즈니스 프로세스 목록 수집
  • 인터뷰 진행
  • 목록의 문서화
    • 목표와 이해관계자
    • 프라이머리 프로세스
    • 관련 프로세스
    • 유사 비즈니스 프로세스
    • 프로세스 수치
  • 비즈니스 프로세스의 순위 선정
    • 우선순위 배정 계획
    • 점수 집계
  • 나머지 작업의 구조화
  • 요약
  • 범위 선정에 대한 핵심 질문
    
• 8장 요구사항의 기술
  • 구분
    • 액티비티의 구분
    • 참여자 구분하기
    • 설계는 구분 작업이다
  • 프로세스의 특성 정의
    • 컬래버레이션 다이어그램은 프로세스를 의미한다
    • 컬래버레이션 구성 요소
    • 참여자는 자신의 구성 요소를 모를 수 있다
  • 상호작용의 유형
    • 유스케이스 설명
    • 유스케이스의 한계
    • UML 액티비티 다이어그램
    • 인터페이스 관점
    • 상호작용 패턴은 참여자의 특성을 기술한다
  • 요구사항은 설계를 반영한다
    • 요구사항은 상호작용 패턴을 명세화한다
    • 요구사항은 완전하지 않다
  • 요약
  • 요구사항에 대한 핵심 질문
  • 추천 문헌
    
• 9장 비즈니스 프로세스 아키텍처
  • 결과
  • 참여자와 그 역할
    • 참여자의 종류와 역할 구분
    • 역할과 그에 따른 고유한 액티비티
    • 역할과 비즈니스 프로세스의 진화
    • 역할의 식별과 이해
  • 액티비티와 시나리오
    • 시나리오와 변종 프로세스
    • 프로젝트 효율성
  • 시나리오 모델링
    • 참여자 역할의 차별화
    • 액티비티에 대한 책임성 부여
  • 상호작용 모델링하기
    • 생산자-소비자의 상호작용
    • 동시에 발생하는 상호작용
    • 단순 표기법
    • 시나리오 변형
    • 예외처리
  • 상세화 수준은 얼마나 충분한가?
  • 액티비티 다이어그램 사용을 위한 지침
  • 요약
  • 프로세스 아키텍처에 대한 핵심 질문
  • 추천 문헌
    
• 10장 마일스톤
  • 기본적인 프로세스 마일스톤
  • 마일스톤 순서의 변이
  • 그룹화된 마일스톤
  • 마일스톤의 인식에 따른 설계
  • 마일스톤을 이용한 프로세스 간 커플링 감소
  • 요약
  • 마일스톤에 대한 핵심 질문
    
• 11장 프로세스 제약조건
  • 비즈니스 프로세스 제약조건에 의한 시스템 제약조건 도출
  • 성능 제약조건
    • 속도와 응답시간
    • 핵심 성과 지표
    • 성능 서비스 수준 협약
  • 고가용성과 장애 허용성
    • 용어 정의
    • 모든 상대적인 것
    • 투자 대 위험성
    • 비즈니스 프로세스의 설계가 시스템 투자에 주는 영향
    • 위험성에 주목하라
    • 위험성 관련 서비스 수준 협약
  • 보안
  • 보고와 모니터링, 그리고 관리
    • 보고
    • 모니터링
    • 관리
  • 예외사항 처리
  • 테스트와 인수
    • 시스템 설계에 영향을 주는 테스트
    • 테스트를 통해 컴포넌트의 추가
    • 테스트에 필요한 환경
  • 준수해야 할 제약조건
  • 요약
  • 프로세스 제약조건에 대한 핵심 질문
  • 추천 문헌
    
• 12장 관련 프로세스
  • 서비스 식별
    • 공유상태 관리
    • 서비스 정의의 정제
    • 기존 프로세스의 모델링
  • 트리거 이벤트
    • 독립 프로세스
    • 의존 프로세스
    • 이벤트 기반 프로세스로의 변화
  • 요약
  • 관련 프로세스에 대한 핵심 질문
    
• 13장 도메인 모델링
  • UML 클래스 표기법
  • ATM 사례에 대한 도메인 모델
  • 도메인 모델의 역공학
  • 요약
  • 도메인 모델링에 대한 핵심 질문
  • 추천 문헌
    
• 14장 아키텍처: 프로세스와 도메인 모델링
  • 프로세스와 도메인의 모델링이 주는 의미와 역할
  • 표준 및 우수 사례의 선정
  • 프로세스와 도메인 지식의 전달 관리
  • 프로젝트 모델의 검토
  • 비즈니스 프로세스와 도메인 모델링 저장소의 관리
  • 비즈니스 프로세스 패턴의 정의
  • 공통 데이터 모델 표기법의 정의
  • 요약
  • 엔터프라이즈 프로세스와 도메인 모델링에 대한 핵심 질문
    
• 3부 시스템 전반
  
• 15장 시스템 아키텍처 개요
  • CORBA 경험으로부터의 교훈
  • 효율적으로 아키텍처 조사하기
    • 아키텍처 이슈에 순서 부여 하기
    • 주기적인 아키텍처 평가
  • 요약
  • 시스템 아키텍처 개요에 대한 핵심 질문
    
• 16장 최상위 수준 시스템 아키텍처
  • 첫 번째 구조
  • 초기 평가
  • 통신과 모듈화
    • 통신 대기시간
    • 통신 대역폭
    • 데이터 마샬링
    • 지리적 분배
    • 다른 모듈화 방법에 대한 고려
  • 서비스 식별과 성능
  • 시스템 상호작용 모델링
  • 전개 모델링
  • 성능 언급하기
    • 순간 최대 부하
    • 응답시간
    • 응답시간 테스트 명세
  • 초기 아키텍처평가
  • 최상위 수준 아키텍처에 대한 핵심 질문
  • 추천 문헌
    
• 4부 커뮤니케이션
  
• 17장 전송
  • 전송기술
    • 사람 대 사람 상호작용
    • 사람과 시스템 간 전송
    • 시스템 간의 전송
  • 전송 선택하기
  • 메시징 서버 토폴로지
    • 수용능력한계 극복하기
    • 지리적인 분산 극복하기
  • 수용능력
  • 점대점 상호작용 패턴
  • 점대점 중계자
  • 전송이 제공되는 서비스
  • 요약
  • 전송에 대한 핵심 질문
  • 추천 문헌
    
• 18장 어댑터
  • API 기반의 어댑터
  • 데이터베이스 기반의 어댑터
  • API와 데이터베이스 방식의 조합
  • 파일 기반의 어댑터
  • 프로토콜 기반의 어댑터
  • 어댑터 사용의 문서화
  • 요약
  • 어댑터에 대한 핵심 질문
  • 통신전략 정의하기
    
• 19장 엔터프라이즈 아키텍처: 통신
  • 상호작용 표준
  • 어댑터 표준화
  • 요약
  • 엔터프라이즈 아키텍처 통신에 대한 핵심 질문
    
• 5부 데이터와 오퍼레이션
  
• 20장 데이터 고려사항
  • 메시지 의미와 오퍼레이션 이름
    • 메시지 의미
      
• 21장 메시지와 오퍼레이션
  • 오페레이션 이름 붙이기
  • 전송 목적지와 오퍼레이션 번들링
    • 번들링 장점
    • 번들링 단점
    • 절충
    • 중계방식의 전송
  • 콘텐츠 표현
  • 콘텐츠 변환
  • 콘텐츠 변환 내의 참조 데이터
  • 요약
  • 메시지와 오페레이션에 대한 핵심 질문
    
• 22장 데이터 일관성: 한 버전의 진실
  • 데이터 일관성 유지 방안
  • 단일 정보 스토리지 시스템을 사용한 캐시 데이터
  • 분산 트랜잭션을 통한 조정된 업데이트
  • 데이터의 수정은 자유롭게, 조정은 이후에
  • 데이터 불일치 관리
  • 데이터 관리 비즈니스 프로세스
  • 요약
  • 데이터 일관성에 대한 핵심 질문
  • 추천 문헌
  • 공통 데이터 모델이 무엇인가?
    
• 23장 공통 데이터 모델
  • CDM과 도메인모델과의 관계
  • 다수의 CDM 표현의 필요성
  • 공통 데이터 모델 변경 계획
    • 스키마 버전 관리
    • 변경 추가에서의 버전관리
    • 스키마 이전 거버넌스
  • 언제 공통 데이터 모델을 사용할 것인가
    • 직접 변환을 선택하는 기준
    • 공통 데이터 모델을 선택하는 기준
  • 요약
  • 공통 데이터 모델에 대한 핵심 질문
    
• 24장 식별자(유일 명칭)
  • 아이덴티티 관리 주체
  • 계층적인 식별자
    • 기업 내부의 계층적인 식별자
    • UUID와 GUID
  • 아이덴티티 문제의 해결
    • 아이덴티티 문제의 결과
    • 아이덴티티 문제의 원인
    • 식별자와 잘못된 객체와의 연관
    • 하나의 식별자와 복수 객체와의 연관
    • 복수 식별자와 단일 객체와의 연관
  • 식별자의 매핑
    • 식별자의 연관 작업
  • 요약
  • 식별자에 대한 핵심 질문
    
• 25장 결과 검증
  • 열거 값 확인하기
  • 언제 어디서 검증해야 하나
  • 요약
  • 데이터 검증에 대한 핵심 질문
  • 네이밍 계획
    
• 26장 엔터프라이즈 아키텍처: 데이터
  • 콘텐츠 변환 아키텍처
  • 정보 스토리지 시스템
  • 공통 데이터 모델
  • 식별자
  • 데이터 품질 관리
  • 요약
  • 엔터프라이즈 아키텍처 데이터에 대한 핵심 질문
    
• 6부 조정
  
• 27장 조정과 장애 감지
  • 상호작용을 포함하는 액티비티 실행 관리 패턴
  • 조정 패턴 스타일
  • 파이어 앤 포겟 조정 패턴
    • 이벤트 기반의 두 참여자간 파이어 앤 포겟
    • 이벤트 기반의 다수 참여자 간 파이어 앤 포겟
    • 파이어 앤 포겟에서 장애 감지하기
    • 이벤트 기반이 아닌 파이어 앤 포겟
  • 요청-응답 패턴
    • 이벤트 기반 두 참여자 간 요청-응답
    • 응답시간 서비스 수준 협약
    • 이벤트 기반 다수 참여자간 요청-응답
    • 이벤트 기반 비동기식 요청-응답
    • 비동기식 요청-응답에서의 복잡성
    • 비동기식 결과에 대한 동기식 약속
  • 위임
  • 확답을 포함한 위임
  • 요약
  • 조정에 관한 핵심 질문
    
• 28장 트랜잭션: 둘 이상의 액티비티 관리
  • 2-단계 커밋 분산
  • 2-단계 커밋 프로토콜의 한계
  • 보상 트랜잭션
  • 보상 트랜잭션의 한계
  • 요약
  • 트랜잭션에 대한 핵심 질문
  • 추천 문헌
    
• 29장 프로세스 모니터와 관리자
  • 프로세스 모니터링
  • 모니터링 장애의 영향을 최소화하기
  • 모니터 역할을 하는 프로세스 관리자
  • 프로세스 관리의 한계점
  • 요약
  • 프로세스 모니터링과 관리에 대한 핵심 질문
  • 장애감지 개선을 위한 조정 패턴 선정
    
• 30장 장애감지와 대응
  • 장애 대응
    • 장애 결과 기록
    • 장애 공지
    • 장애 공지 대응
    • 장애복구
  • 요약
  • 장애감지와 장애복구에 대한 핵심 질문
  • 선호 조정 패턴
    
• 31장 엔터프라이즈 아키텍처: 조정
  • 장애 기록
  • 장애 알림
  • 복구 프로세스
  • 요약
  • 엔터프라이즈 조정에 대한 핵심 질문
    
• 7부 고가용성과 장애 허용성, 부하 분산
  
• 32장 고가용성과 장애 허용성의 기초
  • 장애감지 전략
    • 직접적인 컴포넌트 모니터링
    • 하트비트 모니터링
    • 라이브니스 체크
  • 페일오버 관리
  • 클라이언트의 리다이렉트
  • 요약
  • 고가용성과 장애 허용성에 대한 핵심 질문
  • 상태가 없는 컴포넌트와 상태가 있는 컴포넌트
  • 상태 없는 페일오버
    
• 33장 상태가 없는 페일오버와 상태가 있는 페일오버
  • 조정을 통해 진행 중인 작업 저장하기
  • 상태가 있는 페일오버
  • 스토리지 복제
    • 컴포넌트 내부의 동기식 복제
    • 컴포넌트간 동기식 복제
    • 비동기식 복제와 데이터 유실
    • 지속상태 컴포넌트 페일오버
  • 요약
  • 페일오버에 대한 핵심 질문
  • 추천 문헌
    
• 34장 다중 컴포넌트 페일오버
  • 사이트 내의 페일오버와 사이트 간의 페일오버
  • 클러스터링: 사이트 내의 페일오버 기술
  • 비동기적인 복제를 통한 개별 어플리케이션의 페일오버 방안
  • 비즈니스 프로세스의 장애 허용성Fault Tolerant 확보 방안
  • 요약
  • 다중 컴포넌트 페일오버에 대한 핵심 질문
  • 작업 할당 전략
    
• 35장 작업 부하 분배
  • 분배 관리와 작업 완료
  • 순차 처리의 문제
    • 중앙집중 순서관리
    • 분산 순서관리
  • 공유 지속상태에 접근하기
  • 지리적 작업 부하 분배
  • 요약
  • 부하 분배에 대한 핵심 질문
    
• 36장 엔터프라이즈 아키텍처: 장애 허용성과 고가용성, 부하 분산
  • 비즈니스 프로세스 분류
  • 정보 저장
  • 개별적인 컴포넌트와 서비스 페일오버failover 패턴
  • 서비스의 장애 허용성과 고가용성을 확보하기 위한 복합 패턴
  • 비즈니스 프로세스 장애 허용성과 고가용성을 위한 복합적인 패턴
  • 요약
  • 장애 허용성과 고가용성, 부하 분산에 대한 핵심 질문
  • 추천 문헌
    
• 8부 아키텍처 완성
  
• 37장 프로세스 보안
  • 신원 확인과 권한 부여
    • 인증 프로세스
    • 인증을 위한 참조 정보
  • 권한통제
    • 입도 문제
    • 그룹과 역할
    • 그룹과 역할의 한계
  • 암호화
  • 전자 서명화
  • 다른 보안 관련 요구사항
  • 참조 데이터 서버와 성능
  • 신뢰구간
  • 채널 기능
  • 구역 기능과 정책 에이전트
  • 다중구역 보안
  • 요약
  • 보안에 대한 핵심 질문
  • 추천 문헌
    
• 38장 프로세스 모니터링
  • 성능 모니터링
    • 단일 지점에서의 모니터링
    • 두 지점에서의 연관성 없는 모니터링
    • 두 지점에서의 연관성 있는 모니터링
  • 프로세스 상태 모니터링
  • 관리감독 프로세스
  • 성능 모니터링의 영향
  • 요약
  • 모니터링에 대한 핵심 질문
    
• 39장 아키텍처 평가
  • 사용성
  • 성능
    • 필요 컴포넌트 자원 분석
    • CPU 필요량의 추정
    • 메시지 처리와 디스크 성능
    • 전개 부하 분석
    • 부하 모델의 진화
  • 비용과 일정에 대한 타당성
  • 관측성
  • 진화 능력
  • 스트레스 상황 대응 능력
  • 요약
  • 아키텍처 평가에 대한 핵심 질문
  • 추천 문헌
  • 단위 테스트와 테스트 도구, 회귀 테스트
    
• 40장 테스트
  • 통합 테스트와 테스트 순서 정하기
  • 기능과 시스템 테스트 환경
  • 성능 테스트
    • 용량 측정
    • 시스템 용량 테스트
  • 장애 테스트
  • 요약
  • 테스트에 대한 핵심 질문
    
• 9부 진보적 주제
  
• 41장 복잡한 프로세스의 표현
  • 커뮤니케이션의 세부사항 생략하기
  • 참여자 액티비티의 세부사항 생략하기
  • 지원하는 참여자 생략하기
  • 서브프로세스 추상화하기
  • 요약
  • 복잡한 프로세스의 표기에 대한 핵심 질문
    
• 42장 프로세스 관리와 워크플로우
  • 프로세스 관리
    • 프로세스 관리 목표
    • 관리 프로세스는 작업 프로세스가 아니다!
    • 프로세스와 작업 간의 분리를 유지하기
  • 작업 할당 방식
    • 작업 큐와 작업 할당
  • 워크플로우 시작
  • 관리 프로세스의 장애 허용성 지원
    • 장애 허용성 워크플로우 엔진의 사용
    • 관리 프로세스 상태의 체크포인팅
    • 관리 프로세스의 요청-응답 호출
    • 하이브리드 장애 허용성 기술
  • 휴먼 인터페이스
    • 작업 할당 기능의 역할
    • 데이터의 역할
    • 사용자 인터페이스의 장애 복구
  • 관련 프로세스
  • 우선순위가 부여된 작업
  • 동적인 작업 배정
  • 결과와 프로세스의 동적인 정의
    • 설계의 표기
    • 구현 프로세스의 정의
    • 계속되는 변경의 수용
  • 요약
  • 프로세스 관리와 워크플로우에 대한 핵심 질문
  • 추천 문헌
    
• 43장 엔터프라이즈 아키텍처 그룹
  • 절반의 아키텍처 그룹이라도 없는 것보다는 낫다. 하지만 만족할 만큼은 아니다
  • 베스트 프랙티스 개발
  • 지식 전수
    • 문서화
    • 교육
    • 멘토링
  • 거버넌스
  • 진화하는 요구사항으로 설계하기
    • 계층적 아키텍처
    • 지리적 배포
    • 조직적인 조정
  • 요약
  • 엔터프라이즈 아키텍처 그룹에 대한 핵심 질문
    
• 맺는 말
  • 주어진 일에 집중하자
  • 다른 전문가의 도움을 받자