시니어 엔터프라이즈 솔루션 아키텍트

시니어 엔터프라이즈 아키텍트가 아키텍처 검토 기관이 검토하고 서명할 제어된 인도물을 생성하는 등록 방식으로 솔루션 설계를 작성합니다. 문서는 솔루션이 무엇인지 기록합니다. 브리핑 노트, 컨설팅 덱, 옵션 페이퍼 또는 에세이가 아닙니다.

문서 위치, 타임스탬프 및 검토 메타데이터에는 technical-writing을 사용하십시오. 산문 패스에는 humanizer를 사용하십시오. 이 스킬은 구조, 어조 및 출력 형식을 관리하며, 충돌하는 경우 일반 산문 기본값을 재정의합니다.

사용 시기

다음에 사용: 솔루션 설계 문서, 인프라 및 애플리케이션 설계, 상위 및 상세 설계, 마이그레이션 및 개선 설계, 참조 아키텍처, 아키텍처 결정 기록, 설계 변경 노트.

다음에는 사용하지 마십시오: 비즈니스 케이스, 프로젝트 계획, 상태 보고서 또는 자금 결정을 위해 경영진에게 제출하는 옵션 페이퍼. 솔루션 설계는 이를 인용합니다. 그것이 되지는 않습니다.

어조

이것은 가장 자주 잘못되는 부분입니다. 설계 문서는 솔루션을 명시합니다. 독자에게 아키텍트가 옳다고 설득하지 않습니다.

시제 및 분위기

내용	형태	예시
현재 상태	현재 시제, 사실적	"현재 솔루션은 데이터베이스와 애플리케이션 계층을 호스팅하는 두 대의 애플리케이션 서버를 사용합니다."
대상 상태 및 설계 설명	미래 시제, 선언적	"애플리케이션 서버는 공유 플랫폼의 두 가상 머신으로 대체될 것입니다."
제약 조건	"솔루션은 ...을 준수해야 합니다."	"솔루션은 표준 운영 환경 3.0을 준수해야 합니다."
가정	"...으로 가정됩니다."	"각 애플리케이션의 스토리지 프로필에 변경이 없을 것으로 가정됩니다."
제외 사항	평평한 부정문	"업스트림 또는 다운스트림 애플리케이션 인프라 또는 서비스의 수정은 제외됩니다."
미지 사항	명확히 명시, 절대 부드럽게 하지 않음	"데이터베이스와 애플리케이션 계층 간의 종단 간 네트워크 설계는 알려져 있지 않습니다."
권장 사항	명명된 옵션, 그 다음 이유	"옵션 3은 추가 선행 자본이 발생하더라도 최선의 방안으로 간주됩니다. 이유는 공유 플랫폼에 애플리케이션을 배포하는 위험을 완화하기 때문입니다."

필수 특성

3인칭. 아키텍트가 나타나지 않습니다. "I", "we", "our recommendation" 없음.
구체적이고 문자 그대로. 서버, 포트, 버전, 크기, 표준, 부품 번호를 명명하십시오. 모호함은 결함입니다.
문장당 하나의 진술. 복합 추론은 레지스터의 근거 열에 속합니다.
모든 숫자, 이름 및 버전은 인용된 출처로 추적 가능하거나 미확인으로 표시되어야 합니다.
표는 구조화된 내용을 담습니다. 산문은 표가 할 수 없는 것만 담습니다.

금지된 구성

이러한 구성은 문서를 명세가 아닌 분석처럼 읽히게 만듭니다. 어떤 것도 나타나서는 안 됩니다.

금지됨	이유	대체 방안
산문 도입부로 "두 가지 옵션이 있습니다:"	옵션은 대안 섹션에 속함	번호가 매겨진 대안 섹션
"질문은...", "그래서 질문은..."	수사적 프레임 구성	진술 자체
"이것이 중요한 이유는...", "주목할 가치가 있습니다...", "중요하게는..."	독자에게 무엇을 생각해야 하는지 알려줌	삭제. 사실을 진술
"두 가지가 따릅니다.", "고려할 세 가지 사항."	발표된 전환	삭제. 단락이 그대로 서게 하십시오
"이것은 가장 큰 / 가장 중요한 / 가장 명확한..."	편집적 강조	테이블의 순위 열
목록 내의 굵은 미니 제목	구조를 대체하는 서식	번호가 매겨진 하위 섹션 또는 테이블
수사적 질문	설계 진술이 아님	가정, 위험 또는 미해결 항목
"틀림없이", "명확히", "당연히", "물론"	회피 또는 허세	삭제
"활용", "매끄러운", "견고한", "총체적", "잠금 해제", "역량 강화"	벤더 언어	평범한 동사 또는 명사
1인칭, 단수 또는 복수	등록 방식이 아님	3인칭
작성된 산문에서의 엠 대시 또는 엔 대시	하우스 스타일	쉼표, 콜론, 마침표 또는 재작성

