주제 4.1 — 플랫폼 및 공유 서비스

보건·돌봄에서 공유 플랫폼은 비용을 아끼는 편의가 아니라 안전, 형평성, 신뢰를 반복 가능하게 만드는 방법이다. 그래서 모든 팀이 이를 흔히 서툴게 재발명하는 대신 상속받는다.

보건·돌봄에서 이것이 중요한 이유#

보건·돌봄 시스템 전반에서 디지털 딜리버리를 운영하다 보면 같은 역량이 되풀이해서 다시 만들어지는 것을 금방 알아차리게 된다. 모든 서비스가 환자를 인증하고, 인구통계 기록을 조회하고, 알림을 보내고, 감사 추적을 기록하고, 임상의의 역할을 확인하고 싶어 한다. 내버려 두면 각 팀이 자기 버전을 만든다. 열두 개의 로그인 화면, 환자 신원을 다루는 열두 가지 방식, 품질이 제각각인 열두 개의 감사 로그, 그리고 안전 결함이 숨을 수 있는 열두 곳이 생긴다.

이 중복은 비싸지만, 더 깊은 문제는 위험하고 불평등하다는 점이다. 보건·돌봄에서 배관은 임상 위험을 나른다. 한 팀의 환자 일치 로직이 다른 팀의 것보다 약하면 환자가 엉뚱한 기록을 받을 수 있다. 한 서비스의 접근성이 더 나쁘면 일부 사람들이 조용히 배제된다. 감사 추적이 다르면 정보 거버넌스 조사가 멈춘다. 공유 플랫폼은 역량을 한 번, 임상 안전과 접근성 작업을 제대로 거쳐 높은 기준으로 구축하게 하고, 많은 팀이 각자 혼자 잘 맞추기를 도박하지 않고 그 기준을 상속하게 한다.

플랫폼은 시스템 전체의 속도도 형성한다. 좋은 플랫폼은 어렵고 일반적인 부분이 이미 존재하므로 새 서비스가 몇 년이 아니라 몇 주 만에 환자에게 닿을 수 있다는 뜻이다. 나쁘거나 없는 플랫폼은 모든 팀이 인프라의 전체 무게를 지고, 딜리버리가 자원이 가장 부족한 팀의 속도로 느려진다는 뜻이다. 지속적인 재정 및 인력 압박을 받는 분야에서, 같은 국가 및 지역 역량이 수백 개 조직에 필요할 때, 플랫폼을 제대로 만드는 것은 내릴 수 있는 가장 레버리지 높은 결정 중 하나다. 이 주제는 플랫폼을 아무도 사랑하지 않는 의무화된 인프라가 아니라 실제 사용자가 있는 제품으로서 잘 구축하고 운영하는 방법에 관한 것이다.

핵심 개념#

이 맥락에서 플랫폼은 다른 팀이 직접 만들지 않고 그 위에 쌓는 역량의 집합이다. 가장 유용한 현대적 틀은 플랫폼이 내부 사용자를 가진 제품이라는 것이다. 고객은 자신의 개발자, 딜리버리 팀, 파트너 조직이며, 성공은 여느 제품과 같이 채택, 사용하는 사람들의 경험, 그것이 가능하게 하는 결과로 측정된다.

그 밑에는 몇 가지 관련 개념이 있다. 공유 서비스는 조직의 각 부분에서 중복하는 대신 많은 부분을 위해 역량을 한 번 제공하는 더 오래된 조직 패턴이다. 디지털 공공 인프라는 이를 사회 전체 수준으로 확장한다. 공공 및 민간 서비스가 위에 구축되는 공유되고, 재사용 가능하고, 상호운용 가능한 구성 요소(신원, 결제, 데이터 교환)다. Tim O'Reilly가 만들고 전 세계 디지털 정부 팀이 받아들인 "플랫폼으로서의 정부"라는 표현은 같은 논리를 국가에 적용한다. 정부가 공통 구성 요소를 제공하고, 부처는 각자 전체 스택을 만드는 대신 그것으로 서비스를 구성한다.

