1. 4. 비즈니스 모델과 라이센스 모델의 공생
   1. 비즈니스모델
      1. 정의: 제품이나 서비스를 이용하는 고객에게 과금하는 방식
   2. 라이센스 모델
      1. 약정과 이용조건(또는 권리와 제약조건)으로 구성
   3. 일반적인 소프트웨어 비즈니스 모델
      1. 간략 정의
         1. 1. 약속된 기간 동안 애플리케이션에 접근 하거나 사용할 수 있게 허용
         2. 2. 애플리케이션을 이용함으로써 얻은 매출이나 절약한 비용에 대해 일정 비율을 과금
         3. 3. 사용한 트랜잭션에 과금
         4. 4. 애플리케이션이나 애플리세이션이 처리하는 서비스에 접근하거나 사용하는 것을 미터링
         5. 5. 애플리케이션이 실행되는 하드웨어 또는 애플리케이션과 밀접한 관계가 있는 하드웨어에 과금
         6. 6. 애플리케이션의 작업/사용과 밀접한 관계가 있는 서비스를 1개 이상 제공
      2. 접근이나 이용기간 제한
         1. 영구 라이센스
         2. 연간 라이센스
         3. 임대 라이센스
         4. 가입 라이센스
         5. 사용 후 지불
         6. 사용자별 라이센스 (per-user license)
            1. 볼륭 라이센스 정책 (volume license)
            2. 트랜잭션 볼륨 라이센스 정책 (transactional volume license)
            3. 컨트랙트 볼륨 라이센스 정책 (contractual volume license)
         7. OEM
      3. 트랜잭션
      4. 미터링
         1. 동시자원 관리 (concurrent resource management)
         2. 식별자원 관리 (identified resource management)
         3. 소비자원 관리 (consumptive resource management)
      5. 하드웨어
      6. 서비스
      7. 매출증가/비용절감
   4. 비즈니스 모델과 연관된 권리
   5. 비즈니스 모델을 위한 타키텍처의 지원
      1. 일반적인 문제
         1. 필요한 데이터 수집하기
         2. 보고/결제 관련 요구사항 정하기
         3. 비즈니스 모델 집행하기
         4. 지표 개선에 노력을 집중하기
         5. 매출증가 또는 비용감소를 유도하기
         6. 불법복제/무단사용 방지하기
         7. 비즈니스 모델과 라이선스 모델의 매개변수 검증하기
      2. 트랜잭션
         1. 트랜잭션 정의하기
         2. 트랜잭션과 비즈니스 모델 사이의 관계 정의하기
         3. 추적감사 자료 보관하기
         4. 트랜잭션이 고유하게 식별되도록 보장하기
         5. 트랜잭션의 상태, 라이프사이클, 존속기간 이해하기
      3. 미터링
         1. 사용자를 어떻게 인증하는가?
         2. 사용자가 얼마나 많은가?
         3. 동시 사용자 수를 어떻게 셀 것인가?
         4. 사용자가 떠난 것인가? 움직이는 것인가?
      4. 하드웨어
   6. 라이센스 모델 강제하기 (제공자 입장에서의 라이센스 관리?)
      1. "강제한다" - 라이센스 관리자가 라이센스가 파기됐다고 판단했을 때 애플리케이션의 일부 또는 전부를 멈추는 것
      2. 명예 시스템
      3. 직접 만든 라이센스 관리자
      4. 서드파티 또는 전문 라이선스 관리자
         1. 라이센스 생성기 (license generator)
         2. 클라이언트 또는 로컬 라이센스 관리자 (local license management)
         3. 서버 또는 리모트 라이센스 관리자 (remote license manager)
      5. 비즈니스 모델 지원
      6. 플랫폼과 운영체제 지원
      7. 솔루션의 강력함을 확인하기 위해 크래커 사이트를 체크하라
      8. 백엔드 통합 용이성과 처리용량을 체크하라
      9. 운영 환경이 당신에게 적합한지 확인하라
      10. 브랜딩과 사용자 인터페이스를 바꿀 수 있는지 체크하라
      11. 라이센스의 내용과 형식을 검토하라
      12. 라이센스 배포 기능을 검토하라
   7. 시장의 성숙도가 비즈니스 모델에 미치는 영향
      1. 비즈니스 모델 선택
