From 8c779401e1d26aae5805bffd442d556aa096fe18 Mon Sep 17 00:00:00 2001 From: Eeap Date: Sun, 5 May 2024 12:08:42 +0900 Subject: [PATCH 1/4] docs(platforms): add missing sentence and translate pageinfo note Signed-off-by: Eeap --- .../ko/wgs/platforms/whitepaper/index.md | 156 +++++++++--------- 1 file changed, 79 insertions(+), 77 deletions(-) diff --git a/website/content/ko/wgs/platforms/whitepaper/index.md b/website/content/ko/wgs/platforms/whitepaper/index.md index 3d31020d..0cba38d5 100644 --- a/website/content/ko/wgs/platforms/whitepaper/index.md +++ b/website/content/ko/wgs/platforms/whitepaper/index.md @@ -2,14 +2,14 @@ title: "CNCF 플랫폼 백서(White Paper)" pdf: https://github.com/cncf/tag-app-delivery/raw/main/platforms-whitepaper/v1/assets/platforms-def-v1.0.pdf version_info: https://github.com/cncf/tag-app-delivery/tree/main/platforms-whitepaper/README.md -description: "이 백서는 기업 리더, 엔터프라이즈 아키텍트, 플랫폼 팀 리더가 클라우드 컴퓨팅을 위한 내부 플랫폼을 옹호하고, 조사하고, 계획할 수 있도록 지원하고자 합니다. 플랫폼은 기업의 실제 가치 흐름에 큰 영향을 미치지만 간접적으로만 영향을 미치므로 플랫폼 팀의 장기적인 지속 가능성과 성공을 위해서는 경영진의 합의와 지원이 필수적입니다. 이 백서에서는 플랫폼의 가치가 무엇인지, 이를 측정하는 방법, 그리고 이를 극대화하는 플랫폼 팀을 구현하는 방법에 대해 논의함으로써 이러한 지원을 가능하게 할 것입니다." +description: "이 백서는 기업 리더, 엔터프라이즈 아키텍트, 플랫폼 팀 리더가 클라우드 컴퓨팅을 위한 내부 플랫폼을 옹호하고, 조사하고, 계획할 수 있도록 지원하고자 한다. 플랫폼은 기업의 실제 가치 흐름에 큰 영향을 미치지만 간접적으로만 영향을 미치므로 플랫폼 팀의 장기적인 지속 가능성과 성공을 위해서는 경영진의 합의와 지원이 필수적이다. 이 백서에서는 플랫폼의 가치가 무엇인지, 이를 측정하는 방법, 그리고 이를 극대화하는 플랫폼 팀을 구현하는 방법에 대해 논의함으로써 이러한 지원을 가능하게 할 것이다." --- ## 소개 -데브옵스가 추구하는 부서 간 협력에서 영감을 받은 플랫폼 엔지니어링(Platform Engineering)은 이러한 확실한 협력을 기반으로한 형태로 기업에 도입되기 시작했습니다. 플랫폼은 애플리케이션 개발자, 데이터 과학자, 정보를 다루는 엔지니어(Information worker) 등 내부 고객의 작업을 촉진하고 가속화하기 위해 기본 기능, 프레임워크 및 경험을 선별하고 제공합니다. 특히 클라우드 컴퓨팅에서 플랫폼은 빠른 제품 출시, 인프라 간 이동성, 더 안전하고 탄력적인 제품, 개발자 생산성 향상 등 클라우드가 오랫동안 약속한 가치를 실현하는데 도움이 되었습니다. +데브옵스가 추구하는 부서 간 협력에서 영감을 받은 플랫폼 엔지니어링(Platform Engineering)은 이러한 확실한 협력을 기반으로한 형태로 기업에 도입되기 시작했다. 플랫폼은 애플리케이션 개발자, 데이터 과학자, 정보를 다루는 엔지니어(Information worker) 등 내부 고객의 작업을 촉진하고 가속화하기 위해 기본 기능, 프레임워크 및 경험을 선별하고 제공한다. 특히 클라우드 컴퓨팅에서 플랫폼은 빠른 제품 출시, 인프라 간 이동성, 더 안전하고 탄력적인 제품, 개발자 생산성 향상 등 클라우드가 오랫동안 약속한 가치를 실현하는데 도움이 되었다. -이 백서는 기업의 리더, 아키텍트 및 플랫폼 팀 리더가 클라우드 컴퓨팅을 위한 기업 내부 플랫폼을 지지하고, 조사하고, 계획할 수 있도록 지원하고자 합니다. 플랫폼은 실제로 기업의 실제 가치 흐름에 큰 영향을 미치지만, 표면적으로는 간접적으로만 영향을 받는 것으로 보이기 때문에 플랫폼 팀의 장기적인 지속 가능성과 성공을 위해서는 경영진의 합의와 지원이 필수적입니다. 이 백서에서는 플랫폼의 가치가 무엇인지, 그 가치를 측정하는 방법, 가치를 극대화하는 플랫폼 팀을 구현하는 방법에 대해 논의함으로써 경영진 및 플랫폼 사용자 등 관계자들의 지원이 가능하게 할 것입니다. +이 백서는 기업의 리더, 아키텍트 및 플랫폼 팀 리더가 클라우드 컴퓨팅을 위한 기업 내부 플랫폼을 지지하고, 조사하고, 계획할 수 있도록 지원하고자 한다. 플랫폼은 실제로 기업의 실제 가치 흐름에 큰 영향을 미치지만, 표면적으로는 간접적으로만 영향을 받는 것으로 보이기 때문에 플랫폼 팀의 장기적인 지속 가능성과 성공을 위해서는 경영진의 합의와 지원이 필수적이다. 이 백서에서는 플랫폼의 가치가 무엇인지, 그 가치를 측정하는 방법, 가치를 극대화하는 플랫폼 팀을 구현하는 방법에 대해 논의함으로써 경영진 및 플랫폼 사용자 등 관계자들의 지원이 가능하게 할 것이다. @@ -27,129 +27,129 @@ description: "이 백서는 기업 리더, 엔터프라이즈 아키텍트, 플 ## 왜 플랫폼인가요? -플랫폼과 플랫폼 엔지니어링은 오늘날 클라우드 컴퓨팅 세계에서 인기 있는 주제입니다. 플랫폼 구축에 대한 정의, 기술 및 측정에 대해 알아보기 전에 먼저 플랫폼이 제공하는 가치에 대해 살펴보는 것이 중요합니다. +플랫폼과 플랫폼 엔지니어링은 오늘날 클라우드 컴퓨팅 세계에서 인기 있는 주제이다. 플랫폼 구축에 대한 정의, 기술 및 측정에 대해 알아보기 전에 먼저 플랫폼이 제공하는 가치에 대해 살펴보는 것이 중요하다. -지난 2\~3년 동안의 프로세스 개선으로 소프트웨어 애플리케이션 및 제품(Product) 팀의 민첩성이 크게 향상되어 컴퓨팅, 네트워크, 스토리지와 같은 인프라는 물론 빌드, 테스트, 배포, 관찰 가능성(Observability)과 같은 개발자를 위한 유연한 서비스 제공을 할 수 있게 되었습니다. 이러한 자율성과 프로세스 개선은 서비스 지원에 대한 책임을 점차 제품 팀으로 이전하는 효과도 가져왔으며, 제품 팀은 인프라 문제에 점점 더 많은 시간과 에너지를 소비하고 조직과 관련된 가치를 창출하는 데 더 많은 시간을 할애할 수 밖에 없게 되었습니다. +지난 2\~3년 동안의 프로세스 개선으로 소프트웨어 애플리케이션 및 제품(Product) 팀의 민첩성이 크게 향상되어 컴퓨팅, 네트워크, 스토리지와 같은 인프라는 물론 빌드, 테스트, 배포, 관찰 가능성(Observability)과 같은 개발자를 위한 유연한 서비스 제공을 할 수 있게 되었다. 이러한 자율성과 프로세스 개선은 서비스 지원에 대한 책임을 점차 제품 팀으로 이전하는 효과도 가져왔으며, 제품 팀은 인프라 문제에 점점 더 많은 시간과 에너지를 소비하고 조직과 관련된 가치를 창출하는 데 더 많은 시간을 할애할 수 밖에 없게 되었다. -제공(Delivery, `역자: 일반적으로 한국에서는 현재 기준으로 DevOps 팀에서 주로 담당`) 팀이 핵심 업무에 다시 집중하고 조직 전반에서 중복되는 노력을 줄이려는 열망으로 인해 기업들은 클라우드 네이티브 컴퓨팅을 위한 플랫폼을 구현하게 되었습니다. 플랫폼에 투자함으로써 기업은 다음과 같은 이점을 얻을 수 있습니다: +제공(Delivery, `역자: 일반적으로 한국에서는 현재 기준으로 DevOps 팀에서 주로 담당`) 팀이 핵심 업무에 다시 집중하고 조직 전반에서 중복되는 노력을 줄이려는 열망으로 인해 기업들은 클라우드 네이티브 컴퓨팅을 위한 플랫폼을 구현하게 되었다. 플랫폼에 투자함으로써 기업은 다음과 같은 이점을 얻을 수 있다: -1. 제품 팀의 업무 부하를 줄여 제품 개발 및 배포를 보다 빠르게 합니다. -2. 플랫폼 기능을 구성하고 관리할 전문가를 전담 배치하여 플랫폼 기능에 의존하는 제품의 안정성과 복원력 향상 시킵니다. -3. 기업 내 여러 팀에서 플랫폼 도구와 지식을 재사용하고 공유하여 제품 개발 및 제공을 가속화합니다. -4. 플랫폼 기능과 이를 둘러싼 사용자, 도구 및 프로세스를 관리하여 제품 및 서비스의 보안, 규제 및 기능 문제 위험을 줄입니다. -5. 사용자 경험에 대한 제어를 유지하면서 퍼블릭 클라우드 및 기타 관리형 제공업체에 구현을 위임하여 비용 효율적이고 생산적으로 서비스를 사용할 수 있도록 지원합니다. +1. 제품 팀의 업무 부하를 줄여 제품 개발 및 배포를 보다 빠르게 한다. +2. 플랫폼 기능을 구성하고 관리할 전문가를 전담 배치하여 플랫폼 기능에 의존하는 제품의 안정성과 복원력을 향상시킨다. +3. 기업 내 여러 팀에서 플랫폼 도구와 지식을 재사용하고 공유하여 제품 개발 및 제공을 가속화한다. +4. 플랫폼 기능과 이를 둘러싼 사용자, 도구 및 프로세스를 관리하여 제품 및 서비스의 보안, 규제 및 기능 문제 위험을 줄인다. +5. 사용자 경험에 대한 제어를 유지하면서 퍼블릭 클라우드 및 기타 관리형 제공업체에 구현을 위임하여 비용 효율적이고 생산적으로 서비스를 사용할 수 있도록 지원한다. -이러한 이점들은 부분적으로는 소수의 플랫폼 팀이 많은 제품 팀에 서비스를 제공하여 그 영향력을 확대하기 때문에 발생합니다. 플랫폼 팀이 공통적으로 기능 관리를 통합하여 거버넌스를 쉽게 이용할 수 있게 하고 또한 무엇보다도 사용자 인터페이스와 경험을 중요하게 생각하는 조직이기 때문입니다. +이러한 이점들은 부분적으로는 소수의 플랫폼 팀이 많은 제품 팀에 서비스를 제공하여 그 영향력을 확대하기 때문에 발생한다. 플랫폼 팀이 공통적으로 기능 관리를 통합하여 거버넌스를 쉽게 이용할 수 있게 하고 또한 무엇보다도 사용자 인터페이스와 경험을 중요하게 생각하는 조직이기 때문이다. -플랫폼 전문가로 구성된 팀은 제품 팀에 요구되는 공통 업무를 줄여줄 뿐만 아니라 해당 제품에 사용되는 플랫폼 기능을 최적화합니다. 또한 플랫폼 팀은 전사적으로 광범위하게 사용되는 일련의 기존 패턴, 지식 및 도구를 유지 관리하여 개발자가 동일한 기반 위에 구축된 다른 팀과 제품에 신속하게 기여할 수 있도록 지원합니다. 또한 공유 플랫폼 패턴을 통해 템플릿, 패턴 및 기능에 거버넌스 및 제어 기능을 포함할 수 있습니다. 마지막으로, 플랫폼 팀은 제공업체를 통합하고 제공 서비스에 일관된 경험을 제공하기 때문에 데이터베이스, ID 액세스, 인프라 운영 및 앱 수명주기와 같이 기본적이며 CSP(Cloud Service Provider) 별로 특화되지 않은 기능들을 사용하기 위해서(`역자 생각: Lock in에 대해서 우려`) 퍼블릭 클라우드 및 서비스 제공업체를 이용할 수 있습니다. +플랫폼 전문가로 구성된 팀은 제품 팀에 요구되는 공통 업무를 줄여줄 뿐만 아니라 해당 제품에 사용되는 플랫폼 기능을 최적화한다. 또한 플랫폼 팀은 전사적으로 광범위하게 사용되는 일련의 기존 패턴, 지식 및 도구를 유지 관리하여 개발자가 동일한 기반 위에 구축된 다른 팀과 제품에 신속하게 기여할 수 있도록 지원한다. 또한 공유 플랫폼 패턴을 통해 템플릿, 패턴 및 기능에 거버넌스 및 제어 기능을 포함할 수 있다. 마지막으로, 플랫폼 팀은 제공업체를 통합하고 제공 서비스에 일관된 경험을 제공하기 때문에 데이터베이스, ID 액세스, 인프라 운영 및 앱 수명주기와 같이 기본적이며 CSP(Cloud Service Provider) 별로 특화되지 않은 기능들을 사용하기 위해서(`역자 생각: Lock in에 대해서 우려`) 퍼블릭 클라우드 및 서비스 제공업체를 이용할 수 있다. -## 플랫폼이란 어떤걸까요?? +## 플랫폼이란 어떤 걸까요?? -클라우드 네이티브 컴퓨팅을 위한 플랫폼은 플랫폼 사용자의 필요에 따라 정의되고 제공되는 기능의 통합 모음입니다. 플랫폼은 광범위한 애플리케이션 및 사용 사례에 대한 일반적인 기능과 서비스를 획득하고 통합하기 위한 일관된 경험을 보장하는 횡단 계층(cross-cutting layer, `역자: 계층간에 서로 영향을 주고 받을 수 있음 / 의존성에 가깝지만 여기서는`` `**`단일 사용자 채널`**`에 가까운 용어로 사용함` / [자세히 링크](https://zetawiki.com/wiki/%ED%9A%A1%EB%8B%A8\_%EA%B4%80%EC%8B%AC%EC%82%AC)) 입니다. 좋은 플랫폼은 웹 포털, 프로젝트 템플릿 및 셀프 서비스 API와 같은 기능 및 서비스를 사용하고 관리하기 위한 일관된 사용자 경험을 제공합니다. +클라우드 네이티브 컴퓨팅을 위한 플랫폼은 플랫폼 사용자의 필요에 따라 정의되고 제공되는 기능의 통합 모음이다. 플랫폼은 광범위한 애플리케이션 및 사용 사례에 대한 일반적인 기능과 서비스를 획득하고 통합하기 위한 일관된 경험을 보장하는 횡단 계층(cross-cutting layer, `역자: 계층간에 서로 영향을 주고 받을 수 있음 / 의존성에 가깝지만 여기서는`` `**`단일 사용자 채널`**`에 가까운 용어로 사용함` / [자세히 링크](https://zetawiki.com/wiki/%ED%9A%A1%EB%8B%A8\_%EA%B4%80%EC%8B%AC%EC%82%AC)) 이다. 좋은 플랫폼은 웹 포털, 프로젝트 템플릿 및 셀프 서비스 API와 같은 기능 및 서비스를 사용하고 관리하기 위한 일관된 사용자 경험을 제공한다. -Atlassian\[[1](https://www.atlassian.com/devops/frameworks/team-topologies)]에 따르면, "플랫폼 팀은 오버헤드가 거의 없이 수많은 스트림 정렬 \[제품] 팀에서 사용할 수 있는 기능을 만듭니다.... 플랫폼 팀은 스트림 정렬 \[제품] 팀의 리소스 및 작업 부하를 최소화합니다... 플랫폼 팀은 다양한 사용자 경험 또는 제품에 걸쳐 일관된 경험을 만들 수 있습니다."라고 설명합니다. +Atlassian\[[1](https://www.atlassian.com/devops/frameworks/team-topologies)]에 따르면, "플랫폼 팀은 오버헤드가 거의 없이 수많은 스트림 정렬 \[제품] 팀에서 사용할 수 있는 기능을 만든다.... 플랫폼 팀은 스트림 정렬 \[제품] 팀의 리소스 및 작업 부하를 최소화한다... 플랫폼 팀은 다양한 사용자 경험 또는 제품에 걸쳐 일관된 경험을 만들 수 있다."라고 설명한다. -마틴 파울러와 에반 보처\[[2](https://martinfowler.com/articles/talk-about-platforms.html)]에 따르면, "디지털 플랫폼은 하나의 매력적인 내부 제품으로 셀프 서비스 API, 도구, 서비스, 지식 및 지원을 잘 정리해서 제공합니다. 자율(Autonomous, `역자: 일종의 셀프 서비스 들로 인해서 제공 팀이 직접 서비스들을 제공하지 않아도 되는 형태`) 제공 팀은 플랫폼을 활용하여 조정을 줄이면서 더 빠른 속도로 제품 기능을 제공할 수 있습니다."라고 설명합니다. +마틴 파울러와 에반 보처\[[2](https://martinfowler.com/articles/talk-about-platforms.html)]에 따르면, "디지털 플랫폼은 하나의 매력적인 내부 제품으로 셀프 서비스 API, 도구, 서비스, 지식 및 지원을 잘 정리해서 제공한다. 자율(Autonomous, `역자: 일종의 셀프 서비스 들로 인해서 제공 팀이 직접 서비스들을 제공하지 않아도 되는 형태`) 제공 팀은 플랫폼을 활용하여 조정을 줄이면서 더 빠른 속도로 제품 기능을 제공할 수 있다."라고 설명한다. -플랫폼에서 지원하는 특정 기능 및 시나리오는 이해관계자와 사용자의 요구에 따라 결정되어야 합니다. 플랫폼이 이러한 필수 기능을 제공하지만, 플랫폼 팀이 항상 직접 구현해서는 안 된다는 점에 유의해야 합니다. 관리형 서비스 제공 업체나 전담 내부 팀은 지원 구현을 유지 관리할 수 있지만, 플랫폼을 통해 제공되는 구현 전반에 일관성을 제공하고 조직의 요구 사항을 충족하는 가장 합리적인 팀은 플랫폼 팀이어야 합니다. 예를 들어, 매우 간단한 '플랫폼'은 \[[3](https://teamtopologies.com/key-concepts-content/what-is-a-thinnest-viable-platform-tvp)]에 설명된 대로 제공업체의 기능을 프로비저닝하기 위한 표준 운영 절차에 대한 링크가 있는 위키 페이지일 수 있습니다. +플랫폼에서 지원하는 특정 기능 및 시나리오는 이해관계자와 사용자의 요구에 따라 결정되어야 한다. 플랫폼이 이러한 필수 기능을 제공하지만, 플랫폼 팀이 항상 직접 구현해서는 안 된다는 점에 유의해야 한다. 관리형 서비스 제공 업체나 전담 내부 팀은 지원 구현을 유지 관리할 수 있지만, 플랫폼을 통해 제공되는 구현 전반에 일관성을 제공하고 조직의 요구 사항을 충족하는 가장 합리적인 팀은 플랫폼 팀이어야 한다. 예를 들어, 매우 간단한 '플랫폼'은 \[[3](https://teamtopologies.com/key-concepts-content/what-is-a-thinnest-viable-platform-tvp)]에 설명된 대로 제공업체의 기능을 프로비저닝하기 위한 표준 운영 절차에 대한 링크가 있는 위키 페이지일 수 있다. -이러한 플랫폼은 기업의 내부 사용자만을 대상으로 하기 때문에 내부 플랫폼이라고 부르는 경우가 많습니다. +이러한 플랫폼은 기업의 내부 사용자만을 대상으로 하기 때문에 내부 플랫폼이라고 부르는 경우가 많다. -플랫폼은 이전 패러다임(`역자 생각: DevOps 그리고 SRE 의 트렌드를 의미`, [설명](https://osckorea.tistory.com/173))보다 애플리케이션별 로직에서 지원 기능을 분리하기 때문에 클라우드 네이티브 아키텍처와 특히 밀접하게 연관되어 있습니다. 클라우드와 같은 환경에서는 리소스와 기능이 독립적으로 관리되고 사용자 지정 비즈니스 구성 요소와 통합되는 경우가 많으며, 이러한 리소스에는 데이터베이스 및 개체 저장소, 메시지 큐 및 브로커, 관찰 가능성 수집기(collectors, `역자: 익스포터들을 의미`) 및 대시보드, 사용자 디렉터리 및 인증 시스템, 작업 실행자 및 조정자(reconcilers) 등이 포함될 수 있습니다. 내부 플랫폼은 이러한 리소스를 애플리케이션과 시스템에 쉽게 통합할 수 있는 방식으로 엔터프라이즈 팀에 제공합니다. +플랫폼은 이전 패러다임(`역자 생각: DevOps 그리고 SRE 의 트렌드를 의미`, [설명](https://osckorea.tistory.com/173))보다 애플리케이션별 로직에서 지원 기능을 분리하기 때문에 클라우드 네이티브 아키텍처와 특히 밀접하게 연관되어 있다. 클라우드와 같은 환경에서는 리소스와 기능이 독립적으로 관리되고 사용자 지정 비즈니스 구성 요소와 통합되는 경우가 많으며, 이러한 리소스에는 데이터베이스 및 개체 저장소, 메시지 큐 및 브로커, 관찰 가능성 수집기(collectors, `역자: 익스포터들을 의미`) 및 대시보드, 사용자 디렉터리 및 인증 시스템, 작업 실행자 및 조정자(reconcilers) 등이 포함될 수 있다. 내부 플랫폼은 이러한 리소스를 애플리케이션과 시스템에 쉽게 통합할 수 있는 방식으로 엔터프라이즈 팀에 제공한다. ## 플랫폼 성숙도 -가장 기본적인 내부 플랫폼은 파이프라인 러너, 데이터베이스 시스템 또는 시크릿(Secret) 저장소와 같은 개별 서비스를 사용하기 위한 일관된 환경을 제공합니다. 내부 플랫폼이 성숙해짐에 따라 웹 애플리케이션 개발이나 데이터 분석과 같은 주요 시나리오를 위한 셀프 서비스 가능한 템플릿(일반적으로 MLOps)과 같은 서비스 구성도 제공합니다. +가장 기본적인 내부 플랫폼은 파이프라인 러너, 데이터베이스 시스템 또는 시크릿(Secret) 저장소와 같은 개별 서비스를 사용하기 위한 일관된 환경을 제공한다. 내부 플랫폼이 성숙해짐에 따라 웹 애플리케이션 개발이나 데이터 분석과 같은 주요 시나리오를 위한 셀프 서비스 가능한 템플릿(일반적으로 MLOps)과 같은 서비스 구성도 제공한다. -기업이 플랫폼을 통해 만날 수 있는 사용 사례는 다음과 같이 진행될 수 있습니다. +기업이 플랫폼을 통해 만날 수 있는 사용 사례는 다음과 같이 진행될 수 있다. -1. 제품 개발자는 필요에 따라 기능을 프로비저닝하여 컴퓨팅, 스토리지, 데이터베이스 또는 신원 확인(ID)과 같은 시스템을 즉시 사용할 수 있습니다. -2. 제품 개발자는 필요에 따라 서비스 공간을 프로비저닝하여 파이프라인 및 작업을 실행하고, 아티팩트 및 구성을 저장하고, 원격 측정을 수집하는 데 사용할 수 있습니다. -3. 타사 소프트웨어의 관리자는 필요에 따라 데이터베이스와 같은 필수 의존 요소를 프로비저닝하고 해당 소프트웨어를 쉽게 설치하고 실행할 수 있습니다. -4. 제품 개발자는 웹 개발이나 MLOps와 같은 특정 시나리오에 필요한 런타임 및 개발 시간 서비스를 결합한 템플릿이 갖춰진 완전한 환경에서 프로비저닝할 수 있습니다. -5. 제품 개발자와 관리자는 자동 계측 및 표준 대시보드를 통해 배포된 서비스의 기능, 성능, 비용을 모니터링할 수 있습니다. +1. 제품 개발자는 필요에 따라 기능을 프로비저닝하여 컴퓨팅, 스토리지, 데이터베이스 또는 신원 확인(ID)과 같은 시스템을 즉시 사용할 수 있다. +2. 제품 개발자는 필요에 따라 서비스 공간을 프로비저닝하여 파이프라인 및 작업을 실행하고, 아티팩트 및 구성을 저장하고, 원격 측정을 수집하는 데 사용할 수 있다. +3. 타사 소프트웨어의 관리자는 필요에 따라 데이터베이스와 같은 필수 의존 요소를 프로비저닝하고 해당 소프트웨어를 쉽게 설치하고 실행할 수 있다. +4. 제품 개발자는 웹 개발이나 MLOps와 같은 특정 시나리오에 필요한 런타임 및 개발 시간 서비스를 결합한 템플릿이 갖춰진 완전한 환경에서 프로비저닝할 수 있다. +5. 제품 개발자와 관리자는 자동 계측 및 표준 대시보드를 통해 배포된 서비스의 기능, 성능, 비용을 모니터링할 수 있다. -내부 플랫폼은 개별 기능 또는 기능 세트에 대해 규정을 준수할 뿐만 아니라 일관된 경험을 제공함으로써 궁극적으로 사용자에게 가치 있는 제품을 보다 쉽고 효율적으로 제공할 수 있도록 지원합니다. +내부 플랫폼은 개별 기능 또는 기능 세트에 대해 규정을 준수할 뿐만 아니라 일관된 경험을 제공함으로써 궁극적으로 사용자에게 가치 있는 제품을 보다 쉽고 효율적으로 제공할 수 있도록 지원한다. {{% pageinfo color="info" %}} -Please refer to the [Platform Engineering Maturity Model](https://tag-app-delivery.cncf.io/ko/whitepapers/platform-eng-maturity-model/) created after this paper was originally published. +해당 백서가 출판된 이후에 만들어진 [플랫폼 엔지니어링 성숙도 모델](https://tag-app-delivery.cncf.io/ko/whitepapers/platform-eng-maturity-model/)을 참고해주세요. {{% /pageinfo %}} ## 플랫폼의 속성 -플랫폼이 무엇이며 조직이 플랫폼을 구축하려는 이유를 충분히 알아봤으니 다음으로는 플랫폼이 성공에 영향을 미치는 몇 가지 주요 속성을 파악해 보겠습니다. +플랫폼이 무엇이며 조직이 플랫폼을 구축하려는 이유를 충분히 알아봤으니 다음으로는 플랫폼이 성공에 영향을 미치는 몇 가지 주요 속성을 파악해 보겠다. -1. **제품으로서의 플랫폼.** 플랫폼은 사용자의 요구 사항을 충족하기 위해 존재하며, 다른 소프트웨어 제품과 마찬가지로 이러한 요구 사항을 기반으로 설계되고 발전되어야 합니다. 플랫폼은 제품 팀 전반에서 가장 일반적인 사용 사례를 지원하는 데 필요한 기능을 제공해야 하며, 단일 팀에서만 사용하는 특정 기능보다 이러한 기능에 우선 순위를 두어 제공되는 가치를 극대화해야 합니다. -2. **사용자 경험.** 플랫폼은 일관된 인터페이스를 통해 기능을 제공하고 사용자 경험에 집중해야 합니다. 플랫폼은 사용자가 있는 곳에서 사용자를 만나기 위해 노력해야 하며, 이는 GUI, API, 커맨드 라인(command-line) 도구, IDE 및 포털의 통합을 의미할 수 있습니다. 예를 들어, 플랫폼은 일반적으로 애플리케이션 배포 기능을 제공합니다. 개발자는 IDE를 통해 이러한 기능을 사용할 수 있고, 테스터는 커맨드 라인 도구를 사용할 수 있으며, 제품 소유자는 GUI 기반 웹 포털을 사용할 수 있습니다. -3. **문서화 및 온보딩.** 성공적인 소프트웨어 제품의 핵심 요소는 문서화입니다. 사용자가 플랫폼의 제품을 사용하려면 문서와 예제가 필요합니다. 플랫폼은 사용자의 요구 사항을 충족하는 적절한 문서와 함께 제공되어야 합니다. 또한 사용자가 필요한 플랫폼 서비스를 빠르고 간단하게 사용할 수 있도록 새로운 프로젝트의 온보딩을 가속화할 수 있는 도구를 제공해야 합니다. 예를 들어, 플랫폼은 쿠버네티스에서 웹 애플리케이션을 빌드, 스캔, 테스트, 배포 및 모니터링 하기 위해 재사용 가능한 형태의 서비스 공급망(supply chain) 워크플로우를 제공할 수 있습니다. 이러한 워크플로우는 초기 프로젝트 템플릿 및 문서와 함께 제공될 수 있으며, 종종 가장 빠르게 도입(Golden path)할 수 있는 번들 형태로 제공되기도 합니다. -4. **셀프 서비스.** 플랫폼은 셀프서비스가 가능해야 합니다. 사용자가 자율적으로 자동으로 기능을 요청하고 받을 수 있어야 합니다. 이 속성은 플랫폼 팀이 여러 제품 팀을 지원하고 필요에 따라 확장할 수 있도록 하는 핵심 요소입니다. 플랫폼 기능은 위에서 설명한 인터페이스를 통해 최소한의 수동 개입으로 필요에 따라 사용할 수 있어야 합니다. 예를 들어, 사용자가 커맨드 라인 도구를 실행하거나 웹 포털에서 양식을 작성하여 데이터베이스를 요청하고 해당 위치 및 자격 증명(credentials)을 받을 수 있어야 합니다. -5. **사용자의 작업 부하 감소.** 플랫폼의 필수 목표는 제품 팀의 작업 부하를 줄이는 것입니다. 플랫폼은 구현 세부 사항을 요약하고 아키텍처에서 발생할 수 있는 모든 복잡성을 숨겨야 합니다. 예를 들어, 플랫폼은 특정 서비스를 클라우드 제공업체에 위임할 수 있지만 사용자는 이러한 세부 사항에 노출되어서는 안 됩니다. 동시에 플랫폼은 사용자가 필요에 따라 특정 서비스를 구성하고 관찰할 수 있도록 허용해야 합니다. 사용자는 플랫폼에서 제공하는 서비스 운영에 대한 책임을 져서는 안 됩니다. 예를 들어, 사용자는 종종 데이터베이스가 필요할 수 있지만 데이터베이스 서버를 관리할 필요가 없어야 합니다. -6. **선택 사항 및 구성 가능.** 플랫폼은 제품 개발의 효율성을 높이기 위한 것이므로 장애물이 되어서는 안 됩니다. 플랫폼은 구성이 가능해야 하며 제품 팀이 플랫폼의 일부만 사용할 수 있어야 합니다. 또한 필요한 경우 제품 팀이 플랫폼 외부에서 자체 기능을 제공하고 관리할 수 있어야 합니다. 예를 들어, 플랫폼에서 그래프 데이터베이스(`역자: 예를 들자면 Neo4j`)를 제공하지 않지만 제품에 필요한 경우, 제품 팀이 직접 그래프 데이터베이스를 프로비저닝하고 운영할 수 있어야 합니다. -7. **보안은 기본.** 플랫폼은 기본적으로 안전해야 하며 조직에서 정의한 규칙과 표준에 따라 규정 준수 및 유효성 검사를 보장하는 기능을 제공해야 합니다. +1. **제품으로서의 플랫폼.** 플랫폼은 사용자의 요구 사항을 충족하기 위해 존재하며, 다른 소프트웨어 제품과 마찬가지로 이러한 요구 사항을 기반으로 설계되고 발전되어야 한다. 플랫폼은 제품 팀 전반에서 가장 일반적인 사용 사례를 지원하는 데 필요한 기능을 제공해야 하며, 단일 팀에서만 사용하는 특정 기능보다 이러한 기능에 우선 순위를 두어 제공되는 가치를 극대화해야 한다. +2. **사용자 경험.** 플랫폼은 일관된 인터페이스를 통해 기능을 제공하고 사용자 경험에 집중해야 한다. 플랫폼은 사용자가 있는 곳에서 사용자를 만나기 위해 노력해야 하며, 이는 GUI, API, 커맨드 라인(command-line) 도구, IDE 및 포털의 통합을 의미할 수 있다. 예를 들어, 플랫폼은 일반적으로 애플리케이션 배포 기능을 제공한다. 개발자는 IDE를 통해 이러한 기능을 사용할 수 있고, 테스터는 커맨드 라인 도구를 사용할 수 있으며, 제품 소유자는 GUI 기반 웹 포털을 사용할 수 있다. +3. **문서화 및 온보딩.** 성공적인 소프트웨어 제품의 핵심 요소는 문서화이다. 사용자가 플랫폼의 제품을 사용하려면 문서와 예제가 필요하다. 플랫폼은 사용자의 요구 사항을 충족하는 적절한 문서와 함께 제공되어야 한다. 또한 사용자가 필요한 플랫폼 서비스를 빠르고 간단하게 사용할 수 있도록 새로운 프로젝트의 온보딩을 가속화할 수 있는 도구를 제공해야 한다. 예를 들어, 플랫폼은 쿠버네티스에서 웹 애플리케이션을 빌드, 스캔, 테스트, 배포 및 모니터링 하기 위해 재사용 가능한 형태의 서비스 공급망(supply chain) 워크플로우를 제공할 수 있다. 이러한 워크플로우는 초기 프로젝트 템플릿 및 문서와 함께 제공될 수 있으며, 종종 가장 빠르게 도입(Golden path)할 수 있는 번들 형태로 제공되기도 한다. +4. **셀프 서비스.** 플랫폼은 셀프서비스가 가능해야 한다. 사용자가 자율적으로 자동으로 기능을 요청하고 받을 수 있어야 한다. 이 속성은 플랫폼 팀이 여러 제품 팀을 지원하고 필요에 따라 확장할 수 있도록 하는 핵심 요소이다. 플랫폼 기능은 위에서 설명한 인터페이스를 통해 최소한의 수동 개입으로 필요에 따라 사용할 수 있어야 한다. 예를 들어, 사용자가 커맨드 라인 도구를 실행하거나 웹 포털에서 양식을 작성하여 데이터베이스를 요청하고 해당 위치 및 자격 증명(credentials)을 받을 수 있어야 한다. +5. **사용자의 작업 부하 감소.** 플랫폼의 필수 목표는 제품 팀의 작업 부하를 줄이는 것이다. 플랫폼은 구현 세부 사항을 요약하고 아키텍처에서 발생할 수 있는 모든 복잡성을 숨겨야 한다. 예를 들어, 플랫폼은 특정 서비스를 클라우드 제공업체에 위임할 수 있지만 사용자는 이러한 세부 사항에 노출되어서는 안 된다. 동시에 플랫폼은 사용자가 필요에 따라 특정 서비스를 구성하고 관찰할 수 있도록 허용해야 한다. 사용자는 플랫폼에서 제공하는 서비스 운영에 대한 책임을 져서는 안 된다. 예를 들어, 사용자는 종종 데이터베이스가 필요할 수 있지만 데이터베이스 서버를 관리할 필요가 없어야 한다. +6. **선택 사항 및 구성 가능.** 플랫폼은 제품 개발의 효율성을 높이기 위한 것이므로 장애물이 되어서는 안 된다. 플랫폼은 구성이 가능해야 하며 제품 팀이 플랫폼의 일부만 사용할 수 있어야 한다. 또한 필요한 경우 제품 팀이 플랫폼 외부에서 자체 기능을 제공하고 관리할 수 있어야 한다. 예를 들어, 플랫폼에서 그래프 데이터베이스(`역자: 예를 들자면 Neo4j`)를 제공하지 않지만 제품에 필요한 경우, 제품 팀이 직접 그래프 데이터베이스를 프로비저닝하고 운영할 수 있어야 한다. +7. **보안은 기본.** 플랫폼은 기본적으로 안전해야 하며 조직에서 정의한 규칙과 표준에 따라 규정 준수 및 유효성 검사를 보장하는 기능을 제공해야 한다. ## 플랫폼 팀의 속성 -플랫폼 팀은 웹 포털, 사용자 지정(custom) API, 빠른 도입을 위한 템플릿과 같은 플랫폼 기능에 대한 인터페이스와 사용자 경험을 담당합니다. 플랫폼 팀은 인프라를 구현하고 서비스를 지원하는 팀과 협력하여 일관된 경험을 규정하고, 다른 한편으로는 제품 및 사용자 팀과 협력하여 피드백을 수집하는 한편 이러한 경험이 실제로 사용자의 요구 사항을 충족하는지 확인합니다. +플랫폼 팀은 웹 포털, 사용자 지정(custom) API, 빠른 도입을 위한 템플릿과 같은 플랫폼 기능에 대한 인터페이스와 사용자 경험을 담당한다. 플랫폼 팀은 인프라를 구현하고 서비스를 지원하는 팀과 협력하여 일관된 경험을 규정하고, 다른 한편으로는 제품 및 사용자 팀과 협력하여 피드백을 수집하는 한편 이러한 경험이 실제로 사용자의 요구 사항을 충족하는지 확인한다. -다음은 플랫폼 팀이 담당해야 하는 업무입니다. +다음은 플랫폼 팀이 담당해야 하는 업무이다. 1. 플랫폼 사용자 요구 사항 조사 및 기능 로드맵 수립 2. 플랫폼이 제안하는 가치를 마케팅, 홍보 지원 3. 포털, API, 문서 및 템플릿, 커맨드 라인(CLI) 도구 등 기능 및 서비스를 사용하고 관찰하기 위한 인터페이스를 관리 및 개발 -가장 중요한 것은 플랫폼 팀이 플랫폼에서 제공하는 기능과 인터페이스를 알리고 지속적으로 개선하기 위해 플랫폼 사용자의 요구사항을 파악해야 한다는 것입니다. 사용자 요구 사항을 파악하는 방법에는 사용자 인터뷰, 양방향 해커톤, 이슈 트래커 및 설문조사, 관찰 가능성 도구를 통한 사용 현황 직접 관찰 등이 있습니다. 예를 들어, 플랫폼 팀은 사용자가 기능 요청을 제출할 수 있는 양식을 게시하고, 로드맵 회의를 주도하여 예정된 기능을 공유하고, 사용자의 사용 패턴을 검토하여 우선 순위를 설정할 수 있습니다. +가장 중요한 것은 플랫폼 팀이 플랫폼에서 제공하는 기능과 인터페이스를 알리고 지속적으로 개선하기 위해 플랫폼 사용자의 요구사항을 파악해야 한다는 것이다. 사용자 요구 사항을 파악하는 방법에는 사용자 인터뷰, 양방향 해커톤, 이슈 트래커 및 설문조사, 관찰 가능성 도구를 통한 사용 현황 직접 관찰 등이 있다. 예를 들어, 플랫폼 팀은 사용자가 기능 요청을 제출할 수 있는 양식을 게시하고, 로드맵 회의를 주도하여 예정된 기능을 공유하고, 사용자의 사용 패턴을 검토하여 우선 순위를 설정할 수 있다. -플랫폼은 내부로부터(Inbound)의 피드백과 면밀한 설계를 가지고 있어야 하고, 다른 측면으로는 적극적으로 외부(Outbound)에 마케팅적으로 알려야 하고 지원 받아야 합니다. 플랫폼이 진정으로 사용자 요구사항에 맞게 구축되었다면 사용자들은 플랫폼에서 제공하는 기능등을 기꺼이 사용할 것입니다. 플랫폼 팀이 사용자의 사용을 유도하는 몇 가지 방법으로는 광범위한 공지, 매력적인 데모, 정기적인 피드백 및 커뮤니케이션 세션 등의 내부 마케팅 활동을 들 수 있습니다. 여기서 핵심은 사용자가 있는 곳에서 사용자를 만나고 플랫폼에 참여하고 혜택을 누릴 수 있는 과정을 안내하는 것입니다. +플랫폼은 내부로부터(Inbound)의 피드백과 면밀한 설계를 가지고 있어야 하고, 다른 측면으로는 적극적으로 외부(Outbound)에 마케팅적으로 알려야 하고 지원 받아야 한다. 플랫폼이 진정으로 사용자 요구사항에 맞게 구축되었다면 사용자들은 플랫폼에서 제공하는 기능등을 기꺼이 사용할 것이다. 플랫폼 팀이 사용자의 사용을 유도하는 몇 가지 방법으로는 광범위한 공지, 매력적인 데모, 정기적인 피드백 및 커뮤니케이션 세션 등의 내부 마케팅 활동을 들 수 있다. 여기서 핵심은 사용자가 있는 곳에서 사용자를 만나고 플랫폼에 참여하고 혜택을 누릴 수 있는 과정을 안내하는 것이다. -플랫폼 팀이 반드시 컴퓨팅, 네트워크, 스토리지 또는 기타 서비스를 운영할 필요는 없습니다. 사실 내부 플랫폼은 가능한 한 외부에서 제공하는 서비스와 기능에 의존해야 하며, 플랫폼 팀은 관리 공급업체나 내부 인프라 팀에서 사용할 수 없는 경우에만 자체 기능을 구축하고 유지 관리해야 합니다. 대신 플랫폼 팀은 플랫폼에서 제공하는 서비스 및 기능에 대한 인터페이스(예: GUI, CLI, API) 및 사용자 경험에 대해서 확실히 책임을 지고 유지 관리해야 합니다. +플랫폼 팀이 반드시 컴퓨팅, 네트워크, 스토리지 또는 기타 서비스를 운영할 필요는 없다. 사실 내부 플랫폼은 가능한 한 외부에서 제공하는 서비스와 기능에 의존해야 하며, 플랫폼 팀은 관리 공급업체나 내부 인프라 팀에서 사용할 수 없는 경우에만 자체 기능을 구축하고 유지 관리해야 한다. 대신 플랫폼 팀은 플랫폼에서 제공하는 서비스 및 기능에 대한 인터페이스(예: GUI, CLI, API) 및 사용자 경험에 대해서 확실히 책임을 지고 유지 관리해야 한다. -예를 들어, 플랫폼의 웹 페이지에서 앱의 신원 인증(ID)을 제공하는 버튼에 대해 설명하고 제공할 수 있으며, 실제로해당 기능에 대한 구현은 클라우드에서 호스팅되는 ID 서비스(`역자: 예를 들자면 IAM관련 서비스`)를 통해 이루어질 수 있습니다. 내부 플랫폼 팀이 웹 페이지와 API를 관리할 수 있지만 실제 서비스 구현은 관리하지 않을 수 있습니다. 플랫폼 팀은 일반적으로 필요한 기능을 다른 곳에서 사용할 수 없는 경우에만 자체 기능을 만들고 유지 관리하는 것을 고려해야 합니다. +예를 들어, 플랫폼의 웹 페이지에서 앱의 신원 인증(ID)을 제공하는 버튼에 대해 설명하고 제공할 수 있으며, 실제로해당 기능에 대한 구현은 클라우드에서 호스팅되는 ID 서비스(`역자: 예를 들자면 IAM관련 서비스`)를 통해 이루어질 수 있다. 내부 플랫폼 팀이 웹 페이지와 API를 관리할 수 있지만 실제 서비스 구현은 관리하지 않을 수 있다. 플랫폼 팀은 일반적으로 필요한 기능을 다른 곳에서 사용할 수 없는 경우에만 자체 기능을 만들고 유지 관리하는 것을 고려해야 한다. ## 플랫폼의 당면 과제 -플랫폼은 많은 가치를 약속하지만, 구현자가 염두에 두어야 할 다음과 같은 과제도 있습니다. +플랫폼은 많은 가치를 약속하지만, 구현자가 염두에 두어야 할 다음과 같은 과제도 있다. -1. 플랫폼 팀은 플랫폼을 제품처럼 취급하고, 사용자와 함께 개발해야 합니다. -2. 플랫폼 팀은 우선 순위와 초기 파트너 애플리케이션 팀을 신중하게 선택해야 합니다. -3. 플랫폼 팀은 기업 경영진의 지원을 얻고, 비지니스 가치 흐름에 미치는 영향을 보여줘야 합니다. +1. 플랫폼 팀은 플랫폼을 제품처럼 취급하고, 사용자와 함께 개발해야 한다. +2. 플랫폼 팀은 우선 순위와 초기 파트너 애플리케이션 팀을 신중하게 선택해야 한다. +3. 플랫폼 팀은 기업 경영진의 지원을 얻고, 비지니스 가치 흐름에 미치는 영향을 보여줘야 한다. -가장 중요한 것은 플랫폼을 고객 대상 제품으로 취급하고, 플랫폼의 성공이 사용자와 제품의 성공에 직접적으로 좌우된다는 점을 인식하는 것입니다. 따라서 플랫폼 팀은 애플리케이션 팀 및 다른 사용자와 협력하여 플랫폼의 기능과 사용자 경험의 우선 순위를 정하고, 계획하고, 구현하고, 반복하는 것이 중요합니다. 피드백 없이 기능과 경험을 공개하거나 탑다운 방식에 의존하여 도입을 추진하는 플랫폼 팀은 사용자의 저항과 반발을 불러일으키고 결국 약속한 가치를 상당 부분 놓칠 가능성이 높습니다. 이를 방지하기 위해 플랫폼 팀은 처음부터 제품 관리자를 포함시켜 로드맵을 공유하고, 피드백을 수집하며, 플랫폼 사용자의 요구 사항을 전반적으로 이해하고 반영해야 합니다. +가장 중요한 것은 플랫폼을 고객 대상 제품으로 취급하고, 플랫폼의 성공이 사용자와 제품의 성공에 직접적으로 좌우된다는 점을 인식하는 것이다. 따라서 플랫폼 팀은 애플리케이션 팀 및 다른 사용자와 협력하여 플랫폼의 기능과 사용자 경험의 우선 순위를 정하고, 계획하고, 구현하고, 반복하는 것이 중요하다. 피드백 없이 기능과 경험을 공개하거나 탑다운 방식에 의존하여 도입을 추진하는 플랫폼 팀은 사용자의 저항과 반발을 불러일으키고 결국 약속한 가치를 상당 부분 놓칠 가능성이 높다. 이를 방지하기 위해 플랫폼 팀은 처음부터 제품 관리자를 포함시켜 로드맵을 공유하고, 피드백을 수집하며, 플랫폼 사용자의 요구 사항을 전반적으로 이해하고 반영해야 한다. -플랫폼을 도입할 때는 우선적으로 지원해야 할 기능과 경험을 선택하는 것이 중요합니다. 파이프라인, 데이터베이스 및 관찰 가능성과 같이 자주 필요하지만 차별화되지 않은 기능을 먼저 시작하는 것이 좋습니다. 플랫폼 팀은 참여도가 높고 숙련된 소수의 애플리케이션 팀에 우선적으로 주력할 수도 있습니다. 이러한 팀의 상세한 피드백은 첫 번째 플랫폼 경험을 개선하고, 이러한 팀의 사람들은 나중에 플랫폼을 채택하는 사람들에게 플랫폼을 홍보하고 전파하는 데 도움을 줍니다. +플랫폼을 도입할 때는 우선적으로 지원해야 할 기능과 경험을 선택하는 것이 중요하다. 파이프라인, 데이터베이스 및 관찰 가능성과 같이 자주 필요하지만 차별화되지 않은 기능을 먼저 시작하는 것이 좋다. 플랫폼 팀은 참여도가 높고 숙련된 소수의 애플리케이션 팀에 우선적으로 주력할 수도 있다. 이러한 팀의 상세한 피드백은 첫 번째 플랫폼 경험을 개선하고, 이러한 팀의 사람들은 나중에 플랫폼을 채택하는 사람들에게 플랫폼을 홍보하고 전파하는 데 도움을 준다. -마지막으로, 플랫폼팀은 기업의 경영진으로부터 지원을 신속하게 확보하는 것이 매우 중요합니다. 많은 기업 경영진은 IT 인프라를 주요 비지니스 가치 흐름과 동떨어진 비용으로 인식하고 IT 플랫폼에 할당되는 비용과 리소스를 제한하려고 하기 때문에 구현이 제대로 이루어지지 않아 플랫폼 엔지니어팀의 의욕을 꺽을 수 있고 또한 플랫폼 사용자들을 떠나게 만들 수 있습니다. 이를 방지하기 위해 플랫폼 팀은 최종 제품 및 비지니스 가치 흐름에 직접적인 영향을 미친다는 것을 입증하고, 이를 통해서 제품 팀과 전략적인 협력 관계임을 보여주어야 합니다. +마지막으로, 플랫폼팀은 기업의 경영진으로부터 지원을 신속하게 확보하는 것이 매우 중요하다. 많은 기업 경영진은 IT 인프라를 주요 비지니스 가치 흐름과 동떨어진 비용으로 인식하고 IT 플랫폼에 할당되는 비용과 리소스를 제한하려고 하기 때문에 구현이 제대로 이루어지지 않아 플랫폼 엔지니어팀의 의욕을 꺽을 수 있고 또한 플랫폼 사용자들을 떠나게 만들 수 있다. 이를 방지하기 위해 플랫폼 팀은 최종 제품 및 비지니스 가치 흐름에 직접적인 영향을 미친다는 것을 입증하고, 이를 통해서 제품 팀과 전략적인 협력 관계임을 보여주어야 한다. -## 플랫폼팀을 어떻게 도와줄 것인가? +## 플랫폼 팀을 어떻게 도와줄 것인가? -이러한 당면 과제들을 통해 볼 때 플랫폼 팀은 다양한 책임에 가지고 있으며, 이는 과중한 업무량으로 이어진다는 것을 알 수 있습니다. 애플리케이션 팀과 마찬가지로 플랫폼 팀도 지원해야 하는 사용자와 팀의 수와 다양성이 증가함에 따라 이러한 당면 과제들은 더욱 커집니다. +이러한 당면 과제들을 통해 볼 때 플랫폼 팀은 다양한 책임에 가지고 있으며, 이는 과중한 업무량으로 이어진다는 것을 알 수 있다. 애플리케이션 팀과 마찬가지로 플랫폼 팀도 지원해야 하는 사용자와 팀의 수와 다양성이 증가함에 따라 이러한 당면 과제들은 더욱 커진다. -플랫폼 팀의 에너지를 특정 비즈니스 역량에 집중하는 것은 매우 중요합니다. 플랫폼 팀의 업무 부담을 줄이는 방법에는 다음이 포함됩니다. +플랫폼 팀의 에너지를 특정 비즈니스 역량에 집중하는 것은 매우 중요하다. 플랫폼 팀의 업무 부담을 줄이는 방법에는 다음이 포함된다. -1. 관리형 제공업체에서 이미 구현된 기능을 쓰기 보다 가장 가벼운 형태([TVP](platform\_whitepaper.md#glossary), thinnest viable platform)로 구동할 수 있는 플랫폼 계층을 구축하기 위해 노력해야 합니다. -2. 오픈 소스 프레임워크 및 툴킷(toolkits)을 이용해서 애플리케이션 팀이 사용할 문서, 템플릿 및 구조(compositions)를 만듭니다. -3. 플랫폼 팀이 도메인(Domain)과 고객 수에 맞게 적절한 인력을 확보하도록 합니다. +1. 관리형 제공업체에서 이미 구현된 기능을 쓰기 보다 가장 가벼운 형태([TVP](platform\_whitepaper.md#glossary), thinnest viable platform)로 구동할 수 있는 플랫폼 계층을 구축하기 위해 노력해야 한다. +2. 오픈 소스 프레임워크 및 툴킷(toolkits)을 이용해서 애플리케이션 팀이 사용할 문서, 템플릿 및 구조(compositions)를 만든다. +3. 플랫폼 팀이 도메인(Domain)과 고객 수에 맞게 적절한 인력을 확보하도록 한다. ## 어떻게 플랫폼의 성공을 측정할 수 있나요? -기업은 플랫폼 형태로의 도입 또는 전환이 위에서 설명한 가치와 속성을 제공하고 있는지 측정하고자 할 것입니다. 또한 이 백서 전체에서 내부 플랫폼을 제품으로 취급하는 것이 중요하며, 우수한 제품 관리는 제품 성능의 정량적, 정성적 측정에 달려 있다고 강조했습니다. 이러한 요구 사항을 충족하기 위해 내부 플랫폼 팀은 지속적으로 사용자 피드백을 수집하고 사용자 활동을 측정해야 합니다. +기업은 플랫폼 형태로의 도입 또는 전환이 위에서 설명한 가치와 속성을 제공하고 있는지 측정하고자 할 것이다. 또한 이 백서 전체에서 내부 플랫폼을 제품으로 취급하는 것이 중요하며, 우수한 제품 관리는 제품 성능의 정량적, 정성적 측정에 달려 있다고 강조했다. 이러한 요구 사항을 충족하기 위해 내부 플랫폼 팀은 지속적으로 사용자 피드백을 수집하고 사용자 활동을 측정해야 한다. -하지만 내부 플랫폼의 다른 측면과 마찬가지로 플랫폼 팀은 필요한 피드백을 수집하기 위해 가능한 최소한의 노력을 기울여야 합니다. 여기서는 몇 가지 지표를 제안하지만, 초기에는 사용자 행동에 대한 간단한 설문조사와 분석이 가장 유용할 수 있습니다. +하지만 내부 플랫폼의 다른 측면과 마찬가지로 플랫폼 팀은 필요한 피드백을 수집하기 위해 가능한 최소한의 노력을 기울여야 한다. 여기서는 몇 가지 지표를 제안하지만, 초기에는 사용자 행동에 대한 간단한 설문 조사와 분석이 가장 유용할 수 있다. -기업과 플랫폼 팀이 플랫폼의 영향을 이해하는 데 도움이 되는 지표의 범주는 다음과 같습니다: +기업과 플랫폼 팀이 플랫폼의 영향을 이해하는 데 도움이 되는 지표의 범주는 다음과 같다: ### 사용자 만족도 및 생산성 -많은 플랫폼이 추구하는 첫 번째 품질은 생산성을 높이기 위해 사용자 경험을 개선하는 것입니다. 사용자 만족도와 생산성을 반영하는 지표에는 다음이 포함됩니다 +많은 플랫폼이 추구하는 첫 번째 품질은 생산성을 높이기 위해 사용자 경험을 개선하는 것이다. 사용자 만족도와 생산성을 반영하는 지표에는 다음이 포함된다: * 활성 사용자 및 유지율(Retention): 프로비저닝된 기능 수 및 사용자 증가/이탈 포함 * "제품에 대한 사용자 만족도를 측정하는 "순추천지수(NPS, Net Promoter Score)" 또는 기타 설문조사 @@ -157,7 +157,7 @@ Please refer to the [Platform Engineering Maturity Model](https://tag-app-delive ### 조직 효율성 -많은 플랫폼에서 이루고자하는 또 다른 효과는 대규모 사용자 기반에 공통의 요구 사항을 효율적으로 제공하는 것입니다. 이는 사용자 셀프 서비스를 활성화하고 일일이 수작업으로 진행해야 하는 단계와 사람의 개입을 줄임과 동시에 안전과 규정 준수를 보장하는 정책을 구현함으로써 달성되는 경우가 많습니다. 공통 작업을 줄이는 데 있어 플랫폼의 효율성을 측정하려면 다음과 같은 측정 항목을 고려할 수 있습니다. +많은 플랫폼에서 이루고자하는 또 다른 효과는 대규모 사용자 기반에 공통의 요구 사항을 효율적으로 제공하는 것이다. 이는 사용자 셀프 서비스를 활성화하고 일일이 수작업으로 진행해야 하는 단계와 사람의 개입을 줄임과 동시에 안전과 규정 준수를 보장하는 정책을 구현함으로써 달성되는 경우가 많다. 공통 작업을 줄이는 데 있어 플랫폼의 효율성을 측정하려면 다음과 같은 측정 항목을 고려할 수 있다. * 데이터베이스 또는 테스트 환경과 같은 서비스 또는 기능 요청부터 이행까지의 지연 시간 * 새로운 서비스를 빌드하고 프로덕션 환경에 배포하는 데 걸리는 지연 시간 @@ -165,26 +165,26 @@ Please refer to the [Platform Engineering Maturity Model](https://tag-app-delive ### 제품 및 기능 제공 -내부 플랫폼의 궁극적인 목표는 고객에게 비즈니스 가치를 더 빠르게 제공하는 것이므로, 비즈니스 자체의 제품 및 기능 릴리스에 대한 영향을 측정하면 플랫폼의 목표가 달성되고 있음을 알 수 있습니다. Google의 DevOps 연구 및 평가(DORA) 연구소는 \[[5](https://cloud.google.com/blog/products/devops-sre/the-2019-accelerate-state-of-devops-elite-performance-productivity-and-scaling?hl=en)] 다음 메트릭을 추적할 것을 제안합니다. +내부 플랫폼의 궁극적인 목표는 고객에게 비즈니스 가치를 더 빠르게 제공하는 것이므로, 비즈니스 자체의 제품 및 기능 릴리스에 대한 영향을 측정하면 플랫폼의 목표가 달성되고 있음을 알 수 있다. Google의 DevOps 연구 및 평가(DORA) 연구소는 \[[5](https://cloud.google.com/blog/products/devops-sre/the-2019-accelerate-state-of-devops-elite-performance-productivity-and-scaling?hl=en)] 다음 메트릭을 추적할 것을 제안한다. * 배포 빈도 * 변경에 소요되는 시간(Lead time) * 장애 후 서비스 복원 시간 * 변경 실패율 -일반적으로 플랫폼 팀의 핵심 목표는 인프라 및 기타 IT 기능을 기업의 가치 흐름, 즉 제품에 맞춰 조정하는 것입니다. 따라서 궁극적으로 기업의 제품과 애플리케이션의 성공이 플랫폼의 성공을 가늠하는 진정한 척도입니다. +일반적으로 플랫폼 팀의 핵심 목표는 인프라 및 기타 IT 기능을 기업의 가치 흐름, 즉 제품에 맞춰 조정하는 것이다. 따라서 궁극적으로 기업의 제품과 애플리케이션의 성공이 플랫폼의 성공을 가늠하는 진정한 척도이다. ## 플랫폼의 기능들 -앞서 설명한 것처럼 클라우드 네이티브 컴퓨팅을 위한 플랫폼은 여러 지원 제공업체의 기능과 서비스를 함께 혼합하여 제공합니다. 이러한 제공업체는 같은 기업 내의 다른 팀일 수도 있고 클라우드 서비스 제공업체와 같은 타사일 수도 있습니다. 간단히 말해, 플랫폼은 기본 기능 제공업체와 애플리케이션 개발자와 같은 플랫폼 사용자를 연결하고, 그 과정에서 보안, 성능, 비용 거버넌스, 일관된 경험에 대해 원하는 모범 사례를 구현하고 시행합니다. 다음 그래픽은 제품, 플랫폼, 기능 제공업체 간의 관계를 보여줍니다. +앞서 설명한 것처럼 클라우드 네이티브 컴퓨팅을 위한 플랫폼은 여러 지원 제공업체의 기능과 서비스를 함께 혼합하여 제공한다. 이러한 제공업체는 같은 기업 내의 다른 팀일 수도 있고 클라우드 서비스 제공업체와 같은 타사일 수도 있다. 간단히 말해, 플랫폼은 기본 기능 제공업체와 애플리케이션 개발자와 같은 플랫폼 사용자를 연결하고, 그 과정에서 보안, 성능, 비용 거버넌스, 일관된 경험에 대해 원하는 모범 사례를 구현하고 시행한다. 다음 그래픽은 제품, 플랫폼, 기능 제공업체 간의 관계를 보여준다. -

