Steve Trucking의 랜드스케이프

🌐 28개 언어로도 제공

English · Español · 日本語 · Português (Brasil) · Français · Deutsch · Italiano · 简体中文 · Português (Portugal) · 繁體中文 · Bahasa Indonesia · Türkçe · Polski · Tiếng Việt · ไทย · Nederlands · العربية · עברית · Українська · हिन्दी · Русский · Svenska · Dansk · Norsk bokmål · Suomi · Español (México) · Français (Canada) · Deutsch (Schweiz)

AI로 생성한 이미지

AI로 번역했습니다. 아직 커뮤니티의 검토를 거치지 않았습니다. 영어로 읽기

Data Architect 과정 4장인 기업 데이터 이해하기의 모듈 6/6. 각 모듈은 독립적으로 읽을 수 있습니다. 이전: org 전략은 랜드스케이프 결정이다 · 다음: 다음 장, 데이터 품질과 거버넌스

이 모듈이 답하는 질문: 무엇이든 설계하기 전에 실제 랜드스케이프는 무엇을 알려 줄까요?

이 장은 카메라를 뒤로 빼 왔습니다. 여러 시스템 중 하나인 Salesforce, 데이터의 종류, Salesforce를 둘러싼 시스템, 랜드스케이프를 그리는 법, org 전략. 이제 Steve Trucking에서 그것을 모읍니다. 하지만 아직 아무것도 고치지 않을 겁니다. 그것이 규율입니다. 있는 것을 그리고, 모든 화살표를 따라가고, 랜드스케이프가 무엇을 말하는지 보라.

아는 것에서 시작하라

Steve Trucking은 미국에서 Salesforce org 하나를 운영합니다. Service Cloud가 수령인과 리테일 파트너의 케이스를 처리하고, Field Service가 약속, 배송팀, 모바일 앱을 운영하고, Experience Cloud가 리테일 파트너에게 포털을 주는데 지금은 클레임과 보고서에만 쓰이며, Sales Cloud가 파트너 계약과 새 물류 센터 입찰을 추적합니다. 그러니 Salesforce가 가운데에 갑니다.

왼쪽에는 사람들이 있습니다. 리테일 파트너의 물류 센터 안에서 일하는 배차 코디네이터 45명, 트럭 330대의 배송팀원 약 700명, 고객 상담원 60명, 운영·재무·영업 직원 40명, 그리고 리테일 파트너 사용자 약 300명. 이것만으로도 알 수 있는 게 있습니다. 이건 부서용 CRM이 아닙니다. 비즈니스 대부분을 위한 운영 플랫폼입니다. 그래도 여전히 상자 하나입니다. 이제 그 주변을 봅시다.

Click to enlarge

제대로 된 구현 이전의 오늘의 Steve Trucking. 모든 배송 목록은 RouteDesk에 도착하고, 코디네이터가 경로를 Salesforce에 다시 입력하고 완료된 정차지를 손으로 돌려 입력합니다. FleetLink는 연결이 빠져 있습니다.

잘못된 것을 표시하라

이것은 제대로 된 구현 이전의 현재 상태이고, 저는 그림에 그렇게 적습니다. 그다음 색을 넓힙니다. 완성된 시스템의 랜드스케이프에는 빨간색을 쓰지 않지만, 현재 상태에는 씁니다. 빨간색은 나쁘거나 부적절한 프로세스를, 파선은 손으로 하는 일을, 빨간 점선은 빠진 연결을 표시합니다. 화살표를 빼는 것도 무언가를 말합니다. 어느 것도 장식이 아닙니다. 모든 빨간 선은 쓰이기를 기다리는 요구사항입니다.

파트너 셋, 연동 셋

세 리테일 파트너는 배송 목록을 세 가지 다른 방식으로 보내니, 각각 따로 그리십시오.

Keystone은 매일 오후 이틀 뒤 배송분 CSV 배송 목록을 SFTP 서버에 올리고, 매일 밤 상태 파일을 돌려받기를 원합니다. 화살표 둘. Keystone이 여는, 파일로 들어오는 배송 목록, 그리고 RouteDesk가 여는, 파일로 나가는 상태. 비동기이고 시간 여유가 넓습니다.