기술적으로 플랫폼은 흔히 시스템이 내부를 알지 못해도 다른 시스템의 역량을 쓰게 해 주는 정의된 계약인 애플리케이션 프로그래밍 인터페이스(API)를 통해 역량을 노출한다. 클라우드 서비스형 플랫폼(PaaS) 모델에 기대는 경우가 많고, 공유 국가 플랫폼은 보통 단일 인스턴스가 데이터와 구성을 분리해 유지하면서 많은 조직을 서비스하는 멀티테넌시에 의존한다.

세 가지 개념이 플랫폼이 돕는지 해치는지를 좌우한다. 첫째는 인지 부하다. 좋은 플랫폼은 딜리버리 팀이 머릿속에 담아야 하는 양을 줄여, 팀이 존재 이유인 임상 또는 돌봄 문제에 집중하게 한다. 둘째는 "포장도로" 또는 "황금 경로"다. 공통 과업을 하는 잘 지원되고 의견이 분명한 기본 방식으로, 피하기보다 따르는 것이 더 쉬우며 문지기 방식이 아니라 셀프서비스로 제공된다. 셋째는 공급업체 종속의 회피이며, 그래서 플랫폼은 조직이 과도한 전환 비용 없이 공급업체 사이를 옮길 수 있도록 개방형 표준 위에 구축되어야 한다.

특히 보건에서는 국가 공유 서비스가 이미 풍경의 일부다. NHS Connecting for Health 같은 과거의 프로그램은 Personal Demographics Service 같은 핵심 데이터를 나르는 국가 서비스의 집합인 NHS Spine을 세웠다. 현대의 대응물에는 국가 API, 시민 인증을 위한 NHS login, 메시징을 위한 NHS Notify가 있으며, 개별 서비스가 이를 다시 만들 필요가 없도록 제공되는 역량이다. 플랫폼이 누군가가 누구인지 증명하는 공통의 방법을 제공하는 곳에서는, 임상의가 반복해서 인증하지 않고 한 번 인증하도록 흔히 싱글 사인온을 노출한다. 이 주제는 그러한 플랫폼을 구축하고 운영하는 방법에 관한 것이며, 우리가 누구이고 무엇을 할 수 있는지에 대한 세부는 주제 4.2 — 신원 및 접근 관리에, 시스템이 데이터를 교환하게 하는 표준은 주제 4.3 — 상호운용성 및 데이터 표준에 속한다.

모범 사례#

1. 플랫폼을 프로젝트가 아니라 제품으로 다루라. 플랫폼에는 종료일과 인수인계가 아니라 로드맵, 제품 관리자, 지속적인 재원, 만족도를 측정하는 사용자가 있다. 프로젝트는 끝나고 부패하지만, 팀이 의존하게 되므로 플랫폼은 무기한 운영되어야 한다. 그에 맞게 재원을 대고 인력을 배치하라. 이것이 함의하는 운영 규율은 주제 5.0 — 제품 중심 업무를 보라.

2. 가장 얇은 실행 가능한 플랫폼으로 시작하라. 팀을 진정으로 덜어 주는 가장 작은 공유 역량 집합을 구축하고, 실제 수요와 실제 고통이 정당화할 때만 더하라. 주제 1.1 — 운영 모델에서 소개한 이 "가장 얇은 실행 가능한 플랫폼" 개념은 가장 흔한 실패, 곧 모든 것을 하려 하고, 늦게 도착하고, 누구에게도 맞지 않는 야심 찬 중앙 플랫폼을 막는다. 플랫폼이 아키텍처적 열망이 아니라 사용 증거에서 자라게 하라.

3. 포장도로를 쉬운 길로 만들라. 플랫폼은 지원되는 경로를 직접 만드는 것보다 더 빠르고 단순하게 만들어 채택을 얻는다. 셀프서비스 온보딩, 명확한 문서, 샌드박스, 임상 안전과 접근성이 내장된 합리적인 기본값을 통해서다. 플랫폼 사용이 우회하는 것보다 느리거나 고통스러우면 팀은 우회할 것이고, 돈을 써서 병목을 만든 셈이 된다. 개발자의 첫 한 시간과 최악의 날을 위해 설계하라.