2. 3. 마키텍처와 타키텍처의 차이점
   1. 마키텍트와 아키텍트의 책임
      1. 마키텍처 (Marketecture)
         1. 마케팅 아키텍처 (Marketing architecture)
         2. 대상: 제품 마케팅 관리자, 비즈니스 관리자, 시스템을 책임지는 프로그램 관리자
         3. 의미: 비즈니스적인 관점에서 바라본 시스템 아키텍처
         4. 문서: 라이선스 모델, 판매 모델, 가치제안(Value proposition), 기술 세부사항, 데이터 시트, 경쟁 우위 요소, 브랜드 요소, 멘탈 모델(mental model), 사업 목표
         5. = 완정제품(whole product)
      2. 타키텍처 (Tarchitecture)
         1. 테크니컬 아키텍처 (Technical architecture)
         2. 대상: 소프트웨어 아키텍트, 최고 기술자
         3. 의미: 개발자가 시스템의 아키텍처를 생각할 때 사용하는 생각의 틀
         4. 문서: 클라이언트/서버, 파이프라인, 임베디드 시스템, 블랙보드(blackboard) 패턴
   2. 솔루션 개발 초기에 영향을 주는 요인
      1. 문제영역(problem domain)
         1. 의미: 고유한 규칙, 명명법, 철차, 워크플로어
         2. 마키텍트와 타키텍트가 갖춰야 할 중요한 전제조건
         3. 예> 신용카드 트랜잭션 처리, 자동차의 파워시스템, 재고관리 업무
      2. 지표(ilities)
         1. 의미: 아키텍처의 결과로 얻어지는다양한 품질속성과 제품속성
            1. 품질속성
            2. 시스템이 동작중일 때 관찰을 통해 알아낼 수 있는 것
            3. 성능, 사용 편의성
            4. 타깃 고객으로부터 직접 피드백을 받음
            5. 제품속성
            6. 시스템이 동작중일 때 관찰을 통해 알아낼 수 없는 것
            7. 테스트 편의성, 수정 용이성
            8. 타깃 고객과의 미래 관계에 영향을 주는 2차적인 속성
         2. 관리: 버그의 심각성, 우선순위, 그리고 정규화
            1. 심각성: 객관적으로 검증 가능 (QA 조직과 공유가 쉽다.)
            2. 우선순위: 기준이 주관적
         3. 품질 기준
            1. MUST
            2. SHOULD
            3. MAY
      3. 기술기반(technology base)
         1. 개발팀이 사용하는모든 종류의 기술을 포함
         2. EX> 렝기쥐, 컴파일러, 데이터베이스, 미들웨어, 메시징 시스템, 대표 타키텍처(uber-tarchitecture)
            1. 대표 타키텍처(uber-tarchitecture)
            2. 애플리케이션에서 사용되는 많은 클래스 사이의 기본적인 구조를 미리 정의해놓은 테크니컬 아키텍처
            3. 잘 정의된 일련의 개발도구와 함께 제공
   3. 미래를 보는 안목으로 현실에서 성과 만들기
      1. 마키텍트의 미래 지향적 관점
         1. 현재 출시된 버과 차기 출시 버전은 과거의 시점으로 바라봄
         2. 고객이 스스로 원하는 바를 정리하지 못하는 경우에도 고객을 대신해서 미래를 계획할 수 있는 능력
      2. 타키텍트의 미래 지향적 관점
         1. 여러 갈래의 데이터를 근거로 고객에게 우월한 가치를 제공할 수 있는 기술적 미래를 추론
   4. 미래 계획하기
      1. Map
         1. 시장 지도(market map)
         2. 기능/혜택 지도(feature/benefits map)
         3. 시장 이벤트와 리듬 지도(market events and rhythms map)
         4. 타키텍처 지도(tarchitecture map)
   5. 피드백 이용하기
      1. 피드백 수집
         1. 공식적인 방법
         2. 비공식적인 방법
         3. 외부적인 방법
         4. 내부적인 방법
      2. 타키텍트와 아키텍드는 모든 데이터를 공유한다.
   6. 분명하게 만들기
      1. 마키텍트 제공
         1. 프로토타입, 마케팅 요구사항 문서(marketing requirement document)
      2. 타키텍트 제공
         1. UML, ER 모델(entity relation model), 데이터 흐름도(dataflow diagram)
   7. 협력하며 일하기
      1. 마키텍트 관점
         1. 문제: 개발팀이 만든 시스템 수용력의 진면목을 일상적으로 과소평가하거나 이해하지 못함 고객의 이익을 위해 개발 도구를 활용하는 마케팅 능력 충족
      2. 타키텍트 관점
         1. 타키텍트의 창조적 에너지는 반사적으로 진짜 고객의 진짜 문제를 지향한다 마키텍트에게 그러한 부분을 충족
      3. 합의에 이르기
         1. 프로젝트 관리 원칙과 그에 따른 실행지침에 대한 합의가 프로젝트를 이끈다.
      4. 데이터 공유하기
         1. 각종 지도와 제품 기능에 대한 공개가 매우 중요하다.
         2. 기능: 마키텍트와 타키텍트의 협력을 확보할 수 있는 강력한 도구
   8. 컨텍스트 다이어그램과 타깃 제품
      1. 컨텍스트 다이어그램
         1. 고객이 사용하는 기술을 식별
         2. 잠재적인 협력관계와 시장의 시너지 식별
         3. 가치제안(value proposition)을 분명하게 만듬
         4. 기반 아키텍처의 통합 옵션과 확장 옵션을 식별
         5. 배치(deployment)옵션과 타깃 플랫폼 옵션 선택