소프트웨어 조직의 생산성을 높이고 성공하는 제품 솔루션을 만들기 위해 아키텍처와 마케팅 정보를 어떻게 통합해야 하는지를 기술과 비즈니스 관점에서 날카롭게 지적하고 상세히 설명한다.


[ 소개 ]

지난 수년간 새롭고 혁신적인 제품을 만드는 많은 프로젝트에서 생산한 제품들은 끝내 성공하는 솔루션이 되는 데 실패했거나 힘든 과정을 겪어야만 했다. 실제로 도움이 되는 가이드라인을 엄청나게 제공하는 매우 유용하고 유익한 책이다.

비즈니스 마인드와 기술이 만나면 정말 마법 같은 일이 일어난다. 두 분야의 아이디어를 융합시키는 데 큰 도움이 되는 책이다.

비즈니스와 테크놀로지 사이의 관계를 성공적으로 조율하는 일은 21세기의 모든 기업이 직면한 엄청난 임무다. 『소프트웨어 아키텍처 2.0』은 중요한 임무를 적절히 수행하는 데 도움을 주는 실용적인 안내서다. 현대의 경제 시스템에서 소프트웨어에 관한 결정이 사업에 미치는 영향은 막중하다. 거꾸로, 사업에 관한 대부분 결정 역시 소프트웨어 애플리케이션의 가능성에 영향을 미칠 것이다. 이 책은 현실세계에서 성공하는 솔루션을 만드는 것에 대해 날카로운 직관과 실용적인 가르침을 담고 있다.

소프트웨어는 기업에 어떤 가치를 제공할 수 있도록 만들어져야 하지만 가치보다는 혼란을 초래하는 경우가 다반사다. 강력한 애플리케이션이 시장에 존재하지만, 그것을 구매하거나 라이선스를 도입한다고 해서 성공이 보장되진 않는다. 성공하는 솔루션이 되려면 기업의 인프라에 적절히 통합돼야만 한다.

소프트웨어 전문가인 루크 호만은 소프트웨어 아키텍처에 관한 결정을 내릴 수 있도록 중요한 방향을 일러준다. 그리고 소프트웨어를 성공시키기 위해 반드시 해결해야 하는 비즈니스 이슈를 이해하고 터득하는 방법을 알려준다. 사업 담당자와 개발팀은 항상 중요한 결정 사안들로 뒤덮인 지뢰밭을 지나야 한다. 이 책을 지도로 사용하면 그런 지뢰밭을 안전하게 빠져나갈 수 있을 것이다. 비즈니스와 테크놀로지가 만들어내는 최종적인 시너지를 통해 성공하는 기술 솔루션을 만들 수 있으며 기업도 성공의 발판을 닦을 수 있게 되리라.


[ 추천의 글 Ⅰ ]

소프트웨어 비즈니스 세계에서 아키텍처는 매우 모호한 용어가 됐다. 무엇을 의미하는지 명쾌하게 정의를 내리고 개념을 잡기가 어려운 용어다. 나는 ‘아키텍처’가 본질적으로 주관적인 용어라고 생각한다. 사람들은 자신의 소프트웨어 아키텍처를 설명할 때, 자기 시스템의 중요한 부분을 골라서, 선택한 부분들이 어떻게 조합되는지, 그리고 시스템을 설계할 때 중요한 결정을 어떻게 내렸는지에 대해 설명한다. 아키텍처는 기술적인 문제인 것처럼 보인다. 결정해야 할 중요한 문제들이 기술적인 문제이기 때문이다.

루크와 지난 몇 년간 많은 이야기를 나누며 그가 유감스럽게도 대부분의 아키텍처 관련 논의에서 등한시되던 사안들을 지적하는 말을 듣고 정말 기뻤다. 시스템을 보는 마케팅적인 관점, 라이선스 조약, 브랜딩, 배치, 과금 등 모든 조각이 어느 하나 빠짐없이 모두 중요하다. 이 모든 문제는 중요한 기술적인 함의와 사업적인 함의를 담고 있다. 고참 기술자는 이런 문제를 생각해야 한다. 그렇지 않으면 기술적 잠재력이 있는 시스템도 좋은 사업적 결정을 내리는 데 실패할 수 있다.