4. 존재가 아니라 채택과 사용자 경험으로 성공을 측정하라. 올바른 지표는 얼마나 많은 팀이 자발적으로 플랫폼을 쓰는지, 온보딩에 얼마나 걸리는지, 플랫폼이 얼마나 자주 가용한지, 사용자가 경험을 어떻게 평가하는지다. 배포된 서비스 수 같은 허영 지표는 팀이 도움을 받는지에 대해 아무것도 알려 주지 않는다. 플랫폼을 계측하고, 그 위에 구축하는 팀과 정기적으로 리서치를 하며, 떨어지거나 정체된 채택 곡선을 시행할 준수 문제가 아니라 고칠 제품 문제로 다루라.

5. 개방형 표준 위에 구축하고 퇴출을 저렴하게 유지하라. 여러분도 플랫폼 위의 팀도 갇히지 않도록 개방적이고 널리 채택된 표준과 인터페이스를 선호하라. 팀이 어떻게 떠날지 문서화하고, 실제로 떠날 수 있음을 확인하라. 역설적으로, 떠나기 쉽게 만드는 것이 팀이 도착하는 것을 편안하게 하고, 플랫폼이 포로에 의존하지 않고 자리를 얻어야 하므로 정직하게 유지한다. 이는 주제 4.0 — 기술 아키텍처, 클라우드 및 레거시에서 논의한 더 넓은 자산 전반의 공급업체 종속을 직접 줄인다.

6. 누가 지불하고 누가 결정하는지 명시하라. 공유 플랫폼에는 미리 합의된 재원 모델과 거버넌스 모델이 필요하다. 중앙 재원인지, 사용자에게 청구하는지, 혼합인지, 경쟁하는 테넌트 사이에서 로드맵의 우선순위를 어떻게 정하는지다. 여기서의 모호함이 플랫폼을 정치적 싸움터로 만든다. 모델을 공표하고, 사용자에게 로드맵에 대한 실질적 발언권을 주며, 플랫폼이 자라면서 다시 검토하라.

7. 명확한 책임과 경계로 플랫폼 팀을 운영하라. 주제 7.0 — 팀 구조, 역할 및 책임의 Team Topologies 패턴에 기술된 대로, 셀프서비스를 통해 스트림 정렬 딜리버리 팀을 가능하게 하는 것이 임무인 전담 플랫폼 팀을 중심으로 조직하라. 플랫폼과 소비자 사이의 인터페이스 — 플랫폼이 약속하는 것, 약속하지 않는 것, 지원을 받는 방법 — 를 명시적으로 유지하여 플랫폼이 문지기가 아니라 가능하게 하도록 하라.

8. 처음부터 멀티테넌시, 격리, 안전을 위해 설계하라. 많은 조직이 한 플랫폼을 공유한다면, 그들의 데이터, 구성, 장애 영역의 분리는 나중의 기능이 아니라 기본 요건이다. 보건·돌봄에서는 정보 거버넌스와 임상 안전 요건이기도 하다. 한 테넌트의 사건이 다른 테넌트의 환자를 노출하거나 위태롭게 해서는 안 된다. 격리, 테넌트별 관측 가능성, DCB0129에 따른 플랫폼 자체의 임상 안전 케이스를 내장하라.

팀과 논의할 질문#

1. 우리 팀을 진정으로 덜어 줄 가장 얇은 플랫폼은 무엇이며, 만들고 싶지만 만들어서는 안 되는 것은 무엇인가? 화이트보드에서 방대한 플랫폼을 설계하기는 쉽고, 팀이 사랑하는 것을 출시하기는 어렵다. 딜리버리 팀이 오늘 느끼는 실제로 반복되는 고통, 곧 세 팀 이상이 각자 다시 만들고 있는 역량에서 시작하고, 한 팀만 필요로 하거나 아직 아무도 요청하지 않은 것을 더하려는 유혹에 저항하라. 어떤 역량이 진정으로 공통이고 어떤 것이 멀리서는 비슷해 보이지만 임상적으로 중요한 세부에서 다른지 물으라. 잘못했을 때의 비용을 생각하라. 팀이 우회해야 하는 시기상조의 공유 역량은 플랫폼이 아예 없는 것보다 나쁘다. 플랫폼이 지금 소유할 것과 의도적으로 미룰 것 사이에 명시적인 선에 합의하라. 수요와 고통이 입증될 때만 항목을 옮기며, 일정에 따라 그 선을 다시 검토하라. 규율은 아직 자리를 얻지 못한 좋은 아이디어에 아니라고 말하는 것이다.

