이 모듈이 답하는 질문: 데이터가 어디로 가는지 보여 주는 랜드스케이프를 어떻게 그릴까요?
새 시나리오와 빈 화이트보드를 주면, 제가 가장 먼저 그리는 것 중 하나가 시스템 랜드스케이프입니다. 예쁘게도 아니고, 모든 API도 아니고, 아직 데이터 모델도 아닙니다. 저는 기업을 보고 싶습니다. 사용자가 누구인지, 어떤 시스템이 관련되는지, Salesforce가 어디에 있는지, 그 주변에 무엇이 있는지, 데이터가 어디서 와서 어디로 가는지. 그다음 화살표를 따라가고 싶습니다. 좋은 랜드스케이프는 상자 그림이 아닙니다. 아키텍처 결정을 드러내는 방법입니다.
저는 CTA 후보자들에게 이것을 연습시킵니다. 시나리오를 읽고, 그리기 시작하십시오. 머릿속에서 다 풀 때까지 기다리지 마십시오. 그리는 것이 푸는 것을 돕습니다. 그래서 첫날 숙제가 데이터 모델을 그려 보기 전에 랜드스케이프를 시작하는 것입니다. 데이터 모델을 먼저 그리면 이미 무엇이 Salesforce에 속하는지 가정한 것입니다. 랜드스케이프를 먼저 그리면 그 결정을 형성해야 할 시스템들이 보입니다.
시스템 랜드스케이프를 그리는 방법은 많습니다. 이것은 그저 제 방식이고, 수년에 걸쳐 다듬어 온 것입니다. 하나를 빨리 짜는 법을 볼 수 있도록 공유합니다. 저는 모든 Salesforce 랜드스케이프에 이것을 쓰고, 한 문장처럼 읽힙니다. 왼쪽의 사람들이 가운데의 Salesforce에 닿고, 위의 시스템을 통해 신뢰를 얻고, 아래의 채널을 통해 서비스를 받으며, 오른쪽의 백오피스와 연결된다.
왼쪽의 사람들, 위에서 아래로: 내부 사용자, 파트너, 고객. 아직 모든 페르소나는 아니고, **누가 이 아키텍처에 닿으려 하는가?**에 답할 만큼만. 각 집단은 자신이 들어오는 곳을 가리킵니다. 내부 사용자는 Salesforce로, 파트너는 파트너 커뮤니티로, 고객은 고객 커뮤니티로. 시스템은 혼자 존재하지 않습니다. 누군가, 또는 무언가가 그것을 쓰려고 합니다.
위의 정체성. ID 공급자는 맨 위에 갑니다. 개발자들이 잊는 그것들입니다. 내부 사용자용 하나, 어쩌면 파트너용 또 하나. AppExchange 패키지도 거기, 오른쪽으로 비켜서 갑니다. 그것들은 데이터를 주고받는 백오피스 시스템이 아니라 org 안으로 들여온 기능이기 때문입니다. 공개 웹사이트는 왼쪽 위에 둡니다.
오른쪽의 연동, 그다음 백오피스. 연동 층, 즉 ESB나 iPaaS(이름이 정해져 있다면 MuleSoft)는 Salesforce 바로 오른쪽의 긴 막대입니다. 내부 시스템은 그 뒤에 있습니다. ERP들, 재무, 주문 관리, 레거시 시스템, 웨어하우스. 이제 페이지가 왼쪽에서 오른쪽으로 읽힙니다. 사람, Salesforce, 연동, 백오피스.
아래의 채널. 고객과 직접 닿는 선이 있는 모든 것. 이메일-케이스(email-to-case), 웹-리드(web-to-lead), 전화, 메시징.
오른쪽 아래의 데이터 입출력. 외부 데이터 소스, 아카이브, 데이터 로드.
오른쪽, 연동 층 아래의 Data 360. 사용자는 결코 그것에 연결하지 않고, 그 테넌트는 많은 백엔드 시스템에 연결하므로, 그 선들이 짧게 유지되는 배관과 함께 둡니다. 내부 시스템, 웨어하우스, 오른쪽 아래의 데이터 옆입니다. 데이터 팀이 그 화면을 열기는 하지만, 그 화면은 org 안에 있습니다. Data 360은 코어 인접(near-core), 즉 관리는 코어에서, 호스팅은 코어 밖에서입니다(모듈 1). Salesforce로 돌아가는 선 하나가 누가 그것을 관리하는지 보여 줍니다. 상자를 두는 위치가 그것이 하는 일의 이야기를 해야 합니다.
이 기하학은 신성하지 않습니다. 관례의 가치는 매번 시각 언어를 새로 발명하지 않아도 된다는 것이고, 제 다이어그램을 한 번 본 사람은 다음 것을 더 빨리 읽습니다.
표기는 단순하게 유지하십시오. 모든 시스템은 카드입니다. 이름, 역할, 그리고 그것이 어떤 종류인지 말해 주는 작은 아이콘. ERP, 데이터베이스, ID 공급자, 사람들의 집단. 방금 설명한 구역은 옅은 레이블 영역으로 그려서 배치 자체가 보이게 합니다. 아래쪽의 범례가 모든 아이콘과 선의 뜻을 말해 줍니다.
상자 안에 너무 많이 넣지 마십시오. 아주 복잡한 랜드스케이프에서만 저는 Salesforce를 열어 그 부분들을 보여 줍니다(org 안의 Sales Cloud와 Service Cloud, 그 사이의 화살표). 그리고 각각이 독자에게 무언가를 말해 주지 않는 한 모양을 열다섯 가지씩 만들어 내지 마십시오. 저는 누군가 랜드스케이프를 30초 보고 아키텍처를 이해하기 시작하기를 원합니다. 화려함은 도움이 안 됩니다. 명확함이 도움이 됩니다.
볼륨을 생각하려고 상세 설계를 기다리지 마십시오. 하룻밤에 제품 500건을 나르는 화살표와 하루에 GPS 데이터 20만 건을 나르는 화살표는 랜드스케이프에서 똑같아 보일 수 있습니다. 같은 문제가 아닙니다. 그러니 화살표 하나라도 긋기 전에 무엇이 움직이는지 세십시오. 그림 뒤의 목록을 그 수로 시작하십시오. 중요한 데이터 세트마다 한 줄, 그 볼륨과 함께. 0은 화살표에 결코 나타나지 않을 수도 있지만, 큰 수로 넘어가는 순간은 알아야 합니다. 한 시간에 수천 건이나 수백만 건, 수십만 건의 트랜잭션, 심지어 초당 수십에서 수백 건의 트랜잭션.
그 수가 메커니즘을 정합니다. 하룻밤에 수백 건이면 배치입니다. 누군가 기다리는 호출은 볼륨이 허락한다면 동기일 수 있습니다. 초당 수십에서 수백 건이면 레코드마다 호출하기보다 플랫폼 이벤트 같은 이벤트가 필요할 수 있습니다. 화살표는 똑같아 보일 것입니다. 무엇이 그것을 나를지는 볼륨이 정하니, 메커니즘이 선택되는 곳인 목록에 기록하십시오.
메커니즘은 화살표의 방향까지 바꿀 수 있습니다. 1분에 레코드 몇 건을 보낸다면 Salesforce가 그냥 콜아웃하면 됩니다. 화살표는 Salesforce에서 시작합니다. 훨씬 더 많이 보낸다면 Salesforce는 대신 이벤트 버스에 이벤트를 발행할 수 있습니다. 외부 시스템이 구독하고 그것을 가지러 호출해 들어오니, 이제 화살표는 반대쪽 끝에서 시작합니다. 더 커지면, 예를 들어 수백만 건 레코드의 야간 동기화라면 배치 프로세스입니다. 그러니 메커니즘을 설계하기 시작할 때 일찍 수를 아십시오. 수가 화살표를 다시 그릴 수 있기 때문입니다.
볼륨은 두 곳에서, 두 가지 이유로 중요합니다. 데이터 모델에서는 대용량 데이터를 주시하고 아카이빙을 계획하려고 필요합니다. 파트 2에서 깊이 다룹니다. 시스템 랜드스케이프에서는 목록의 큰 수가 연동 패턴과 메커니즘의 선택을 이끕니다. 모듈 6에서 Steve Trucking의 랜드스케이프와 그 목록에 실제 0을 적습니다. 수를 손에 쥐었으면 화살표를 그리십시오.
시스템이 제자리에 놓이면 그것들을 연결하고, 랜드스케이프가 아키텍처가 됩니다. 상자는 시스템이고, 화살표는 누가 연결을 시작하는지 보여 준다. 화살표는 연결을 여는 시스템에서 시작해 그것이 호출하는 시스템을 가리킵니다. 클라이언트에서 서버로. 레이블은 무엇이 움직이는지, 그리고 어느 방향인지 말합니다.
그 규칙은 시스템이 시스템과 대화하는 시스템 랜드스케이프를 위한 것입니다. 데이터 흐름 다이어그램에서는 예상대로 화살표가 데이터를 따릅니다. 랜드스케이프 규칙을 다른 다이어그램으로 가져가지 마십시오. 혼란만 더할 뿐입니다.
화살표를 넣었습니다. 모든 상자는 원래 자리에 있고, 각 화살표는 연결을 여는 시스템에서 시작하며, 레이블은 무엇이 어느 방향으로 움직이는지 말합니다.
그러니 연동 층이 제품을 Salesforce로 밀어 넣는다면, 화살표는 연동 층에서 Salesforce로 가고 레이블은 제품 들어옴입니다. Salesforce가 그것을 가져오려고 콜아웃한다면 화살표는 Salesforce에서 시작하고, 레이블은 여전히 제품 들어옴입니다. 같은 데이터, 다른 대화. 그리고 그 차이가 누가 자격 증명을 가져야 하고 누가 실패를 처리해야 하는지 알려 줍니다. Salesforce는 연동 층을 통해 주문을 보냅니다. 주문 나감. ERP의 처리 결과가 돌아옵니다. 주문 상태 들어옴. 이제 누가 각 대화를 시작하는지, 데이터가 어디서 Salesforce로 들어오고 어디서 나가는지, 어떤 흐름이 경계를 넘는지, 소유권이 아마 어디에 있는지, 어디서 더 물어야 하는지 보입니다.
그리고 모듈 1을 기억하십시오. 흐름이 하나뿐이면 저는 걱정합니다. 높은 수준에서 주문 나감 화살표는 역방향 흐름에 의존합니다. 고객 들어옴, 제품 들어옴, 가격. 더 깊이 보면 돌아오는 길이 있습니다. 수락, 거부, 상태, 청구서 번호, 취소. 화살표가 반론할 구체적인 무언가를 줍니다.
그리고 다른 쪽이 다운되면 어떻게 되는가? 모든 화살표에는 메커니즘이 필요합니다. 설명할 수 없다면 그 선은 장식입니다.
그리고 “보내고 잊기”는 답이 아닙니다. 보통은 “보낸 뒤에 무슨 일이 일어나는지 설계하지 않았다”는 뜻입니다. 도착했나? 수락됐나? 실패했나? 재시도하나? 막혔다는 걸 누가 아나? 같은 메시지가 두 번 오면? 그중 어느 것도 랜드스케이프에 들어가지 않습니다. 넣으면 읽을 수 없게 됩니다. 하지만 화살표는 그 질문들이 존재한다는 걸 알게 해야 합니다.
어느 화살표든 확대해 보면 클라이언트와 서버가 있고, 각자 자기 절반을 소유합니다. 클라이언트는 연결을 엽니다. 엔드포인트와 포트가 필요하고, 먼저 인증 서버에서 토큰을 받고, 서버가 정의한 프로토콜과 계약을 호출하고, 기다릴지 말지를 고릅니다. 왕복 전체를 보는 것은 클라이언트뿐이므로, 재시도할 수 있는 것도 클라이언트뿐입니다. 서버는 수신 대기하고, 프로토콜, 계약, 페이로드를 정의하고, 들어오는 것을 검증하며, 자기 부분만 봅니다. 화살표를 그릴 때 저는 이미 어느 끝이 어느 쪽인지 알고, 그것이 각 질문을 누가 소유하는지 알려 줍니다.
아키텍트들이 좋은 다이어그램을 망치는 지점이 여기입니다. 산출물 하나로 모든 것에 답하게 만듭니다. 랜드스케이프에 API 이름, 페이로드, 재시도, 오류 큐, 변환, 모든 콜백이 들어가고, 곧 아무도 읽을 수 없게 됩니다. 그러지 마십시오. 랜드스케이프는 큰 그림입니다. 시스템과 그 사이의 중요한 흐름.
상호작용을 설명해야 할 때 저는 두 번째 다이어그램을 그리지만, 모든 연동에 대해서는 아닙니다. 시스템 A가 B에 무언가를 보내거나, 묻고 답을 받는 정도라면 레이블이 붙은 화살표로 충분합니다. 프로세스가 대화가 될 때 스윔 레인을 원합니다. A가 B를 호출하고, B가 C에 확인하고, C가 답하고, B가 무언가를 만들어 A를 다시 호출하고, 사람이 승인하고, 다른 시스템이 이어 갑니다. 제 경험칙은 주고받기가 한두 번보다 많으면 그 순서에 자기 스윔 레인을 준다입니다. 랜드스케이프에는 화살표를, 대화는 스윔 레인에.
그리고 거기서 화살표가 다른 뜻이라는 것에 주목하십시오. 랜드스케이프에서 화살표는 연결입니다. 누가 열고, 무엇이 움직이는가. 스윔 레인에서 각 화살표는 대화 속 메시지 하나이고, 순서대로 읽습니다. 요청이 한쪽으로 가고, 응답이 반대쪽으로 돌아오고, 다음 단계가 이어집니다.
랜드스케이프가 거의 완성된 것 같으면 화살표 하나하나 따라가십시오. ERP에서 Salesforce로: 무엇이 움직이고, 누가 소유하고, 어떻게 인증하고, 메커니즘은 무엇이고, 동기인가 비동기인가, 얼마나 최신이어야 하는가? 그다음 화살표, 또 그다음. 여기서 빈틈이 나타납니다. “아, 파트너가 그걸 실제로 어떻게 보내는지 정한 적이 없네요.” “주문은 ERP로 보내는데, 거부된 주문이 어떻게 돌아오는지는 설계하지 않았네요.” 좋습니다. 운영 환경이 아니라 화이트보드에서 찾았습니다.
그래서 저는 이 산출물을 좋아합니다. 생각을 돕습니다. “Salesforce와 ERP를 아우르는 보고는 어떻게 하죠?” 모듈 3의 질문입니다. 내 다이어그램 중 어느 것이 이걸 멋지게 풀어 주지? 랜드스케이프입니다. 모두 코어 내에 있다면 표준 보고서. 데이터가 ERP와 웨어하우스에 있다면 곧바로 보입니다. “이 고객 속성은 어디서 마스터로 관리해야 하죠?” 어떤 시스템이 그것을 쓰고, 어느 시스템이 이미 고객을 소유하는지 보십시오. “Salesforce에 모든 GPS 데이터가 필요한가요?” 누가 만들고, 누가 소비하고, 워크로드는 무엇인가? 어쩌면 Salesforce에는 현재 위치만 필요하고 다른 플랫폼이 이력을 보관합니다. 랜드스케이프가 답을 건네주지는 않습니다. 문제를 보는 올바른 시야를 줍니다.
규율 하나 더. 기존 기업에서는 있었으면 하는 것이 아니라 있는 것을 그리십시오. 매주 금요일 이메일로 오는 스프레드시트, 그리십시오. SFTP 서버에 있는 파트너의 CSV, 그리십시오. 역사적 이유로 ESB를 우회하는 연동, 그리십시오. 두 시스템 사이에서 데이터를 다시 입력하는 사람들, 보여 주십시오. 기록하는 동안 현실을 정리하지 마십시오. 목표 랜드스케이프를 설계하기 전에 현재 랜드스케이프가 필요하고, 모듈 6에서 Steve Trucking으로 바로 그것을 합니다.
시험 너머: AI가 바꾸는 것. 랜드스케이프는 에이전트의 지도가 되어 가고 있습니다. 에이전트가 “제 배송 어디쯤이에요?”에 답한다면, 랜드스케이프는 그 답이 Salesforce, 파트너 시스템, 텔레매틱스, ERP, 또는 그 조합 중 어디서 오는지 말해야 합니다. 에이전트는 시스템 경계를 없애지 않습니다. 어느 시스템이 권위 있고 어떻게 안전하게 닿는지 아는 것을 더 중요하게 만듭니다.