소프트웨어를 다른 사람들에게 판매하는 사람들 대부분이 이런 문제를 겪는다. 조직 내부의 IS 부서 아키텍트도 이런 문제에서 자유로울 수 없다. 외부 업체와의 라이선싱 계약 때문에 소프트웨어 비용에 큰 영향이 있을 것이다. 과금 방식 또한 사업적인 문제로 입금취소 기능을 도입하기로 결정할 경우 중요한 문제로 부각된다. 브랜딩은 사업적인 측면에서 회사를 노출시키는 데 도움이 된다.

루크는 기술적인 측면과 사업적인 측면을 모두 다뤄본 사람의 관점에서 글을 쓴다. 양쪽 측면 모두에 능숙하기 때문에 그는 종종 논의조차 되지 않는 문제도 숙고한다. 이것이 그의 장점이다. 루크는 생각조차 하지 않았던 문제로 인해 우리가 곤란에 처할 수도 있음을 지적한다. 그리고 그런 곤란함을 극복할 수 있는 절차에 대해 조언한다. 앞으로 이 책은 소프트웨어 설계의 기술적 측면에서 매우 훌륭한 업적으로 자리매김할 것이다.



[ 추천의 글 Ⅱ ]

소프트웨어 짜는 일은 과학이라기보다 예술에 가깝다고 생각한다는 점을 미리 밝힌다. 그렇다면, 어떻게 내가 창의적인 문제가 아닌 실천적인 문제를 깊게 다루는 책에 대해 추천사를 쓸 것인가?

예술과 소프트웨어 양쪽의 창의적인 프로세스는 너무 과대평가되어 있다. 편안한 의자에 앉아 마음의 눈을 깨끗이 하고 소프트웨어의 요정이 마음속에 들어와 아무런 노력 없이도 수천 줄의 우아한 코드를 두뇌에 흘려주는 장면을 상상해보라. 소프트웨어를 만들어본 적이 있는 사람이라면, 현실은 그렇지 않다는 사실을 잘 알 것이다.

예술은 어렵다. 디버깅 역시 어렵다. 이 책은 당신과 당신 팀이 더 나은 예술가가 되도록 도울 것이다. 이 책은 원칙, 팀워크, 땀, 그리고 영감에 관한 책이다. 나는 많은 이가 이 책을 읽기 바란다. 그래서 위대한 예술을(즉 소프트웨어를) 만들어 세상을 바꿨으면 좋겠다.

[ 저자 서문 ]

소프트웨어 아키텍처에 대한 훌륭한 책들이 이미 많이 출간됐다. 이 책들은 무엇보다 소프트웨어 아키텍처를 정의하고, 분류하고, 서술한다. 아키텍처를 표현하는 표기법을 정의하고, 그 내용에 대해 의견을 교환한다. 그리고 오래도록 가치를 유지할 수 있는 좋은 아키텍처를 선택할 수 있도록 가이드를 제공한다. 불행히도 이런 책들은 성공적인 아키텍처를 만드는 데는 도움이 될지 모르지만, 성공하는 솔루션을 만드는 데는 도움이 되지 않는다. 성공하는 솔루션을 만들려면, 서브시스템이나 인터페이스를 뛰어넘어야 한다. ‘Front Controller’ 또는 ‘Pipe and Filters’ 같은 아키텍처 패턴을 뛰어넘어야 하고, 관계형 데이터베이스를 3차 노말 폼(third-normal-form)으로 만드는 문제를 뛰어넘어야 한다. 또한 소프트웨어 아키텍처를 뛰어넘어서 비즈니스적인 문제를 이해하고 포용하는 방향으로 나아가야 한다. 성공하는 솔루션을 만들려면 반드시 비즈니스적인 문제를 해결해야 한다.

비즈니스적인 문제의 한 예로 기술지원 문제를 들 수 있다. 피치 못하게 고객 중에는 당신의 소프트웨어 때문에 문제를 겪는 고객이 생길 수밖에 없다. 로그 파일을 운영하는 방식, 다른 시스템과 통합하는 방식, 시스템을 설정하는 방식, 시스템을 업그레이드하는 방식 등에 관해 당신이 오래전에 내린 결정들이 고객의 문제를 얼마나 잘 지원할 수 있을지를 결정짓는다. 『소프트웨어 아키텍처 2.0』은 비즈니스적인 문제와 아키텍처적인 선택 간의 관계를 논의하면서, 소프트웨어 아키텍처를 넘어 성공하는 솔루션에 도달할 수 있도록 도와줄 것이다.