2. 테넌트들의 의견이 갈릴 때 플랫폼에 어떻게 재원을 대고 로드맵을 결정할 것인가? 플랫폼은 경쟁하는 우선순위를 가진 많은 팀을 서비스하며, 두 중요한 테넌트가 양립 불가능한 것을 원하는 순간 거버넌스가 시험받는다. 플랫폼이 중앙 재원인지, 사용자에게 청구하는지, 혼합인지 지금 결정하고, 각 모델이 만드는 유인에 정직하라. 청구는 채택을 억누를 수 있고, 중앙 재원은 플랫폼을 사용자 필요에서 떼어 놓을 수 있다. 누가 로드맵을 쥐는지, 테넌트가 어떻게 영향을 주는지, 대형 조직의 긴급한 필요와 소규모 조직의 기본적 필요 사이를 어떻게 중재하는지 정하라. 형평성을 명시적으로 생각하라. 청구 모델은 소규모이거나 가난한 조직을 공유 안전 역량에서 값으로 밀어낼 수 있다. 다른 테넌트가 원하지 않는 기능에 재원을 대고 싶은 테넌트를 어떻게 다룰지 합의하라. 결정이 편애가 아니라 거버넌스로 느껴지도록 모델을 적어 공표하라. 그런 다음 플랫폼과 사용자 기반이 자라면서 다시 검토하겠다고 약속하라.

3. 플랫폼이 단지 의무화된 것이 아니라 사랑받는다는 것을 어떻게 알 수 있으며, 그렇지 않다면 무엇을 할 것인가? 플랫폼은 기술적으로 건전하고, 공식적으로 요구되며, 조용히 미움받을 수 있고, 의무화되었지만 사랑받지 못하는 플랫폼은 우회책, 그림자 시스템, 원망을 쌓는다. 어떤 신호가 진실을 알려 주는지 미리 정하라. 팀에게 선택권이 있는 곳에서의 자발적 채택, 새 팀의 첫 성공까지 걸리는 시간, 가용성과 사건 이력, 사용하는 개발자의 직접 피드백이다. 사용자에게 권한도 쥐고 있을 때 정직한 피드백을 어떻게 모을지 이야기하라. 사람들은 써야만 하는 플랫폼을 비판하기를 꺼린다. 건강한 채택 곡선이 어떤 모습인지, 어떤 임계값이 진지한 재고를 촉발할지 합의하라. 증거가 요구한다면 플랫폼을 폐기하거나 교체할 의향이 있는지 정하라. 플랫폼이 작동하지 않는다는 말을 들을 의향이 플랫폼이 계속 작동하게 한다. 대안은 주요 서비스가 우리를 우회할 때야 진실을 발견하는 것이다.

4. 퇴출을 어떻게 저렴하게 유지하며, 우리 플랫폼의 팀이 필요하다면 실제로 떠날 수 있는가? 개방형 표준 위에 구축되었다고 주장하기는 쉽지만, 팀이 과도한 재작성 없이 걸어 나갈 수 있음을 증명하는 것은 전혀 다른 일이다. 종속이 어디로 스며들고 있는지 솔직히 이야기하라. 독점 인터페이스, 문서화되지 않은 데이터 형식, 대안이 없는 국가 의존성이며, 떠나는 비용이 시간에 따라 조용히 오르고 있는지다. 퇴출 경로가 있다고 가정하지 말고, 그것을 문서화하고 주기적으로 시험할 책임자를 정하라. 보건·돌봄에서는 종속 위험이 복합된다는 점을 생각하라. 포로에 기반한 국가 플랫폼은 한 세대 동안 시스템 전체를 가둘 수 있고, 전환 비용을 흡수하기 가장 어려운 팀은 보통 가장 작은 제공자다. 정직한 답은 풀어내기 어려울 구체적 의존성을 명명하고, 적어도 하나의 실제 테넌트에 대한 구체적 퇴출을 설명하며, 이식성을 되풀이하는 구호가 아니라 유지하는 기능으로 다룬다. 떠나기 쉽게 만드는 것이 팀이 도착하는 것을 편안하게 하는 경우가 많음을 기억하라.