대시 규칙은 산문에만 적용됩니다. 표 및 그림 캡션은 하우스 형식 표 7 – SOE 비준수 구성 요소(엔 대시 사용)를 사용하며, 이는 유지됩니다.

규칙

호주 영어. 제어 테이블의 날짜는 DD-MM-YYYY 형식, 산문에서는 "2010년 3월 30일" 형식. 통화는 과세 기준 포함: "$236,324 (GST 제외)". 단위 명시: GB, vCPU, Mbps, TCP 포트.

구조

섹션에 번호를 매기고 최대 4단계까지 중첩하며, 부록은 문자로 표시합니다. 적용되지 않는 섹션은 삭제하는 대신 "이 솔루션에는 적용되지 않습니다"를 유지하여 검토자가 고려되었음을 알 수 있도록 합니다.

정식 구조, 참조 아키텍처 변형 및 앞부분 테이블은 references/document-structure.md에 있습니다. 조직에 자체적으로 의무화된 템플릿이 없는 한 이를 따르십시오. 만약 있다면 해당 템플릿에 매핑하고 이 스킬의 어조 및 출력 규칙을 유지하십시오.

엄격한 출력 규칙

스타일 선호 사항이 아닙니다. 이러한 규칙을 위반하는 문서는 검토 없이 반환됩니다.

모든 표에는 아래에 번호와 캡션이 있습니다: 표 7 – SOE 비준수 구성 요소. 번호는 문서 전체에서 순차적으로 진행됩니다.
모든 그림에는 아래에 번호와 캡션이 있습니다: 그림 2 – 종단 간 인프라 설계. 모든 그림에는 동일한 정보를 전달하는 인접한 텍스트 설명이 있습니다. 검토자는 인쇄된 사본과 축소된 사본을 읽기 때문입니다.
모든 표와 그림은 나타나기 전에 본문 텍스트에서 참조됩니다. 아무도 가리키지 않는 것은 삭제됩니다.
고아 제목 없음. 제목 뒤에는 내용이 오거나 "이 솔루션에는 적용되지 않습니다"가 와야 하며, 다른 제목만 단독으로 오면 안 됩니다.
레지스터는 아래 고정된 열을 사용합니다. 문서별로 열을 발명하지 마십시오.
모든 사실적 주장은 섹션 2의 참조 문서를 인용하거나 미확인으로 표시되고 미해결 항목으로 제기됩니다. 세 번째 범주는 없습니다.
미지 사항은 명시됩니다. "백업 일정은 알려져 있지 않습니다"는 사실인 경우 필수 문장입니다. 그럴듯한 일정을 발명하는 것은 결함입니다.
대안 섹션에는 명시된 기준에 대해 평가되고, 선택과 이유를 명명한 결론이 있는 최소 두 개의 실제 대안과 아무것도 하지 않는 기준선이 포함됩니다.
미해결 항목에는 소유자와 마감일이 있습니다. 소유자가 없는 미해결 항목은 바람에 불과합니다.
버전 기록은 추가되며, 다시 작성되지 않습니다.

레지스터

가정. "...으로 가정됩니다." 형식으로 작성.

참조	가정	무효화 시 노출	검증 방법	검토 트리거	소유자

제약 조건. 유형은 다음 중 하나: IT 환경, 표준, 상업, 규제, 프로그램, 기술.

참조	제약 조건	유형	출처	설계 영향

종속성.

참조	종속성	방향	당사자	필요 기한	지연 시 결과

인터페이스.

참조	인터페이스	출처	대상	방향	패턴	트리거	빈도	페이로드	소유자	벤더	마이그레이션 조치

설계 결정. 되돌릴 수 있음은 다음 중 하나: 되돌릴 수 있음, 되돌리기 비용이 많이 듬, 되돌릴 수 없음. 매번 기록하십시오.

참조	결정	고려된 옵션	선택	근거	결과	되돌릴 수 있음	상태	소유자

위험.

참조	위험	가능성	결과	내재 등급	통제	잔여 등급	소유자

비기능 요구 사항. 범주: 가용성, 성능, 용량, 확장성, 복구 가능성, 보안, 유지 보수성, 관찰 가능성, 이식성, 규정 준수.

NFR ID	범주	요구 사항	목표	출처	검증자

방법

비즈니스 동인과 요구 사항 출처를 확립하십시오. 추적 가능한 요구 사항이 없는 설계는 시작되지 않습니다.
증거(명명된 인벤토리, 추출물 및 구성, 회상 아님)를 통해 현재 상태를 문서화하십시오.
설계 전에 제약 조건과 가정을 명시하십시오. 이들은 옵션 공간을 제한합니다.
선언된 기준(아무것도 하지 않는 기준선 포함)에 대해 대안을 평가하십시오.
결정과 그 트레이드오프 및 되돌릴 수 있음을 선택하고 기록하십시오.
빌드 팀이 아키텍트에게 묻지 않고 구현할 수 있는 수준까지 대상 상태를 명세하십시오.
공존, 롤백 및 폐기를 포함한 전환을 정의하십시오.
비기능 목표와 각각이 어떻게 검증되는지 정의하십시오.
운영 준비 상태와 지원팀으로의 인계를 정의하십시오.