이 책은 내가 저가의 단일 사용자 프로그램, 학술 연구에 사용하는 소프트웨어 시스템, 사내용 시스템의 문제를 진단하고 해결하는 유틸리티, 수백만 달러짜리 기업용 분산 플랫폼 등을 개발하던 경험으로부터 배워온 고유한 관점을 제시한다. 지금까지 나는 개인적인 기여자, 현장 관리자, 기업의 고참 경영진 등 다양한 역할을 수행해왔다. 긴 시간 동안 엔지니어링팀, 제품 마케팅과 관리팀, QA팀, 기술문서 발행팀, 그리고 1선과 2선 지원조직 등의 내부에서 일하거나, 이런 조직을 이끌며 일했으며, 여러 도시와 대륙에서 팀과 프로젝트를 관리했다.

모든 소프트웨어를 함께 묶는 공통 분모는 그것이 어떤 사람에게 가치를 제공하기 위해 만들어졌다는 점이다. 예를 들어, 연구용 소프트웨어는 어떤 현상을 이해하고자 하는 연구원의 필요를 위해 봉사한다. 고객관리에서부터 공급체인 관리에 이르기까지 모든 것을 다루는 기업용 애플리케이션 소프트웨어는 잘 정의된 일군의 기업 사용자들의 필요를 위해 봉사한다. 기업용 애플리케이션 소프트웨어는 라이선스를 통해 지속적으로 이익을 내려는 사업적 목적으로도 사용된다. 게임에서부터 개인용 연락처 관리 프로그램, 재고관리 시스템, 그래픽 디자인 도구에 이르기까지 모든 종류의 소프트웨어에 대해서도 비슷한 설명을 적용할 수 있다.

이 책에서 밝히고 논의하는 문제들은 모든 종류의 시스템에 적용된다. 그중에서도 특히 기업용 애플리케이션 소프트웨어를 중심으로 논의한다. 기업용 애플리케이션은 내가 오랜 시간 경력을 쌓아온 분야다. 범용적으로 통용되는 정의가 존재하지는 않지만, 기업용 애플리케이션이란 일반적으로 다음 특성 중 한두 가지를 만족시키는 애플리케이션을 말한다.

● 비즈니스적 필요를 지원하기 위해 설계됐다. 그리고 소규모 부서나 거대 조직에서 사용된다.
● 구축과 라이선스 비용이 많이 든다($50,000~$5,000,000 또는 그 이상).
● 복잡한 배치와 운영을 필요로 한다.
● 독립적으로 운영된다. 하지만 다른 기업용 애플리케이션과 통합될 때 비즈니스 목표를 더 잘 달성할 수 있다.

당신이 만드는 애플리케이션이 기업용이 아니더라도, 이 책은 유용할 것이다. 지속적인 가치를 유지하는 소프트웨어 솔루션을 만들고, 오랜 시간 동안 여러 번의 출시를 통해 고객의 필요를 만족시키는 일은 도전적이고, 즐겁고, 보상받을 만한 노력이다. 이것은 분명 기업용 애플리케이션 영역에만 한정된 이야기가 아니다!

이 책에서 소프트웨어 아키텍처를 언급하고 기술적인 문제를 논의하긴 하지만, 다이어그램을 완성하는 방법, 아키텍처를 문서화하는 방법, 안정적이고 분산된 웹 기반 컴포넌트 시스템을 디자인하는 방법 등에 논의를 집중하지는 않을 것이다. 이전에 말한 바와 같이, 이런 주제를 다루는 책은 시중에 많이 나와 있다. 사실 너무 많다. 그래서 많은 사람이 기술적인 세부사항에 그토록 집중함으로써 원래 제공하려 했던 비즈니스적 가치에 대한 시선을 잃게 만든다. 이것은 불행한 부작용이다.