5. 플랫폼이 자체 임상 안전 케이스를 갖고 있으며, 한 테넌트의 실패가 다른 테넌트의 환자를 해치지 않게 하려면 어떻게 하는가? 많은 조직이 한 플랫폼을 공유할 때, 그 배관은 그 위에 구축된 모든 서비스를 대신해 임상 위험을 나르므로, 환자 일치의 결함이나 테넌트 간 유출은 한 팀의 문제가 아니라 모두의 문제다. 플랫폼에 소비 팀이 진정으로 의존할 수 있는 자체 DCB0129 안전 케이스가 있는지, 아니면 각 서비스가 같은 공유 위험을 조용히 다시 평가하고 있는지 결정하라. 테넌트의 데이터, 구성, 장애 영역을 어떻게 격리하는지, 그 격리가 깨졌을 때 어떻게 알지 논의하라. 테넌트별 관측 가능성이 사건을 봉쇄하는 것과 늦게 발견하는 것의 차이다. 정보 거버넌스의 결과도 생각하라. 한 테넌트에 대한 조사가 다른 테넌트의 기록을 노출하도록 요구해서는 안 된다. 정직한 답은 유지되는 안전 케이스, 시험된 격리 경계, 플랫폼이 안전에 대해 약속하는 것과 각 서비스의 책임으로 남는 것에 대한 명확한 설명을 가리킬 수 있다. 안전과 격리를 나중의 기능이 아니라 기초로 다루는 것이 팀이 보증을 도박하지 않고 상속하게 한다.

6. 플랫폼 팀과 그 팀이 서비스하는 팀들 사이의 선은 어디이며, 플랫폼이 병목이 되지 않게 하려면 어떻게 하는가? 공유 플랫폼은 모든 팀을 가속하거나 모두를 하나의 중앙 대기열의 속도로 늦출 수 있으며, 그 차이는 플랫폼과 소비자 사이의 인터페이스를 얼마나 날카롭게 그었는지에 있다. 플랫폼이 소유하고 약속하는 것, 명시적으로 하지 않는 것, 일상 업무에서 티켓을 기다리지 않고 지원을 받는 방법을 정하라. 셀프서비스를 기본으로 이야기하라. 온보딩, 프로비저닝, 일반적인 변경이 모두 플랫폼 팀이 손으로 처리해야 한다면, 포장도로가 아니라 관문을 만든 것이다. 좋은 플랫폼의 핵심에 있는 인지 부하 거래를 생각하라. 딜리버리 팀이 머릿속에 담아야 하는 것을 줄여 임상 문제에 집중하게 해야 하며, 협상할 새 계층을 더해서는 안 된다. 정직한 답은 병목으로서 여전히 플랫폼 팀을 통과하는 과업을 명명하고, 그것을 셀프서비스로 만들 방향을 정하며, 플랫폼이 가능하게 하는 곳과 문지기 노릇을 하는 곳에 대해 솔직하다.

실제 사례: 보건·돌봄 예시#

여러 NHS 트러스트, 지역사회 제공자, 카운티 의회의 성인 사회적 돌봄 서비스를 아우르는 통합 돌봄 시스템(ICS)이 같은 벽에 계속 부딪힌다. 모든 새 디지털 서비스 — 가상 병동, 지역사회 물리치료 자가 의뢰 양식, 요양원 감독 도구 — 가 첫 석 달을 같은 토대, 곧 환자가 누구인지 증명하고, 전문가의 역할을 확인하고, SMS 알림을 보내고, 감사 추적을 쓰는 일을 다시 만드는 데 쓴다. 가상 병동 팀의 환자 일치가 물리치료 팀의 것보다 약한 것으로 드러나고, 알림이 엉뚱한 사람에게 가는 아차 사고가 발생한다. ICS의 디지털 리더십은 패턴을 알아본다. 한 번만 존재해야 할 역량에 여러 번 값을 치르고 있고, 그 변이는 안전 위험이다.