제품과 플랫폼 그리고 기능 제공업체 간의 관계 그래프

+ -이 백서에서는 우수한 플랫폼과 플랫폼 팀을 구성하는 방법에 중점을 두었으며, 이제 마지막 섹션에서는 플랫폼이 실제로 제공할 수 있는 기능에 대해 설명하고자 합니다. 이 목록은 플랫폼 구축 담당자를 안내하기 위한 것으로, 일반적으로 클라우드 네이티브 애플리케이션에 필요한 기능을 포함하고 있습니다. 하지만 앞서 언급했듯이 좋은 플랫폼은 사용자의 요구 사항을 반영하므로 궁극적으로 플랫폼 팀은 사용자와 함께 플랫폼이 제공하는 기능을 선택하고 우선 순위를 정해야 합니다. +이 백서에서는 우수한 플랫폼과 플랫폼 팀을 구성하는 방법에 중점을 두었으며, 이제 마지막 섹션에서는 플랫폼이 실제로 제공할 수 있는 기능에 대해 설명하고자 한다. 이 목록은 플랫폼 구축 담당자를 안내하기 위한 것으로, 일반적으로 클라우드 네이티브 애플리케이션에 필요한 기능을 포함하고 있다. 하지만 앞서 언급했듯이 좋은 플랫폼은 사용자의 요구 사항을 반영하므로 궁극적으로 플랫폼 팀은 사용자와 함께 플랫폼이 제공하는 기능을 선택하고 우선 순위를 정해야 한다. -기능들은 도메인의 특성에 따라 여러가지로 특성 및 속성이 나누어질 수 있습니다. 예를 들어, 관찰 가능성에는 메트릭, 추적 및 로그를 수집 및 게시하고 비용 및 리소스 사용량을 모니터링하기 위한 기능이 포함될 수 있습니다. 이 때 조직에서는 각 기능 또는 요소의 필요성과 우선순위를 고려해서 적용해야 합니다. 추후 CNCF 발행물은 각 도메인에 대해 더 확장해서 배포할 수 있습니다. +기능들은 도메인의 특성에 따라 여러가지로 특성 및 속성이 나누어질 수 있다. 예를 들어, 관찰 가능성에는 메트릭, 추적 및 로그를 수집 및 게시하고 비용 및 리소스 사용량을 모니터링하기 위한 기능이 포함될 수 있다. 이 때 조직에서는 각 기능 또는 요소의 필요성과 우선 순위를 고려해서 적용해야 한다. 추후 CNCF 발행물은 각 도메인에 대해 더 확장해서 배포할 수 있다. -다음은 클라우드 네이티브 컴퓨팅을 위한 플랫폼을 구축할 때 고려해야 할 기능 영역입니다. +다음은 클라우드 네이티브 컴퓨팅을 위한 플랫폼을 구축할 때 고려해야 할 기능 영역이다. 1. **웹 포털**: 제품 및 기능을 관찰하고 할당 및 배포 관리(provisioning)함 2. **API(및 CLI)**: 제품 및 기능을 자동으로 할당 및 배포 관리(provisioning)함 @@ -194,16 +194,17 @@ Please refer to the [Platform Engineering Maturity Model](https://tag-app-delive 6. **개발 환경**: 사용할 수 있도록 설치 구성된(hosted) IDE와 원격 연결 도구 제공 7. **관찰 가능성**: 계측 및 대시보드를 사용하여 서비스 및 제품을 모니터링(기능, 성능 및 비용 관찰 포함) 8. **인프라(Infrastructure) 서비스**: 런타임이 동작가능한 컴퓨터, 프로그래밍에 사용할 네트워크, 블록 및 볼륨 스토리지를 제공 -9. **데이터 서비스**: 데이터베이스, 캐시, 객체 저장소, 메시징 및 이벤트 서비스(서비스 브로커, 큐, 이벤트 패브릭을 포함) 제공 -10. **사용자 인증 및 시크릿(Secret) 관리 서비스**: 서비스 및 사용자 ID 및 권한 부여, 인증서 및 키 발급, 정적 시크릿 저장소 제공 -11. **보안 서비스**: 코드 및 아티팩트의 정적 분석, 런타임 분석, 정책 적용을 제공 -12. **아티팩트(Artifact ) 저장소**: 컨테이너 이미지 및 언어별 패키지, 사용자 지정 바이너리 및 라이브러리, 소스 코드의 저장 제공 +9. **데이터 서비스**: 데이터베이스, 캐시, 객체 저장소 제공 +10. **메시징 및 이벤트 서비스**: 브로커, 큐, 이벤트 패브릭 제공 +11. **사용자 인증 및 시크릿(Secret) 관리 서비스**: 서비스 및 사용자 ID 및 권한 부여, 인증서 및 키 발급, 정적 시크릿 저장소 제공 +12. **보안 서비스**: 코드 및 아티팩트의 정적 분석, 런타임 분석, 정책 적용을 제공 +13. **아티팩트(Artifact ) 저장소**: 컨테이너 이미지 및 언어별 패키지, 사용자 지정 바이너리 및 라이브러리, 소스 코드의 저장 제공 -다음 표는 독자들이 각 기능을 기존 CNCF 또는 CDF 프로젝트와 느슨하게 연관시켜 파악하는 데 도움을 주기 위한 것입니다. +다음 표는 독자들이 각 기능을 기존 CNCF 또는 CDF 프로젝트와 느슨하게 연관시켜 파악하는 데 도움을 주기 위한 것이다. | 기능 | 설명 | CNCF/CDF 프로젝트 예시 | | ---------------------- | -------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------- | -| 프로비저닝 및 관찰 기능을 위한 웹 포털 | 문서, 서비스 카탈로그 및 프로젝트 템플릿을 게시합니다. 시스템 및 기능에 대한 원격 분석을 게시 | Backstage, Skooner, Ortelius | +| 프로비저닝 및 관찰 기능을 위한 웹 포털 | 문서, 서비스 카탈로그 및 프로젝트 템플릿을 게시한다. 시스템 및 기능에 대한 원격 분석을 게시 | Backstage, Skooner, Ortelius | | 자동 프로비저닝 기능을 위한 API | 자동으로 생성, 업데이트, 삭제 및 관찰 기능을 위한 구조화된 형식 | Kubernetes, Crossplane, Operator Framework, Helm, KubeVela | | 최적(Golden) 경로 템플릿 및 문서 | 신속한 프로젝트 개발을 위해 잘 통합된 코드와 기능으로 구성된 템플릿을 제공 | ArtifactHub | | 제품 구축 및 테스트를 위 한 자동화 | 디지털 제품 및 서비스의 빌드 및 테스트를 자동화 | Tekton, Jenkins, Buildpacks, ko, Carvel | @@ -213,6 +214,7 @@ Please refer to the [Platform Engineering Maturity Model](https://tag-app-delive | 인프라 서비스 | 애플리케이션 코드 실행, 애플리케이 션 구성 요소 연결 및 애플리케이션의 데이터 유지 | Kubernetes, Kubevirt, Knative, WasmEdge CNI, Istio, Cilium, Envoy, Linkerd, CoreDNS Rook, Longhorn, Etcd | | 데이터 서비스 | 애플리케이션을 위한 구조화된 데이터 유지 | TiKV, Vitess, SchemaHero | | 메시징 및 이벤트 서비스 | 애플리케이션이 서로 비동기적으로 통신할 수 있도록 지원 | Strimzi, NATS, gRPC, Knative, Dapr | -| 신원인증 및 시크릿(Secret) 서비스 | 워크로드에 리소스와 기능을 사용할 수 있는 로케이터와 암호가 있는지 확인합니다. 서비스가 다른 서비스에 자신을 식별할 수 있도록 지원 | Dex, External Secrets, SPIFFE/SPIRE, Teller, cert-manager | -| 보안 서비스 | 런타임 동작을 관찰하고 이상 징후 를 보고/수정합니다. 빌드 및 아티팩트에 취약점이 없는지 확인합니다. 엔터프라이즈 요구 사항에 따라 플랫폼에서 활동을 제한하고 이상 징후를 알리거나 수정 | Falco, In-toto, KubeArmor, OPA, Kyverno, Cloud Custodian | -| 아티팩트 스토리지 | 프로덕션에서 사용할 수 있도록 빌드된 아티팩트를 저장, 게시 및 보호합니다. 타사 아티팩트를 캐시하고 분석합니다. 그리고 소스 코드를 저장하는 기능도 제공 | ArtifactHub, Harbor, Distribution, Porter | +| 신원인증 및 시크릿(Secret) 서비스 | 워크로드에 리소스와 기능을 사용할 수 있는 로케이터와 암호가 있는지 확인한다. 서비스가 다른 서비스에 자신을 식별할 수 있도록 지원 | Dex, External Secrets, SPIFFE/SPIRE, Teller, cert-manager | +| 보안 서비스 | 런타임 동작을 관찰하고 이상 징후 를 보고/수정한다. 빌드 및 아티팩트에 취약점이 없는지 확인한다. 엔터프라이즈 요구 사항에 따라 플랫폼에서 활동을 제한하고 이상 징후를 알리거나 수정 | Falco, In-toto, KubeArmor, OPA, Kyverno, Cloud Custodian | +| 아티팩트 스토리지 | 프로덕션에서 사용할 수 있도록 빌드된 아티팩트를 저장, 게시 및 보호한다. 타사 아티팩트를 캐시하고 분석한다. 그리고 소스 코드를 저장하는 기능도 제공 | ArtifactHub, Harbor, Distribution, Porter | + From c1ef781cf9dd0bcfe1ac1a04ed7ed5d2c2379451 Mon Sep 17 00:00:00 2001 From: Eeap Date: Sun, 5 May 2024 12:10:00 +0900 Subject: [PATCH 2/4] docs(platforms): add maturity-model contents in korea docs Signed-off-by: Eeap --- .../ko/wgs/platforms/maturity-model/README.md | 10 + .../wgs/platforms/maturity-model/v1/index.md | 501 ++++++++++++++++++ 2 files changed, 511 insertions(+) create mode 100644 website/content/ko/wgs/platforms/maturity-model/README.md create mode 100644 website/content/ko/wgs/platforms/maturity-model/v1/index.md diff --git a/website/content/ko/wgs/platforms/maturity-model/README.md b/website/content/ko/wgs/platforms/maturity-model/README.md new file mode 100644 index 00000000..90fd8500 --- /dev/null +++ b/website/content/ko/wgs/platforms/maturity-model/README.md @@ -0,0 +1,10 @@ +# Platform Engineering Maturity Model + +CNCF TAG App Delivery maintains and publishes this paper describing how +organizations can review and grow their platform engineering maturity. + +v1 was completed in October 2023; improvements and iterations continue in the +[`latest`](./latest/) directory. + +Currently, the edition in the `v1` directory is published to TAG App Delivery's website at +. diff --git a/website/content/ko/wgs/platforms/maturity-model/v1/index.md b/website/content/ko/wgs/platforms/maturity-model/v1/index.md new file mode 100644 index 00000000..35baa853 --- /dev/null +++ b/website/content/ko/wgs/platforms/maturity-model/v1/index.md @@ -0,0 +1,501 @@ +--- +title: "플랫폼 엔지니어링 성숙도 모델" +pdf: https://github.com/cncf/tag-app-delivery/raw/main/platforms-maturity-model/v1/assets/platform-eng-maturity-model-v1.0.pdf +version_info: https://github.com/cncf/tag-app-delivery/tree/main/platforms-maturity-model/README.md +description: "This maturity model intends to provide tactical guidance to users seeking to adopt the patterns discussed in the Platforms Definition White Paper. That paper suggests why and what to build; this document will begin to describe how to plan to build it. The target audience is CTOs, Directors of engineering, lead engineers, and architects seeking to evaluate their current state and environment and identify opportunities for improvement.

+This document refers to, enhances, and follows similar standards as the following related documents:
+[Cloud Maturity Model](https://maturitymodel.cncf.io/)
+[Platforms Definition White Paper](https://tag-app-delivery.cncf.io/whitepapers/platforms/)" +type: whitepapers +--- + + + + +## Introduction + +CNCF's initial [Platforms Definition white paper](https://tag-app-delivery.cncf.io/whitepapers/platforms/) describes what internal platforms for cloud computing are and the values they promise to deliver to enterprises. But to achieve those values an organization must reflect and deliberately pursue outcomes and practices that are impactful for them, keeping in mind that every organization relies on an internal platform crafted for its own organization - even if that platform is just documentation on how to use third party services. This maturity model provides a framework for that reflection and for identifying opportunities for improvement in any organization. + +## What is platform engineering? + +Inspired by the cross-functional cooperation promised by DevOps, platforms and platform engineering have emerged in enterprises as an explicit form of that cooperation. Platforms curate and present common capabilities, frameworks and experiences. In the context of this working group and related publications, the focus is on platforms that facilitate and accelerate the work of [internal users]({{< ref "/wgs/platforms/glossary#platform-users" >}}) such as product and application teams. + +[**Platform engineering**]({{< ref "/wgs/platforms/glossary#platform-engineering" >}}) is the practice of planning and providing such computing platforms to developers and users and encompasses all parts of platforms and their capabilities — their people, processes, policies and technologies; as well as the desired business outcomes that drive them. + +Please read the [CNCF Platforms Definition white paper](https://tag-app-delivery.cncf.io/whitepapers/platforms/) first for complete context. + +## How to use this model + +As platform engineering has risen in prominence over the last few years, some patterns have become apparent. By organizing those patterns and observations into a progressive maturity model, we aim to orient [platform teams]({{< ref "/wgs/platforms/glossary#platform-teams" >}}) to the challenges they may face and opportunities to aim for. Each aspect is described by a continuum of characteristics of different teams and organizations at each level within the aspect. We expect readers to find themselves in the model and identify opportunities in adjacent levels. + +Of note, each additional level of maturity is accompanied by greater requirements for funding and people's time. Therefore, reaching the highest level should not be a goal in itself. Each level describes qualities that should appear at that stage. Readers must consider if their organization and their current context would benefit from these qualities given the required investment. + +Keep in mind that each aspect is meant to be evaluated and evolved independently. However, as in any socio-technical system these aspects are complex and interrelated. Thus you may find that to improve in one aspect you must reach a minimum level in another aspect too. + +It's also important to recognize that implementations of platforms vary from organization to organization. Make sure to evaluate the current state of _your_ group’s overall cloud native transformation. A phenomenal resource to leverage for this evaluation is the [Cloud Native Maturity Model](https://maturitymodel.cncf.io/). + +Finally, this model encourages organizations to mature their platform engineering discipline and their resulting platforms through intentional planning. Such planning and discipline themselves are a requirement for mature platform development and ongoing evolution. + +In general, keep in mind that mapping your organization into a model captures current state _to enable_ progressive iteration and improvement. [Martin Fowler](https://martinfowler.com/bliki/MaturityModel.html) says it well: "The true outcome of a maturity model assessment isn't what level you are at but the list of things you need to work on to improve. Your current level is merely a piece of intermediate work in order to determine that list of skills to acquire next." In that vein, seek to find yourself in the model then identify opportunities in adjacent levels. + +## Context behind this work + +It's valuable to understand the context a document has been written in. The following sections lay out some context behind the model as well as some expectations for you, the reader. + +### Intended audiences + +Each reader brings a unique context and will take unique learnings from this model. Following are some personas we have in mind, along with their possible motivations for engaging with this model: + +* **CTOs, VPs, and directors of technology**: Leaders looking to map a path to digital transformation and greater developer productivity +* **Engineering managers**: Groups and individuals seeking to empower engineers to provide value with less overhead and higher efficiency +* **Enterprise architects**: Individuals navigating the modern technology landscape who seek a value- and solution-oriented perspective on technology problems +* **Platform engineers and platform product managers**: Teams and people seeking to build the best possible experience for platform builders and platform users +* **Product vendors and project maintainers**: Organizations and engineers wishing to design tools and deliver messages to enable users to succeed with platforms and capabilities +* **Application and product developers**: Platform users seeking to understand in more detail what they might expect of an internal platform + +### Understanding the levels + +This model is not meant to classify an organization or platform team as wholly “Level 1” or “Level 4.” Each aspect should be considered independently of the others; the characteristics of each level represent a continuum within that aspect but are not necessarily coupled to other aspects at the same level. Even more so, many organizations will see characteristics of more than one level being applicable across their teams and work. This is because no level is inherently good or bad, only contextual to the team’s goals. + +The labels for each level are intended to reflect the impact of platform engineering at your organization. As you recognize your organization at a given level you will gain insight into opportunities which follow at the next ones. Lower-numbered levels comprise more tactical solutions while higher-numbered ones are more strategic. + +This yields a potential process for platform development and maturity similar to other digital product development: first recognize a problem and need for a new solution, next develop minimally-viable products as hypothesized solutions, third iterate to better solve the problem and ensure fit for your customers and finally scale and optimize the product to solve the problem for many teams and users. + +Similar to the [CNCF Cloud Native Maturity Model](https://maturitymodel.cncf.io/), this model highlights that successful business outcomes can only be achieved through balancing people, process, and policy alongside technology. Notably, this model introduces aspects which are often not fully in the remit of a single internal team, but rather require cooperation across the engineering department and quite often the wider organization. + +### But it doesn't seem to fit + +That’s perfectly fine! All organizations and groups have dynamics and parameters that are specific to them. + +Keep in mind that the goal of this paper isn’t to prescribe a rigid formula, but rather a framework that you can apply to your circumstances. Every single word may not be relevant to you, but we hope the content will inspire you to introspect on your own platform journey, taking what makes sense and leaving the rest. + +The objective of this model is to provide a tool to help guide platform engineering practitioners, stakeholders, and other interested parties on their journeys. Platform design and implementation is not an exact science, but rather depends on the needs of an individual project, an organization and a particular time and place. + + +## Model table + +|
Aspect
| | Provisional | Operational | Scalable | Optimizing | +|:---------------------------------------|:-------------------------------------------------------------------------------------------|:-----------------------|:----------------------|:-----------------------|:-----------------------------| +| [Investment](#Investment) | _How are staff and funds allocated to platform capabilities?_ | Voluntary or temporary | Dedicated team | As product | Enabled ecosystem | +| [Adoption](#Adoption) | _Why and how do users discover and use internal platforms and platform capabilities?_ | Erratic | Extrinsic push | Intrinsic pull | Participatory | +| [Interfaces](#Interfaces) | _How do users interact with and consume platform capabilities?_ | Custom processes | Standard tooling | Self-service solutions | Integrated services | +| [Operations](#Operations) | _How are platforms and their capabilities planned, prioritized, developed and maintained?_ | By request | Centrally tracked | Centrally enabled | Managed services | +| [Measurement](#Measurement) | _What is the process for gathering and incorporating feedback and learning?_ | Ad hoc | Consistent collection | Insights | Quantitative and qualitative | + +## Model Detail + +
+{{< tabs tabTotal="6">}} +{{< tab tabName="Investment" >}} + +

How are staff and funds allocated to platform capabilities?

+ +Investment in platforms and platform engineering is the process of allocating budget and people to build and maintain common capabilities. It is common for initiatives to be described as organically built from the bottom up, or driven through top down initiatives. In either case, it is the ability to invest sustained effort that drives high-impact work. This aspect captures how the scale and breadth of investment can impact platform success. + +### Level 1, Provisional — Voluntary or temporary + +Individual capabilities may exist to provide common foundations for common or critical functionality. These capabilities are built and maintained out of necessity rather than planned and intentionally funded. + +These capabilities are built and maintained by people assigned temporarily or voluntarily; no central funding or staffing are intentionally allocated to them. They depend on the current tactical requirements of their users. + +#### Characteristics: + +* "Hit" or "tiger" teams are built to tackle urgent requirements. These teams are short lived and not assigned nor granted the time to provide long term planning and support. +* Migrations, improvements, or enhancements are often considered "nice to have" work items and rely on "research" or "hack day" efforts. +* Process improvements or automation may be introduced while tackling a new requirement such as an urgent security patch, however there is not support to build the solutions in a reusable or sustainable way. +* Employees complain of burn out and frustration with the amount of work they are doing outside their core role. + +#### Example Scenarios: + +* There is a specific employee who is viewed as the test environment expert. While this employee means well, their attempt to enable better test environments despite limited investment has led to increased risk since there is no maintenance of their solution and no shared understanding of how to triage a broken test environment. +* Engineers are encouraged to invest in capability improvements when there is no pressure from management for revenue generating features. This translates to the last few days of some sprints where they prioritize automating and improving parts of their CI/CD pipeline. It is not uncommon for these improvements to come in bursts as there can be months of overly full sprints not allowing for time on these side endeavors. + +### Level 2, Operationalized — Dedicated team + +Budget and people are allocated for persistent people and resource support. The assigned people are tasked with providing a set of commonly-required capabilities to speed up software delivery. Often these teams focus on meeting reactive technical requirements. They may be called DevOps, Engineering Enablement, Developer Experience (DevEx or DevX), Shared Tools, a Centre-Of-Excellence, or even Platform. They're funded centrally and treated as cost centers; their impact on direct value streams and application teams is not measured. It can be hard to map the impact of platform teams at this level on the organization and its value streams, which can make it hard to sustain and continue funding such teams. + +#### Characteristics: + +* The team is made up of nearly all technical generalists. +* Team budget may include the infrastructure costs associated with their work leading to often being a key point in budget conversations. +* Backlog items range a number of technologies, leading to frequent and large context switches. +* This team is often the first to fill a gap that is not yet being addressed, even if not in the declared scope for the team. This team takes ownership of resources that don't have an owner. +* Assigned people rarely have the time or experience with customer research to validate their designs or implementations. + +#### Example Scenarios: + +* Application developers raise an issue with the long build time for their applications. A centralized team is tasked with reducing the build time by 50%. They solve this by doubling the size and quantity of the CI runners given they are not close enough to the software to individually improve the application builds. This creates a budget concern for their centralized team as the productivity gain is not directly measurable against this increased infrastructure cost. + +### Level 3, Scalable — As product + +Investment in internal platforms and their capabilities is similar to investment in an enterprise's outbound products and value streams: based on the value they are expected to provide to their customers. Product management and user experience are explicitly considered and invested in. A chargeback system may be used to reflect platforms' impact on their customers' own direct value streams and products. The enterprise allocates funds and staff to the appropriate initiatives by using data-driven performance indicators and feedback loops. Platform teams can ultimately optimize the business itself and contribute to increased profitability. + +#### Characteristics: + +* Platform teams staff roles not traditionally found in internal serving or technical teams, for example, product management and user experience. +* The team publicizes a roadmap internally to the organization, which indicates the value delivered and high level feature targets. +* Features are tested for both implementation quality and user experience during design, delivery, and post deployment. +* Feature removal is a key part of the conversation, the goal is to have a well supported, well used suite of capabilities instead of a sprawling estate that may not be maintained. + +#### Example Scenarios: + +* Data derived from platform usage metrics inform decisions to allocate funds and staff to the most impactful initiatives. + +### Level 4, Optimizing — Enabled ecosystem + +Platform teams find ways to increase organization-wide efficiency and effectiveness beyond basic capabilities. Core platform maintainers intentionally strive to optimize time-to-market for new products, reduce costs across the enterprise, enable efficient governance and compliance for new services, scale workloads quickly and easily, and other cross-cutting requirements. These core maintainers are focused on enabling capability specialists to seamlessly integrate their requirements and offerings into existing and new parts of platforms. Further, the organization focuses people and resources from specialist domains like security, performance, quality on engaging with provided platform frameworks to introduce advanced features that can enable product teams to accelerate their adherence to company goals without depending on a centralized team backlog. + +#### Characteristics: + +* It becomes a priority to enable specialists to extend platform capabilities and introduce new ones. +* The organization can centralize specialists allowing their knowledge and support to be spread through platform capabilities. + +#### Example Scenarios: + +* Marketing works with platform builders to introduce consistent user tracking in order to attribute marketing efforts to product outcomes. +* Automation initiative reduces human time to provision databases by 30 minutes per instance, saving $10m/year. + +{{< /tab >}} +{{< tab tabName="Adoption" >}} + +

Why and how do users discover and use internal platforms and platform capabilities?

+ +Adoption describes not only how and how much an organization uses platform capabilities, but also what motivates them to do so. In the early stages, many target users may not realize they are using a platform at all, rather they see their tools as an ad hoc collection of capabilities from various internal sources. This may mature into a group of capabilities that is consistently managed and presented to users — that is, one or more platforms. As the capabilities become more refined and discoverable, it is common that the drive for platform use moves away from more external motivations like mandates or incentives. This leads to users self-selecting into platform capabilities and ideally even investing their own efforts into the wider platform ecosystem. + +
+ +
+
+A diagram to indicate a common growth pattern for platform adoption. This showcases the often slow start driven mainly by platform builders. Once platforms provide enough value to users, growth becomes more pulled by the users causing a steeper adoption curve. +
+
+
+
+ +### Level 1, Provisional — Erratic + +Adoption of shared platforms and capabilities is sporadic and inconsistent. No organization-wide strategy or guidance exists for choosing and integrating required backing services and technologies. Individual teams might leverage platform practices to improve their own processes, but there is no coordinated effort or standardization across the organization. This level of adoption is characterized by the absence of a coherent approach and the idea that external tools are more effective than those provided internally. + +#### Characteristics: + +* One-off tools, services, and capabilities are managed by and consumed by various teams and departments in the organization. +* Provider-managed (aka "cloud") services are adopted and used inconsistently and without standard practices and policies, as internal configurations are hard to find or use. +* App and service teams discover tools and capabilities haphazardly, via rumors and chance conversations rather than through a more centralized process. +* Coordination and reuse of components and capabilities is driven only by end users (application teams), if at all. +* Product teams each maintain their own set of scripts or tools to deploy their applications. + +#### Example Scenarios: + +* A banking service requires a database. A developer finds out from a friend on another team that they can request an AWS account and set up an RDS database. From another team they find a Terraform script to provision that database. For monitoring they use CloudWatch on an ad hoc basis; they copy secrets from the AWS console to an instance of Hashicorp Vault manually before running the Terraform script. + +### Level 2, Operationalized — Extrinsic push + +The organization recognizes the value of shared platforms and capabilities and strives to encourage and nurture them. Internal directives incentivize or even require use of shared platform services for some use cases. Some product teams use platform capabilities more than others; capabilities cover typical use cases in the organization but not unusual ones; and it is difficult to add those outliers to the common platform. + +User discovery of capabilities and how to use them is inconsistent; it is possible a user on a product team won't discover a supported capability unless directed there by a platform team. + +#### Characteristics: + +* Some degree of external impetus leads to use of platform capabilities, for example: + * Incentives such as personal reviews + * Mandates such as requiring use for production releases or receiving funding +* The utilization of platform capabilities is fragmented — users may take advantage of one capability but might not be aware of, or interested in adopting, others that are available. +* Users have low motivation to learn how to use platform capabilities and rely heavily on collaboration with the providers through forums like office hours or help desk. +* Platform users are encouraged to join informal communities of practice to share problems and solutions but attendance may be limited. + +#### Example Scenarios: + +* An engineering organization decides on a standard deployment tool and instructs all teams to use it. New processes (communication of release notes, etc) are built around that standard. Teams are instructed to stop using other sorts of deployment scripts and use the common tool instead. This is difficult for some teams whose needs are not met by the new process but do not understand or are not allowed to extend it. + +### Level 3, Scalable — Intrinsic pull + +Users on product and service teams choose to use platforms and their capabilities because of the clear value they provide in reducing cognitive load on product teams while providing higher quality supporting services. Documentation and ergonomic interfaces enable product team users to quickly provision and use platform capabilities. Users choose internal platform implementations over alternatives such as developing the capability themselves or hiring a provider. + +#### Characteristics: + +* Platform adoption is self-sustaining –The primary driver for core adoption is not an external impetus or incentive which mandates users use platform offerings – rather it is the values of these platform offerings themselves which draws users to them. +* After using and appreciating one or some platform capabilities, users seek out others and find the experience is similar across capabilities. There is an expectation that an individual capability is not isolated, rather it is one feature among a larger platform feature set. +* Platform teams encourage the natural adoption of platforms by gathering user feedback, sharing roadmaps and maintaining open forums for conversation with users. +* Application and product teams value platform capabilities enough to pay for them, e.g., via a chargeback system. +* Users can share feedback and learn about upcoming features through open forums and shared roadmaps. +* Self-serve portals, golden-path templates, and other documents enable rapid use. + +#### Example Scenarios: + +* An application team previously had success requesting a new database. Their process was easy to understand and required almost no waiting time. In addition, key capabilities like backups and monitoring that allowed the team to progress their use all the way to production without issue were included. This experience meant that when the team later needed a queue, their first instinct was to check for an internal platform option. While they originally intended to use a specific queue technology, in the end, they chose to use the one offered internally since they knew how well integrated the solution would be for their organization. + +### Level 4, Optimizing — Participatory + +Users from product teams further invest in platform capabilities by joining the ecosystem and contributing back to it. Some contributions improve and fix existing capabilities; others introduce new capabilities and features to address new use cases. Processes and services are defined and enable users to identify requirements and coordinate contributions amongst several product and platform teams. New capabilities are published via consistent interfaces and portals and with complete documentation and standard versioning. + +#### Characteristics: + +* Users in app/service teams are empowered to contribute fixes, features, and feedback for platform capabilities. +* External projects and standards are strategically leveraged to reduce maintenance costs, accelerate new feature delivery, and use organization headcount most effectively. +* New capabilities and enhancements are coordinated asynchronously through issue boards and pull requests. Documents and checklists enable self-driven development by contributors. +* Developer advocates and internal ambassadors build and support an internal user community that extends platform ownership to app and service team contributors, too. +* Use of platform capabilities is viewed as the best way of working at the organization by both leadership and individual contributors. +* Platform engineers participate in product team planning to learn of requirements and suggest relevant existing capabilities. + +#### Example Scenarios: + +* A team wants an alternative backup plan. After proposing this as a general offering, it is deemed low priority due to minimal reuse. The proposing team chooses to integrate their solution into the platform framework and make it available to the organization. It is originally an alpha offering but once it meets all of the operational requirements can be promoted to a core platform capability. + +{{< /tab >}} +{{< tab tabName="Interfaces">}} + +

How do users interact with and consume platform capabilities?

+ +The interfaces provided by platforms affect how users interact with these platform offerings to provision, manage, and observe capabilities. Interfaces can include ticketing systems, project templates, and graphical portals as well as automatable APIs and command-line (CLI) tools. + +Key characteristics of an interface include how discoverable and user-friendly it is during key user journeys like initial request, maintenance, or incident triage. Higher levels of maturity here reflect more integrated, consistent, automated, and supported interfaces. + +### Level 1, Provisional — Custom processes + +A collection of varying processes exists to provision different capabilities and services, but the consistency of the interface is not considered. Custom tailor-made processes address the immediate needs of individuals or teams and are reliant on manual intervention even if the provider uses some automated implementation scripts. + +Knowledge of how to request these solutions is shared from person to person. The process for requesting a service lacks standardization and consistency. Provisioning and using a platform service likely requires deep support from the capability provider. + +Lack of central requirements and standards makes this level appropriate when the company has not yet identified and documented expectations. It can be particularly effective for teams at early stage companies or platform efforts. In these environments teams are provided the freedom to evolve processes and capabilities to their needs, allowing them to deliver more quickly and pay the price of standardization only when necessary later on. + +#### Characteristics: + +* User interaction is not a key topic of discussion and rarely (if ever) are interactions tested during design and delivery of new capabilities. +* Capabilities are mainly provided through manual requests, though providers may choose to automate some or all of the activities necessary to provision a user request. +* Requests that are on the face “simple” become complex due to finding out the right process to follow +* Sometimes a process appears to be sanctioned, but users run into issues when a different department or team gets involved + +#### Example Scenarios: + +* An application team wants to performance test their new change. To do this, they want an isolated environment that contains enough test data to get an accurate performance read. The last time they had this request a former teammate was able to get access to an environment, but they have since moved on and no one knows how to recreate it. In the end, they are connected to an engineer on the infrastructure team who is able to provision them an environment in a few days. +* A team in the exploratory phases of product development uses a bespoke process to provision a new cloud service without needing to validate their solution warrants further investment. + +### Level 2, Operationalized — Standard tooling + +Consistent, standard interfaces for provisioning and observing platforms and capabilities exist and meet broad needs. Users are able to identify what capabilities are available and are enabled to request capabilities that they require. + +"Paved roads" or "golden paths", in the form of documentation and templates, are provided. These resources define how to provision and manage typical capabilities using compliant and tested patterns. While some users are able to use these solutions on their own, the solutions often still require deep domain expertise and therefore support from maintainers is still vital. + +#### Characteristics: + +* Technical solutions are built-in tools specific to their problem domain, not always tools familiar to the users. +* There is investment in a common path; however, deviating from that path quickly uncovers few customization options as the focus was on building a single option. +* Given standardization, informal internal groups are able to form and gather to share good practices and overcome shared problems. +* There may be drift on capability implementation as teams take templates, customize them, and then cannot merge in changes from the centralized team. + +#### Example Scenarios: + +* A centralized team curates a library of Terraform modules, Kubernetes controllers, and CRDs for provisioning different types of infrastructure. +* A shared location includes comprehensive documents about solutions across the organization. + +### Level 3, Scalable — Self-service solutions + +Solutions are offered in a way that provides autonomy to users and requires little support from maintainers. The organization encourages and enables solutions to provide consistent interfaces that enable discoverability and portability of user experience from one capability to another. While self-service, the solutions do require team awareness and implementation. In order to improve this experience there may be a guided and simplified internal language which enables users to adopt and integrate platform capabilities more quickly. This generates a user-centric, self-serviceable, and consistent collection of capabilities. + +#### Characteristics: + +* Solutions are provided as “one-click” implementations, enabling teams to benefit from a capability without needing to understand how they are provisioned. +* While the solutions are easy to create, there may not be as much usability built into the day 2 and beyond management of the solution. +* There continues to be a narrow path of available solutions, leaving users with unique requirements unsure how to proceed. + +#### Example Scenarios: + +* An API is provided which abstracts the creation and maintenance of databases and provides users with any information they require to leverage that platform capability such as a connection string, location for secret data, and dashboard with observability data. + +### Level 4, Optimizing — Managed services + +Platform capabilities are transparently integrated into the tools and processes that teams already use to do their work. Some capabilities are provisioned automatically, such as observability or identity management for a deployed service. When users hit the edges of the provided services, there is an opportunity to move past automated solutions and customize for their needs without leaving the internal offerings because platform capabilities are considered building blocks. These building blocks are used to build transparent and automatic compositions to meet the higher-level use cases while enabling deeper customization where necessary. + +#### Characteristics: + +* It is clear what capabilities are differentiating for the organization and which are not, allowing the internal teams to invest in custom solutions only where they can not leverage industry standards. +* While capabilities are surfaced in a consistent way, there is no one way to use a capability. Some are best suited as CLI tools for use in scripts whereas others benefit from integration into where the user is writing code in their editors and IDEs. +* The value of individual capabilities is extended with a focus on the flow of both software development and release, leading to a focus on how to combine capabilities into higher level offerings. +* While capabilities are often provided in packages, super users are enabled to decompose these higher level offerings in order to optimize when and where they need to. + +#### Example Scenarios: + +* Observability agents are injected into every workload and an OIDC proxy is placed in front of all applications. +* By default every new project receives a space in a task runner (pipelines) and a runtime environment (K8s namespace), however a project can opt into other options such as serverless runtime. +* From a catalog in a Service Now portal a user selects "Provision a Database." Automation provisions an RDS database and sends a URL and location to get credentials to the user. + +{{< /tab >}} +{{< tab tabName="Operations">}} + +

How are platforms and their capabilities planned, prioritized, developed and maintained?

+ +Operation of platforms means running and supporting its capabilities and their features over their whole lifetime, including acceptance of new requests, initial releases, upgrades and extensions, ongoing maintenance and operations, user support, and even deprecation and termination. Organizations and their platform teams choose platforms and capabilities to create and maintain and can prioritize the most valuable and impactful initiatives. + +Notably, most of the work to provide a capability is expended after its initial release — in providing seamless upgrades, new and improved features, operational support, and end-user enablement and education. Therefore an impactful, valuable platform will plan in advance and manage their platform for long-term sustainable operations and reliability. + +### Level 1, Provisional — By request + +Platforms and capabilities are developed, published, and updated reactively, based on ad hoc product team requests and requirements. Product teams themselves may even need to plan and build the capabilities they require. + +Teams who build a new capability, whether dedicated centralized teams or application teams meeting their own needs, take only informal responsibility for supporting others using it. They are not expected to actively maintain it and few processes exist to vet the quality of the offering. In this level, implementations are often ignored until a security vulnerability is discovered, a bug prevents use, or a new requirement arrives, at which point another reactive plan may be quickly implemented. + +#### Characteristics: + +* Capabilities are created to meet the pressing needs of individual application teams. +* Focus is on initial delivery of core capabilities; plans are not made for ongoing maintenance and sustainability. +* Capability implementations are generally out of date and awaiting updates. +* Sudden spikes of work are introduced for late-breaking high-impact changes to capabilities, such as discovery of a vulnerability. +* Changes can result in both planned and unplanned downtime. +* Each upgrade is done in a bespoke way, requiring time and research to devise a process on each upgrade. + +#### Example Scenarios: + +* Log4Shell security vulnerability is announced and the organization spins up a specialty team to investigate where the organization may be vulnerable and instigate patches. Once the team identifies the impact, they must work hand in hand with a number of different teams since each one manages their servers and upgrade processes differently. Even when this work is deemed complete, the confidence level is fairly low that there won’t be more instances uncovered. + +### Level 2, Operationalized — Centrally tracked + +Platforms and capabilities are centrally documented and discoverable, and processes for planning and managing the lifecycle of capabilities is at least lightly defined. Responsibility and ownership is documented for each service and function. Lifecycle management processes vary for different capabilities depending on their owners and their priorities. A centralized team maintains, or is able to on demand generate, an inventory of backlog capabilities to provide the state of maintenance for current capabilities. This allows the organization to track progress towards capability offering and compliance with upgrade requirements. + +#### Characteristics: + +* Application teams create new capabilities as needed to meet pressing needs. +* A central team provides a register of available shared services across the organization. +* Loose standards, such as requiring an automatable API and usage docs, are applied to capabilities. +* Infrastructure as Code is used to allow easier traceability of deployed services. +* Audits for compliance regulations such as PCI DSS or HIPPA are enabled through the service inventories. +* Migration and upgrade work is tracked against a burndown chart enabling the organization to track rate of compliance and time until completion. +* Tracking does not indicate level of support; often upgrades at this stage are still manual and bespoke. + +#### Example Scenarios: + +* PostgreSQL 11 is going EOL by the end of the year. The organization is aware of which databases require upgrade and are scheduling the work on each team’s backlog to complete. + +### Level 3, Scalable — Centrally enabled + +Platforms and capabilities are not only centrally registered but also centrally orchestrated. Platform teams take responsibility for understanding the broad needs of the organization and prioritize work across platform and infrastructure teams accordingly. Those responsible for a capability are expected to not only maintain it technically, but also provide standard user experiences for integrating the capability with other related services around the organization, ensure secure and reliable use, and even provide observability. + +Standard processes for creating and evolving new capabilities exist, enabling anyone in the organization to contribute a solution that meets expectations. Continuous delivery processes for platform capabilities and features enable regular rollout and rollback. Large changes are planned and coordinated as they would be for customer-facing product changes. + +#### Characteristics: + +* Application teams request services from platform teams first before creating them. +* New services must adhere to standard practices such as standard interfaces, documentation, and governance. +* Upgrade processes are documented and consistent across versions and services. +* Where the capability provider does not manage an upgrade, they provide tooling and support to the users for minimal impact. + +#### Example Scenarios: + +* The organization is going to upgrade to RHEL 9. In doing so, each application team needs to validate that their software continues to work. In order to enable this testing phase the centralized compute team is setting up test environments for each team with the correct software and OS versions. + +### Level 4, Optimizing — Managed services + +The lifecycle of each capability is managed in a standardized, automated way. Capabilities, features and updates are delivered continuously with no impact on users. Any large changes instigated by platform providers include migration plans for existing users with defined responsibilities and timelines. + +Platform capability providers take on the brunt of responsibility for maintenance, but there is a clear contract — a "shared responsibility model" — describing the responsibilities of users, enabling both sides to operate mostly autonomously. + +#### Characteristics: + +* A shared ownership model clearly defines who is responsible for platforms and their capabilities and what is expected of users. +* Teams script both the execution of the upgrade and any rollback strategies to keep risk and impact low. + +#### Example Scenarios: + +* The users of virtual machines are not required to manage anything to do with version upgrades. Their only requirement is to have a stage in their delivery pipeline that contains a representative smoke test. They are then asked to declare their application as having lower risk tolerance so as to wait for a fully hardened upgrade or higher tolerance to become an early adopter. The virtual machine capability then manages the automated release of upgrades including rollbacks after either smoke test or canary release failures. + +{{< /tab >}} +{{< tab tabName="Measurement">}} + +

What is the process for gathering and incorporating feedback and learning?

+ +By reacting to explicit and implicit feedback from users, organizations can increase user satisfaction and ensure long-term platform sustainability. Organizations must balance innovation and meeting user demands to keep platform relevance. As technology and user preferences change, platforms that are agile and responsive to these changes will stand out. Regularly revisiting and refining the feedback mechanism can further optimize platform development and improve user engagement. + +### Level 1, Provisional — Ad hoc + +Usage and satisfaction metrics are gathered in custom ways, if at all, for each platform and capability. Outcomes and measures of success are not consistently aligned across capabilities, and therefore corresponding insights are not gathered. User feedback and instrumentation of platform use may not be gathered, or if it is, it will be informal. Decisions are made based on anecdotal requirements and incomplete data. + +#### Characteristics: + +* No experience or opinions about how to measure success of platforms +* Use familiar tools to gather common metrics with limited intent and forethought +* Reliance on small amounts of data +* Difficult to secure user participation — users believe their feedback isn't considered +* If surveys are used, the questions change between runs, negating the ability to track progress + +#### Example Scenarios: + +* A platform tech lead wants to improve the collaboration with users by adding key topics to their next quarterly planning. They decide to run a survey on what users would like to see. The response is overwhelming, which is exciting, but also results in a difficulty organizing and responding to all of the ideas. While some ideas influence the quarterly planning, the users do not see their ideas as being accepted and are less inclined to reply to the next survey. +* The team wants to capture more data automatically, so they look for opportunities for easy collection such as test failures in CI. However, not every team uses the same CI automation so the data is only available for Java applications even though some teams have moved on to writing their services in Scala. + +### Level 2, Operationalized — Consistent collection + +Organizations at this level have an intentional goal to verify platform products meet the needs of their market of internal users. Actionable, structured collection of user feedback is valued. Dedicated teams or individuals might be assigned to gather feedback, ensuring a more consistent approach. Feedback channels, such as surveys or user forums, are standardized, and feedback is categorized and prioritized. Beyond user feedback, there is also an expectation that user experiences are instrumented to generate usage data over time. + +Challenges remain in translating feedback into actionable tasks. While there is a growing repository of user data, the organization might need help effectively understanding and integrating this feedback into a platform roadmap. It may be hard to ensure that users see tangible changes driven by their feedback. + +#### Characteristics: + +* Data collection is discussed as part of most major planning sessions or capability implementations. +* There may not be alignment on exactly what to measure to verify success. +* Platform features can be measured for success, such as by measuring user adoption or user time saved. + +#### Example Scenarios: + +* A platform team allocates 20% of their time to user defined features, which they identify based on surveys and other interview techniques. Their findings are collected into a tool that enables additional voting and commenting to further refine priorities. During implementation the requesting users are approached for collaboration on early designs and implementations. Once implemented, there are announcements which make sure requesting users are aware of new features and supported in adopting them. +* The team focused on software delivery capabilities wants to capture more data automatically including cycle time which they automate through the build tool from commit to production. There is an understanding that cycle time can include other activities like PR review, but that isn’t included at this time. + +### Level 3, Scalable — Insights + +While robust, standard feedback mechanisms already exist, at this stage data is collected in crafted ways to yield specific strategic insights and actions. Desired results and outcomes are identified followed by standard metrics chosen to indicate progress towards those outcomes. Industry frameworks and standards may be used to benefit from industry research on the impact of certain behaviors. + +Dedicated teams or tools are employed to gather and review feedback and summarize actionable insights. A symbiotic relationship between platform products and their users is established. Feedback is considered a strategic asset that guides platform operations and roadmap. Regular feedback review sessions might be instituted, where cross-functional teams come together to discuss and strategize based on user insights. + +#### Characteristics: + +* Before delivering any new platform feature, the team discusses how to evaluate the outcome from their work. +* The organization has broad alignment on measures that indicate success of platform initiatives. +* A [product manager]({{< ref "/wgs/platforms/glossary#platform-product-managers" >}}) or dedicated team member drives an ongoing and consistent feedback collection and analysis process. +* The organization has established metrics and goals to observe and target to indicate success. + +#### Example Scenarios: + +* The organization has consistently tracked build times and lead time. However, now they realize that while easy to collect, these alone do not give a complete picture of software delivery. With this in mind, the team implements measurement for service reliability and stability. + +### Level 4, Optimizing — Quantitative and qualitative + +Feedback and measurements are deeply integrated into the organization's culture. The entire organization, from top-level executives to engineers organization-wide, recognizes the value of data collection and feedback on product evolution. There is a democratization of data, where various stakeholders, including platform users and business leaders, are actively involved in identifying hypotheses for platform improvements, providing feedback during the design process, and then measuring the impact post delivery. All of these measurements are considered when planning platform initiatives. + +Not only are standard frameworks leveraged, but there is an understanding that measuring from multiple angles creates a more holistic picture. There is an investment in understanding how qualitative measures change as quantitative ones are improved. There is a focus on identifying leading measures which can allow anticipation of features that would support user needs, alleviate their challenges, and stay ahead of industry trends and business requirements. + +#### Characteristics: + +* Platform teams continuously seek ways to improve the metrics they watch and the way they gather data. +* The organization is familiar with and sensitive to [Goodhart's Law](https://en.wikipedia.org/wiki/Goodhart%27s_law): "When a measure becomes a target, it ceases to be a good measure." +* Metrics and telemetry gathered is continuously evaluated for true insight and value. +* Metric data management is well supported, such as standard platform capabilities to manage data lakes and derive insights. +* Cross-departmental collaboration is encouraged to avoid data silos and enable effective feedback cycles. + +#### Example Scenarios: + +* Over time the organization has collected data indicating a rise in build time of over 15%. This triggers negative developer experiences and once triggered, even if the build time is reduced below the original time, developers stay frustrated for longer. This insight drives the build team to set and adhere to a Service Level Objective (SLO), which enables early identification and improvement before instigating the negative cycle with their users. + +{{< /tab >}} +{{< /tabs >}} +
+ +
+ +--- +## Conclusion + +Platforms and their maintainers provide a foundation for agile digital product development. They provide a consistent collection of capabilities that enable efficient software development and delivery. This maturity model provides a map for your platform engineering journey. From 1b057946c18441d541584431991d176afcdbd890 Mon Sep 17 00:00:00 2001 From: Eeap Date: Wed, 8 May 2024 18:53:37 +0900 Subject: [PATCH 3/4] docs(platforms): translate maturity-model contents into korean Signed-off-by: Eeap --- .../wgs/platforms/maturity-model/v1/index.md | 527 +++++++++--------- 1 file changed, 264 insertions(+), 263 deletions(-) diff --git a/website/content/ko/wgs/platforms/maturity-model/v1/index.md b/website/content/ko/wgs/platforms/maturity-model/v1/index.md index 35baa853..7c562fc8 100644 --- a/website/content/ko/wgs/platforms/maturity-model/v1/index.md +++ b/website/content/ko/wgs/platforms/maturity-model/v1/index.md @@ -2,7 +2,7 @@ title: "플랫폼 엔지니어링 성숙도 모델" pdf: https://github.com/cncf/tag-app-delivery/raw/main/platforms-maturity-model/v1/assets/platform-eng-maturity-model-v1.0.pdf version_info: https://github.com/cncf/tag-app-delivery/tree/main/platforms-maturity-model/README.md -description: "This maturity model intends to provide tactical guidance to users seeking to adopt the patterns discussed in the Platforms Definition White Paper. That paper suggests why and what to build; this document will begin to describe how to plan to build it. The target audience is CTOs, Directors of engineering, lead engineers, and architects seeking to evaluate their current state and environment and identify opportunities for improvement.

+description: "이 성숙도 모델은 플랫폼 정의 백서에서 논의된 패턴을 채택하려는 사용자에게 전술적 지침을 제공하기 위한 것이다. 해당 백서는 왜 그리고 무엇을 구축해야 하는지를 제안하며; 이 문서는 어떻게 구축을 계획하는지를 설명하기 시작할 것이다. The target audience is CTOs, Directors of engineering, lead engineers, and architects seeking to evaluate their current state and environment and identify opportunities for improvement.

This document refers to, enhances, and follows similar standards as the following related documents:
[Cloud Maturity Model](https://maturitymodel.cncf.io/)
[Platforms Definition White Paper](https://tag-app-delivery.cncf.io/whitepapers/platforms/)" @@ -28,466 +28,467 @@ window.onhashchange = function() { } -## Introduction +## 도입 -CNCF's initial [Platforms Definition white paper](https://tag-app-delivery.cncf.io/whitepapers/platforms/) describes what internal platforms for cloud computing are and the values they promise to deliver to enterprises. But to achieve those values an organization must reflect and deliberately pursue outcomes and practices that are impactful for them, keeping in mind that every organization relies on an internal platform crafted for its own organization - even if that platform is just documentation on how to use third party services. This maturity model provides a framework for that reflection and for identifying opportunities for improvement in any organization. +CNCF의 초기 [플랫폼 정의 백서](https://tag-app-delivery.cncf.io/whitepapers/platforms/)에서는 클라우드 컴퓨팅을 위한 내부 플랫폼이 무엇인지, 그리고 이들이 기업에 제공하겠다고 약속하는 가치에 대해 설명한다. 그러나 이러한 가치를 달성하려면 모든 조직은 자체 조직을 위해 제작된 내부 플랫폼에 의존한다는 점을 명심해두고 조직은 자신에게 영향을 미치는 결과와 관행을 반영하고 의도적으로 추구해야 한다. - 해당 플랫폼이 단지 제3자 서비스를 사용하는 방법에 대한 문서일지라도 말이다. 이 성숙도 모델은 모든 조직에서 이러한 성찰과 개선 기회 식별을 위한 프레임워크를 제공한다. -## What is platform engineering? +## 플랫폼 엔지니어링이란 무엇인가요 ? -Inspired by the cross-functional cooperation promised by DevOps, platforms and platform engineering have emerged in enterprises as an explicit form of that cooperation. Platforms curate and present common capabilities, frameworks and experiences. In the context of this working group and related publications, the focus is on platforms that facilitate and accelerate the work of [internal users]({{< ref "/wgs/platforms/glossary#platform-users" >}}) such as product and application teams. +DevOps가 약속한 부서 간 협력에서 영감을 받아 플랫폼과 플랫폼 엔지니어링은 이러한 협력의 명시적인 형태로 기업에 등장했다. 플랫폼은 공통 기능, 프레임워크 및 경험을 선별하고 제시한다. 해당 작업 그룹 및 관련 출판물에서는 프로덕트 및 애플리케이션 팀의 [내부 사용자]({{< ref "/wgs/platforms/glossary#platform-users" >}})의 작업을 촉진하고 가속화하는 플랫폼에 중점을 두고 있다. -[**Platform engineering**]({{< ref "/wgs/platforms/glossary#platform-engineering" >}}) is the practice of planning and providing such computing platforms to developers and users and encompasses all parts of platforms and their capabilities — their people, processes, policies and technologies; as well as the desired business outcomes that drive them. +[**플랫폼 엔지니어링**]({{< ref "/wgs/platforms/glossary#platform-engineering" >}})은 이러한 컴퓨팅 플랫폼을 개발자와 사용자에게 계획하고 제공하는 관행으로 플랫폼의 모든 부분과 그들의 역량을 포괄한다 - 그들의 인력, 프로세스, 정책 및 기술과 같은 역량을 말이다; 뿐만 아니라 그들이 추구하는 원하는 비즈니스 결과도 있다. -Please read the [CNCF Platforms Definition white paper](https://tag-app-delivery.cncf.io/whitepapers/platforms/) first for complete context. +전체 내용을 보려면 먼저 [CNCF 플랫폼 정의 백서](https://tag-app-delivery.cncf.io/whitepapers/platforms/)를 읽어보세요. -## How to use this model +## 해당 모델 사용 방법 -As platform engineering has risen in prominence over the last few years, some patterns have become apparent. By organizing those patterns and observations into a progressive maturity model, we aim to orient [platform teams]({{< ref "/wgs/platforms/glossary#platform-teams" >}}) to the challenges they may face and opportunities to aim for. Each aspect is described by a continuum of characteristics of different teams and organizations at each level within the aspect. We expect readers to find themselves in the model and identify opportunities in adjacent levels. +지난 몇 년 동안 플랫폼 엔지니어링이 두각을 나타내면서 몇 가지 패턴이 분명해졌다. 이러한 패턴과 관찰을 점진적인 성숙도 모델로 구성함으로써 우리는 [플랫폼 팀]({{< ref "/wgs/platforms/glossary#platform-teams" >}})이 직면할 수 있는 과제와 목표로 삼을 수 있는 기회에 방향을 맞추는 것을 목표로 한다. 각 측면은 해당 측면 내의 각 수준에서 서로 다른 팀과 조직의 특성의 연속체로 설명된다. 우리는 독자들이 모델에서 자신을 찾고 인접한 수준에서 기회를 식별하기를 기대한다. -Of note, each additional level of maturity is accompanied by greater requirements for funding and people's time. Therefore, reaching the highest level should not be a goal in itself. Each level describes qualities that should appear at that stage. Readers must consider if their organization and their current context would benefit from these qualities given the required investment. +주목할 만한 점은 각각의 성숙도 수준이 높아질수록 자금과 인력(사람들의 시간)에 대한 더 큰 요구사항이 뒤따른다는 점이다. 그러므로 최고 수준에 도달하는 것 자체가 목표가 되어서는 안 된다. 각 수준은 해당 단계에서 나타나야 하는 특성을 설명한다. 독자들은 필요한 투자를 고려할 때 그들의 조직과 현재 상황이 이러한 특성으로부터 이익을 얻을 수 있는지 고려해야 한다. -Keep in mind that each aspect is meant to be evaluated and evolved independently. However, as in any socio-technical system these aspects are complex and interrelated. Thus you may find that to improve in one aspect you must reach a minimum level in another aspect too. +각각의 측면은 독립적으로 평가되고 발전된다는 점을 명심해야 한다. 그러나 모든 사회 기술적 시스템과 마찬가지로 이 측면들은 복잡하고 상호 연관되어 있다. 따라서 한 측면에서 개선하려면 다른 측면에서도 최소 수준에 도달해야 한다는 것을 알 수 있다. -It's also important to recognize that implementations of platforms vary from organization to organization. Make sure to evaluate the current state of _your_ group’s overall cloud native transformation. A phenomenal resource to leverage for this evaluation is the [Cloud Native Maturity Model](https://maturitymodel.cncf.io/). +플랫폼의 구현은 조직마다 다르다는 점을 인지하는 것도 또한 중요하다. 여러분의 그룹의 전반적인 클라우드 네이티브 전환의 현황을 반드시 평가해야 한다. 이러한 평가에 활용할 수 있는 경이로운 리소스는 [클라우드 네이티브 성숙도 모델](https://maturitymodel.cncf.io/)이다. -Finally, this model encourages organizations to mature their platform engineering discipline and their resulting platforms through intentional planning. Such planning and discipline themselves are a requirement for mature platform development and ongoing evolution. +마지막으로, 이 모델은 조직이 의도적인 계획을 통해 플랫폼 엔지니어링 규율과 그에 따른 플랫폼을 성숙시키도록 장려한다. 이러한 계획과 규율 그 자체는 성숙한 플랫폼 개발과 지속적인 발전을 위한 요구 사항이다. -In general, keep in mind that mapping your organization into a model captures current state _to enable_ progressive iteration and improvement. [Martin Fowler](https://martinfowler.com/bliki/MaturityModel.html) says it well: "The true outcome of a maturity model assessment isn't what level you are at but the list of things you need to work on to improve. Your current level is merely a piece of intermediate work in order to determine that list of skills to acquire next." In that vein, seek to find yourself in the model then identify opportunities in adjacent levels. +일반적으로, 조직을 모델에 매핑하면 점진적인 반복과 개선이 가능한 현재 상태가 포착된다는 사실을 명심해야 한다. [마틴 파울러](https://martinfowler.com/bliki/MaturityModel.html)는 다음과 같이 말했다: "성숙도 모델 평가의 진정한 결과는 당신이 어떤 수준에 있는지가 아니라 개선하기 위해 노력해야 할 것들의 목록이다. 당신의 현재 수준은 다음에 습득해야 할 기술 목록을 결정하기 위한 중간 작업에 불과하다." 그러한 맥락에서 모델에서 자신을 찾고 인접한 수준에서 기회를 식별하세요. -## Context behind this work +## 해당 작업의 배경 -It's valuable to understand the context a document has been written in. The following sections lay out some context behind the model as well as some expectations for you, the reader. +문서가 작성된 맥락을 이해하는 것은 가치가 있는 일이다. 다음 절에서는 모델 뒤에 있는 몇 가지 맥락과 독자 여러분이 기대하는 바를 설명한다. -### Intended audiences +### 대상 독자들 -Each reader brings a unique context and will take unique learnings from this model. Following are some personas we have in mind, along with their possible motivations for engaging with this model: +각 독자는 이 모델을 통해 독특한 학습을 하게 되고 다른 맥락을 갖게 된다. 우리가 염두에 두고 있는 몇 가지 인물들과 이 모델에 참여하기 위한 가능한 동기는 다음과 같다: -* **CTOs, VPs, and directors of technology**: Leaders looking to map a path to digital transformation and greater developer productivity -* **Engineering managers**: Groups and individuals seeking to empower engineers to provide value with less overhead and higher efficiency -* **Enterprise architects**: Individuals navigating the modern technology landscape who seek a value- and solution-oriented perspective on technology problems -* **Platform engineers and platform product managers**: Teams and people seeking to build the best possible experience for platform builders and platform users -* **Product vendors and project maintainers**: Organizations and engineers wishing to design tools and deliver messages to enable users to succeed with platforms and capabilities -* **Application and product developers**: Platform users seeking to understand in more detail what they might expect of an internal platform +* **CTO, VP 및 기술 담당 이사**: 디지털 전환 및 개발자 생산성 향상을 위한 길을 모색하는 리더 +* **엔지니어링 관리자**: 엔지니어가 더 적은 오버헤드와 더 높은 효율성으로 가치를 제공할 수 있도록 지원하고자 하는 그룹과 개인 +* **엔터프라이즈 아키텍트**: 기술 문제에 대한 가치와 솔루션 중심의 관점을 추구하는 현대 기술 환경을 탐색하는 개인 +* **플랫폼 엔지니어 및 플랫폼 프로덕트 관리자**: 플랫폼 빌더와 플랫폼 사용자를 위해 가능한 최고의 경험을 구축하고자 하는 팀과 사람들 +* **프로덕트 벤더 및 프로젝트 메인테이너**: 사용자가 플랫폼과 기능으로 성공할 수 있도록 도구를 설계하고 메시지를 전달하고자 하는 조직 및 엔지니어 +* **애플리케이션 및 프로덕트 개발자**: 내부 플랫폼에 대해 무엇을 기대할 수 있는지 더 자세히 이해하고자 하는 플랫폼 사용자 -### Understanding the levels +### 수준 이해하기 -This model is not meant to classify an organization or platform team as wholly “Level 1” or “Level 4.” Each aspect should be considered independently of the others; the characteristics of each level represent a continuum within that aspect but are not necessarily coupled to other aspects at the same level. Even more so, many organizations will see characteristics of more than one level being applicable across their teams and work. This is because no level is inherently good or bad, only contextual to the team’s goals. +이 모델은 조직이나 플랫폼 팀을 전적으로 "레벨 1" 또는 "레벨 4"로 분류하는 것을 의미하지 않는다. 각 측면은 다른 측면과 독립적으로 고려되어야 한다; 각 수준의 특성은 그 측면 내의 연속체를 나타내지만 반드시 동일한 수준의 다른 측면과 결합되지는 않는다. 더욱이, 많은 조직들은 하나 이상의 수준의 특성이 팀과 업무 전반에 걸쳐 적용 가능하다고 볼 것이다. 어떤 수준도 본질적으로 좋거나 나쁘거나하지 않고 팀의 목표에 맥락적일 뿐이기 때문이다. -The labels for each level are intended to reflect the impact of platform engineering at your organization. As you recognize your organization at a given level you will gain insight into opportunities which follow at the next ones. Lower-numbered levels comprise more tactical solutions while higher-numbered ones are more strategic. +각 수준의 레이블은 조직에서 플랫폼 엔지니어링의 영향을 반영하기 위한 것이다. 주어진 수준에서 귀하의 조직을 인식하면 다음 수준에서 뒤따르는 기회에 대한 통찰력을 얻게 될 것이다. 숫자가 낮은 수준은 더 많은 전술적 솔루션을 구성하고 숫자가 높은 수준은 더 전략적 솔루션을 구성한다. -This yields a potential process for platform development and maturity similar to other digital product development: first recognize a problem and need for a new solution, next develop minimally-viable products as hypothesized solutions, third iterate to better solve the problem and ensure fit for your customers and finally scale and optimize the product to solve the problem for many teams and users. +이는 다른 디지털 프로덕트 개발과 유사한 플랫폼 개발 및 성숙도를 위한 잠재적 프로세스를 생성한다: 먼저 문제와 새로운 솔루션에 대한 필요성을 인식하고, 다음으로 최소 실행 가능한 프로덕트를 가설화된 솔루션으로 개발하고, 세 번째로 문제를 더 잘 해결하고 고객에게 적합하도록 반복하고 마지막으로 많은 팀과 사용자의 문제를 해결하기 위해 프로덕트를 확장하고 최적화한다. -Similar to the [CNCF Cloud Native Maturity Model](https://maturitymodel.cncf.io/), this model highlights that successful business outcomes can only be achieved through balancing people, process, and policy alongside technology. Notably, this model introduces aspects which are often not fully in the remit of a single internal team, but rather require cooperation across the engineering department and quite often the wider organization. +[CNCF 클라우드 네이티브 성숙도 모델](https://maturitymodel.cncf.io/)과 유사하게, 이 모델은 기술과 함께 사람, 프로세스, 정책의 균형을 통해서만 성공적인 비즈니스 성과를 달성할 수 있다는 점을 강조한다. 특히, 이 모델은 단일 내부 팀의 소관이 아닌 경우가 많으며 오히려 엔지니어링 부서와 광범위한 조직 간의 협력이 필요한 측면을 소개한다. -### But it doesn't seem to fit +### 그런데 안 맞는 것 같아요 -That’s perfectly fine! All organizations and groups have dynamics and parameters that are specific to them. +정말 괜찮다! 모든 조직과 그룹에는 해당 조직과 관련된 동적 요소와 매개변수가 있다. -Keep in mind that the goal of this paper isn’t to prescribe a rigid formula, but rather a framework that you can apply to your circumstances. Every single word may not be relevant to you, but we hope the content will inspire you to introspect on your own platform journey, taking what makes sense and leaving the rest. +이 백서의 목표는 엄격한 공식을 규정하는 것이 아니라, 상황에 맞게 적용할 수 있는 프레임워크를 규정하는 것이다. 모든 단어가 귀하와 관련이 없을 수도 있지만, 우리는 그 내용이 여러분이 스스로의 플랫폼 여정을 성찰하고, 의미가 있는 것을 선택하고 나머지는 버리도록 영감을 주기를 바란다. -The objective of this model is to provide a tool to help guide platform engineering practitioners, stakeholders, and other interested parties on their journeys. Platform design and implementation is not an exact science, but rather depends on the needs of an individual project, an organization and a particular time and place. +이 모델의 목적은 플랫폼 엔지니어링 실무자, 이해관계자 및 기타 이해관계자의 여정을 안내하는 데 도움이 되는 도구를 제공하는 것이다. 플랫폼 디자인과 구현은 정확한 과학이 아니라, 오히려 개별 프로젝트, 조직 및 특정 시간과 장소의 요구에 달려 있다. -## Model table +## 모델 테이블 -|
Aspect
| | Provisional | Operational | Scalable | Optimizing | +|
측면
| | 제공(Provisional) | 운영(Operational) | 확장성(Scalable) | 최적화(Optimizing) | |:---------------------------------------|:-------------------------------------------------------------------------------------------|:-----------------------|:----------------------|:-----------------------|:-----------------------------| -| [Investment](#Investment) | _How are staff and funds allocated to platform capabilities?_ | Voluntary or temporary | Dedicated team | As product | Enabled ecosystem | -| [Adoption](#Adoption) | _Why and how do users discover and use internal platforms and platform capabilities?_ | Erratic | Extrinsic push | Intrinsic pull | Participatory | -| [Interfaces](#Interfaces) | _How do users interact with and consume platform capabilities?_ | Custom processes | Standard tooling | Self-service solutions | Integrated services | -| [Operations](#Operations) | _How are platforms and their capabilities planned, prioritized, developed and maintained?_ | By request | Centrally tracked | Centrally enabled | Managed services | -| [Measurement](#Measurement) | _What is the process for gathering and incorporating feedback and learning?_ | Ad hoc | Consistent collection | Insights | Quantitative and qualitative | +| [투자(Investment)](#Investment) | _플랫폼 기능에 대한 인력 및 자금 배분은 어떻게 이루어지나요?_ | 자발적 혹은 일시적 | 전담 팀 | 프로덕트 | 활성화된 에코시스템 | +| [채택(Adoption)](#Adoption) | _사용자가 내부 플랫폼 및 플랫폼 기능을 발견하고 사용하는 이유와 방법은 무엇인가요?_ | 불규칙 | 외부 푸시 | 내부 풀 | 참여형 | +| [인터페이스(Interfaces)](#Interfaces) | _사용자는 어떻게 플랫폼 기능과 상호 작용하고 소비하나요?_ | 사용자 정의 프로세스 | 표준 도구 | 셀프 서비스 솔루션 | 통합 서비스 | +| [운영(Operations)](#Operations) | _플랫폼과 그 기능은 어떻게 계획되고, 우선순위가 정해지고, 개발되고, 유지관리되나요?_ | 요청 시 | 중앙 추적 | 중앙 활성화 | 관리형 서비스 | +| [측정(Measurement)](#Measurement) | _피드백과 학습을 수집하고 반영하는 과정은 어떻게 되나요?_ | 즉흥적(Ad hoc) | 일관된 수집 | 인사이트(Insights) | 정량적, 정성적 | -## Model Detail +## 모델 상세
{{< tabs tabTotal="6">}} {{< tab tabName="Investment" >}} -

How are staff and funds allocated to platform capabilities?

+

인력과 자금은 플랫폼 기능에 어떻게 할당되나요?

-Investment in platforms and platform engineering is the process of allocating budget and people to build and maintain common capabilities. It is common for initiatives to be described as organically built from the bottom up, or driven through top down initiatives. In either case, it is the ability to invest sustained effort that drives high-impact work. This aspect captures how the scale and breadth of investment can impact platform success. +플랫폼 및 플랫폼 엔지니어링에 대한 투자는 공통 기능을 구축하고 유지하기 위해 예산과 인력을 할당하는 과정이다. 이니셔티브는 상향식으로 유기적으로 구축되거나 하향식 이니셔티브를 통해 추진되는 것으로 설명되는 것이 일반적이다. 어느 경우든 영향력이 큰 작업을 추진하는 것은 지속적인 노력을 투자하는 능력이다. 이러한 측면은 투자의 규모와 폭이 플랫폼 성공에 어떤 영향을 미칠 수 있는지를 포착한다. -### Level 1, Provisional — Voluntary or temporary +### 레벨 1, 제공(Provisional) — 자발적 혹은 일시적 -Individual capabilities may exist to provide common foundations for common or critical functionality. These capabilities are built and maintained out of necessity rather than planned and intentionally funded. +개별 기능은 공통 또는 중요한 기능에 대한 공통 기반을 제공하기 위해 존재할 수 있다. 이러한 기능은 계획하고 의도적으로 자금을 지원하기보다는 필요에 따라 구축되고 유지된다. -These capabilities are built and maintained by people assigned temporarily or voluntarily; no central funding or staffing are intentionally allocated to them. They depend on the current tactical requirements of their users. +이러한 기능은 일시적으로 또는 자발적으로 배정된 사람들에 의해 구축되고 유지된다; 중앙 자금이나 인력이 의도적으로 할당되지 않는다. 그들은 사용자의 현재 전술적 요구 사항에 의존한다. -#### Characteristics: +#### 특징: -* "Hit" or "tiger" teams are built to tackle urgent requirements. These teams are short lived and not assigned nor granted the time to provide long term planning and support. -* Migrations, improvements, or enhancements are often considered "nice to have" work items and rely on "research" or "hack day" efforts. -* Process improvements or automation may be introduced while tackling a new requirement such as an urgent security patch, however there is not support to build the solutions in a reusable or sustainable way. -* Employees complain of burn out and frustration with the amount of work they are doing outside their core role. +* "Hit" 또는 "tiger" 팀은 긴급한 요구 사항을 처리하기 위해 구성되었다. 이러한 팀은 수명이 짧으며 장기적인 계획과 지원을 제공할 시간이 할당되거나 부여되지 않는다. +* 마이그레이션, 개선 또는 향상은 종종 "있으면 좋은" 작업 항목으로 간주되며 "리서치" 또는 "핵 데이(hack day)" 노력에 의존한다. +* 긴급 보안 패치와 같은 새로운 요구 사항을 처리하는 동안 프로세스 개선이나 자동화가 도입될 수 있지만, 재사용 가능하거나 지속 가능한 방식으로 솔루션을 구축하기 위한 지원은 없다. +* 직원들은 자신의 핵심 역할 이외의 업무량으로 인해 피로감과 좌절감을 호소한다. -#### Example Scenarios: +#### 예시 시나리오: -* There is a specific employee who is viewed as the test environment expert. While this employee means well, their attempt to enable better test environments despite limited investment has led to increased risk since there is no maintenance of their solution and no shared understanding of how to triage a broken test environment. -* Engineers are encouraged to invest in capability improvements when there is no pressure from management for revenue generating features. This translates to the last few days of some sprints where they prioritize automating and improving parts of their CI/CD pipeline. It is not uncommon for these improvements to come in bursts as there can be months of overly full sprints not allowing for time on these side endeavors. +* 테스트 환경 전문가로 평가되는 특정 직원이 있다. 이 직원의 의도는 좋지만, 제한된 투자에도 불구하고 더 나은 테스트 환경을 가능하게 하려는 그들의 시도는 솔루션의 유지 보수가 없고 고장 난 테스트 환경을 분류하는 방법에 대한 공유된 이해가 없기 때문에 위험을 증가시켰다. +* 엔지니어들은 수익 창출 기능에 대한 경영진의 압력이 없을 때 기능 개선에 투자할 것을 권장받는다. 이는 CI/CD 파이프라인의 일부를 자동화하고 개선하는 데 우선순위를 두는 일부 스프린트의 마지막 며칠로 해석된다. 이러한 측면에서 시간을 허용하지 않는 지나치게 꽉 찬 스프린트가 수개월 동안 있을 수 있기 때문에 이러한 개선이 갑자기 발생하는 것은 드문 일이 아니다. -### Level 2, Operationalized — Dedicated team +### Level 2, 운영(Operationalized) — 전담 팀 -Budget and people are allocated for persistent people and resource support. The assigned people are tasked with providing a set of commonly-required capabilities to speed up software delivery. Often these teams focus on meeting reactive technical requirements. They may be called DevOps, Engineering Enablement, Developer Experience (DevEx or DevX), Shared Tools, a Centre-Of-Excellence, or even Platform. They're funded centrally and treated as cost centers; their impact on direct value streams and application teams is not measured. It can be hard to map the impact of platform teams at this level on the organization and its value streams, which can make it hard to sustain and continue funding such teams. +예산과 인력은 지속적인 인력과 자원 지원을 위해 할당된다. 할당된 인력은 소프트웨어 제공 속도를 높이기 위해 일반적으로 필요한 기능을 제공하는 임무를 맡는다. 종종 이러한 팀은 반응형 기술 요구 사항을 충족하는 데 중점을 둔다. 이러한 팀은 DevOps, Engineering Enablement, Developer Experience (DevEx 또는 DevX), Shared Tools, Centre-Of Excellence 또는 심지어 플랫폼이라고도 불린다. 이러한 팀은 중앙 집중식으로 자금을 받고 비용 센터로 취급된다; 직접적인 가치 스트림과 애플리케이션 팀에 미치는 영향은 측정되지 않는다. 이러한 수준의 플랫폼 팀이 조직과 가치 스트림에 미치는 영향을 매핑하는 것이 어려울 수 있으며, 이는 이러한 팀에 자금을 계속 지원하고 유지하는 것을 어렵게 만들 수 있다. -#### Characteristics: +#### 특징: -* The team is made up of nearly all technical generalists. -* Team budget may include the infrastructure costs associated with their work leading to often being a key point in budget conversations. -* Backlog items range a number of technologies, leading to frequent and large context switches. -* This team is often the first to fill a gap that is not yet being addressed, even if not in the declared scope for the team. This team takes ownership of resources that don't have an owner. -* Assigned people rarely have the time or experience with customer research to validate their designs or implementations. +* 팀은 거의 모든 기술 저널리스트들로 구성되어 있다. +* 팀 예산은 종종 예산 논의의 핵심 사항으로 이어지는 업무와 관련된 인프라 비용을 포함할 수 있다. +* 백로그 항목들은 다양한 기술들을 포함하고 있어 빈번하고 큰 컨텍스트 스위치들로 이어진다. +* 이 팀은 선언된 팀의 범위가 아니더라도 아직 해결되지 않은 공백을 가장 먼저 채우는 경우가 많다. 이 팀은 소유자가 없는 리소스의 소유권을 갖는다. +* 할당된 사람들은 그들의 디자인이나 구현을 검증하기 위한 고객 조사에 대한 시간이나 경험이 거의 없다. -#### Example Scenarios: +#### 예시 시나리오: -* Application developers raise an issue with the long build time for their applications. A centralized team is tasked with reducing the build time by 50%. They solve this by doubling the size and quantity of the CI runners given they are not close enough to the software to individually improve the application builds. This creates a budget concern for their centralized team as the productivity gain is not directly measurable against this increased infrastructure cost. +* 애플리케이션 개발자들은 자신들의 애플리케이션 빌드 시간이 길다는 문제를 제기한다. 중앙 집중식 팀은 빌드 시간을 50% 단축하는 임무를 맡고 있다. 그들은 개별적으로 애플리케이션 빌드를 개선할 만큼 소프트웨어와 가깝지 않다는 점을 고려하여 CI 러너의 크기와 양을 두 배로 늘려서 이 문제를 해결한다. 증가된 인프라 비용에 비해 생산성 향상을 직접 측정할 수 없기 때문에 이로 인해 중앙 집중식 팀에 예산 문제가 발생한다. -### Level 3, Scalable — As product +### 레벨 3, 확장성(Scalable) — 프로덕트 -Investment in internal platforms and their capabilities is similar to investment in an enterprise's outbound products and value streams: based on the value they are expected to provide to their customers. Product management and user experience are explicitly considered and invested in. A chargeback system may be used to reflect platforms' impact on their customers' own direct value streams and products. The enterprise allocates funds and staff to the appropriate initiatives by using data-driven performance indicators and feedback loops. Platform teams can ultimately optimize the business itself and contribute to increased profitability. +내부 플랫폼과 그 기능에 대한 투자는 기업의 아웃바운드 프로덕트와 가치 흐름(value streams)에 대한 투자와 유사하다: 이는 그들이 고객에게 제공할 것으로 기대되는 가치에 기반으로 한다. 프로덕트 관리 및 사용자 경험은 명시적으로 고려되고 투자된다. 플랫폼이 고객 자신의 직접적인 가치 흐름 및 프로덕트에 미치는 영향을 반영하기 위해 지불 거절(chargeback) 시스템이 사용될 수 있다. 기업은 데이터 기반 성과 지표와 피드백 루프를 사용하여 적절한 이니셔티브에 자금과 직원을 할당한다. 플랫폼 팀은 궁극적으로 비즈니스 자체를 최적화하고 수익성 향상에 기여할 수 있다. -#### Characteristics: +#### 특징: -* Platform teams staff roles not traditionally found in internal serving or technical teams, for example, product management and user experience. -* The team publicizes a roadmap internally to the organization, which indicates the value delivered and high level feature targets. -* Features are tested for both implementation quality and user experience during design, delivery, and post deployment. -* Feature removal is a key part of the conversation, the goal is to have a well supported, well used suite of capabilities instead of a sprawling estate that may not be maintained. +* 플랫폼 팀의 직원 역할은 전통적으로 내부 서빙 또는 기술 팀에서 찾아볼 수 없는 역할, 예를 들어 프로덕트 관리와 사용자 경험이다. +* 팀은 전달된 가치와 높은 수준의 기능 목표를 나타내는 로드맵을 조직 내부에 공개한다. +* 기능은 디자인, 제공 및 배포 후에 구현 품질과 사용자 경험 모두에 대해 테스트된다. +* 기능 제거는 대화의 핵심 부분이며, 유지 관리가 되지 않을 수 있는 방대한 기능 대신 잘 지원되고 잘 사용되는 기능 제품군을 보유하는 것이 목표이다. -#### Example Scenarios: +#### 예시 시나리오: -* Data derived from platform usage metrics inform decisions to allocate funds and staff to the most impactful initiatives. +* 플랫폼 사용 지표에서 도출된 데이터는 가장 영향력 있는 이니셔티브에 자금과 인력을 할당하는 결정을 내리는 데 도움이 된다. -### Level 4, Optimizing — Enabled ecosystem +### 레벨 4, 최적화(Optimizing) — 활성화된 에코시스템 -Platform teams find ways to increase organization-wide efficiency and effectiveness beyond basic capabilities. Core platform maintainers intentionally strive to optimize time-to-market for new products, reduce costs across the enterprise, enable efficient governance and compliance for new services, scale workloads quickly and easily, and other cross-cutting requirements. These core maintainers are focused on enabling capability specialists to seamlessly integrate their requirements and offerings into existing and new parts of platforms. Further, the organization focuses people and resources from specialist domains like security, performance, quality on engaging with provided platform frameworks to introduce advanced features that can enable product teams to accelerate their adherence to company goals without depending on a centralized team backlog. +플랫폼 팀은 기본적인 기능을 넘어 조직 전반의 효율성과 효과를 높일 수 있는 방법을 모색한다. 핵심 플랫폼 메인테이너는 새로운 프로덕트 출시 기간 최적화, 전사적 비용 절감, 새로운 서비스에 대한 효율적인 거버넌스와 규정 준수, 빠르고 쉬운 워크로드 확장과 기타 여러 요구 사항을 충족하기 위해 노력한다. 이러한 핵심 메인테이너는 기능 전문가가 요구 사항과 제안을 플랫폼의 기존 및 새로운 부분에 원활하게 통합할 수 있도록 지원하는 데 중점을 둔다. 또한, 조직은 보안, 성능, 품질과 같은 전문 영역의 인력과 리소스를 제공된 플랫폼 프레임워크에 집중하여 프로덕트 팀이 중앙 집중식 팀 백로그에 의존하지 않고 회사 목표를 빠르게 달성할 수 있는 고급 기능을 도입할 수 있도록 집중한다. -#### Characteristics: +#### 특징: -* It becomes a priority to enable specialists to extend platform capabilities and introduce new ones. -* The organization can centralize specialists allowing their knowledge and support to be spread through platform capabilities. +* 전문가가 플랫폼 기능을 확장하고 새로운 기능을 도입할 수 있도록 하는 것이 우선 순위가 된다. +* 조직은 전문가를 중앙 집중화하여 그들의 지식과 지원이 플랫폼 기능을 통해 확산될 수 있도록 할 수 있다. -#### Example Scenarios: +#### 예시 시나리오: -* Marketing works with platform builders to introduce consistent user tracking in order to attribute marketing efforts to product outcomes. -* Automation initiative reduces human time to provision databases by 30 minutes per instance, saving $10m/year. +* 마케팅은 플랫폼 빌더와 협력하여 일관된 사용자 추적 기능을 도입하여 마케팅 노력을 프로덕트 성과에 기여한다. +* 자동화 이니셔티브를 통해 데이터베이스 프로비저닝에 소요되는 인력 시간을 인스턴스당 30분 단축하여 연간 1,000만 달러를 절약한다. {{< /tab >}} {{< tab tabName="Adoption" >}} -

Why and how do users discover and use internal platforms and platform capabilities?

+

사용자가 내부 플랫폼과 플랫폼 기능을 발견하고 사용하는 이유와 방법은 무엇인가요?

-Adoption describes not only how and how much an organization uses platform capabilities, but also what motivates them to do so. In the early stages, many target users may not realize they are using a platform at all, rather they see their tools as an ad hoc collection of capabilities from various internal sources. This may mature into a group of capabilities that is consistently managed and presented to users — that is, one or more platforms. As the capabilities become more refined and discoverable, it is common that the drive for platform use moves away from more external motivations like mandates or incentives. This leads to users self-selecting into platform capabilities and ideally even investing their own efforts into the wider platform ecosystem. +채택(Adoption)은 조직이 플랫폼 기능을 어떻게 얼마나 사용하는지 뿐만 아니라, 그렇게 하도록 동기를 부여하는 요소도 설명한다. 초기 단계에서는 많은 대상 사용자가 플랫폼을 사용하고 있다는 사실을 전혀 인식하지 못할 수 있으며, 오히려 도구를 다양한 내부 소스의 기능을 임시로(ad hoc) 모아놓은 것으로 간주한다. 이는 일관되게 관리되고 사용자에게 제공되는 기능 그룹으로 발전할 수 있다 - 즉, 하나 이상의 플랫폼으로 말이다. 기능이 더욱 세분화되고 발견이 가능해짐에 따라, 플랫폼 사용의 동기는 의무나 인센티브와 같은 더 외부적인 동기에서 벗어나는 것이 일반적이다. 이는 사용자가 스스로 플랫폼 기능을 선택하고 더 넓은 플랫폼 에코시스템에 이상적으로 그들의 노력을 투자하도록 만든다.

-A diagram to indicate a common growth pattern for platform adoption. This showcases the often slow start driven mainly by platform builders. Once platforms provide enough value to users, growth becomes more pulled by the users causing a steeper adoption curve. +플랫폼 채택의 일반적인 성장 패턴을 나타내는 다이어그램이다. 이는 주로 플랫폼 빌더에 의해 주도하는 느린 시작을 보여준다. 일단 플랫폼이 사용자에게 충분한 가치를 제공하게 되면, 사용자에 의해 성장세가 더욱 빨라져 채택 곡선이 가파르게 된다.


-### Level 1, Provisional — Erratic +### 레벨 1, 제공(Provisional) — 불규칙 -Adoption of shared platforms and capabilities is sporadic and inconsistent. No organization-wide strategy or guidance exists for choosing and integrating required backing services and technologies. Individual teams might leverage platform practices to improve their own processes, but there is no coordinated effort or standardization across the organization. This level of adoption is characterized by the absence of a coherent approach and the idea that external tools are more effective than those provided internally. +공유 플랫폼과 기능의 채택은 산발적이고 일관성이 없다. 필요한 지원 서비스 및 기술을 선택하고 통합하기 위한 조직 차원의 전략이나 지침이 존재하지 않는다. 개별 팀은 자체 프로세스를 개선하기 위해 플랫폼 관행을 활용할 수 있지만, 조직 전체에 걸쳐 조율된 노력이나 표준화는 없다. 이러한 수준의 채택은 일관된 접근 방식이 없고 외부 도구가 내부에서 제공하는 도구보다 더 효과적이라는 생각이 특징이다. -#### Characteristics: +#### 특징: -* One-off tools, services, and capabilities are managed by and consumed by various teams and departments in the organization. -* Provider-managed (aka "cloud") services are adopted and used inconsistently and without standard practices and policies, as internal configurations are hard to find or use. -* App and service teams discover tools and capabilities haphazardly, via rumors and chance conversations rather than through a more centralized process. -* Coordination and reuse of components and capabilities is driven only by end users (application teams), if at all. -* Product teams each maintain their own set of scripts or tools to deploy their applications. +* 일회성 도구, 서비스와 기능은 조직의 다양한 팀과 부서에서 관리하고 사용한다. +* 공급자 관리(일명 "클라우드") 서비스는 내부 구성을 찾거나 사용하기 어렵기 때문에 표준 관행과 정책 없이 일관성 없이 채택되고 사용된다. +* 앱 및 서비스 팀이 중앙 집중식 프로세스가 아닌 소문이나 우연한 대화를 통해 도구와 기능을 우연히 발견한다. +* 구성 요소와 기능의 조정과 재사용은 최종 사용자(애플리케이션 팀)에 의해서만 이루어진다. +* 프로덕트 팀은 각각 애플리케이션 배포를 위한 자체 스크립트 또는 도구 세트를 유지 관리한다. -#### Example Scenarios: +#### 예시 시나리오: -* A banking service requires a database. A developer finds out from a friend on another team that they can request an AWS account and set up an RDS database. From another team they find a Terraform script to provision that database. For monitoring they use CloudWatch on an ad hoc basis; they copy secrets from the AWS console to an instance of Hashicorp Vault manually before running the Terraform script. +* 은행 서비스에는 데이터베이스가 필요하다. 한 개발자가 다른 팀의 친구로부터 AWS 계정을 요청하고 RDS 데이터베이스를 설정할 수 있다는 사실을 알게 되었다. 다른 팀에서 해당 데이터베이스를 프로비저닝하기 위한 Terraform 스크립트를 찾는다. 모니터링을 위해 임시로 CloudWatch를 사용한다; Terraform 스크립트를 실행하기 전에 AWS 콘솔에서 해시코프 볼트 인스턴스로 시크릿을 수동으로 복사한다. -### Level 2, Operationalized — Extrinsic push +### 레벨 2, 운영(Operationalized) — 외부 푸시 -The organization recognizes the value of shared platforms and capabilities and strives to encourage and nurture them. Internal directives incentivize or even require use of shared platform services for some use cases. Some product teams use platform capabilities more than others; capabilities cover typical use cases in the organization but not unusual ones; and it is difficult to add those outliers to the common platform. +조직은 공유 플랫폼과 기능의 가치를 인정하고 이를 장려하고 육성하기 위해 노력한다. 내부 지침에 따라 일부 사용 사례에 대해서는 공유 플랫폼 서비스 사용을 장려하거나 요구하기도 한다. 일부 프로덕트 팀은 다른 프로덕트 팀보다 플랫폼 기능을 더 많이 사용한다; 기능은 조직의 일반적인 사용 사례는 포함하지만 특이한 사용 사례는 포함하지 않는다; 그리고 이러한 이상치를 공통 플랫폼에 추가하기는 어렵다. -User discovery of capabilities and how to use them is inconsistent; it is possible a user on a product team won't discover a supported capability unless directed there by a platform team. +사용자가 기능을 발견하고 사용하는 방법은 일관되지 않는다; 프로덕트 팀의 사용자가 플랫폼 팀의 지시가 없다면 지원되는 기능을 발견하지 못할 수도 있다. -#### Characteristics: +#### 특징: -* Some degree of external impetus leads to use of platform capabilities, for example: - * Incentives such as personal reviews - * Mandates such as requiring use for production releases or receiving funding -* The utilization of platform capabilities is fragmented — users may take advantage of one capability but might not be aware of, or interested in adopting, others that are available. -* Users have low motivation to learn how to use platform capabilities and rely heavily on collaboration with the providers through forums like office hours or help desk. -* Platform users are encouraged to join informal communities of practice to share problems and solutions but attendance may be limited. +* 어느 정도의 외부 자극은 플랫폼 기능의 사용으로 이어진다. 예를 들면 다음과 같다. + * 개인 리뷰와 같은 인센티브 + * 프로덕션 릴리스에 사용을 요구하거나 자금을 지원받는 것과 같은 의무 사항 +* 플랫폼 기능의 활용은 단편적이다 - 사용자는 한 가지 기능을 활용할 수 있지만 사용 가능한 다른 기능을 인식하지 못하거나 채택하는 데 관심이 없을 수도 있다. +* 사용자는 플랫폼 기능 사용법을 배우려는 동기가 낮고 업무 시간이나 헬프 데스크와 같은 포럼을 통해 공급자와의 협업에 크게 의존한다. +* 플랫폼 사용자는 비공식적인 실무 커뮤니티에 참여하여 문제와 해결책을 공유하도록 권장되지만 참석이 제한될 수 있다. -#### Example Scenarios: +#### 예시 시나리오: -* An engineering organization decides on a standard deployment tool and instructs all teams to use it. New processes (communication of release notes, etc) are built around that standard. Teams are instructed to stop using other sorts of deployment scripts and use the common tool instead. This is difficult for some teams whose needs are not met by the new process but do not understand or are not allowed to extend it. +* 엔지니어링 조직에서 표준 배포 도구를 결정하고 모든 팀에게 이를 사용하도록 지시한다. 새로운 프로세스(릴리스 노트 커뮤니케이션 등)는 해당 표준을 중심으로 구축된다. 팀들은 다른 종류의 배포 스크립트 사용을 중단하고 대신 공통 도구를 사용하라는 지시를 받는다. 새로운 프로세스를 이해하지 못하거나 확장할 수 없는 일부 팀에게는 이 과정이 어려울 수 있다. -### Level 3, Scalable — Intrinsic pull +### 레벨 3, 확장(Scalable) — 내부 풀 -Users on product and service teams choose to use platforms and their capabilities because of the clear value they provide in reducing cognitive load on product teams while providing higher quality supporting services. Documentation and ergonomic interfaces enable product team users to quickly provision and use platform capabilities. Users choose internal platform implementations over alternatives such as developing the capability themselves or hiring a provider. +프로덕트와 서비스 팀의 사용자들은 더 높은 품질의 지원 서비스를 제공하면서 프로덕트 팀의 인지 부하를 줄이는 데 제공되는 명확한 가치 때문에 플랫폼과 그 기능을 사용하기로 선택한다. 문서화와 인체공학적 인터페이스를 통해 프로덕트 팀 사용자는 플랫폼 기능을 신속하게 프로비저닝하고 사용할 수 있다. 사용자들은 직접 기능을 개발하거나 공급자를 고용하는 등의 대안 대신 내부 플랫폼 구현을 선택한다. -#### Characteristics: +#### 특징: -* Platform adoption is self-sustaining –The primary driver for core adoption is not an external impetus or incentive which mandates users use platform offerings – rather it is the values of these platform offerings themselves which draws users to them. -* After using and appreciating one or some platform capabilities, users seek out others and find the experience is similar across capabilities. There is an expectation that an individual capability is not isolated, rather it is one feature among a larger platform feature set. -* Platform teams encourage the natural adoption of platforms by gathering user feedback, sharing roadmaps and maintaining open forums for conversation with users. -* Application and product teams value platform capabilities enough to pay for them, e.g., via a chargeback system. -* Users can share feedback and learn about upcoming features through open forums and shared roadmaps. -* Self-serve portals, golden-path templates, and other documents enable rapid use. +* 플랫폼 채택은 자립적이다 - 핵심 채택의 주요 동인은 사용자가 플랫폼 제품을 사용하도록 하는 외부의 자극이나 인센티브가 아니다 - 오히려 사용자를 끌어들이는 플랫폼 제품 자체의 가치이다. +* 사용자는 한 가지 또는 일부 플랫폼 기능을 사용하고 만족한 후, 다른 기능을 찾게 되고 여러 기능에서 비슷한 경험을 하게 된다. 개별 기능이 분리된 것이 아니라, 오히려 더 큰 플랫폼 기능 세트 중 하나의 기능일 것이라는 기대가 있다. +* 플랫폼 팀은 사용자 피드백을 수집하고 로드맵을 공유하며 사용자와의 대화를 위한 공개 포럼을 유지함으로써 플랫폼의 자연스러운 채택을 장려한다. +* 애플리케이션 및 프로덕트 팀은 지불 거절(chargeback) 시스템 등을 통해 플랫폼 기능에 대한 비용을 지불할 만큼 플랫폼 기능을 중요하게 생각한다. +* 사용자는 공개 포럼과 공유 로드맵을 통해 피드백을 공유하고 향후 출시될 기능에 대해 배울 수 있다. +* 셀프 서비스 포털, 골든패스 템플릿과 기타 문서를 통해 빠르게 사용할 수 있다. -#### Example Scenarios: +#### 예시 시나리오: -* An application team previously had success requesting a new database. Their process was easy to understand and required almost no waiting time. In addition, key capabilities like backups and monitoring that allowed the team to progress their use all the way to production without issue were included. This experience meant that when the team later needed a queue, their first instinct was to check for an internal platform option. While they originally intended to use a specific queue technology, in the end, they chose to use the one offered internally since they knew how well integrated the solution would be for their organization. +* 한 애플리케이션 팀이 이전에 새 데이터베이스를 성공적으로 요청한 적이 있다. 프로세스는 이해하기 쉬웠고 대기 시간도 거의 필요하지 않았다. 게다가, 백업과 모니터링 같은 핵심 기능이 포함되어 있어 문제 없이 프로덕션까지 사용할 수 있었다. 이러한 경험은 팀이 나중에 큐가 필요할 때, 가장 먼저 본능적으로 내부 플랫폼 옵션을 확인하는 것임을 의미했다. 원래는 특정 큐 기술을 사용하려고 했지만, 결국 내부에서 제공하는 솔루션이 조직에 얼마나 잘 통합되는지 알았기 때문에 내부에서 제공하는 기술을 사용하기로 결정했다. -### Level 4, Optimizing — Participatory +### 레벨 4, 최적화(Optimizing) — 참여형 -Users from product teams further invest in platform capabilities by joining the ecosystem and contributing back to it. Some contributions improve and fix existing capabilities; others introduce new capabilities and features to address new use cases. Processes and services are defined and enable users to identify requirements and coordinate contributions amongst several product and platform teams. New capabilities are published via consistent interfaces and portals and with complete documentation and standard versioning. +프로덕트 팀의 사용자는 에코시스템에 참여하여 다시 기여함으로써 플랫폼 기능에 더욱 투자한다. 일부 기여는 기존 기능을 개선하고 수정한다; 다른 기여는 새로운 사용 사례를 해결하기 위해 새로운 기능과 특징을 도입한다. 프로세스와 서비스가 정의되어 사용자가 요구사항을 파악하고 여러 제품과 플랫폼 팀 간의 기여를 조정할 수 있다. 새로운 기능은 일관된 인터페이스와 포털을 통해 완전한 문서화 와 표준 버전 관리와 함께 게시된다. -#### Characteristics: +#### 특징: -* Users in app/service teams are empowered to contribute fixes, features, and feedback for platform capabilities. -* External projects and standards are strategically leveraged to reduce maintenance costs, accelerate new feature delivery, and use organization headcount most effectively. -* New capabilities and enhancements are coordinated asynchronously through issue boards and pull requests. Documents and checklists enable self-driven development by contributors. -* Developer advocates and internal ambassadors build and support an internal user community that extends platform ownership to app and service team contributors, too. -* Use of platform capabilities is viewed as the best way of working at the organization by both leadership and individual contributors. -* Platform engineers participate in product team planning to learn of requirements and suggest relevant existing capabilities. +* 앱/서비스 팀의 사용자는 플랫폼 기능에 대한 수정 사항, 기능 및 피드백을 제공할 수 있다. +* 외부 프로젝트와 표준을 전략적으로 활용하여 유지관리 비용을 절감하고, 새로운 기능 제공을 가속화하고, 조직 인력을 가장 효과적으로 활용한다. +* 새로운 기능과 개선 사항은 이슈 보드와 풀 리퀘스트를 통해 비동기적으로 조정된다. 문서와 체크리스트를 통해 기여자가 자기 주도적으로 개발할 수 있다. +* 개발자 옹호자와 내부 홍보대사가 플랫폼 소유권을 앱과 서비스 팀 기여자에게까지 확장하여 내부 사용자 커뮤니티를 구축하고 지원한다. +* 플랫폼 기능의 사용은 리더(leadership)와 개인 기여자 모두 조직에서 일하는 가장 좋은 방법으로 간주된다. +* 플랫폼 엔지니어는 프로덕트 팀 계획에 참여하여 요구 사항을 파악하고 관련 기존 기능을 제안한다. -#### Example Scenarios: +#### 예시 시나리오: -* A team wants an alternative backup plan. After proposing this as a general offering, it is deemed low priority due to minimal reuse. The proposing team chooses to integrate their solution into the platform framework and make it available to the organization. It is originally an alpha offering but once it meets all of the operational requirements can be promoted to a core platform capability. +* 한 팀에서 대체 백업 계획을 원한다. 이를 일반 제안(offering)으로 제안한 후, 재사용이 최소화되어 우선순위가 낮은 것으로 간주된다. 제안 팀은 솔루션을 플랫폼 프레임워크에 통합하여 조직에서 사용할 수 있도록 하기로 선택한다. 원래는 알파 제안(offering)이지만 모든 운영 요구 사항을 충족하면 핵심 플랫폼 기능으로 승격될 수 있다. {{< /tab >}} {{< tab tabName="Interfaces">}} -

How do users interact with and consume platform capabilities?

+

사용자는 어떻게 플랫폼 기능과 상호 작용하고 소비하나요?

-The interfaces provided by platforms affect how users interact with these platform offerings to provision, manage, and observe capabilities. Interfaces can include ticketing systems, project templates, and graphical portals as well as automatable APIs and command-line (CLI) tools. +플랫폼에서 제공하는 인터페이스는 사용자가 기능을 프로비저닝, 관리, 관찰하기 위해 이러한 플랫폼 제품과 상호작용하는 방식에 영향을 미친다. 인터페이스에는 자동화 가능한 API 및 명령줄(CLI) 도구뿐만 아니라 티켓팅 시스템, 프로젝트 템플릿, 그래픽 포털들이 포함될 수 있다. -Key characteristics of an interface include how discoverable and user-friendly it is during key user journeys like initial request, maintenance, or incident triage. Higher levels of maturity here reflect more integrated, consistent, automated, and supported interfaces. +인터페이스의 주요 특징에는 초기 요청, 유지 관리 또는 사고 분류와 같은 주요 사용자 여정에서 얼마나 검색 가능하고 사용자 친화적인지가 포함된다. 여기서 성숙도가 높을수록 더 통합되고, 일관되며, 자동화되고, 지원되는 인터페이스가 반영된다. -### Level 1, Provisional — Custom processes +### 레벨 1, 제공(Provisional) — 사용자 정의 프로세스 -A collection of varying processes exists to provision different capabilities and services, but the consistency of the interface is not considered. Custom tailor-made processes address the immediate needs of individuals or teams and are reliant on manual intervention even if the provider uses some automated implementation scripts. +다양한 기능과 서비스를 제공하기 위해 다양한 프로세스의 집합이 존재하지만, 인터페이스의 일관성은 고려되지 않는다. 사용자 맞춤형 프로세스는 개인이나 팀의 즉각적인 요구 사항을 해결하며 공급자가 일부 자동화된 구현 스크립트를 사용하더라도 수동 개입에 의존한다. -Knowledge of how to request these solutions is shared from person to person. The process for requesting a service lacks standardization and consistency. Provisioning and using a platform service likely requires deep support from the capability provider. +이러한 솔루션을 요청하는 방법에 대한 지식은 개인 간에 공유된다. 서비스 요청 프로세스는 표준화 및 일관성이 부족하다. 플랫폼 서비스를 프로비저닝하고 사용하려면 기능 공급자의 심층적인 지원이 필요할 수 있다. -Lack of central requirements and standards makes this level appropriate when the company has not yet identified and documented expectations. It can be particularly effective for teams at early stage companies or platform efforts. In these environments teams are provided the freedom to evolve processes and capabilities to their needs, allowing them to deliver more quickly and pay the price of standardization only when necessary later on. +중앙 요구사항과 표준이 부족하여 회사가 아직 기대치를 파악하고 문서화하지 않은 경우에 이 수준이 적합하다. 특히 초기 단계의 회사나 플랫폼 작업을 하는 팀에 효과적일 수 있다. 이러한 환경에서는 팀이 필요에 따라 프로세스와 기능을 자유롭게 발전시킬 수 있으므로, 나중에 필요할 때만 표준화에 대한 대가를 지불하고 더 빠르게 제공할 수 있다. -#### Characteristics: +#### 특징: -* User interaction is not a key topic of discussion and rarely (if ever) are interactions tested during design and delivery of new capabilities. -* Capabilities are mainly provided through manual requests, though providers may choose to automate some or all of the activities necessary to provision a user request. -* Requests that are on the face “simple” become complex due to finding out the right process to follow -* Sometimes a process appears to be sanctioned, but users run into issues when a different department or team gets involved +* 사용자 상호작용은 주요 논의 주제가 아니며 새로운 기능을 다자인하고 제공하는 과정에서 상호작용을 테스트하는 경우는 거의 없다. +* 기능은 주로 수동 요청을 통해 제공되지만 공급자는 사용자 요청을 프로비저닝하는 데 필요한 활동의 일부 또는 전부를 자동화할 수 있다. +* 겉보기에는 “단순”해 보이는 요청이 따라야 할 올바른 프로세스를 찾느라 복잡해지기도 한다. +* 때때로 프로세스가 승인된 것처럼 보이지만, 다른 부서나 팀이 관여할 때 사용자에게 문제가 발생하는 경우도 있다. -#### Example Scenarios: +#### 예시 시나리오: -* An application team wants to performance test their new change. To do this, they want an isolated environment that contains enough test data to get an accurate performance read. The last time they had this request a former teammate was able to get access to an environment, but they have since moved on and no one knows how to recreate it. In the end, they are connected to an engineer on the infrastructure team who is able to provision them an environment in a few days. -* A team in the exploratory phases of product development uses a bespoke process to provision a new cloud service without needing to validate their solution warrants further investment. +* 애플리케이션 팀이 새로운 변경 사항을 성능 테스트하려고 한다. 이를 위해, 정확한 성능을 파악할 수 있는 충분한 테스트 데이터가 포함된 격리된 환경을 원한다. 마지막으로 이 요청을 받았을 때 이전 팀원이 환경에 액세스할 수 있었지만, 그 후 이직하여 아무도 환경을 다시 만드는 방법을 모른다. 결국, 며칠 내에 환경을 프로비저닝할 수 있는 인프라 팀의 엔지니어와 연결되어졌다. +* 프로덕트 개발의 탐색 단계에 있는 팀은 맞춤형 프로세스를 사용하여 솔루션이 추가 투자를 보장하는지 검증할 필요 없이 새로운 클라우드 서비스를 프로비저닝할 수 있다. -### Level 2, Operationalized — Standard tooling +### 레벨 2, 운영(Operationalized) — 표준 도구 -Consistent, standard interfaces for provisioning and observing platforms and capabilities exist and meet broad needs. Users are able to identify what capabilities are available and are enabled to request capabilities that they require. +플랫폼과 기능을 프로비저닝하고 관찰하기 위한 일관된 표준 인터페이스가 존재하며 광범위한 요구사항을 충족한다. 사용자는 사용 가능한 기능을 파악할 수 있으며 필요한 기능을 요청할 수도 있다. -"Paved roads" or "golden paths", in the form of documentation and templates, are provided. These resources define how to provision and manage typical capabilities using compliant and tested patterns. While some users are able to use these solutions on their own, the solutions often still require deep domain expertise and therefore support from maintainers is still vital. +문서와 템플릿의 형태로 "포장된 길(Paved roads)" 또는 "황금 경로(golden paths)"가 제공된다. 이러한 리소스는 규정을 준수하고 테스트를 거친 패턴을 사용하여 일반적인 기능을 프로비저닝하고 관리하는 방법을 정의한다. 일부 사용자는 이러한 솔루션을 스스로 사용할 수 있지만, 이러한 솔루션에는 여전히 심층적인 도메인 전문 지식이 필요한 경우가 많으므로 유지 관리자의 지원이 여전히 필수적이다. -#### Characteristics: +#### 특징: -* Technical solutions are built-in tools specific to their problem domain, not always tools familiar to the users. -* There is investment in a common path; however, deviating from that path quickly uncovers few customization options as the focus was on building a single option. -* Given standardization, informal internal groups are able to form and gather to share good practices and overcome shared problems. -* There may be drift on capability implementation as teams take templates, customize them, and then cannot merge in changes from the centralized team. +* 기술 솔루션은 문제 영역에 특정한 기본 제공 도구이며, 항상 사용자에게 친숙한 도구는 아니다. +* 공통 경로에 대한 투자가 있다; 그러나, 단일 옵션을 구축하는 데 중점을 두었기 때문에 해당 경로에서 벗어나는 것은 적은 사용자 정의 옵션을 빠르게 발견하게 된다. +* 표준화를 통해, 비공식 내부 그룹이 형성되고 모여 모범 사례를 공유하고 공유된 문제를 극복할 수 있다. +* 팀이 템플릿을 가져와 사용자 정의한 다음 중앙 집중식 팀의 변경 사항을 병합할 수 없기 때문에 기능 구현에 드리프트가 있을 수 있다. -#### Example Scenarios: +#### 예시 시나리오: -* A centralized team curates a library of Terraform modules, Kubernetes controllers, and CRDs for provisioning different types of infrastructure. -* A shared location includes comprehensive documents about solutions across the organization. +* 중앙 집중식 팀이 다양한 유형의 인프라를 프로비저닝하기 위해 Terraform 모듈, Kubernetes 컨트롤러 및 CRD를 큐레이션한다. +* 공유 위치에는 조직 전반의 솔루션에 대한 종합적인 문서가 포함되어 있다. -### Level 3, Scalable — Self-service solutions +### 레벨 3, 확장(Scalable) — 셀프 서비스 솔루션 -Solutions are offered in a way that provides autonomy to users and requires little support from maintainers. The organization encourages and enables solutions to provide consistent interfaces that enable discoverability and portability of user experience from one capability to another. While self-service, the solutions do require team awareness and implementation. In order to improve this experience there may be a guided and simplified internal language which enables users to adopt and integrate platform capabilities more quickly. This generates a user-centric, self-serviceable, and consistent collection of capabilities. +솔루션은 사용자에게 자율성을 제공하고 메인테이너의 지원이 거의 필요하지 않은 방식으로 제공된다. 조직은 솔루션이 한 기능에서 다른 기능으로 사용자 경험을 검색하고 이동시킬 수 있는 일관된 인터페이스를 제공하도록 장려하고 이를 가능하게 한다. 셀프 서비스이지만, 이러한 솔루션은 팀의 인식과 구현이 필요하다. 이러한 경험을 개선하기 위해 사용자가 플랫폼 기능을 보다 빠르게 채택하고 통합할 수 있도록 안내하고 간소화한 내부 언어가 있을 수 있다. 이렇게 하면 사용자 중심의 셀프 서비스가 가능하고 일관된 기능 모음이 생성된다. -#### Characteristics: +#### 특징: -* Solutions are provided as “one-click” implementations, enabling teams to benefit from a capability without needing to understand how they are provisioned. -* While the solutions are easy to create, there may not be as much usability built into the day 2 and beyond management of the solution. -* There continues to be a narrow path of available solutions, leaving users with unique requirements unsure how to proceed. +* 솔루션은 "원클릭" 구현으로 제공되므로, 프로비저닝 방법을 이해할 필요 없이 팀에서 기능을 활용할 수 있다. +* 솔루션은 쉽게 만들 수 있지만, 2일 차와 솔루션 관리 이후에는 유용성이 그다지 높지 않을 수 있다. +* 사용 가능한 솔루션의 경로가 계속 좁아지고 있어, 고유한 요구 사항을 가진 사용자가 어떻게 진행해야 할지 모를 수 있다. -#### Example Scenarios: +#### 예시 시나리오: -* An API is provided which abstracts the creation and maintenance of databases and provides users with any information they require to leverage that platform capability such as a connection string, location for secret data, and dashboard with observability data. +* 데이터베이스의 생성과 유지 관리를 추상화하고 연결 문자열, 시크릿 데이터의 위치, 관찰 가능성(Observability) 데이터가 있는 대시보드와 같은 해당 플랫폼 기능을 활용하는 데 필요한 모든 정보를 사용자에게 제공하는 API가 제공된다. -### Level 4, Optimizing — Managed services +### 레벨 4, 최적화(Optimizing) — 관리형 서비스 -Platform capabilities are transparently integrated into the tools and processes that teams already use to do their work. Some capabilities are provisioned automatically, such as observability or identity management for a deployed service. When users hit the edges of the provided services, there is an opportunity to move past automated solutions and customize for their needs without leaving the internal offerings because platform capabilities are considered building blocks. These building blocks are used to build transparent and automatic compositions to meet the higher-level use cases while enabling deeper customization where necessary. +플랫폼 기능은 팀이 이미 업무에 사용하고 있는 도구와 프로세스에 투명하게 통합된다. 배포된 서비스에 대한 관찰 가능성(Observability) 또는 신원 관리와 같은 일부 기능은 자동으로 프로비저닝된다. 사용자가 제공된 서비스의 가장자리에 도달하면, 플랫폼 기능은 빌딩 블록으로 간주되기 때문에 내부 제품을 떠나지 않고도 자동화된 솔루션을 넘어 필요에 맞게 사용자 정의할 수 있는 기회가 있다. 이러한 빌딩 블록은 투명하고 자동화된 구성을 구축하여 상위 수준의 사용 사례를 충족하는 동시에 필요한 경우 더 심층적인 사용자 지정이 가능하도록 하는 데 사용된다. -#### Characteristics: +#### 특징: -* It is clear what capabilities are differentiating for the organization and which are not, allowing the internal teams to invest in custom solutions only where they can not leverage industry standards. -* While capabilities are surfaced in a consistent way, there is no one way to use a capability. Some are best suited as CLI tools for use in scripts whereas others benefit from integration into where the user is writing code in their editors and IDEs. -* The value of individual capabilities is extended with a focus on the flow of both software development and release, leading to a focus on how to combine capabilities into higher level offerings. -* While capabilities are often provided in packages, super users are enabled to decompose these higher level offerings in order to optimize when and where they need to. +* 조직을 차별화하는 기능과 그렇지 않은 기능이 명확하므로, 내부 팀은 업계 표준을 활용할 수 없는 경우에만 맞춤형 솔루션에 투자할 수 있다. +* 기능은 일관된 방식으로 표면화되지만, 기능을 사용하기 위한 방법은 제한이 없다. 일부는 스크립트에 사용하기 위한 CLI 도구로 가장 적합한 반면 다른 일부는 사용자가 편집기 및 IDE에서 코드를 작성하는 위치에 통합되어 이점을 얻는다. +* 개별 기능의 가치는 소프트웨어 개발 및 릴리스의 흐름에 초점을 맞춰 확장되어, 기능을 더 높은 수준의 제품으로 결합하는 방법에 중점을 둔다. +* 기능은 패키지 형태로 제공되는 경우가 많지만, 슈퍼 유저는 필요한 시기와 장소를 최적화하기 위해 이러한 더 높은 수준의 서비스를 분해할 수 있다. -#### Example Scenarios: +#### 예시 시나리오: -* Observability agents are injected into every workload and an OIDC proxy is placed in front of all applications. -* By default every new project receives a space in a task runner (pipelines) and a runtime environment (K8s namespace), however a project can opt into other options such as serverless runtime. -* From a catalog in a Service Now portal a user selects "Provision a Database." Automation provisions an RDS database and sends a URL and location to get credentials to the user. +* 모든 워크로드에 관찰 가능성(Observability) 에이전트가 주입되고 모든 애플리케이션 앞에 OIDC 프록시가 배치된다. +* 기본적으로 모든 새 프로젝트는 태스크 러너 (파이프라인) 와 런타임 환경(K8s 네임스페이스)의 공간을 제공받지만, 프로젝트는 서버리스 런타임과 같은 다른 옵션을 선택할 수 있다. +* 서비스 나우 포털의 카탈로그에서 사용자가 “데이터베이스 프로비저닝”을 선택하면 자동화가 RDS 데이터베이스를 프로비저닝하고 사용자에게 자격 증명을 가져올 수 있는 URL과 위치를 보낸다. {{< /tab >}} {{< tab tabName="Operations">}} -

How are platforms and their capabilities planned, prioritized, developed and maintained?

+

플랫폼과 그 기능은 어떻게 계획되고, 우선순위가 정해지고, 개발되고, 유지관리되나요?

-Operation of platforms means running and supporting its capabilities and their features over their whole lifetime, including acceptance of new requests, initial releases, upgrades and extensions, ongoing maintenance and operations, user support, and even deprecation and termination. Organizations and their platform teams choose platforms and capabilities to create and maintain and can prioritize the most valuable and impactful initiatives. +플랫폼 운영이란 새로운 요청의 수락, 초기 릴리스, 업그레이드와 확장, 지속적인 유지관리와 운영, 사용자 지원, 심지어 사용 중단과 종료까지 포함하여 전체 수명 기간 동안 플랫폼의 기능과 특징들을 실행하고 지원하는 것을 의미한다. 조직과 플랫폼 팀은 플랫폼과 기능을 선택하여 만들고 유지 관리하며 가장 가치 있고 영향력 있는 이니셔티브의 우선순위를 정할 수 있다. -Notably, most of the work to provide a capability is expended after its initial release — in providing seamless upgrades, new and improved features, operational support, and end-user enablement and education. Therefore an impactful, valuable platform will plan in advance and manage their platform for long-term sustainable operations and reliability. +특히, 기능을 제공하기 위한 대부분의 작업은 초기 출시 이후 - 원활한 업그레이드, 새롭고 향상된 기능, 운영 지원, 최종 사용자 지원 과 교육 제공으로 확장된다. 따라서 영향력 있고 가치 있는 플랫폼은 장기적으로 지속 가능한 운영과 안정성을 위해 미리 계획을 세우고 플랫폼을 관리한다. -### Level 1, Provisional — By request +### 레벨 1, 제공(Provisional) — 요청마다 -Platforms and capabilities are developed, published, and updated reactively, based on ad hoc product team requests and requirements. Product teams themselves may even need to plan and build the capabilities they require. +플랫폼과 기능은 임시(ad hoc) 프로덕트 팀의 요청과 요구 사항에 따라 즉각적으로 개발되고, 게시되고 업데이트된다. 심지어 프로덕트 팀이 스스로 필요한 기능을 계획하고 구축해야 할 수도 있다. -Teams who build a new capability, whether dedicated centralized teams or application teams meeting their own needs, take only informal responsibility for supporting others using it. They are not expected to actively maintain it and few processes exist to vet the quality of the offering. In this level, implementations are often ignored until a security vulnerability is discovered, a bug prevents use, or a new requirement arrives, at which point another reactive plan may be quickly implemented. +전담 중앙 집중식 팀이든 자체 요구 사항을 충족하는 애플리케이션 팀이든 새로운 기능을 구축하는 팀은 그 기능을 사용하는 다른 사람들을 지원하는 비공식적인 책임만 진다. 그들은 적극적으로 유지 관리하지 않을 것으로 예상되며 제공된 기능의 품질을 검증하는 프로세스도 거의 존재하지 않는다. 이러한 수준에서, 보안 취약점이 발견되거나 버그로 인해 사용이 불가능하거나 새로운 요구 사항이 발생할 때까지 구현이 종종 무시되며, 이 시점에서 다른 대응 계획이 신속하게 구현될 수 있다. -#### Characteristics: +#### 특징: -* Capabilities are created to meet the pressing needs of individual application teams. -* Focus is on initial delivery of core capabilities; plans are not made for ongoing maintenance and sustainability. -* Capability implementations are generally out of date and awaiting updates. -* Sudden spikes of work are introduced for late-breaking high-impact changes to capabilities, such as discovery of a vulnerability. -* Changes can result in both planned and unplanned downtime. -* Each upgrade is done in a bespoke way, requiring time and research to devise a process on each upgrade. +* 개별 애플리케이션 팀의 긴급한 요구 사항을 충족하기 위해 기능이 만들어진다. +* 핵심 기능의 초기 제공에 중점을 두며; 지속적인 유지 관리와 지속 가능성에 대한 계획은 수립되지 않는다. +* 기능 구현이 일반적으로 오래되어 업데이트를 기다리고 있다. +* 취약점 발견과 같이 영향력이 큰 기능 변경을 위해 갑작스럽게 업무가 급증한다. +* 변경으로 인해 계획된 다운타임과 계획되지 않은 다운타임이 모두 발생할 수 있다. +* 각 업그레이드는 맞춤형 방식으로 이루어지므로 각, 업그레이드에 대한 프로세스를 고안하는 데 많은 시간과 연구가 필요하다. -#### Example Scenarios: +#### 예시 시나리오: -* Log4Shell security vulnerability is announced and the organization spins up a specialty team to investigate where the organization may be vulnerable and instigate patches. Once the team identifies the impact, they must work hand in hand with a number of different teams since each one manages their servers and upgrade processes differently. Even when this work is deemed complete, the confidence level is fairly low that there won’t be more instances uncovered. +* Log4Shell 보안 취약점이 발표되고 조직은 전문 팀을 구성하여 조직이 취약할 수 있는 부분을 조사하고 패치를 유도한다. 팀에서 영향을 파악한 후, 각 팀마다 서버와 업그레이드 프로세스를 다르게 관리하기 때문에 여러 팀과 협력하여 작업해야 한다. 이 작업이 완료된 것으로 간주되더라도, 더 많은 사례가 발견되지 않을 것이라는 신뢰 수준은 상당히 낮다. -### Level 2, Operationalized — Centrally tracked +### Level 2, 운영(Operationalized) — 중앙 추적 -Platforms and capabilities are centrally documented and discoverable, and processes for planning and managing the lifecycle of capabilities is at least lightly defined. Responsibility and ownership is documented for each service and function. Lifecycle management processes vary for different capabilities depending on their owners and their priorities. A centralized team maintains, or is able to on demand generate, an inventory of backlog capabilities to provide the state of maintenance for current capabilities. This allows the organization to track progress towards capability offering and compliance with upgrade requirements. +플랫폼과 기능은 중앙에서 문서화되고 검색이 가능하며, 기능의 수명주기를 계획하고 관리하는 프로세스는 최소한 간략하게 정의되어 있다. 각 서비스와 기능에 대한 책임과 소유권이 문서화되어 있다. 수명 주기 관리 프로세스는 소유자와 우선순위에 따라 기능마다 다양하다. 중앙 집중식 팀은 현재 기능에 대한 유지 관리 상태를 제공하기 위해 백로그 기능의 인벤토리를 유지 관리하거나 필요에 따라 생성할 수 있다. 이를 통해 조직은 기능 제공에 대한 진행 상황을 추적하고 업그레이드 요구 사항을 준수할 수 있다. -#### Characteristics: +#### 특징: -* Application teams create new capabilities as needed to meet pressing needs. -* A central team provides a register of available shared services across the organization. -* Loose standards, such as requiring an automatable API and usage docs, are applied to capabilities. -* Infrastructure as Code is used to allow easier traceability of deployed services. -* Audits for compliance regulations such as PCI DSS or HIPPA are enabled through the service inventories. -* Migration and upgrade work is tracked against a burndown chart enabling the organization to track rate of compliance and time until completion. -* Tracking does not indicate level of support; often upgrades at this stage are still manual and bespoke. +* 애플리케이션 팀은 긴급한 요구 사항을 충족하기 위해 필요에 따라 새로운 기능을 만든다. +* 중앙 팀에서 조직 전체에 사용 가능한 공유 서비스 목록을 제공한다. +* 자동화 가능한 API와 사용 설명서 요구와 같은 느슨한 표준이 기능에 적용된다. +* 배포된 서비스를 더 쉽게 추적할 수 있도록 코드형 인프라(IaC)를 사용한다. +* 서비스 인벤토리를 통해 PCI DSS 또는 HIPPA와 같은 규정 준수 규정에 대한 감사가 활성화된다. +* 마이그레이션과 업그레이드 작업을 번다운 차트에 따라 추적되므로 규정 준수율과 완료까지 걸리는 시간을 추적할 수 있다. +* 추적은 지원의 수준을 나타내지 않으며; 이 단계의 업그레이드는 여전히 수동과 맞춤형으로 이루어지는 경우가 많다. -#### Example Scenarios: +#### 예시 시나리오: -* PostgreSQL 11 is going EOL by the end of the year. The organization is aware of which databases require upgrade and are scheduling the work on each team’s backlog to complete. +* PostgreSQL 11은 연말에 지원 종료된다. 조직은 업그레이드가 필요한 데이터베이스를 파악하고 있으며 각 팀의 백로그 작업을 완료하기 위해 일정을 잡고 있다. -### Level 3, Scalable — Centrally enabled +### Level 3, 확장(Scalable) — 중앙 활성화 -Platforms and capabilities are not only centrally registered but also centrally orchestrated. Platform teams take responsibility for understanding the broad needs of the organization and prioritize work across platform and infrastructure teams accordingly. Those responsible for a capability are expected to not only maintain it technically, but also provide standard user experiences for integrating the capability with other related services around the organization, ensure secure and reliable use, and even provide observability. +플랫폼과 기능은 중앙에서 등록될 뿐만 아니라 중앙에서 조율된다. 플랫폼 팀은 조직의 광범위한 요구 사항을 파악하고 그에 따라 플랫폼 팀과 인프라 팀의 업무 우선순위를 정할 책임을 가진다. 기능을 담당하는 사람들은 해당 기능을 기술적으로 유지 관리할 뿐만 아니라, 조직 내 다른 관련 서비스와 기능을 통합하기 위한 표준 사용자 경험을 제공하고, 안전하고 안정적인 사용을 보장하며, 관찰 가능성까지 제공할 것으로 기대된다. -Standard processes for creating and evolving new capabilities exist, enabling anyone in the organization to contribute a solution that meets expectations. Continuous delivery processes for platform capabilities and features enable regular rollout and rollback. Large changes are planned and coordinated as they would be for customer-facing product changes. +새로운 기능을 만들고 발전시키기 위한 표준 프로세스가 존재하므로, 조직 내 누구나 기대에 부합하는 솔루션을 제공할 수 있다. 플랫폼 기능과 특징에 대한 지속적인 제공 프로세스를 통해 정기적인 롤아웃과 롤백이 가능하다. 대규모 변경은 고객 대면 프로덕트 변경과 마찬가지로 계획되고 조정된다. -#### Characteristics: +#### 특징: -* Application teams request services from platform teams first before creating them. -* New services must adhere to standard practices such as standard interfaces, documentation, and governance. -* Upgrade processes are documented and consistent across versions and services. -* Where the capability provider does not manage an upgrade, they provide tooling and support to the users for minimal impact. +* 애플리케이션 팀은 서비스를 만들기 전에 먼저 플랫폼 팀에 서비스를 요청한다. +* 새로운 서비스는 표준 인터페이스, 문서화와 거버넌스 같은 표준 관행을 준수해야 한다. +* 업그레이드 프로세스는 버전과 서비스 전반에 걸쳐 문서화되고 일관성을 유지한다. +* 기능 공급자가 업그레이드를 관리하지 않는 경우, 영향을 최소화하기 위해 사용자에게 도구와 지원을 제공한다. -#### Example Scenarios: +#### 예시 시나리오: -* The organization is going to upgrade to RHEL 9. In doing so, each application team needs to validate that their software continues to work. In order to enable this testing phase the centralized compute team is setting up test environments for each team with the correct software and OS versions. +* 조직은 RHEL 9로 업그레이드할 예정이다. 이 과정에서, 각 애플리케이션 팀은 소프트웨어가 계속 작동하는지 확인해야 한다. 이 테스트 단계를 활성화하기 위해 중앙 집중식 컴퓨팅 팀은 각 팀에 올바른 소프트웨어 및 OS 버전으로 테스트 환경을 설정하고 있다. -### Level 4, Optimizing — Managed services +### Level 4, 최적화(Optimizing) — 관리형 서비스 -The lifecycle of each capability is managed in a standardized, automated way. Capabilities, features and updates are delivered continuously with no impact on users. Any large changes instigated by platform providers include migration plans for existing users with defined responsibilities and timelines. +각 기능의 수명 주기는 표준화되고 자동화된 방식으로 관리된다. 기능, 특징과 업데이트는 사용자에게 영향을 주지 않고 지속적으로 제공된다. 플랫폼 공급자가 주도하는 모든 대규모 변경에는 책임과 일정이 정의된 기존 사용자를 위한 마이그레이션 계획이 포함된다. -Platform capability providers take on the brunt of responsibility for maintenance, but there is a clear contract — a "shared responsibility model" — describing the responsibilities of users, enabling both sides to operate mostly autonomously. +플랫폼 기능 공급자는 유지 관리에 대한 책임을 지지만, 사용자의 책임을 설명하는 명확한 계약 - "공유 책임 모델" - 을 통해, 양측이 대부분 자율적으로 운영할 수 있도록 한다. -#### Characteristics: +#### 특징: -* A shared ownership model clearly defines who is responsible for platforms and their capabilities and what is expected of users. +* 공유 소유권 모델은 플랫폼과 그 기능에 대한 책임이 누구에게 있는지 사용자에게 기대되는 것이 무엇인지 명확하게 정의한다. +* 팀은 업그레이드 실행과 롤백 전략을 모두 스크립화하여 위험과 영향을 낮게 유지한다. * Teams script both the execution of the upgrade and any rollback strategies to keep risk and impact low. -#### Example Scenarios: +#### 예시 시나리오: -* The users of virtual machines are not required to manage anything to do with version upgrades. Their only requirement is to have a stage in their delivery pipeline that contains a representative smoke test. They are then asked to declare their application as having lower risk tolerance so as to wait for a fully hardened upgrade or higher tolerance to become an early adopter. The virtual machine capability then manages the automated release of upgrades including rollbacks after either smoke test or canary release failures. +* 가상 머신 사용자는 버전 업그레이드와 관련된 어떤 것도 관리할 필요가 없다. 그들의 유일한 요구 사항은 배포 파이프라인에 대표적인 스모크 테스트가 포함된 단계를 갖는 것이다. 그런 다음 얼리 어답터가 되기 위해 완전히 굳어진 업그레이드 또는 더 높은 위험 허용 범위를 기다릴 수 있도록 애플리케이션을 위험 허용 범위가 낮은 것으로 선언하도록 요청받는다. 그런 다음 가상 머신 기능은 스모크 테스트 또는 카나리아 릴리스 실패 후 롤백을 포함한 업그레이드의 자동 릴리스를 관리한다. {{< /tab >}} {{< tab tabName="Measurement">}} -

What is the process for gathering and incorporating feedback and learning?

+

피드백과 학습을 수집하고 반영하는 과정은 어떻게 되나요?

-By reacting to explicit and implicit feedback from users, organizations can increase user satisfaction and ensure long-term platform sustainability. Organizations must balance innovation and meeting user demands to keep platform relevance. As technology and user preferences change, platforms that are agile and responsive to these changes will stand out. Regularly revisiting and refining the feedback mechanism can further optimize platform development and improve user engagement. +사용자의 명시적 및 암묵적 피드백에 반응함으로써, 조직은 사용자 만족도를 높이고 장기적인 플랫폼 지속 가능성을 보장할 수 있다. 조직은 플랫폼의 관련성을 유지하기 위해 혁신과 사용자 요구 충족의 균형을 유지해야 한다. 기술과 사용자 선호도가 변화함에 따라, 이러한 변화에 민첩하게 대응하는 플랫폼이 돋보이게 될 것이다. 피드백 메커니즘을 정기적으로 재검토하고 개선하면 플랫폼 개발을 더욱 최적화하고 사용자 참여를 향상시킬 수 있다. -### Level 1, Provisional — Ad hoc +### Level 1, 제공(Provisional) — 즉흥적 -Usage and satisfaction metrics are gathered in custom ways, if at all, for each platform and capability. Outcomes and measures of success are not consistently aligned across capabilities, and therefore corresponding insights are not gathered. User feedback and instrumentation of platform use may not be gathered, or if it is, it will be informal. Decisions are made based on anecdotal requirements and incomplete data. +사용량과 만족도 지표는 각 플랫폼과 기능별로 사용자 지정 방식으로 수집된다. 결과와 성공의 척도가 여러 기능에 걸쳐 일관되게 조정되지 않으므로, 그에 상응하는 인사이트가 수집되진 않는다. 플랫폼 사용에 대한 사용자 피드백과 계측이 수집되지 않거나, 수집되더라도 비공식적으로 이루어진다. 일화적인 요구 사항과 불완전한 데이터를 기반으로 의사 결정이 이루어지게 된다. -#### Characteristics: +#### 특징: -* No experience or opinions about how to measure success of platforms -* Use familiar tools to gather common metrics with limited intent and forethought -* Reliance on small amounts of data -* Difficult to secure user participation — users believe their feedback isn't considered -* If surveys are used, the questions change between runs, negating the ability to track progress +* 플랫폼의 성공을 측정하는 방법에 대한 경험이나 의견이 없다 +* 익숙한 도구를 사용하여 제한된 의도와 예측을 통해 일반적인 지표를 수집 +* 소량의 데이터에 의존 +* 사용자 참여를 확보하기 어렵다 - 사용자는 자신의 피드백이 고려되지 않는다고 생각한다 +* 설문조사를 사용하는 경우, 설문조사가 실행 간에 질문이 변경되어 진행 상황을 추적할 수 없다 -#### Example Scenarios: +#### 예시 시나리오: -* A platform tech lead wants to improve the collaboration with users by adding key topics to their next quarterly planning. They decide to run a survey on what users would like to see. The response is overwhelming, which is exciting, but also results in a difficulty organizing and responding to all of the ideas. While some ideas influence the quarterly planning, the users do not see their ideas as being accepted and are less inclined to reply to the next survey. -* The team wants to capture more data automatically, so they look for opportunities for easy collection such as test failures in CI. However, not every team uses the same CI automation so the data is only available for Java applications even though some teams have moved on to writing their services in Scala. +* 플랫폼 기술 책임자가 다음 분기 계획에 주요 주제를 추가하여 사용자와의 협업을 개선하고자 한다. 사용자들이 보고 싶어 하는 것에 대한 설문조사를 실시하기로 결정한다. 응답이 압도적으로 많아 흥미롭지만, 모든 아이디어를 정리하고 응답하는 데 어려움을 겪게 된다. 일부 아이디어는 분기별 계획에 영향을 미치지만, 사용자들은 자신의 아이디어가 받아들여졌다고 생각하지 않고 다음 설문조사에 응답하는 경향이 줄어든다. +* 팀은 더 많은 데이터를 자동으로 수집하기를 원하기 때문에, CI에서 테스트 실패와 같이 쉽게 수집할 수 있는 기회를 찾는다. 그러나, 모든 팀이 동일한 CI 자동화를 사용하는 것은 아니기 때문에 일부 팀은 Scala로 서비스를 작성하는 단계로 넘어갔지만 데이터는 Java 애플리케이션에서만 사용할 수 있다. -### Level 2, Operationalized — Consistent collection +### Level 2, 운영(Operationalized) — 일관된 수집 -Organizations at this level have an intentional goal to verify platform products meet the needs of their market of internal users. Actionable, structured collection of user feedback is valued. Dedicated teams or individuals might be assigned to gather feedback, ensuring a more consistent approach. Feedback channels, such as surveys or user forums, are standardized, and feedback is categorized and prioritized. Beyond user feedback, there is also an expectation that user experiences are instrumented to generate usage data over time. +이 단계의 조직은 플랫폼 프로덕트가 내부 사용자 시장의 요구 사항을 충족하는지 검증하려는 의도적인 목표를 가지고 있다. 실행 가능하고 구조화된 사용자 피드백 수집이 중요하다. 피드백 수집을 위해 전담 팀이나 개인을 지정하여, 보다 일관된 접근 방식을 보장할 수 있다. 설문조사나 사용자 포럼과 같은 피드백 채널은 표준화되어 있으며, 피드백은 분류되고 우선순위가 정해진다. 사용자 피드백 외에도, 사용자 경험을 계측하여 시간이 지남에 따라 사용 데이터를 생성하는 것도 기대할 수 있다. -Challenges remain in translating feedback into actionable tasks. While there is a growing repository of user data, the organization might need help effectively understanding and integrating this feedback into a platform roadmap. It may be hard to ensure that users see tangible changes driven by their feedback. +피드백을 실행 가능한 작업으로 전환하는 데는 여전히 과제가 남아 있다. 사용자 데이터의 저장소가 늘어나고 있지만, 조직은 이러한 피드백을 효과적으로 이해하고 플랫폼 로드맵에 통합하는 데 도움이 필요할 수 있다. 사용자가 피드백을 통해 가시적인 변화를 체감할 수 있도록 보장하는 것이 어려울 수 있다. -#### Characteristics: +#### 특징: -* Data collection is discussed as part of most major planning sessions or capability implementations. -* There may not be alignment on exactly what to measure to verify success. -* Platform features can be measured for success, such as by measuring user adoption or user time saved. +* 데이터 수집은 대부분의 주요 계획 세션 또는 기능 구현의 일부로 논의된다. +* 성공을 확인하기 위해 무엇을 측정해야 하는지 정확히 일치하지 않을 수 있다. +* 플랫폼 기능은 사용자 채택 또는 사용자 시간 절약을 측정하여 성공 여부를 측정할 수 있다. -#### Example Scenarios: +#### 예시 시나리오: -* A platform team allocates 20% of their time to user defined features, which they identify based on surveys and other interview techniques. Their findings are collected into a tool that enables additional voting and commenting to further refine priorities. During implementation the requesting users are approached for collaboration on early designs and implementations. Once implemented, there are announcements which make sure requesting users are aware of new features and supported in adopting them. -* The team focused on software delivery capabilities wants to capture more data automatically including cycle time which they automate through the build tool from commit to production. There is an understanding that cycle time can include other activities like PR review, but that isn’t included at this time. +* 플랫폼 팀은 설문조사와 기타 인터뷰 기법을 통해 파악한 사용자 정의 기능에 업무 시간의 20%를 할당한다. 조사 결과는 추가 투표와 댓글을 통해 우선순위를 더욱 구체화할 수 있는 도구로 수집된다. 구현 과정에서 요청하는 사용자에게 접근하여 초기 디자인과 구현에 대한 협업을 요청한다. 구현이 완료되면, 공지를 통해 요청 사용자가 새로운 기능을 인지하고 이를 채택할 수 있도록 지원한다. +* 소프트웨어 제공 기능에 중점을 둔 팀은 커밋부터 프로덕션까지 빌드 도구를 통해 자동화하는 사이클 타임을 포함하여 더 많은 데이터를 자동으로 캡쳐하기를 원한다. 사이클 타임에는 PR 검토와 같은 다른 활동도 포함될 수 있다는 것을 알고 있지만, 현재로서는 포함되지 않는다. -### Level 3, Scalable — Insights +### Level 3, 확장(Scalable) — 인사이트(Insights) -While robust, standard feedback mechanisms already exist, at this stage data is collected in crafted ways to yield specific strategic insights and actions. Desired results and outcomes are identified followed by standard metrics chosen to indicate progress towards those outcomes. Industry frameworks and standards may be used to benefit from industry research on the impact of certain behaviors. +강력한 표준 피드백 메커니즘이 이미 존재하지만, 이 단계에서는 구체적인 전략적 인사이트와 조치를 도출하기 위해 정교한 방식으로 데이터를 수집한다. 원하는 결과와 성과가 식별되고 이어서 해당 결과에 대한 진행 상황을 나타내기 위해 선택된 표준 측정 기준이 따른다. 특정 행동의 영향에 대한 업계 리서치로부터 이익을 얻기 위해 업계 프레임워크와 표준이 활용될 수 있다. -Dedicated teams or tools are employed to gather and review feedback and summarize actionable insights. A symbiotic relationship between platform products and their users is established. Feedback is considered a strategic asset that guides platform operations and roadmap. Regular feedback review sessions might be instituted, where cross-functional teams come together to discuss and strategize based on user insights. +피드백을 수집하고 검토하며 실행 가능한 인사이트를 요약하는 데 전담 팀 또는 도구가 사용된다. 플랫폼 프로덕트와 사용자 간의 공생 관계가 구축된다. 피드백은 플랫폼 운영과 로드맵을 안내하는 전략적 자산으로 간주된다. 정기적인 피드백 검토 세션을 마련하여, 여러 부서 팀이 모여 사용자 인사이트를 기반으로 토론하고 전략을 수립할 수 있다. -#### Characteristics: +#### 특징: -* Before delivering any new platform feature, the team discusses how to evaluate the outcome from their work. -* The organization has broad alignment on measures that indicate success of platform initiatives. -* A [product manager]({{< ref "/wgs/platforms/glossary#platform-product-managers" >}}) or dedicated team member drives an ongoing and consistent feedback collection and analysis process. -* The organization has established metrics and goals to observe and target to indicate success. +* 새로운 플랫폼 기능을 제공하기 전에, 팀은 작업 결과를 평가하는 방법에 대해 논의한다. +* 조직은 플랫폼 이니셔티브의 성공을 나타내는 지표에 대해 폭넓게 조율한다. +* [프로덕트 관리자]({{< ref "/wgs/platforms/glossary#platform-product-managers" >}}) 또는 전담 팀원이 지속적이고 일관된 피드백 수집과 분석 프로세스를 주도한다. +* 조직이 성공을 나타내기 위해 관찰하고 목표로 삼을 지표와 목표를 설정했다. -#### Example Scenarios: +#### 예시 시나리오: -* The organization has consistently tracked build times and lead time. However, now they realize that while easy to collect, these alone do not give a complete picture of software delivery. With this in mind, the team implements measurement for service reliability and stability. +* 조직은 빌드 시간과 리드 시간을 지속적으로 추적해 왔다. 그러나 이제는 수집하기는 쉽지만, 이것만으로는 소프트웨어 제공에 대한 완전한 그림을 보여주지 못한다는 것을 깨닫게 되었다. 이를 염두에 두고, 팀은 서비스 신뢰성 및 안정성에 대한 측정을 구현한다. -### Level 4, Optimizing — Quantitative and qualitative +### Level 4, 최적화(Optimizing) — 정량적, 정성적 -Feedback and measurements are deeply integrated into the organization's culture. The entire organization, from top-level executives to engineers organization-wide, recognizes the value of data collection and feedback on product evolution. There is a democratization of data, where various stakeholders, including platform users and business leaders, are actively involved in identifying hypotheses for platform improvements, providing feedback during the design process, and then measuring the impact post delivery. All of these measurements are considered when planning platform initiatives. +피드백과 측정은 조직의 문화에 깊이 통합되어 있다. 최고 경영진부터 엔지니어에 이르기까지 조직 전체가 데이터 수집과 프로덕트 발전에 대한 피드백의 가치를 인식하고 있다. 플랫폼 사용자와 비즈니스 리더를 비롯한 다양한 이해관계자가 플랫폼 개선을 위한 가설을 세우고, 디자인 과정에서 피드백을 제공하고, 출시 후 영향을 측정하는 데 적극적으로 참여하는 데이터의 민주화가 이루어지고 있다. 이러한 모든 측정은 플랫폼 이니셔티브를 계획할 때 고려된다. -Not only are standard frameworks leveraged, but there is an understanding that measuring from multiple angles creates a more holistic picture. There is an investment in understanding how qualitative measures change as quantitative ones are improved. There is a focus on identifying leading measures which can allow anticipation of features that would support user needs, alleviate their challenges, and stay ahead of industry trends and business requirements. +표준 프레임워크가 활용될 뿐만 아니라, 다양한 각도에서 측정해야 보다 전체적인 그림을 그릴 수 있다는 인식이 확산되고 있다. 정량적 측정이 개선됨에 따라 정성적 측정이 어떻게 변화하는지 이해하는 데 투자하고 있다. 사용자의 요구를 지원하고, 문제를 완화하며, 업계 트렌드와 비즈니스 요구사항에 앞서 나갈 수 있는 기능을 예측할 수 있는 선도적인 측정을 파악하는 데 초점을 맞추고 있다. -#### Characteristics: +#### 특징: -* Platform teams continuously seek ways to improve the metrics they watch and the way they gather data. -* The organization is familiar with and sensitive to [Goodhart's Law](https://en.wikipedia.org/wiki/Goodhart%27s_law): "When a measure becomes a target, it ceases to be a good measure." -* Metrics and telemetry gathered is continuously evaluated for true insight and value. -* Metric data management is well supported, such as standard platform capabilities to manage data lakes and derive insights. -* Cross-departmental collaboration is encouraged to avoid data silos and enable effective feedback cycles. +* 플랫폼 팀은 지속적으로 모니터링하는 지표와 데이터 수집 방식을 개선하기 위한 방법을 모색한다. +* 조직은 [굿하트의 법칙(Goodhart's Law)](https://en.wikipedia.org/wiki/Goodhart%27s_law)에 익숙하며 이에 민감하다: "측정값이 목표가 되면, 더 이상 좋은 측정값이 아니다." +* 수집된 메트릭과 원격 측정은 진정한 인사이트와 가치를 위해 지속적으로 평가된다. +* 데이터 레이크 관리와 인사이트 도출을 위한 표준 플랫폼 기능과 같이 메트릭 데이터 관리가 잘 지원된다. +* 부서 간 협업을 장려하여 데이터 사일로를 방지하고 효과적인 피드백 사이클을 가능하게 한다. -#### Example Scenarios: +#### 예시 시나리오: -* Over time the organization has collected data indicating a rise in build time of over 15%. This triggers negative developer experiences and once triggered, even if the build time is reduced below the original time, developers stay frustrated for longer. This insight drives the build team to set and adhere to a Service Level Objective (SLO), which enables early identification and improvement before instigating the negative cycle with their users. +* 시간이 지남에 따라 조직에서 수집한 데이터에 따르면 빌드 시간이 15% 이상 증가했다. 이는 부정적인 개발자 경험을 유발하며, 일단 트리거가 발생하면 빌드 시간이 원래 시간보다 단축되더라도 개발자는 더 오랫동안 좌절감을 느끼게 된다. 이러한 인사이트를 통해 빌드 팀은 서비스 수준 목표(SLO)를 설정하고 준수하여, 사용자에게 부정적인 사이클이 시작되기 전에 조기에 식별하고 개선할 수 있다. {{< /tab >}} {{< /tabs >}} @@ -496,6 +497,6 @@ Not only are standard frameworks leveraged, but there is an understanding that m
--- -## Conclusion +## 결론 -Platforms and their maintainers provide a foundation for agile digital product development. They provide a consistent collection of capabilities that enable efficient software development and delivery. This maturity model provides a map for your platform engineering journey. +플랫폼과 해당 메인테이너는 애자일한 디지털 프로덕트 개발을 위한 기반을 제공한다. 플랫폼은 효율적인 소프트웨어 개발과 제공을 가능하게 하는 일관된 기능 모음을 제공한다. 이 성숙도 모델은 플랫폼 엔지니어링 여정을 위한 지도를 제공한다. From 5f0db78d8a17bf40d6238b40caf0016f5a0976a3 Mon Sep 17 00:00:00 2001 From: Eeap Date: Wed, 8 May 2024 18:54:58 +0900 Subject: [PATCH 4/4] docs(platforms): add description translation of platform maturity model Signed-off-by: Eeap --- .../content/ko/wgs/platforms/maturity-model/v1/index.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/website/content/ko/wgs/platforms/maturity-model/v1/index.md b/website/content/ko/wgs/platforms/maturity-model/v1/index.md index 7c562fc8..332f8070 100644 --- a/website/content/ko/wgs/platforms/maturity-model/v1/index.md +++ b/website/content/ko/wgs/platforms/maturity-model/v1/index.md @@ -2,10 +2,10 @@ title: "플랫폼 엔지니어링 성숙도 모델" pdf: https://github.com/cncf/tag-app-delivery/raw/main/platforms-maturity-model/v1/assets/platform-eng-maturity-model-v1.0.pdf version_info: https://github.com/cncf/tag-app-delivery/tree/main/platforms-maturity-model/README.md -description: "이 성숙도 모델은 플랫폼 정의 백서에서 논의된 패턴을 채택하려는 사용자에게 전술적 지침을 제공하기 위한 것이다. 해당 백서는 왜 그리고 무엇을 구축해야 하는지를 제안하며; 이 문서는 어떻게 구축을 계획하는지를 설명하기 시작할 것이다. The target audience is CTOs, Directors of engineering, lead engineers, and architects seeking to evaluate their current state and environment and identify opportunities for improvement.

-This document refers to, enhances, and follows similar standards as the following related documents:
-[Cloud Maturity Model](https://maturitymodel.cncf.io/)
-[Platforms Definition White Paper](https://tag-app-delivery.cncf.io/whitepapers/platforms/)" +description: "이 성숙도 모델은 플랫폼 정의 백서에서 논의된 패턴을 채택하려는 사용자에게 전술적 지침을 제공하기 위한 것이다. 해당 백서는 왜 그리고 무엇을 구축해야 하는지를 제안하며; 이 문서는 어떻게 구축을 계획하는지를 설명하기 시작할 것이다. 대상 청중은 현재 상태와 환경을 평가하고 개선 기회를 파악하고자 하는 CTO, 엔지니어링 책임자, 수석 엔지니어와 아키텍트이다.

+이 문서는 다음 관련 문서를 참조하고 개선하며 유사한 표준을 따른다:
+[클라우드 성숙도 모델](https://maturitymodel.cncf.io/)
+[플랫폼 정의 백서](https://tag-app-delivery.cncf.io/whitepapers/platforms/)" type: whitepapers ---