순전히 기술적인 선택에 집중하지 않는 대신, 광범위한 영역에서 개발팀이 반드시 내려야 하는 실용적이고, 실무적인 선택에 집중한다. 그래서 성공하는 솔루션을 만들고 유지하는 데 진정한 도움을 준다. 나는 어떻게 출시본을 도출해야 하는지, 또는 어떻게 솔루션에 브랜드 요소를 통합시켜야 하는지 같은 실용적인 문제에 집중함으로써, 인위적인 장벽을 제거할 수 있다는 사실을 발견했다. 인위적인 장벽이란 함께 일하는 개발 분야의 사람들, 그리고 비즈니스와 마케팅 분야의 사람들 사이에 존재하는 장벽을 말한다.

이런 장벽이 양쪽 그룹 사람들이 성공하는 솔루션을 만드는 것을 가로막는다. 나는 엔지니어들이 비즈니스 문제에 대한 당연한 고려 없이 학구적인 기술에만 집중할 때 긴장한다. 또한 마케팅 사람들이 기반 기술 부산물에 대한 당연한 고려 없이 “이 기능을 만들어줘”라고 요구할 때도 마찬가지다. 양쪽 사람들이 그 영향에 대한 당연한 고려 없이 자기 주장을 하면, 성공하는 솔루션을 만들고 유지할 수 있는 가능성이 극적으로 낮아진다.

특히 문제가 되는 것이 있다. 이런 논쟁이, 기술 문제는 어떻게든 비즈니스 문제로부터 분리될 수 있다는 생각에서, 또는 비즈니스 문제는 어떻게든 기술 문제로부터 분리될 수 있다는 생각에서 만들어지는 것처럼 보인다는 점이다. 좋게 생각해도 이것은 틀린 생각이다. 나쁘게 생각하면 이것은 재앙을 낳는 처방이다. 개발자는 일상적으로 극한의 설계를 강요 받는다. 예를 들어 전체 시스템 비용을 낮추기 위한, 작은 메모리 풋프린트(footprint) 같은 요구다. 모든 회사가 이미 존재하는 시장에서 경쟁을 시작한다. 투자자들은 기술 혁신이 성공을 위해 필요한 경쟁우위를 제공할 것이라고 확신하기 때문이다. 당연하게도 투자자들은 기술 혁신이 고객에게 제공하는 비즈니스 모델에서의 혁신을 동반할 때보다 적극적으로 투자한다.

기술과 비즈니스 사이의 상호관계를 관리하는 것이 이 책에서 반복하는 주제다. 기술만 다룰 경우 당신은 흥미로운 기술, 또는 그저 우아한 시스템을 보유하게 될 것이다. 하지만 곧 시들고 만다. 아무도 사용하지 않을 것이기 때문이다. 비즈니스만 다룰 경우 많은 사람이 환호하는 페이퍼 솔루션을 가질 수 있다. 아마 투자도 유치할 수 있을 것이다. 하지만 서류로만 존재하는 솔루션일 뿐 지속적인 가치를 전달할 수 없다. 두 가지를 모두 다뤄야 성공하는 솔루션을 가질 수 있다. 새로운 기술이나 우아한 솔루션을 만드는 일은 재미있다. 그리고 복잡한 새로운 소프트웨어 애플리케이션이나 비즈니스 모델을 설계하는 것은 흥분되는 일이다. 이 두 가지 감정과 비견할 수 있는 깊은 만족감이 성공하는 솔루션을 만들고 유지하는 데에서부터 비롯된다.


[ 저자 소개 ]

루크 호만
독립 컨설턴트로서 고객들에게 제품 관리, 소프트웨어 개발, 조직 활성화 분야에 관한 매우 효과적인 코칭을 제공해왔다. 여러 회사에서 제품개발, 제품 마케팅/관리, 품질보증, 고객지원, 사업기획 업무를 수행하고 이끌어왔으며, $50 미만의 개인용 프로그램부터 수백만 달러의 기업용 분산 소프트웨어 플랫폼에 이르기까지 다양한 소프트웨어를 개발해왔다. 『이노베이션 게임』(에이콘출판, 2008)의 저자로서, 소프트웨어 개발에 관한 수많은 기사도 기고하고 있다.


[ 옮긴이의 말 ]