방대한 ICS 플랫폼을 의뢰하는 대신 얇게 시작한다. 한 가지를 잘하는 단일 공유 서비스를 세운다. NHS login과 국가 Personal Demographics Service를 샌드박스가 있는 깔끔하고 문서화된 API 뒤에 감싸서, 어떤 팀이든 하나의 지원되는 경로로 시민의 신원을 확인하고 확정된 인구통계 기록을 가져올 수 있게 한다. 다섯 명의 소규모 플랫폼 팀이 이를 제품으로 다룬다. 포장도로 안내서를 공표하고, 셀프서비스 온보딩을 제공하며, 새 팀이 하루 안에 첫 성공적 호출을 해야 한다는 목표를 정한다. 결정적으로 의무화하지 않는다. 가장 쉬운 선택지로 만들고, 가상 병동 팀이 첫 자발적 채택자가 되게 한다.

재원 모델은 공개적으로 합의된다. 채택이 청구로 억눌리지 않도록 ICS가 처음 2년 동안 플랫폼의 핵심에 중앙으로 재원을 대고 18개월에 검토한다. 의회를 포함한 제공자 간 그룹이 로드맵을 쥐고 매달 만난다. 물리치료 팀이 다음으로 알림 역량을 요청했을 때, 플랫폼 팀은 메시징을 처음부터 만드는 대신 NHS Notify 주위에 얇은 래퍼를 추가한다. 한 번 만들어 여러 번 쓴다. 1년 안에 여섯 팀이 신원 서비스를 자발적으로 채택했고, 온보딩이 몇 달에서 며칠로 줄었으며, 플랫폼 팀은 가용성과 채택 수치를 공개적으로 공표한다. 한 트러스트의 맞춤 시스템이 플랫폼을 우회했을 때, 팀은 이를 반항이 아니라 리서치로 다루고, 결정을 이끈 마찰을 배워 고친다. 플랫폼은 팀이 선택하기 때문에 자라며, ICS는 위험하고 흔한 일을 하는 단일하고, 잘 시험되고, 접근 가능한 방식을 상속한다.

부문별 관점#

스타트업#

보건 기술 스타트업은 다른 이들을 위한 플랫폼을 만드는 일이 드물고, 플랫폼 위에 구축한다. 레버리지는 국가 및 클라우드 플랫폼 — NHS login, 국가 API, 클라우드 제공자의 관리형 서비스 — 을 소비하는 데서 나오므로, 작은 팀이 신원이나 메시징을 재발명하지 않고 임상 문제에 에너지를 쓴다. 그래도 종속을 경계하라. 개방형 표준을 선택하고 데이터를 이식 가능하게 유지하라. 오늘 싸게 빌리는 역량이 내일 발목을 잡는 의존성이 될 수 있기 때문이다. 내부적으로는 자체 "플랫폼"을 거의 보이지 않을 만큼 얇게 유지하라. 두 사람 팀에게는 황금 경로 추상화가 아니라 출시가 필요하다. 규율은 공유 내부 역량을 추출할 가치가 있을 만큼 자랐는지 아는 것이다.

소규모 사업체#

확립된 소규모 제공자 — 일반의 진료소, 지역 약국, 요양원, 단일 사업장 클리닉 — 는 거의 언제나 자체 디지털 역량이 거의 없는 플랫폼 소비자이므로, 의존하는 플랫폼이 사실상 안전과 형평성의 바닥을 정한다. 실용적 과제는 인력을 두거나 유지할 수 없는 맞춤 구축보다 지원되는 공유 서비스를 고르는 것이며, 혼자서는 재원을 댈 수 없는 접근성과 임상 안전 작업을 이미 담고 있는 NHS login, 인구통계 조회, NHS Notify 같은 국가 역량을 선호하라. 에스컬레이션할 플랫폼 팀이 없고 긴 통합 프로젝트를 감당할 수 없으므로 진정한 셀프서비스 온보딩과 명확한 문서를 요구하라. 재원 모델을 면밀히 지켜보라. 청구 플랫폼은 소규모 제공자를 가장 필요한 안전 역량에서 가격으로 밀어낼 수 있으므로, 형평성 있는 접근을 압박하고 닿을 수 있는 로드맵 거버넌스에서 제기하라. 퇴출도 주시하라. 독점 공급업체 종속은 이전을 도울 사내 기술 직원이 없을 때 가장 벗어나기 어렵기 때문이다. 이득은 좋은 공유 플랫폼이 스스로 만들 수 없는 표준을 상속하게 해 주어, 대형 조직의 자원 없이도 같은 의무를 충족하게 한다는 점이다.

