워크로드 팀과의 공동 작업
아키텍처 사양을 제공하는 작업은 일회성 작업이 아닙니다. 설계자는 구현 전반에 걸쳐 워크로드 팀과 협력할 것으로 예상해야 합니다.
연속 공동 작업
명확성을 제공합니다. 설계자는 구현 팀이 차단되지 않은 상태로 유지되도록 제공된 사양에 대한 명확성을 제공하기 위해 쉽게 사용할 수 있어야 합니다. 잠재적인 방해 문제를 해결하기 위해 설계자는 반복 계획 연습 및 팀 모임에 적극적으로 참여해야 합니다.
구현 시퀀싱 제안을 합니다. 설계자는 디자인에서 프로덕션 준비 제품으로의 여정이 반복적이라는 것을 이해합니다. 먼저 구현할 애플리케이션의 일부를 추천할 수 있습니다. 이 접근 방식을 사용하면 워크로드 팀이 해당 환경에서 학습하고 얻은 지식을 워크로드의 나머지 부분에 적용할 수 있습니다.
구현 검토 검사점을 설정합니다. 워크로드 팀은 구현과 아키텍처 사양을 비교하기 위한 정기적인 검토 검사점을 설정해야 합니다. 이 방법은 사양에 따라 디자인이 구현되고 사양이 예측 요구 사항을 충족하는지 확인하는 데 도움이 됩니다. 이 피드백 루프는 디자인 또는 구현 오류를 수정할 수 있습니다.
관련자와 통신합니다. 설계자는 이해 관계자 및 비즈니스와 긴밀한 관계를 맺고 있으며 워크로드에 대해 잘 알고 있습니다. 따라서 구현 팀의 우려 사항 또는 요구 사항 변경 협상 요청을 릴레이할 수 있는 좋은 위치에 있는 경우가 많습니다.
환경 권장 사항을 만듭니다. 워크로드 디자인은 프로덕션 및 재해 복구를 위해 설계하는 것 이상으로 확장되는 경우가 많습니다. 프로덕션은 워크로드 구현 팀이 필요로 할 수 있는 많은 환경 중 하나일 뿐입니다. 또한 설계자는 워크로드 팀이 적절한 크기의 사전 프로덕션 환경을 지원할 수 있습니다.
POC(개념 증명)를 사용합니다. 설계자는 워크로드 아키텍처에 대한 디자인 사양에 대한 결정을 알리기 위해 디자인에서 POC를 자주 사용합니다. 이러한 POC는 실제 워크로드 구현의 타당성에 대한 인사이트를 제공할 수도 있습니다. POC가 없는 경우 구현 팀이 개발을 시작하기 전에 설계자가 POC를 만들어야 합니다.
플랫폼 팀과의 공동 작업
일부 조직에서는 Azure 랜딩 존에 제안된 것과 같이 워크로드 팀과 플랫폼 팀 간에 책임을 분할합니다. 플랫폼 팀과 협력하여 솔루션과 가치를 공동 제공하는 워크로드의 경우 해당 팀과 공동 작업하는 것이 중요합니다. 플랫폼 팀과 공동 작업하지 않으면 디자인에서 사용 가능한 플랫폼 제공 제품의 비용을 활용하지 못하거나 워크로드에 대한 플랫폼 위임 제약 조건을 위반하는 솔루션을 디자인할 수 있습니다.