내가 처음 컴퓨터를 접했을 당시에는 컴퓨터로 할 수 있는 가장 재미있는 놀이가 프로그래밍이었다. 당시에 컴퓨터를 접한 대부분의 사람처럼 나도 조그만 코드를 만들고 그것이 동작하는 것을 보며 즐거워했다. 컴퓨터에 관한 최신 소식과 기술은 언제나 흥미진진한 관심거리였다. 그리고 당시에는 새로운 프로그래밍 언어를 습득하는 것이 새로운 소프트웨어 개발 기술을 습득하는 지름길이었다. 베이직에서 파스칼로, 파스칼에서 C로, 또 C++를 비롯한 객체 지향 언어로, 수많은 언어가 명멸했다. 소프트웨어 개발을 직업으로 삼아 15년 가까이 일하면서 나름의 경험을 축적했다. 지금 와서 생각해보면 프로그래밍 언어는 소프트웨어를 만드는 도구일 뿐, 그 자체로는 큰 의미가 없다. 필요에 따라 그리고 상황에 따라 선택하는 도구는 본질이 아니기 때문이다. 경험이 많은 개발자는 누구나 유행을 타는 도구보다는 쉽게 변하지 않는 본질에 관심을 둔다. 그래서 소프트웨어 아키텍처에 관심을 갖는다. UML 다이어그램과 디자인 패턴을 응용한 설계를 고민한다. 그리고 그 다음에는 무엇을 고민해야 할까?

이 책 『소프트웨어 아키텍처 2.0』은 소프트웨어 개발자가 가져야 할 궁극적인 목표를 주제로 삼고 있다. 즉 ‘성공하는 솔루션’을 만드는 것이다. 성공하는 솔루션은 아키텍처적으로 아름다운 솔루션을 말하지 않는다. 성공하는 솔루션은 사용자가 원하는 기능을 충분히 제공하는 솔루션을 말한다. 성공하는 솔루션은 시장에서 수익을 내는 솔루션을 말한다. 이 책은 UML 다이어그램을 멋지게 그리는 방법이나, 디자인 패턴을 멋지게 적용하는 방법, 코드를 멋지게 작성하는 방법 등을 설명하지 않는다. 그 대신 시장의 흐름을 읽는 방법, 마케팅 부서와 개발 부서 사이의 작업을 조율하는 방법, 시장에 솔루션을 내놓을 때 필요한 비즈니스 모델과 라이선스 모델을 계획하는 방법 등을 설명한다. 이 책은 마케팅을 이해해야 하는 개발부서 사람들과 개발을 이해해야 하는 마케팅 부서 사람들이 읽어야 한다. 양쪽 진영 사람들 모두에게 실전에 임할 수 있는 충분한 교양을 전해줄 것이다.

이 책의 주제는 ‘성공하는 솔루션’이다. 영어 원서에는 ‘winning solution’이라고 표현되어 있다. 이 용어를 ‘대박 솔루션’이라고 번역하고 싶었다. 강렬한 어감이 끌리기는 했지만, 고차원적 종합예술인 소프트웨어 개발을 너무 생생한 시장경제적 차원으로 끌어내리는 것 같은 걱정이 들었다. 그래서 ‘성공하는 솔루션’이라는 서술적인 번역을 선택했다. 이 책은 마케팅 아키텍트(마키텍트)의 역할을 강조하고 있다. 마키텍트는 개발팀, 영업팀, 기획팀을 총괄하면서 제품을 성공시키고자 노력하는 사람이다. 마키텍트는 개발자 출신의 관리자일 수도 있고, 영업이나 기획 출신의 관리자일 수도 있다. 본질적으로 마키텍트는 시장과 기술을 모두 이해하는 종합예술인이다. 저자는 개발자이고, 그래서 개발자가 대접받는 환경을 강렬하게 원한다. 이 책은 시장에서 성공하지 못하는 솔루션은 제아무리 기술적인 도달 수준이 높다 하더라도, ‘성공하는 솔루션’이 아니라고 정의한다. 그래서 개발자에게 시장에 대한 관심을 촉구한다. 개발자가 대접받는 환경도 궁극적으로는 개발팀과 영업팀과 기획팀이 합심해서 성공하는 솔루션을 많이 만들어야 이룰 수 있다고 생각한다. 대한민국에 성공 솔루션과 서비스가 많이 나오기를 기원한다.


[ 옮긴이 소개 ]

