비즈니스 인텔리전스를 위한 지속적인 통합의 이점

비즈니스 인텔리전스 산업이 지속적인 통합을 통해 이점을 얻을 수 있는 방법

산업 용어로 비즈니스 인텔리전트(BI)는 여전히 상대적으로 새로운 분야입니다. 많은 기술 기반 산업과 마찬가지로 BI는 임시 프로세스 및 광범위하게 다양한 성공에 따라 구현되는 초기 단계를 통해 진행되었습니다. 과거에는 동일한 조직에서 구현한 여러 BI 프로젝트가 매우 유사한 목표를 달성하기 위해 완전히 다른 접근 방식을 취하는 것이 일반적이었습니다. 그러나 최근 몇 년 동안 진취적인 조직은 BI 지식과 전문 지식을 중앙 집중화하여 BI 기능을 향상시켰습니다. "BI Competency Center"(BICC) 및 "BI Center of Excellence"와 같은 모델이 점차 보편화됨에 따라 이러한 조직은 이제 전체 조직의 성공을 보장하고 ROI를 극대화하기 위해 BI 기술 스택, 도구 세트, 프로세스 및 기법을 정의하고 있습니다. 새로운 BI 이니셔티브. 그들은 또한 측면 범주(이 경우에는 소프트웨어 산업)의 모범 사례에서 힌트를 얻고 있습니다.

BI 커뮤니티에서 아직 인정하지 않은 모범 사례 중 하나는 CI(지속적인 통합)입니다. 소프트웨어 개발 분야에서 CI는 개발 환경에서 소프트웨어 코드베이스가 자동으로 구축되고 빈번한 간격으로 스모크 테스트되는 프로세스입니다. 일반적인 CI 지원 소프트웨어 프로젝트에서 "빌드 서버"는 프로젝트의 소스 코드 리포지토리를 모니터링하고 변경 사항이 감지되면 소스의 깨끗한 복사본을 가져오고 전체 재구축을 수행하며 모든 회귀 테스트를 실행하고 사전에 개발에 알립니다. 모든 실패 팀. 각각의 완전히 성공적인 주기1는 소프트웨어 제품에 대한 설치 가능한 바이너리 세트를 생성합니다.

이 빈번하고 자동화된 통합은 시스템에 도입된 모든 오류를 신속하게 파악하고(종종 도입 후 몇 분 이내에) 누가 언제 오류를 도입했는지 훨씬 쉽게 확인할 수 있습니다. 결함과 비호환성은 도입된 지 몇 분 이내에 발견되면(특히 개발 환경에서 벗어나지 않는 경우) 수정하는 데 항상 비용이 적게 듭니다.

지속적 통합(CI)의 주요 원칙

반복 가능하고 자동화된 빌드 및 테스트 프로세스.
이러한 자동화된 빌드 및 테스트 프로세스는 통합 문제를 조기에 감지할 수 있도록 자주 실행됩니다.
빈번하고 자동화된 주기는 손상되거나 호환되지 않는 아티팩트에 대한 조기 경고를 제공합니다.
시스템의 모든 변경 사항을 거의 즉각적으로 검증하고 테스트합니다.

CI 실행이 현대 소프트웨어 개발 조직의 무기고에서 귀중한 도구가 되었다는 데에는 거의 이견이 없습니다. CI는 소프트웨어 개발 팀의 품질과 추진력을 모두 향상시킵니다. CI 개념을 수용한 숙련된 개발 팀은 CI 없이는 대규모 소프트웨어 프로젝트를 수행하는 것을 상상할 수 없습니다.

CI의 관행은 2000년대 초반부터 Martin Fowler와 같은 개인의 선구적인 노력 덕분에 소프트웨어 개발 업계에서 채택률이 크게 증가했습니다.² 그리고 켄트 벡.

BI 산업도 지속적인 통합을 통해 이점을 얻을 수 있습니까?

전적으로. 앞으로 몇 년 동안 CI의 관행은 현대 BI 개발 환경에 적용될 때 엄청난 잠재력을 인정받을 것입니다. BI 에코시스템은 본질적으로 복잡합니다(그림 1 참조). 그들은 종종 많은 상호 의존성을 가진 많은 움직이는 부분으로 구성됩니다. 예를 들어 일반적인 BI 에코시스템에는 다음이 포함될 수 있습니다.

