데이터 메시 및 이를 유지하는 스레드

데이터 메시는 엔터프라이즈 데이터 아키텍쳐에 대한 접근 방식으로 꾸준히 인기를 얻고 있습니다. 뛰어난 아이디어를 구현하고 있지만, 이와 같은 접근 방식을 실생활에 적용할 때 쉽게 놓칠 수 있는 몇 가지 중요한 원칙이 있습니다.

데이터 메시의 핵심 아이디어는 엔터프라이즈 데이터 아키텍쳐를 논리적이고 비즈니스 지향적인 도메인으로 구성하는 것이며, 주로 각 도메인의 "소유자" 사이에 책임을 분배함으로써 구현됩니다. 이는 기술 아키텍쳐(수집, 데이터 관리, 액세스 등) 내에서 계층별로 구성하는 기존의 접근 방식과 대조되며 주로 중앙 집중식 조정에 의해 주도됩니다.

엔터프라이즈와 그 데이터 자산 및 프로세스가 점점 더 복잡해짐에 따라 이러한 복잡성을 관리하는 방법을 수립하는 것이 매우 합리적입니다. 그리고 각 영역(비즈니스 프로세스, 데이터 주체 등)에 가장 숙련된 사람들에게 최대한 많은 책임을 맡기는 것이 해당 영역과 관련된 솔루션 구성 요소에 올바른 전문 지식과 경험을 일치시키는 가장 좋은 방법입니다.

지금까지는 좋은 생각인 것 같습니다.

그러나 데이터 메시의 문제, 아니 여러 조직에서 데이터 메시를 처음 구현한 방법의 문제는 복잡성을 줄이고 책임을 분산하기 위한 선의의 노력으로 인해 중앙 집중화의 많은 긍정적인 측면이 손실된다는 것입니다. 즉, 아기(고도로 조정된, 교차 기능적 능력)가 목욕물(과도한 중앙 집중화 및 관리할 수 없는 복잡성)과 함께 버려지는 것과 같습니다.

이러한 문제의 추세를 방지하기 위해 데이터 책임자는 관련성을 유지하고 데이터 메시 철학을 따를 때 세심한 주의가 필요한 몇 가지 중요하고 오랜 시간 동안 검증된 원칙을 보존해야 합니다.

자금을 지원받는 비즈니스 이니셔티브에 부합하는 것이 (여전히) 가장 중요한 성공 요인입니다. 저는 데이터 메시 접근 방식을 따르려고 시도하는 과정에서 중앙 데이터 거버넌스 조직이 데이터 환경을 명명된 도메인으로 나누고, 각 도메인에 데이터 소유자를 할당하여 할당된 도메인에 대한 계획과 구현을 주도하고 시작하는 여러 사례를 보았습니다. 결과는 여러분도 짐작할 수 있을 것입니다.

각 데이터 소유자는 노력을 정당화하고, 도메인 전반에 걸쳐 작업을 범위화하며 구현 요소의 우선 순위를 지정하기 위해 비즈니스 동인에 적절하게 조정하지 않고, "중요"하다고 생각하는 데이터를 기반으로 무작위적으로 보이는 방식을 통해 구현의 우선 순위를 지정했습니다. 각 도메인 내의 모든 데이터 요소는 틀림없이 범위 내에 있었고 발생한 모든 데이터 문제는 심층 분석 및 해결의 대상이 되었습니다. 사전 예방적이고 엄격한 조정 없이는 모든 사용자가 믿을 수 있는 합리적인 일정에 따라 도메인이 부서 간 비즈니스 이니셔티브를 지원할 수 있는지 확인할 방법이 없었습니다. 그 결과 배포된 데이터의 사용이 제한되는 길고 비용이 많이 드는 프로젝트와 많은 실패한 애플리케이션 프로젝트가 필요한 데이터를 수집하고 관리하기 위해 혼자 남겨졌습니다.