김인기
C/C++ 프로그래머로서, 10년 넘는 시간 동안 임베디드 기반 펌웨어부터 서버 사이드 컴포넌트까지 방대한 경험을 축적했다. 현재는 이노에이스에서 새로운 모바일 솔루션을 기획하고 있다. 그동안은 군더더기 없이 간결한 시스템을 설계하고 구현하고자 노력했으며, 지금은 사람에 대해 고민하고 있다. 어떻게 하면 세상을 편하게 할 제품을 만들고, 또한 그런 제품을 만드는 개발자를 편하게 만들 수 있을지를 늘 고민한다.

목차

• 1장 소프트웨어 아키텍처
  • 소프트웨어 아키텍처의 정의
  • 소프트웨어 아키텍처를 보는 또 다른 관점
    • 서브시스템은 의존성을 관리할 수 있도록 디자인한다
    • 서브시스템은 인간적인 동기와 욕구를 충족시킬 수 있도록 디자인한다
    • 훌륭한 아키텍처에 승복하라
    • 아름다움은 그것을 추구하는 사람의 눈 안에 있다!
  • 소프트웨어 아키텍처가 중요한 이유
    • 수명
    • 안정성
    • 수정 작업의 난이도와 성격
    • 수익성
    • 사회적 구조
    • 영역 결정
    • 지속 가능한, 우월한 경쟁력
  • 아키텍처 만들기
  • 패턴과 아키텍처
  • 아키텍처의 발전과 성숙: 기능과 수용력
  • 아키텍처에 대한 관심과 육성
    • 기술적 자산
    • 기술적 부채
    • 알고 있는 버그
    • 라이선스 협약 준수
  • 제1, 제2, 제3의 원칙
    • 캡슐화
    • 인터페이스
    • 느슨한 연결
    • 적절한 규모
    • 높은 응집력
    • 매개변수
    • 지연
  • 아키텍처의 이해
  • 팀
    
• 2장 제품개발 첫걸음
  • 제품관리의 정의
  • 제품관리의 중요성
  • 제품개발 프로세스: 릴리즈 1.0 만들기
    • 개념제안서
    • 제품제안서/사업계획서
    • 개발계획서
    • 개발
    • 최종 품질보증QA
    • 출시준비
    • 출시
  • 오해하지 말자
    • 폭포수 프로세스를 닮았다. 그런데 폭포수 프로세스는 효과적이지 않다
    • 모든 단계가 동등하게 중요한 것처럼 소개하고 있다
    • 시간을 상술하지 않고 있다
    • 어떻게 반복하나?
    • 개발 프로세스를 정하지 않고 있다
    • 진행 단계별로 관련된 그룹 사이의 협업 수준을 명시하지 않고 있다
  • 사업계획서
  • 제품개발 프로세스: 릴리즈 버전 n.n.n 만들기
  • 제품개발 프로세스의 확장
    • 지속적인 마감
    • 변화관리 프로토콜
    • 재활용 상자
  • 주요 제품관리 개념
    • 마케팅의 4P
    • 총 유효 시장, 총 접근가능 시장, 시장 세그먼트
    • S자 제품 채택 곡선
    • 완전제품
    • 기술 우월성과 시장 우월성
    • 포지션과 포지셔닝
    • 브랜드
    • 메인 메시지
      
• 3장 마키텍처와 타키텍처의 차이점
  • 누가 무엇을 책임지는가?
  • 솔루션 개발 초기에 영향을 주는 요인
  • 미래를 보는 안목으로 현실에서 성과 만들기
  • 미래 계획하기
  • 피드백 이용하기
  • 분명하게 만들기
  • 협력하며 일하기
    • 합의에 이르기
    • 데이터 공유하기
  • 컨텍스트 다이어그램과 타깃 제품
    
• 4장 비즈니스 모델과 라이선스 모델의 공생
  • 일반적인 소프트웨어 비즈니스 모델
    • 접근이나 이용기간 제한
    • 트랜잭션
    • 미터링
    • 하드웨어
    • 서비스
    • 매출증가/비용절감
  • 비즈니스 모델과 연관된 권리
  • 비즈니스 모델을 위한 타키텍처의 지원
    • 일반적인 문제
    • 접근이나 이용기간 제한
    • 트랜잭션
    • 미터링
    • 하드웨어
  • 라이선스 모델 강제하기
    • 명예 시스템
    • 직접 만든 라이선스 관리자
    • 서드파티 또는 전문 라이선스 관리자
    • 클라이언트
  • 시장의 성숙도가 비즈니스 모델에 미치는 영향
    • 비즈니스 모델 선택
      
