Chapter01. 소프트웨어 아키텍처의 설계

1. 아키텍처란?

- 비즈니스 요구 사항을 만족하는 시스템을 구축하기 위해서 전체 시스템에 대한 구조를 정의한 문서로, 시스템을 구성하는 컴포넌트와 그 컴포넌트 간의 관계, 그리고 컴포넌트가 다루는 정보(데이터)를 정의한다.

- 변화하는 Biz 전략에 대응할 수 있도록 장기적인 로드맵 수용/확장 가능

- 구현 및 사용하고자 하는 조직의 기술 수준, 규모와 형태, Biz 형태에 맞춰서 설계 되어야 한다.

resources.sei.cmu.edu/library/asset-view.cfm?assetID=513807

What Is Your Definition of Software Architecture

 

2. 아키텍처 설계 프로세스

- TOGAF(The Open Group Architecture Framework) 경량화 프로세스

www.opengroup.org/togaf

TOGAF | The Open Group Website

아키텍처 설계 프로세스

 

3. 비즈니스 아키텍처 설계

전체 기술에 관련된 팀원들이 Business 배경과 목표에 대한 이해를 바탕으로 같은 방향의 목표를 향할 수 있도록 해주며, 설계 배경 이해를 돕는다.

• 전체 서비스에 대한 요약/개여
• 시장 현황과 타 서비스와의 차별 요소
• 주요 기능 정의
• 도메인 모델 : 사용자, 서비스 컴포넌트, 권한/역할.. 개념과 그 관계를 도식화 하여 표현(ERD와 유사)
• 전체적인 시스템 구성, 전체 아키텍처
• 전체적인 로드맵과 일정

 

4. 아키텍처 설계 원칙의 정의

비즈니스 요구사항에 의해서 원칙이 세워진다. 예를들어

• 미국 정부 수준의 보안 수준을 충족해야한다.
• Public Cloud에 종속성이 없으며, On-Perm 배포 할 수 있어야 한다.
• 글로벌 서비스가 가능해야 한다.
• 모바일, PC 등 멀티 디바이스를 지원해야 한다.
• 사용자 인터페이스가 사용하기 쉬워야 한다.

5. 시스템 아키텍처 설계

(Biz 아키텍처 + 설계 원칙 + 레퍼런스)를 기본으로 설계

• 3가지 관점에서 설계
  • 애플리케이션 아키텍처 설계
    • 컴포넌트 정의(Layer or Tier)
    • 시나리오에서 동작 흐름 정의(컴포넌트간 관계 표시)
    • 컴포넌트간 통신 인터페이스 정의(프로토콜, 메시지 포맷, 메시지 교환 패턴)
  • 테크니컬
    • 배포 솔루션
    • 하드웨어
      • 네트워크 가용량, 메모리, CPU Core, HA
  • 데이터
    • 개념/논리/상세 모델링
    • 데이터 저장소
    • 애플리케이션 컴포넌트와 매핑
    • 데이터 관리 프로세스(보안, 생명 주가, 공유와 통합, 분석과 리포팅)

6. 아키텍처 결정 프로세스(Architecture Decision Process; AD)

1. [NEW] 생성됨
2. [ASSIGNED] 할당됨
3. [ESCALATED] 에스컬레이션 됨
4. [RESOLVED] 해결 됨

• AD 템플릿 항목
  • Description & Motivation
  • Assumption
  • Consideration
  • Options
  • Pros & Cons
  • Decesion
  • Implication

7. 효과적인 아키텍트의 역할과 종류

• 비즈니스(사업)의 언어를 기술적 언어로 통역 하는 소통자
• 비즈니즈 / 기술 / 자원 - 3가지 요인을 고려하여 의사 결정