아키텍쳐에 대한 모든 접근 방식은 비즈니스 이니셔티브에서 시작해야 합니다. 특히 자금을 지원받는 교차 기능 비즈니스 이니셔티브는 기업에 중요합니다. 여기서는 "데이터 마켓플레이스" 또는 "단일 버전의 진실"(비즈니스 이니셔티브를 지원하는 개념만큼 유용함)과 같은 이름을 가진 "데이터 이니셔티브"를 말하는 것이 아닙니다. 그 대신 동인은 옴니채널 고객 경험, 공급망 최적화, 제조 자동화 등과 같은 이니셔티브여야 합니다. 실제 비즈니스 이니셔티브를 동인으로 사용하여 각 데이터 소유자는 단기 비즈니스 요구 사항을 지원하기 위해 해당 도메인 내에서 요소를 제공하는 데 전념할 수 있습니다. 이 접근 방식은 각 증분 전달의 초점을 크게 좁히고 도메인 전반에 걸쳐 명확한 범위 지정 메커니즘을 제공합니다. 제공되는 모든 요소는 전략적 가치를 지니는 동시에 일관성 있는 데이터에 기여합니다.

복잡하고 자주 결합되고 재사용률이 높은 대량의 데이터는 동일한 데이터베이스에 저장해야 합니다. 데이터 웨어하우징의 개념이 적어도 부분적으로는 기술적 한계에 대한 대응이라는 점을 인정합시다. 트랜잭션 시스템(예: POS 시스템, 구매 시스템 등)에 모든 현재 및 과거 데이터를 보존하고 이러한 시스템 위에 "가상화 계층"을 배치하여 모든 최종 사용자 또는 애플리케이션이 쉽게 이러한 시스템 내부 및 전체에서 데이터에 원활하게 액세스하고 트랜잭션 및 분석 워크로드 모두에 대해 우수한 성능을 얻을 수 있다면, 데이터 웨어하우징은 존재하지 않을 것입니다. 그러나 그것은 존재하고 성장하고 있습니다. 실제로 목적에 맞게 구축된 데이터 웨어하우징 기술은 그 어느 때보다 광범위하게 구현되고 있습니다. 왜 그럴까요? 데이터베이스에 물리적으로 데이터를 함께 저장하지 않고는 여러 데이터 도메인에 걸쳐 연결된 복잡하고 자주 결합되며 재사용이 많은 데이터(최소한 기술 능력만큼 빠르게 증가하고 있음)에 대해 좋은 성능을 얻을 수 있는 방법이 아직 없기 때문입니다.

분산되고 고도로 세분화된 도메인에서 실시간으로 데이터를 가상으로 연결하는 것이 일부 애플리케이션에서는 작동할 수 있지만 데이터 웨어하우스 워크로드에 대한 효과적인 성능과 확장성을 지원하지 않습니다.

그렇다고 해서 모든 핵심 엔터프라이즈 데이터를 하나의 거대한 단일 데이터 웨어하우스에 저장해야 한다는 의미는 아닙니다. 예를 들어, 대부분 독립적인 여러 사업부가 있는 회사의 경우 각 비즈니스 유닛이 고유한 데이터 웨어하우스를 갖고 필요할 때만 특정 사용 사례를 위해 데이터 웨어하우스 간에 데이터를 연결하거나 결합하는 것이 합리적일 수 있습니다. 크고 현대적인 조직에 필요한 데이터 웨어하우스의 수는 하나 이상일 수 있지만 확실히 0은 아닙니다.

조직 내에서 데이터 웨어하우스의 역할은 조직의 특성과 지원해야 할 교차 기능 비즈니스 이니셔티브의 수 및 유형에 따라 철저한 고려가 필요합니다.

데이터는 도메인 간에 의미적으로 연결되어야 합니다. 핵심 엔터프라이즈 데이터를 통합하는 것은 비즈니스 이니셔티브의 요구 사항을 충족하고 이니셔티브 간에 데이터 공유를 가능하게 하는 데 항상 필수적이었습니다. 그리고 현대적인 비즈니스 이니셔티브로 인해 과거보다 훨씬 더 많은 도메인 통합이 필요합니다. 현대 비즈니스에서 요구하는 데이터에 대한 일관성 있고 기능적인 관점을 제공하려면 데이터가 기술적으로 연결될 뿐만 아니라 의미적으로도 연결되도록 하는 노력이 필요합니다.