대기업#

대형 트러스트나 국가 기관은 진정한 플랫폼을 정당화할 규모와 그것을 망칠 관료제를 모두 갖는다. 위험은 상아탑이 되는 중앙 플랫폼 팀이다. 아키텍처적으로 우아하지만 반응이 느리고, 서비스한다고 여기는 딜리버리 팀에서 동떨어진다. 플랫폼에 자체 로드맵과 사용자 리서치를 가진 장수하는 제품으로 재원을 대고, 의무 준수가 아니라 채택과 개발자 경험으로 측정하여 이에 맞서라. 이 규모에서는 멀티테넌시, 격리, 플랫폼 자체의 임상 안전 케이스가 필수가 된다. 보상은 엄청나다. 높은 기준으로 한 번 구축되어 수십 개 서비스가 상속하는 역량이 조직 전체의 바닥을 높인다.

정부#

국가 및 시스템 수준에서 틀은 디지털 공공 인프라와 플랫폼으로서의 정부다. 수백 개 조직이 서비스로 구성하는 공통 구성 요소 — 신원, 알림, 인구통계 조회, 데이터 교환 — 를 구축하라. 독점적 종속 위에 구축된 국가 플랫폼이 한 세대 동안 보건 시스템 전체를 가둘 수 있으므로 여기서 개방성의 위험이 가장 높다. 거버넌스와 재원은 공개적으로, 공유 플랫폼이 부분적으로 보호하려고 존재하는 더 작고 가난한 조직에게 실질적 영향력을 주며 정해져야 한다. 의무화하려는 유혹이 이 수준에서 가장 강하고 가장 위험하다. 요구되지만 사랑받지 못하는 국가 플랫폼은 전국에 그림자 시스템을 낳는다. 품질과 지원으로 채택을 얻고, 모든 우회책을 개선의 신호로 다루라.

흔한 실패 양상#

• 병목. 모든 팀이 무엇이든 하려면 중앙 플랫폼 팀을 기다려야 하므로, 플랫폼이 딜리버리를 가속하지 않고 늦춘다. 해결은 셀프서비스다. 팀이 티켓 없이 온보딩하고 행동할 수 있어야 한다.
• 상아탑. 플랫폼이 딜리버리에서 먼 사람들이 설계하여, 기술적으로 훌륭하지만 어떤 실제 팀의 필요에도 맞지 않는다. 해결은 지속적인 사용자 리서치와 함께 플랫폼을 제품으로 운영하는 것이다.
• 의무화되었지만 사랑받지 못함. 플랫폼이 정책으로 요구되지만 실제로는 우회되어 그림자 시스템과 원망이 쌓인다. 해결은 품질로 채택을 얻고 팀이 우회할 때 경청하는 것이다.
• 모든 것을 하는 플랫폼. 지나치게 야심 찬 범위 때문에 플랫폼이 늦게 도착하고, 너무 많은 것을 하며, 어느 것도 잘하지 못한다. 해결은 수요의 증거에서 자라는 가장 얇은 실행 가능한 플랫폼이다.
• 은밀한 종속. 플랫폼이 팀을 독점 공급업체나 인터페이스에 조용히 묶어, 떠나는 비용이 엄청나게 된다. 해결은 개방형 표준과 문서화되고 시험된 퇴출 경로다.
• 재원의 모호함. 누가 지불하고 누가 결정하는지 아무도 합의하지 않아 플랫폼이 굶거나 정치적 싸움터가 된다. 해결은 명시적이고 공표된 재원 및 거버넌스 모델이다.
• 사후 고려로서의 안전. 플랫폼에 자체 임상 안전 케이스가 없어, 모든 소비 서비스가 평가되지 않은 위험을 상속한다. 해결은 플랫폼의 DCB0129 안전 케이스를 기초로 다루는 것이다.

