파이프라인이 조직 구조에 대해 말하는 것

DevOps와 관련된 "법칙" 중 하나는 멜빈 콘웨이라는 프로그래머의 것입니다. 그의 법칙은 1967년에 도입되었는데, "시스템을 설계하는 조직은 이들 조직의 의사소통 구조를 모방한 설계를 생산해야 한다"고 간단히 기술하고 있습니다.

"시스템"이라는 단어를 강조한 이유는 Conway의 법칙이 앱에만 적용되는 경우가 너무 많기 때문입니다. 소프트웨어 시스템. 하지만 현실적으로 "시스템"은 앱에서부터 이를 전달하고 배포하는 통합 파이프라인에 이르기까지 모든 것을 포괄합니다. 파이프라인.

배포 측면(즉, 프로덕션)에서 DevOps 방법론을 도입하는 것에 대해 이야기할 때, 콘웨이의 법칙과 같은 관련 원칙도 알아야 합니다. 해당 법률은 시장에 출시하는 앱과 마찬가지로 배포 파이프라인의 설계에도 적용되기 때문입니다.

2019년 애플리케이션 서비스 현황에서 두 가지 질문을 기억하실 겁니다. 첫 번째 질문은 IT의 조직 구조, 즉 결합된 운영, 단일 기능 팀, 교차 기능 팀에 대한 질문이었습니다. 2,000명이 넘는 응답자 중 거의 절반(46%)이 단일 기능 팀으로 조직되어 있는 것으로 나타났습니다. 결합된 운영은 37%로 2위를 차지했습니다. 교차 기능팀은 덜 일반적이어서 그러한 구조에서 운영되는 응답자는 15%에 불과했습니다.

이제 배포 파이프라인 자동화의 상태를 살펴보는 것이 중요합니다. 그 결과는 확실히 단일 기능 팀의 지배력을 반영하기 때문입니다.

여기 나온 데이터는 일관되지 않은 자동화 노력을 보여주며, 이로 인해 디지털 혁신과 관련해 응답자의 절반(48%)이 추구한 목표, 즉 앱을 더 빠르고 더 자주 배포한다는 목표를 달성하는 데 도움이 되지 않습니다. IT 내에서 기존 도메인 간의 차이는 코네웨이의 법칙이 모든 시스템, 모든 장소에 적용된다는 것을 실존적으로 증명해 줍니다.

더 깊이 파고들어보면 10명 중 1명(11%)만이 이러한 도메인 중 하나만 자동화한 것으로 나타났습니다. 4명 중 1명(25%)이 2~3개 도메인을 자동화하는 데 성공했습니다. 그리고 5명 중 1명(21%)이 완전 자동화된 배포 파이프라인을 완료하는 데 필요한 4가지 기본 도메인을 모두 자동화했습니다.

상당수(42%)가 이러한 도메인 중 정확히 전혀 자동화하지 않았습니다.

배포 파이프라인 전반의 자동화 불평등은 시간 대 가치 퍼즐의 중요한 부분입니다. 파이프라인에서 수동 프로세스가 발생할 때마다 지연이 발생하기 때문입니다. 이러한 지연으로 인해 가치 실현 시간(또는 원하는 경우 시장 출시 시간)이 늦어집니다. 비율의 차이는 개별 "사일로"가 자동화되어 파이프라인의 나머지 부분과 어떻게 상호 작용하는지에 대한 관심이 거의 없거나 전혀 없기 때문에 조직이 "단일 기능 팀 구조"에 남아 있는 영향을 보여줍니다.

이것이 결합된 운영이나 기능 간 팀 구조가 선호되는 이유입니다. IT 도메인 간의 커뮤니케이션 채널이 여러 문제를 포괄하는 시스템 설계를 더 쉽게 만들어 주는 피어 프로세스가 되기 때문입니다. 팀이 파이프라인(시스템)을 설계할 때, 파이프라인을 합성된 부분이 아닌 전체로 고려할 수 있습니다.

자동화 작업 자체는 도메인 전문가가 처리할 수도 있고(아마도 그래야 할 것입니다). 그러나 전반적인 디자인 및 통합 방법(API)은 개방적이고 협업적인 팀에서 설계되어야 합니다. 그렇지 않으면 시장에 더 빨리, 더 자주 출시한다는 비즈니스 목표에 부합할 수도, 부합하지 않을 수도 있는 자동화 사일로가 생겨나게 됩니다.

따라서 생산 파이프라인을 자동화하는 데 지연이나 우회로가 생긴다면 한 걸음 물러서서 현재의 조직 구조와 그것이 파이프라인 설계에 어떤 영향을 미치는지 고려해 보세요. 무엇이든 효과적으로 자동화하려면 먼저 이러한 노력을 지원할 수 있는 보다 효과적인 조직 구조를 구축해야 한다는 것을 알게 될 것입니다.