Redrock은 REST API로 배송 목록을 보내고 상태 갱신을 일어나는 즉시 웹훅으로 받기를 기대합니다. 화살표 둘, 메커니즘 둘. Redrock은 API로 배송 목록을 들고 호출해 들어오고, RouteDesk는 웹훅으로 상태를 들고 호출해 나갑니다. 준실시간입니다.

Brightwave는 제3자 네트워크를 통해 EDI 파일을 보내고 EDI 상태 메시지를 돌려받기를 기대합니다. 또 다른 형식, 또 다른 메커니즘.

같은 비즈니스 개념(배송 목록, 배송, 상태), 전혀 다른 연동 셋. 일관되었으면 좋겠다는 이유로 그림을 단순화하지 마십시오. 일관되지 않습니다. 그것이 현재 상태입니다.

그다음 따라가십시오. Keystone: SFTP 연결은 어떻게 인증하나, 파일은 어디에 떨어지나, 무엇이 그것을 가져가나, 파일 전체가 처리됐는지 어떻게 아나, 잘못된 줄은 어떻게 되나, 오늘 밤 파일 전에 Keystone이 변경을 어떻게 아나? Redrock: API는 어떻게 인증하나, 어느 한쪽이 다운되면 어떻게 되나, 무엇이 성공한 웹훅인가, 같은 상태가 두 번 오면? Brightwave: EDI 네트워크는 누가 운영하나, 변환은 어디서 하나, 어떤 확인 응답이 돌아오나? 아무것도 다시 설계하지 않습니다. 질문을 발견하는 중입니다. 그것이 랜드스케이프의 일입니다.

RouteDesk는 아직 거기 있다

RouteDesk는 코디네이터들이 각 물류 센터에서 배송 목록을 경로로 바꾸는 데 쓰는 레거시 데스크톱 배차·경로 도구입니다. 8년치 배송 이력을 담고 있고, 퇴역이 예정되어 있습니다. 그래도 그리십시오. 흔한 실수는 “없앨 시스템”을 빼는 것입니다. 언제요? 답이 18개월이라고 합시다. 그렇다면 적어도 18개월 동안은 아키텍처의 일부이고, 그 8년치 이력, 약 500만 건의 배송은 애플리케이션이 사라질 때 함께 사라지지 않습니다. 그리고 랜드스케이프가 드러내는 것을 보십시오. RouteDesk와 Salesforce는 연결되어 있지 않습니다. 배송팀은 Salesforce의 Field Service 앱에서 정차지를 처리하지만 경로는 RouteDesk에서 만들어지므로, 코디네이터가 매일 저녁 경로를 Salesforce에 다시 입력하고, 그다음 RouteDesk가 파트너에게 상태를 보낼 수 있도록 완료된 정차지를 RouteDesk에 다시 입력합니다. 하루 약 3,300개 정차지를 두 번, 손으로. 그림에서는 파선이고 빨간색입니다. 이것은 또한 Redrock의 “일어나는 즉시” 웹훅이 실제로는 즉시가 아니라는 것도 알려 줍니다. RouteDesk는 지금 무엇을 소유하나? 무엇이 그것에 의존하나? 어떤 이력이 그것보다 오래 살아남아야 하고, 어디에: Salesforce, 웨어하우스, 아카이브? 아직 답하지 않습니다. 랜드스케이프가 질문을 드러냈을 뿐입니다.

FleetLink는 섬이다

텔레매틱스 플랫폼인 FleetLink는 모든 트럭에서 GPS를 받습니다. 하루 약 20만 건, 모든 트럭이, 달리는 매 분마다. 그리고 어디에도 연결되어 있지 않습니다. 코디네이터들은 별도 화면에서 그것을 봅니다. 그러니 FleetLink를 화살표 없이 그리십시오. 있어야 할 것 같다는 이유로 마법의 연동 선을 긋지 마십시오.

그다음 0을 세십시오. 하루 20만 건이면 1년에 7,000만 건이 넘습니다. “GPS 데이터가 있다”가 아닙니다. Salesforce 경험 밖에 있는, 0이 많은 스트리밍 원천입니다. Salesforce에 1년에 7,000만 건의 읽기가 필요할까요? 아마 전부는 아닙니다. 나중을 위한 설계 질문입니다.

