고객 360에 대한 생각

고객 360.

또는 경쟁사 중 한 곳(이름은 밝히지 않겠지만 자작나무 잎을 로고로 사용하는)이 싱글 뷰라고 부르기도 합니다.

모두가 원합니다.

누구에게나 필요합니다.

결국 대부분의 고객 데이터는 다양한 시스템에 저장되어 있으며, 각 시스템은 개별 고객에 대한 단편적인 정보만 제공합니다.

한 곳에서 고객에 대한 전체적 관점을 한 번에 파악할 수 있다면 정말 좋을 것입니다.

따라서 고객 데이터의 성배인 고객 360이 탄생했습니다.

저희 웹사이트의 마케팅을 믿으신다면, 기존 시스템을 모두 가져와서 그 가운데에 Couchbase를 놓고 화살표 몇 개만 그리면 바로 실행할 수 있습니다.

마법과도 같습니다!

글쎄요...

아직은 아닙니다.

저희 마케팅 담당자들은 이 서비스가 얼마나 간단하고 쉬운지 설득하기 위해 돈을 받습니다.

(피터에게 죄송합니다. 솔직히 말해서요)

저는 다른 일을 하고 있습니다.

제 역할은 Couchbase를 사용하여 프로젝트가 성공할 수 있도록 돕는 것입니다.

결국, 우리 업계는 실패한 프로젝트의 시체로 가득 차 있습니다.

우리 모두는 그들을 보았습니다...

장례식에 다녀왔습니다...

그리고 우리 중 많은 사람들이 적어도 한 명 이상의 죽음에 관여했습니다...

따라서 단순화된 관점을 취하는 것은 의미가 없습니다.

(직책이 'C'로 시작하지 않는 한)

아니요, 고객 360과 같은 시스템을 구현하는 일을 하는 우리에게는 세부 사항에 주의를 기울여야 합니다.

통합

따라서 웹사이트의 참조 아키텍처 도면을 왼쪽에서 오른쪽으로 보면 다양한 이름의 시스템이 캡슐화되어 있는 상자를 볼 수 있습니다.

CRM, ERP, 메인프레임 등

그리고 "통합"이라고 표시된 키가 큰 직사각형 안팎을 가리키는 화살표 두 개가 있습니다.

간단해 보입니다.

안타깝게도 그렇지 않습니다.

이 부분은 많은 고민이 필요한 부분입니다.

정말 많이요.

Kafka나 다른 커넥터를 사용하여 다양한 시스템을 Couchbase에 연결하고 데이터를 전송하는 것만으로는 충분하지 않다는 것을 알 수 있습니다.

물론 그렇게 할 수도 있지만, 그러면 연결되지 않은 데이터가 Couchbase 버킷을 어지럽히게 될 것입니다.

아니요, 다양한 이질적인 시스템에서 가져올 고객 데이터를 어떻게 연관시킬지 고민해야 합니다.

그리고 결합하는 방법.

그리고 포맷합니다.

말씀드렸듯이 많은 고민을 했습니다.

데이터를 Couchbase로 가져오는 것은 쉬운 부분이고, 결합하고 서식을 지정하는 것이 어려운 부분입니다.

또는 적어도 어떻게 해야 하는지 결정할 수 있습니다.

실제 ETL 프로세스는 매우 간단합니다.

결국, 소스 시스템에서 데이터를 추출하여 JSON으로 포맷하고 다양한 소스의 데이터를 결합한 다음 Couchbase에 저장하기만 하면 됩니다.

쉽고 간편한...

자다가도 할 수 있습니다.

ETL 부분, 즉 데이터 모델링이 아닌...

그 부분을 하려면 깨어 있어야 하는데...

마이크로서비스

예, 모든 고객 360 구현에는 몇 가지 마이크로 서비스 세트가 포함됩니다.

이 버킷에는 중요하고 민감한 데이터가 있을 수 있으며, 최소한 이 데이터에 대한 액세스를 제어하고 싶을 것입니다.

어떤 다른 마이크로 서비스가 필요한지는 비즈니스와 고객 데이터로 무엇을 하려는지에 따라 달라집니다.

아마도 REST API 뒤에 있는 일종의 비즈니스 규칙일 것입니다...

비즈니스 프로세스 한두 가지...

그리고 일종의 모바일 애플리케이션을 위한 데이터 동기화입니다.

그래서 저는...

모바일 통합

여기 저희(Couchbase)가 여러분을 위해 정말 단순화할 수 있는 곳이 있습니다.

모바일 스택을 통합함으로써...

카우치베이스 서버, 동기화 게이트웨이 및 카우치베이스 라이트...

모바일 데이터 동기화에 대한 책임을 모바일 사용자의 데이터를 어떻게 분할할지 결정하는 것으로 줄일 수 있습니다.