• 5장 기술 도입
  • 라이선스 도입의 위험/보상
  • 계약서―액션(행동지침)이 있는 곳
    • 계약서의 기초
    • 라이선스 약정
  • 비즈니스 모델이 충돌하면, 협상을 해야 한다
  • 라이선스 협정서 존중
  • 라이선스 도입한 기술 관리
  • 오픈 소스 라이선스 도입
  • 라이선스 비용
  • 라이선스 도입의 경제학
    
• 6장 이식성
  • 알려진 이식성의 장점
  • 이식성에 관한 제안
  • 이식 가능한 애플리케이션 만들기
    • 인터프리터 언어를 사용하라
    • 표준에 기반한 영구 스토리지를 사용하라
    • 비즈니스 로직을 이식 가능하게 만들라
    • 사용자에게 가까울수록 이식성이 떨어진다
    • 표준화되고 공동 사용 가능한 서브시스템 간의 통신에는 XML을 사용하라
    • 이식성이란 명목으로 특정 플랫폼에 한정적인 우수한 기능을 감추지 마라
  • 난이도 도표
    • 1단계: 실행환경 지우기
    • 2단계: 실행환경 정렬하기
    • 3단계: 최종본 만들기
  • 조심해서 약속하라
    
• 7장 배치 아키텍처
  • 배치 방식
    • 고객 사이트 방식
    • ASP 방식
    • MSP 방식
    • 트랜잭션 방식(웹 서비스)
  • 고객이 배치 아키텍처에 미치는 영향
    • 통제와 통합
    • 데이터 보안/프라이버시와 최고 부하
    • 비용과 업체에 대한 신뢰
    • 고객의 역량과 경험 그리고 지리적 분포
  • 회사가 배치 아키텍처에 미치는 영향
    • 세일즈 사이클
    • 인프라에 대한 투자
    • 현금 흐름
    • 유연성
    • 지리적 분포
    • 가격이 아닌, 서비스
  • 소프트웨어 배치 아키텍처의 선택
  • 배치 아키텍처와 작업 배분
  • 정보기기
  • 배포 방식이 소프트웨어 아키텍처에 미치는 영향
    • 유연한, 파라미터에 의한 통합 옵션, 또는 통합 옵션이 없는 경우
    • 업그레이드 정책
    • 데이터 보호와 접근
    • 이전 옵션
  • 소비자 소프트웨어의 미래
    
• 8장 통합과 확장
  • 사용자의 지배력―주도하는 힘
    • 통합/확장의 이유
  • 계층적인 비즈니스 아키텍처: 논리적인 구조
    • 사용자 인터페이스 계층
    • 서비스 계층
    • 도메인 모델 계층
    • 퍼시스턴트 데이터 계층
    • 주제에 의한 변주
  • 계층적인 비즈니스 아키텍처 만들기
  • 비즈니스 로직 계층에서의 통합과 확장
    • 기술, 그리고 제어권의 소재
    • API를 통한 통합
    • 등록을 통한 확장
  • 퍼시스턴트 데이터의 통합과 확장
    • 뷰
    • 사용자 필드
    • 후크 테이블
    • 스프레드시트 피벗 테이블
    • 추출, 변환, 로드 스크립트
    • 고객에게 현실을 공개하라
  • 비즈니스 파생물
    • 전문가 서비스
    • 교육 프로그램
    • 자격증
    • 사용자 커뮤니티
    • 라이선스 협약
  • 여러 출시에 걸쳐 API를 관리하기
    • API 관리 테크닉
      
• 9장 브랜드와 브랜드 요소
  • 브랜드 요소
    • 브랜드 네임
    • 그래픽, 슬로건, 기타 브랜드 요소
    • 언제 트레이드마크(™) 심볼을 사용하나
  • 라이선스 도입한 브랜드의 관리
  • 브랜드 요소 수정 및 맞춤
  • 브랜드 요소 바꾸기
    • 변경해야 할 제품 영역
    • QA와 변경
      
