아키텍처

온프레미스 환경에서 고객은 종종 다른 제품 또는 기능 팀에 대한 중첩되는 역할을 통해 모범 사례를 따르는지를 확인하는 기술 아키텍처에 대한 중앙 집중형 팀을 보유하고 있습니다. 기술 아키텍처 팀은 종종 테크니컬 아키텍트(인프라), 솔루션즈 아키텍트(소프트웨어), 데이터 아키텍트, 네트워킹 아키텍트 및 보안 아키텍트와 같은 일련의 역할로 구성됩니다. 이러한 팀에서는 대개 TOGAF 또는 Zachman Framework를 엔터프라이즈 아키텍처 기능의 일부로 사용합니다.

AWS는 해당 기능을 갖춘 중앙 집중형 팀을 보유하는 대신, 팀에 기능을 배포하는 것을 선호합니다. 팀 내 표준 충족 확인에 대한 감사 등을 할 때 의사결정 권한을 분산한다면 위험이 있습니다. AWS는 두 가지 방법으로 이러한 위험을 완화합니다. 첫째로, 각 팀이 해당 역량을 갖추는 방법을 중점적으로 설명하는 사례« [ 작업 수행 방식, 프로세스, 표준 및 용인된 규범 ] »  을 도입하고, 팀이 충족해야 하는 표준에 대한 기준을 높일 수 있는 전문가를 배치합니다. 둘째로, 해당 사례를 실제로 적용하기 위한 메커니즘을 구현합니다. « 의도가 좋다고 효과도 좋은 것은 아닙니다. 무언가를 해내려면 좋은 메커니즘이 필요합니다 Jeff Bezos. 즉, 사람이 다할 수 있는 최선의 노력을 규칙이나 프로세스 준수 여부를 확인하는 메커니즘(자동화된 메커니즘인 경우가 많음)으로 대체하는 것입니다. ] »  표준 충족 여부를 확인하는 자동화된 검사를 수행합니다. 이러한 분산된 접근 방식은 Amazon 리더십 원칙을 통해 뒷받침되며 Working backward을 수행하는 모든 역할에서 문화를 만듭니다. « [ Working backward는 아마존 혁신 프로세스의 기본 요소입니다. AWS는 고객 및 고객이 원하는 대상부터 시작하며, 자체 작업을 정의하고 안내합니다. ] »  문화를 수립합니다. 고객 중심의 팀은 고객의 요구 사항에 대응하여 제품을 개발합니다.

아키텍처 측면에서, 이는 모든 팀이 아키텍처를 생성하고 모범 사례를 따르는 기능을 갖추고 있음을 의미합니다. AWS는 새로운 팀이 이러한 기능을 확보하거나 기존 팀이 기준을 높이도록 돕기 위해, 설계를 검토하고 AWS 모범 사례가 무엇인지 이해하는 데 도움을 주는 책임 엔지니어의 가상 커뮤니티에 액세스할 수 있도록 권한을 활성화합니다. 주요 엔지니어링 커뮤니티는 모범 사례를 가시화하고 쉽게 액세스할 수 있도록 최선을 다합니다. 예를 들어 모범 사례를 실제 사례에 적용하는 데 중점을 둔 간략한 회의를 통해 이를 수행합니다. 이러한 회의 내용을 기록하여 새 팀원을 위한 온보딩 자료의 일부로 사용할 수 있습니다.

AWS의 모범 사례는 수천 개의 시스템을 인터넷 규모로 운영한 경험에서 비롯된 것입니다. AWS는 데이터를 사용하여 모범 사례를 정의하는 것을 선호하지만, 수석 엔지니어와 같은 주제 전문가를 활용하여 설정하기도 합니다. 수석 엔지니어가 새로운 모범 사례를 확인하게 되면 커뮤니티로 활동하여 팀이 이를 따를 수 있도록 안내합니다. 시간이 지나면서 이러한 모범 사례는 내부 검토 절차 및 규정 준수를 시행하는 메커니즘으로 공식화됩니다. Well-Architected는 내부 검토 프로세스를 고객 중심으로 구현한 결과이며, 주요 현장에서 활동하는 솔루션 아키텍처 및 내부 엔지니어링 팀에서 엔지니어링 사고를 체계화한 것입니다. Well-Architected는 이러한 결과를 활용할 수 있는 확장 가능한 메커니즘입니다.

아키텍처의 분산된 소유권을 가진 주요 엔지니어링 커뮤니티의 접근 방식에 따라, AWS는 고객 요구 사항을 중심으로 하는 Well-Architected 엔터프라이즈 아키텍처가 실현될 수 있다고 믿습니다. 모든 워크로드 전반에 걸쳐 Well-Architected 검토 방식을 수행하는 기술 리더(CTO 또는 개발 관리자)는 기술 포트폴리오의 위험을 더 효과적으로 이해할 수 있습니다. 이 접근 방식을 사용하면 책임 엔지니어가 특정 영역에 대한 사고 방식을 여러 팀과 공유할 수 있는 메커니즘, 교육 또는 간략한 회의를 통해 조직에서 해결 가능한 전반적인 주제를 식별할 수 있습니다.