통합은 부분적으로 기술에 의해 가능하지만, 단순히 각 도메인 내부의 기술적 복잡성을 숨기고 도메인 인터페이스를 통한 쉬운 통신을 가능하게 하는 것은 데이터 자체가 도메인 전체에서 일관성을 보장하지 않습니다. 예를 들어, 모든 옴니채널 이니셔티브는 물론 접점과 판매 채널을 통해 각 개별 고객에 대한 정보를 연결할 수 있어야 합니다. 공급망 가시성을 위해서는 공급망의 다양한 지점을 연결하는 일관된 제품 데이터가 필요합니다. 도메인 전반에서 이러한 종류의 일관성은 사전 예방적이고 고도로 조정된 비즈니스 중심 데이터 거버넌스 프로세스 없이는 불가능합니다. 엔터프라이즈 데이터 관리 경험이 있는 사람이라면 누구나 알겠지만 동일한 데이터 도메인이 다른 구조, 다른 데이터 값, 다른 정의, 다른 계층 구조 및 기타 그룹화 등의 여러 시스템에 존재할 수 있습니다. 몇 가지 지침과 데이터 소유자가 도메인 간에 통신할 수 있는 포럼이 있는 데이터 카탈로그로는 충분하지 않습니다.

데이터 관리 도구를 성공적으로 활용하고 도메인 간 데이터 거버넌스를 효과적으로 구현하려면 전문 지식이 필요합니다. 데이터 관리 도구가 사용하기 쉽고 인공 지능에 의해 잘 지원되기 때문에 비전문가도 원시 데이터 세트에 도구를 가리키기만 하면 의미를 추론하고 구조를 정의하며 데이터 변환 및 통합을 위한 워크플로를 개발할 수 있습니다. 그러나 아직은 때가 아닙니다. 그리고 설령 그렇게 되더라도 조직의 이익에 더 큰 도움이 될지라도 동일한 데이터를 다양한 목적으로 사용하는 데 동의하도록 조직을 세심하게 조정할 수 있는 도구는 없습니다. 데이터 관리 전문가는 데이터 거버넌스 및 관리와 협력하여 구현 과정에서 발생하는 기술적 및 비기술적 문제를 해결해야 합니다.

다양한 도메인 팀에 지침과 도구를 제공하는 것만으로는 충분하지 않습니다. 자격을 갖춘 전문가는 데이터 품질 프로세스, 데이터 구조 설계, 데이터 조정 및 기타 아키텍쳐 요소를 단기 애플리케이션 및 분석 사용 사례에 적용할 뿐만 아니라 새로운 데이터 요구 사항에 대응하기 위해 대대적인 재작업 및 재설계 없이 기본 기반을 강화할 수 있도록 확장성과 연장성을 지원합니다. 이를 잘 수행하려면 전문 교육과 약간의 경험이 필요합니다.

결론
이러한 원칙을 데이터 메시가 촉진하거나 촉진하지 않는 것과 비교하려고 하기보다는 분산에 중점을 두고 있기 때문에 이러한 개념을 포기할 위험이 높다는 점을 간단히 지적하겠습니다. 실제로 데이터 메시는 고도로 조정된 도메인 간 거버넌스 프로그램을 지지하지만 여러 가지 이유로 간과하기 쉽습니다. 특히 많은 조직에서 이를 교차 도메인을 조정하는 힘든 작업을 피할 수 있는 기회로 보고 있습니다. 애자일 방법론과 마찬가지로 도메인 간 조정은 시대를 초월한 프로그램 및 프로젝트 관리 원칙을 부적절하게 폐기하기 위해 종종 잘못 사용되었습니다.

따라서 데이터 메시에 관심이 있는 많은 엔터프라이즈 데이터 전문가 중 하나이거나 조직에서 데이터 메시 아이디어를 적용하기 시작하는 경우 메시를 함께 유지해야 할 연결을 적용하여 도메인 전반의 활동을 조정하는 데 필요한 전문성을 유지하도록 주의하십시오.