성숙도 모델#

체크리스트#

• 플랫폼에 지정된 제품 관리자, 로드맵, 지속적인(프로젝트가 아닌) 재원이 있다.
• 가장 얇은 실행 가능한 플랫폼에서 시작했고 의도적으로 미룬 것을 명명할 수 있다.
• 지원되는 경로가 팀이 직접 만드는 것보다 진정으로 더 빠르고 쉽다.
• 새 팀이 샌드박스와 명확한 문서가 있는 셀프서비스로 온보딩할 수 있다.
• 채택, 첫 성공까지의 시간, 가용성, 개발자 경험을 측정한다.
• 재원 모델(중앙, 청구, 혼합)이 합의되어 공표되어 있다.
• 로드맵 거버넌스가 더 작은 조직을 포함한 테넌트에게 실질적 발언권을 준다.
• 플랫폼이 개방형 표준 위에 구축되어 있고 문서화된 퇴출 경로가 있다.
• 멀티테넌트 데이터와 장애 격리가 나중에 덧붙이지 않고 설계에 내장되어 있다.
• 플랫폼에 소비 팀이 의존할 수 있는 자체 임상 안전 케이스(DCB0129)가 있다.
• 플랫폼을 우회하는 팀을 반항이 아니라 리서치로 다룬다.

주요 출처#

• GOV.UK Service Manual과 플랫폼으로서의 정부 및 공통 구성 요소에 관한 Government Digital Service의 글.
• Matthew Skelton and Manuel Pais, Team Topologies — 플랫폼 팀, 가장 얇은 실행 가능한 플랫폼, 인지 부하.
• NHS England 개발자 및 API 지침(NHS login, NHS Notify, 국가 API, Spine 서비스).
• 보건 IT 시스템을 위한 DCB0129 및 DCB0160 임상 위험 관리 표준.
• 디지털 공공 인프라와 재사용 가능한 공공 구성 요소에 관한 World Bank와 United Nations의 글.
• Tim O'Reilly, "Government as a Platform", Open Government (O'Reilly Media) 수록.

참고문헌#

1. Digital public infrastructure — Wikipedia — https://en.wikipedia.org/wiki/Digital_public_infrastructure
2. Shared services — Wikipedia — https://en.wikipedia.org/wiki/Shared_services
3. API (application programming interface) — Wikipedia — https://en.wikipedia.org/wiki/API
4. Platform as a service — Wikipedia — https://en.wikipedia.org/wiki/Platform_as_a_service
5. Multitenancy — Wikipedia — https://en.wikipedia.org/wiki/Multitenancy
6. Cognitive load — Wikipedia — https://en.wikipedia.org/wiki/Cognitive_load
7. Vendor lock-in — Wikipedia — https://en.wikipedia.org/wiki/Vendor_lock-in
8. Open standard — Wikipedia — https://en.wikipedia.org/wiki/Open_standard
9. NHS Connecting for Health (including the NHS Spine and Personal Demographics Service) — Wikipedia — https://en.wikipedia.org/wiki/NHS_Connecting_for_Health
10. Single sign-on — Wikipedia — https://en.wikipedia.org/wiki/Single_sign-on
11. Team Topologies: Organizing Business and Technology Teams for Fast Flow — Matthew Skelton and Manuel Pais (IT Revolution Press) — https://teamtopologies.com/book
12. Government as a Platform — Tim O'Reilly, in Open Government (O'Reilly Media) — https://www.oreilly.com/library/view/open-government/9781449381936/ch02.html
13. GOV.UK Service Manual — Government Digital Service — https://www.gov.uk/service-manual
14. NHS login and NHS England developer/API guidance — NHS England — https://digital.nhs.uk/services/nhs-login
15. Clinical risk management: its application in the manufacture of health IT systems (DCB0129) — NHS England — https://digital.nhs.uk/services/clinical-safety/documentation