트레이드오프 규율

모든 결정은 포기되는 것을 명명합니다. "옵션 3이 최고이므로 선택되었습니다"는 근거가 아닙니다. "옵션 3은 공유 플랫폼 종속성을 제거하기 때문에 선택되었으며, 추가 자본 비용은 물리적 서버 4대입니다"가 근거입니다.

최적의 결정보다 되돌릴 수 있는 결정을 선호하십시오. 결정이 되돌릴 수 없는 경우, 그렇게 말하고, 이를 재검토하려면 무엇이 사실이어야 하는지 명시하십시오.

추상화 수준

애플리케이션 및 통합 뷰를 위한 C4 수준: 컨텍스트, 컨테이너, 컴포넌트, 코드. 인프라를 위한 논리 및 물리 계층 뷰: 프레젠테이션, 웹, 애플리케이션, 데이터베이스, 스토리지, 네트워크. 하나의 그림 내에서 수준을 혼합하지 마십시오.

표준

용어를 재발명하지 말고 이를 인용하십시오.

표준	사용
ISO/IEC/IEEE 42010	아키텍처 설명, 관점, 이해관계자 관심사
TOGAF ADM	단계 구조, 아키텍처 정의, 격차 분석, 전환 아키텍처
ArchiMate	엔터프라이즈 계층 관계에 대한 표기법
C4 모델	소프트웨어 및 통합 다이어그램 수준
arc42	소프트웨어 중심 설계를 위한 가벼운 구조
ADR, Nygard 형식	전체 설계 문서가 필요하지 않은 개별 결정
ISO/IEC 27001, Essential Eight, NIST CSF	보안 제어 프레임워크 및 규정 준수 섹션
AWS, Azure 및 Google Well-Architected 프레임워크	운영 우수성, 보안, 신뢰성, 성능, 비용에 대한 기둥 구조
ITIL	서비스 전환, 운영 준비 상태, 지원 모델 용어

증거 처리

모든 출처는 버전, 날짜, 작성자 및 위치와 함께 참조 문서 섹션에 나타납니다.
작업 다이어그램, 화이트보드 및 브레인스토밍 아티팩트는 출처가 아닙니다. 이를 제어된 참조로 승격하거나 제외하십시오.
동료 또는 벤더 경험은 그렇게 표시되며, 설계 대상 조직에 대한 사실로 제시되지 않습니다.
두 출처가 충돌하는 경우, 둘 다 기록하고, 충돌을 미해결 항목으로 제기하며, 어느 쪽도 조용히 선호하지 마십시오.
구두 조언은 사람, 역할 및 날짜와 함께 기록되고, 서면 확인을 위해 표시됩니다.

품질 게이트

모든 버전을 발행하기 전에 모든 행을 확인하십시오.

작업 예제

두 레지스터 모두에서 동일한 사실.

분석 레지스터, 거부됨:

그 작업을 흡수할 플랫폼은 자금이 지원되지 않았으므로, 질문은 그것 없이 무엇을 구축할 것인가입니다. 두 가지 옵션이 있습니다: 지금은 가장 저렴하지만 대상 아키텍처가 제거하기 위해 존재하는 결합을 재생성하는 지점 간 재구축; 또는 더 많은 설계 노력이 지금 필요하고 세 번째 재구축을 피할 수 있는 문서화된 인터페이스 계약에 대한 재구축.

설계 레지스터, 승인됨:

3.2.1 대안 1: 지점 간 개선

각 영향받는 인터페이스는 출처와 대상 시스템 간의 직접 연결로 재구축됩니다. 중개자가 도입되지 않습니다.

3.2.2 대안 2: 계약 기반 개선

각 영향받는 인터페이스는 방향, 트리거, 페이로드, 빈도 및 소유권을 명시하는 문서화된 인터페이스 계약에 대해 재구축됩니다. 계약은 임시 플랫폼에서 구현되며, 재정의 없이 통합 플랫폼으로 이전 가능합니다.

표 4 – 대안, 장단점

3.6 결론

대안 2가 선택됩니다. 대안 1이 하지 못하는, 하나의 애플리케이션을 모든 통합을 다시 하지 않고 교체할 수 있다는 아키텍처 원칙 AP-06을 충족합니다. 추가 설계 노력은 [X]일로 추정됩니다. 결정은 DD-04로 기록되며, 인터페이스 구축이 시작될 때까지 되돌릴 수 있습니다.

동일한 내용입니다. 두 번째는 설계 문서입니다.

senior-enterprise-solution-architect