재무에는 재무의 진실이 있다

재무 ERP는 각 리테일 파트너에게 배송, 설치, 헌 제품 수거마다 청구하고, 배송팀 인센티브를 지급합니다. 그리고 배송 건수는 월간 스프레드시트로 들어갑니다. 스프레드시트를 그리십시오. 우리가 아키텍트이고 더 잘 안다는 이유로 깔끔한 API 화살표로 바꾸지 마십시오. 현재 아키텍처의 일부입니다. 그리고 그려 놓으면 질문이 옵니다. 누가 만드나, 어느 시스템에서, 누가 확인하나, 보낸 뒤 배송이 바뀌면 어떻게 되나, 누구의 숫자가 이기나? 그 답에는 돈이 걸려 있습니다.

Snowflake는 주간 내보내기를 받는다

Snowflake에는 운영과 재무 분석이 있고, 주간 내보내기로 채워집니다. Snowflake가 스스로 그렇게 할 수는 없습니다. 중간의 무언가가 합니다. Salesforce 밖에서 실행되는 예약된 내보내기 작업이 Bulk API로 끌어와 Snowflake에 적재합니다. 분석이 사는 곳은 데이터가 사는 곳을 따르고, Snowflake는 이미 분석의 집입니다. 하지만 타이밍도 무언가를 알려 줍니다. “지난달에 무슨 일이 있었지?” 주간 피드면 충분합니다. “이 배송이 지금 어디 있지?” 제가 Snowflake에서 시작할 질문은 아닙니다. 같은 기업, 다른 워크로드, 다른 최신성, 다른 답.

정체성은 모두에게 같은 방식으로 닿지 않는다

회사 ID 공급자는 Salesforce 위에 갑니다. 사무 직원은 SSO를 씁니다. 하지만 코디네이터와 배송팀은 Salesforce 자격 증명으로 로그인합니다. 그러니 IdP에서 Salesforce로 가는 신뢰선 하나는 이야기의 절반을 숨깁니다. 진짜 질문은 어떤 사용자가 어떤 경로로 로그인하는가이고, 그것이 랜드스케이프에 속합니다.

수령인 경험에는 빈틈이 있다

SMS·이메일 업체가 RouteDesk에서 수령인에게 일반적인 “배송은 내일입니다” 메시지를 보냅니다. 추적 링크는 없습니다. 한편 케이스는 1년에 약 18만 건이고, 그중 약 60%가 “제 배송 어디쯤이에요?”입니다. 1년에 약 10만 8,000건이 같은 질문을 합니다. 이제 그것을 FleetLink 옆에 놓아 보십시오. 회사는 트럭이 어디 있는지 압니다. 수령인들은 계속 전화로 묻습니다. 그리고 아는 시스템은 답하는 시스템과 연결되어 있지 않습니다. 아직 해법을 설계할 필요는 없습니다. 랜드스케이프가 이미 이야기를 하고 있습니다.

0을 목록에 넣어라

이제 무엇이 움직이는지 세십시오. 모듈 4에서처럼 0은 화살표 위가 아니라 그림 뒤의 목록에 갑니다. 설계할 때 거기서 메커니즘을 이끌 것입니다. 1년에 배송 약 100만 건, 하루 약 3,300건, 매년 30% 성장. 배송당 품목 약 1.6개. 배송당 상태 갱신 약 여덟 번, 그래서 오늘 1년에 상태 갱신 800만 건. 1년에 사진 400만~500만 장, 지금은 배송팀 개인 휴대폰에. 하루 GPS 데이터 약 20만 건. 1년에 케이스 약 18만 건. “배송 상태”라고 레이블이 붙은 화살표는 가끔 오는 메시지가 아닙니다. 상자는 무엇이 존재하는지 알려 줍니다. 화살표는 무엇이 움직이는지 알려 줍니다. 0은 당신의 가정이 현실에서 살아남는지 알려 줍니다.

Click to enlarge

Steve Trucking 랜드스케이프 뒤의 목록: 볼륨이 그것이 이끌 메커니즘 옆에 있습니다.

아직 목표 아키텍처는 없지만, 중요한 데이터가 어디 있고, 어떤 종류이며, 얼마나 빨리 움직이고, 시스템들이 그것을 어떻게 주고받는지 이미 보입니다.