누가 어떤 데이터를 받는지 알 수 있습니다.

네, 저도 알아요, 더 생각해보세요...

생각이라는 부분을 없애기 위해 우리가 할 수 있는 일은 한정되어 있습니다.

사실, 거의 없습니다.

이 문제를 피할 수는 없습니다. 여기에는 많은 생각이 필요합니다 ...

하지만 일단 생각하는 부분을 완료하면 나머지는 가능한 한 고통스럽지 않게 하려고 노력합니다.

또한 모바일 스택을 사용하면 데이터를 사용자에게 할당하는 방법과 이 할당을 결정하는 데 사용할 수 있는 다양한 문서에 어떤 속성이 있는지까지 고려해야 할 사항을 줄일 수 있습니다.

그런 다음 이 모든 것을 자바스크립트로 작성된 함수에 넣습니다.

그리고 모바일 앱 자체에 집중하세요.

네, 앱은 여전히 작성해야 할 것 같습니다.

이 문제를 피할 수는 없습니다.

하지만 REST API를 처리하거나 서버에서 응답을 기다릴 필요가 없습니다.

아니요, 모바일 앱은 로컬 온디바이스 데이터베이스만 처리하면 됩니다.

데이터를 기기와 주고받는 데 관련된 다른 모든 작업은 저희가 처리합니다.

따라서 모바일 스택을 사용하면 모바일 애플리케이션 코딩에 대한 부담을 줄일 수 있습니다:

여기까지:

어떤 코딩을 담당하고 싶은지 알고 있습니다...

프론트엔드

이제 Customer 360의 마지막 부분인 사용자 액세스 애플리케이션에 대해 알아보겠습니다.

안타깝게도 이 부분을 제거하거나 단순화할 수 있는 방법은 많지 않습니다.

사용자가 데이터에 액세스하고 데이터로 작업하는 방법을 결정해야 합니다...

그런 다음 개발자를 느슨하게 하세요...

그리고 그 결과물이 여러분이 실제로 원했던 것과 비슷하기를 바랍니다.

개발자가 Couchbase로 쉽게 작업할 수 있도록 지원하고 있습니다.

당사는 대부분의 인기 프로그래밍 언어로 SDK를 제공합니다...

데이터 작업을 위해 SQL에서 N1QL로 쉽게 전환할 수 있습니다...

또한 여러분의 노력을 지원하기 위해 다양한 교육 및 컨설팅 서비스를 제공하고 있습니다.

하지만 저희가 코드를 대신 작성해드릴 수는 없습니다.

죄송합니다.

그렇다면 왜 카우치베이스일까요?

즉, 모든 사람이 자신의 데이터베이스가 이 솔루션에 가장 적합하다고 말할 것입니다.

그렇다면 왜 우리일까요?

높은 가용성, 속도, 손쉬운 확장성 외에도 몇 가지 다른 장점이 있습니다...

제 개인적인 편견을 제외하고는...

즉, N1QL 쿼리 언어가 ANSI를 준수하도록 만들어 SQL 기반 데이터베이스에서 쉽게 전환할 수 있도록 지원하므로 기존의 SQL 지식과 경험을 그대로 가져올 수 있습니다(지식이 남아 있지 않나요?)...

또한 스키마가 없는 문서 저장소를 사용하면 조직에서 개발자에게 새로운 기능을 다양하게 요구함에 따라 데이터 모델을 시간이 지남에 따라 발전시킬 수 있습니다....

내장된 전체 텍스트 검색 기능을 사용하면 다른 도구에 통합할 필요 없이 원하는 정보를 쉽게 찾을 수 있습니다....

비즈니스 분석가들이 밤새 기다리지 않고도 데이터를 온갖 이상한 모양으로 변형할 수 있는 분석 서비스를 제공합니다....

이벤트 서비스를 통해 실시간으로 모든 종류의 장난을 일으킬 수 있습니다...

또한 모바일 스택을 사용하면 사용자가 모바일 디바이스에 가지고 있는 데이터를 매우 간단하게 제한할 수 있으며, REST 서비스를 기다리거나 복잡한 동기화 루틴을 작성할 필요 없이 휴대폰과 데이터 센터 간에 업데이트를 동기화합니다....

피할 수 없는 상황이 발생하여 서버 중 하나가 죽어도(그리고 언젠가는 서버 중 하나가 죽게 되겠지만) 데이터는 그대로 유지되어 사용할 수 있습니다.

이렇게 하면 CIO가 매우 만족할 것입니다.

결국, CEO가 고함을 질러야 할 이유가 하나 줄어드는 셈이죠.

그리고 결국 그 행복은 디지털 참호에서 일하는 우리들에게도 전해질 것입니다.

행복이 흘러내립니다.

생각해보면 좋은 일입니다...

네, 또 다시 '생각'이라는 단어가 등장했습니다.