• 10장 사용성
  • 사용성은 돈에 관한 문제다
  • 멘탈 모델, 메타포 그리고 사용성
  • 타키텍처가 사용자 인터페이스 디자인에 미치는 영향
    • 영향을 미치는 범위
  • 속도에 대한 욕구
    • 우리가 이야기할 것을 분명하게 정하자
    • 마키텍트가 진정으로 원하는 것
    • 사용자에게 응답하기
    • 성능 그리고 타키텍처의 효과
      
• 11장 설치
  • OOBE
  • 아야! 그건 아프다고
    • 고객의 공포
  • 설치와 아키텍처
    • 원인과 선택
  • 설치 방법
    • 설치 관련 데이터 수집과 전제 조건 검사하기
    • 설치하기
    • 설치 이후 확인하기
  • 마지막 손길
    • 사용자는 매뉴얼을 읽지 않는다
    • 설치와 삭제를 테스트하라
      
• 12장 업그레이드
  • 설치와 비슷하다. 단지 더 나쁠 뿐이다
    • 업그레이드에 대한 공포
  • 업그레이드의 고통을 줄이는 방법
    • 고통 없는 업그레이드를 위한 선택
  • 시장 성숙도와 업그레이드
    
• 13장 설정
  • 설정용이성(사용성의 한 요소)
  • 시스템 컨텍스트
    • 컨텍스트 정보
  • 초기화와 실행
  • 값 설정하기
  • 올바른 값 설정하기
  • 설정 매개변수 결정법
    
• 14장 로그
  • 무슨 일이 일어나는지 알고 싶다
  • 충분한 데이터가 필요하다
  • 로그 포맷과 관리
    • 로그 포맷
    • 로그 관리
    • 로그 관련 표준과 라이브러리
  • 로그 데이터에 대한 후처리
  • 서비스에 대한 로그 남기기
    
• 15장 출시관리
  • 그렇다, 당신이 정말 필요로 하는 것은 이것이다
  • 기초 다지기
  • 출시본 관리
    • 당신이 출시하려는 것
    • 당신이 타깃으로 삼는 사람
    • 그들이 그것을 원하는 이유
  • 출시본 식별
    • 전체 또는 완전 출시본
    • 부분 출시본
    • 패치본
    • 변형본
  • SKU(제품번호)와 시리얼넘버(일련번호)
    • SKU 관리
    • 시리얼넘버, 등록 그리고 활성화
  • 출시관리가 타키텍처에 미치는 영향
    
• 16장 보안
  • 바이러스, 해커, 무단사용자
    • 위험 관리
    • 나쁜 것은 보지도, 말하지도 마라
  • 디지털 신원 관리
    • 권한부여(누가 무엇을 할 수 있는지 정의하기)
    • 신원확인(누구인지 확인하기)
  • 트랜잭션 보안
    • 감사가능성(행위에 대한 증명)
    • 무결성(데이터에 대한 위조와 변조 막기)
    • 기밀성(권한 없는 사람들로부터 데이터를 보호하기)
    • 책임성(사람들이 자신의 행동에 책임을 지게 만들기)
  • 소프트웨어 보안
    • 소프트웨어 보안 기술
    • 소프트웨어 보안 비용/혜택
  • 정보 보안
  • 알고리즘을 비밀로 할까, 아니면 키를 비밀로 할까?
  • 백도어
  • 보안과 마키텍처
    • 상호작용의 영역
      
• 부록 A 출시 체크리스트
  • 정보 추적
  • 엔지니어링/개발
  • 품질 보증
  • 기술문서
  • 핵심 제품관리
  • 지식 이전: 전문가 서비스
  • 지식 이전: 세일즈와 채널
  • 지식 이전: 기술지원
  • 출시 활동
    
• 부록 B 전략적인 제품관리를 위한 패턴 랭귀지
  • 패턴 적용
  • 결과 표시와 공유
  • 시장 지도
    • 내용
    • 문제
    • 요인
    • 해법
    • 결과
    • 관계된 패턴
  • 시장 이벤트/시장 리듬
    • 내용
    • 문제
    • 요인
    • 해법
    • 결과
    • 관계된 패턴
  • 기능/혜택 지도
    • 내용
    • 문제
    • 요인
    • 해법
    • 결과
    • 관계된 패턴
  • 타키텍처 로드맵
    • 내용
    • 문제
    • 요인
    • 해법
    • 결과