시험 너머: AI가 바꾸는 것. Steve Trucking이 수령인의 “제 배송 어디쯤이에요?”에 답하는 에이전트를 만든다고 합시다. 어느 시스템에 물어야 할까요? Salesforce는 약속을 알고, FleetLink는 트럭이 어디 있는지 알고, 파트너의 배송 목록이 배송을 정의했습니다. 현재 랜드스케이프가 에이전트의 지도이고, 에이전트가 안전하게 답하기 전에 아키텍트는 각 사실에 대해 어느 시스템이 권위 있고 얼마나 최신인지 알아야 합니다. 에이전트를 잘못된 원천에 연결하면 오래된 데이터가 자신 있는 답이 됩니다.

고통을 읽어라, 아직 고치지 말고

한 발 물러서 보십시오. 파트너 셋, 연동 방식 셋. 8년치 이력을 담은 레거시 배차 도구, 그리고 하루 3,300개 정차지를 Salesforce에 다시 입력하고 되돌려 입력하는 코디네이터들. 하루 20만 건을 받으면서 연결되지 않은 텔레매틱스 플랫폼. 월간 스프레드시트로 배송을 세는 재무. 일주일 늦은 분석. 일부 사용자에게만 있는 SSO. 추적 링크는 없고, 1년에 10만 8,000건이 배송이 어디 있는지 묻습니다. 모두 매년 30%씩 커집니다.

그림 하나에서 나오는 아키텍처가 많습니다. 고치고 싶은 유혹이 듭니다. 하지 마십시오. 아직은요. 현재 상태 다이어그램을 보기 흉한 채로 두는 데 익숙해지기를 바랍니다. 때로 현재 상태는 정말 보기 흉하니까요. 요점은 깔끔한 그림으로 누군가를 감동시키는 것이 아니라 현실에 대한 공통된 이해입니다. 기록하면서 다시 설계하면 기준선을 잃습니다. 나중에 저는 이렇게 말하고 싶습니다. 이것이 있었고, 이것이 우리가 푼 문제이고, 이것이 우리가 바꾼 것이며, 그 이유는 이렇다. 6장은 소유권과 정체성에 대한 결정을 내리기 시작하고, 체크포인트 1이 파트 1을 모읍니다. Integration Architect 과정이 파트너 흐름을 깊이 설계합니다.

아키텍트가 여기서 결정하는 것

이 단계에서 아키텍트는 목표 아키텍처를 결정하지 않습니다. 결정은 현재 상태를 목표를 설계할 만큼 충분히 이해했는지입니다.

• 오늘 실제로 어떤 시스템, 사용자 집단, 데이터 저장소, 외부 파트너가 존재하는지.
• 중요한 각 경계를 어떤 데이터가, 어느 방향으로, 얼마나 자주, 어떤 메커니즘으로 넘는지.
• 운영, 분석, 스트리밍, 이력, 비정형 데이터가 지금 어디에 있는지.
• 어떤 흐름이 가장 많은 볼륨을 나르며 먼저 주목할 가치가 있는지.
• 어떤 빈틈, 수작업 단계, 끊어진 시스템, 불분명한 권한, 일관되지 않은 패턴이 명시적인 설계 질문이 되는지.

이 장은 하나의 생각에서 시작했습니다. org를 설계하기 전에 랜드스케이프를 그려라. Steve Trucking의 데이터 모델에서 시작했다면, FleetLink가 하루 20만 건을 받으며 바깥에 있고, RouteDesk가 8년치 이력을 쥐고 있고, 파트너 셋이 세 언어로 말하고, 재무가 스프레드시트를 쓰고, 1년에 10만 건의 케이스가 배송이 어디 있는지 묻는 동안 개체와 관계에 몇 시간을 쓸 수도 있었습니다. 그것들은 개체 모델 질문이 아닙니다. 기업 데이터 질문입니다. 보기 흉한 연동, 스프레드시트, 퇴역시킨다는 시스템을 그리십시오. 0을 적으십시오. 모든 화살표를 따라가십시오. 그러면 바꿀 준비가 된 것입니다.

더 알아보기

• Steve Trucking 브리프 2~4절, 그리고 그 랜드스케이프 다이어그램.