여러 업스트림 데이터 소스.
ETL 프로세스는 이러한 각 업스트림 소스에서 데이터를 주기적으로 추출, 정리하고 데이터 마트 또는 데이터 웨어하우스로 로드합니다.
많은 BI 제품은 이러한 마트 또는 창고 위에 "모델" 레이어를 추가합니다.
전문 BI 작성자는 이 모델 계층(예: 보고서)에 대해 BI 콘텐츠를 구축합니다.

숙련된 BI 실무자는 이러한 계층의 사소한 변경이 전체 시스템에 파급되어 결과 BI 출력에 오류 또는 비효율이 발생할 수 있음을 증명할 수 있습니다. BI 팀이 릴리스 주기의 어느 위치에 있느냐에 따라 이러한 오류나 비효율성은 며칠, 몇 주 또는 몇 달 동안 눈에 띄지 않을 수 있습니다.

다음은 몇 가지 실제 사례입니다.

모델 계층에서 겉보기에 무해한 수정으로 인해 몇 달 동안 편집되지 않은 보고서의 수치가 예기치 않게 변경되었습니다. 또한 이러한 변경 사항은 동일한 보고서의 성능을 저하시킵니다(수동으로 정량화하고 감지하기 훨씬 더 어려운 조건).
DB에서 보기가 변경되면 보고서 실행 시간이 크게 증가합니다.
모델러는 보고서가 의존하는 열의 이름을 바꾸거나 삭제합니다.
보고서 작성자가 보고서를 최적화하려고 시도하지만 선택적 매개 변수가 설정된 경우 새 보고서가 올바른 결과를 생성하지 않습니다.

대부분의 BI 개발 환경에서 개발 중인 BI 콘텐츠의 테스트는 매우 수동적인 방식으로 수행되는 경우가 많습니다(예: "보고서 실행, 숫자 확인, 올바른지 확인"). BI 팀은 최근에 수정되지 않은 항목이 아니라 적극적으로 변경하는 아티팩트3에 이 수동 테스트를 집중하는 경향이 있습니다. 이러한 경향은 시스템의 하위 수준에 대한 변경 사항이 위쪽으로 파급되어 많은 BI 아티팩트에 영향을 미치기 시작할 때 감지되지 않는 문제에 적합합니다.

대부분의 조직은 개발 환경에서 테스트 또는 품질 보증(QA) 환경으로 BI 콘텐츠의 기준선을 주기적으로 제공하며, 여기에서 QA 전문가가 보다 공식적인 테스트를 받게 됩니다. QA팀의 철저함에 따라 성능의 결함이나 저하가 여기에서 잡힐 수도 있지만, 현 시점에서 이러한 문제를 수정하는 비용이 상당히 증가했습니다. 일단 결함이 개발 환경을 벗어나면(예: QA 환경으로) 수정하는 데 훨씬 더 많은 비용이 듭니다. 정정을 위한 일반적인 작업 흐름에는 결함을 재현하는 방법을 설명하는 문제 티켓 생성(QA 팀에 의해), BI 팀에서 보류 중인 모든 문제 티켓 분류(우선 순위 결정), 개발 중인 문제 재현, 수정한 다음 다른 기준선을 QA에 재배포합니다. 마찬가지로 생산 환경에서 발견된 결함은 QA에서 발견된 것보다 수정하는 데 훨씬 더 많은 비용이 듭니다.

CI 원칙을 사용하여 BI 개발 팀은 이러한 문제를 사전에 감지하고(주로 문제를 일으킨 변경 후 몇 분 이내) BI 콘텐츠가 아직 개발 환경에 있는 동안 수정 조치를 취할 수 있습니다. 이것은 전체 수정 비용이 훨씬 저렴하다는 것을 의미합니다.

그렇다면 CI의 원칙을 일반적인 비즈니스 인텔리전스 프로젝트에 어떻게 적용할 수 있습니까? 몇 가지 구체적인 예를 들어 MotioCI™, 비즈니스 인텔리전스 개발 환경을 위한 지속적인 통합을 가능하게 하는 상용 도구. MotioCI 는 BI 팀에 다음 기능을 제공합니다.