이 친숙한 시나리오는 하나 이상의 레거시 시스템이 교체되어야 할 경우 레거시 시스템의 요구사항을 판단하는 프로세스를 더욱 복잡하게 만든다. 레거시 시스템들 대부분이 난로연통(스토브파이프)처럼 개발되었기 때문에 이 시스템들 전반에 걸쳐서 동일한 기능이 상당부분 중복될 것이다. 또 기능이 정확하게 중복되지는 않더라도 데이터는 중복될 것이다. 물론 형식이나 데이터 정의는 다를 수 있다.
레거시 시스템 교체하기
필자도 최근 한 프로젝트에서 바로 그런 도전에 직면했었다. 우리 팀은 여러 부류의 사용자들을 위해 엔터프라이즈 전반에 걸쳐 의사결정을 지원하는 데이터 웨어하우스 구축을 맡았었다.
그 사용자들 중 일부에게는 직접 데이터베이스에 질의할 수 있도록 허용되었고, 일부는 데이터의 서브세트에 대한 질의를 할 수 있었으며, 일부는 미리 포맷된 리포트들을 조회할 수 있었다.
이 시스템은 새로운 데이터 요소들의 통합 외에도 11가지 레거시 시스템 교체라는 만만치 않은 목표를 가지고 있었다. 그 중에는 거의 20년이나 된 레거시 시스템도 일부 있었다.
새로운 시스템이 가동되면 이 레거시 시스템들의 운영은 중지될 예정이었다. 우리는 몇몇 소스 시스템들로부터 데이터를 받아들일 생각을 해야 했고, 여러 레벨의 사용자들에게 데이터를 제공해서 그들이 지금까지 친숙하게 느껴온 데이터를 얻게 해주어야 했다.
또, 가능할 경우에는 데이터 요소들을 통합해서 한 가지 버전의 진실을 제공해야 했다. 이 신규 시스템은 또 효율적이어야 했기 때문에 더 이상 필요가 없거나, 최소한 우선순위 목록에서 상위에 있지 않은 항목들이나 프로세스들을 제거해야 했다.
우리의 첫 번째 접근법은 이용 가능한 모든 시스템 다큐멘테이션을 검토하면서 준비작업을 하는 것이었다. 우리는 하루만에 이 작업을 끝낸 다음(읽을 거리가 많지 않았기 때문에 더 이상 시간이 걸릴 것도 없었다) 우리의 접근법을 확대해, 레거시 시스템들의 사용자들 그리고 그들의 프로세스들을 이용하여 신규 시스템들을 위한 요구사항을 어떻게 결정할지 시뮬레이션 했다. 또 우리의 최종 목표는 데이터 웨어하우스에 데이터를 저장하는 것이었기 때문에 데이터 중심의 접근법을 선택하기로 결정했다.
모든 전략적 시스템들이 다 데이터 웨어하우스는 아니지만, 모든 시스템이 데이터를 포함하고 있으므로 필자가 이 글에서 설명할 접근법은 일반적으로 적용 가능하다. 우리 팀은 ▲ 데이터 저장 및 처리 ▲ 데이터 소스들 ▲ 타깃 아웃풋 등 3가지 분야에 초점을 맞추었다.
데이터 저장 및 처리
가장 복잡한 요구사항은 데이터 저장 및 처리와 관련이 있었기 때문에 우리는 그것들을 가장 먼저 처리했다. 요구되는 데이터 자체는 소스들로부터 받은 데이터, 이 데이터에 적용된 변화, 그리고 리포트나 질의, 다른 시스템들에 대한 피드로 사용자에게 전달될 데이터에 따라 차이가 있었다. 우리는 각 레거시 시스템의 데이터, 제공된 리포트, 그리고 적용된 변화를 정의하여 각 레거시 시스템을 처리했다.
① 레거시 시스템 데이터이 작업을 보조하기 위해서 우리의 지식(인풋, 프로세스, 아웃풋)을 모두 담은 스프레드시트를 만들었다<표 1>. 이 매트릭스의 왼쪽 세로 열은 레거시 시스템별로 모든 인풋 데이터 요소들의 목록을 포함하고 있다. 그 옆의 세로 열 한 세트는 각 요소의 메타데이터를 포함하고 있다. 가장 많이 이용된 질의들과 가장 많이 만들어진 리포트들, 그리고 타깃 사용자는 맨 위에 나와 있다. 리포트 열에서 데이터 요소가 등장하는 각각의 칸에는 X 표시가 되어 있다. 가공되지 않은 인풋 데이터가 처리되면 거기에 포함된 비즈니스 룰도 기록된다.
우리는 11가지 시스템마다 각각의 데이터 요소와 그것의 메타데이터를 정리했다.② 리포트와 질의
이어서 우리는 특정 리포트들이 언제, 얼마나 자주, 누구에 의해 이용되었는지 판단하기 위해서 가능한 레거시 시스템에 프로그램을 설치했다. 그리고 6주일 동안 어떤 사용자들이 맞춤 질의 제공을 요청했고, 또 언제 그런 질의 요청이 있었는지 추적했다. 우리는 또 이용된 모든 리포트의 목록, 이용 횟수, 타깃 사용자를 파악했다. 이러한 정보를 토대로 우리는 ▲ 가장 많이 이용된 리포트 및 질의 ▲ 최고위층 의사 결정권자들에 의해 사용된 리포트 및 질의 등 2가지 방법으로 리포트 및 질의를 분류했다.③ 변화
이 마지막 단계가 가장 어려웠다. 우리는 사용자 대표들과 공동 애플리케이션 개발 형태의 그룹들을 만들어서, 인풋 데이터를 리포트 및 질의 데이터로 변화시키는데 사용되었던 비즈니스 룰들을 캡처하고자 했다.
매트릭스가 완료되자 각 시스템의 데이터 요소들, 아웃풋으로 사용된 데이터 요소들, 그리고 그 데이터에 적용된 변화를 보여주는 종합목록이 생겼다. 데이터 요소가 리포트나 질의에서 직접 보이지는 않았지만 변화나 질의에서 사용된 경우들은 있었다. 그러면 이 데이터 요소는 매트릭스에서 캡처되고, 「필수 필드」 열에서 표시되었다. 그런 필드의 한 예가 「수정일」이다. 수정일은 최신 업데이트만 필드에 적용되게 하기 위해서 필요하지만 사용자 리포트에 항시 등장하지는 않는다.
그 다음에는 기술된 데이터 요소들의 목록과 비즈니스 룰들을 레거시 시스템 사용자들이 검증했다. 사용자들이 데이터 요소들을 목록에 추가하는 경우도 있었다(어떤 컴퓨터 시스템에서도 데이터에 접근하는 중에 중요한 요소들이 항시 표면에 등장하지는 않는다). 사용자들은 또 이렇게 완성된 스프레드시트들을 새로운 시스템 요구사항을 위한 기준선으로 사용하는데 동의했다. 우리의 목표 시스템은 유연하게 구축되어, 필요할 경우 구현단계에서 새로운 항목들이 쉽게 추가될 수 있었다.
테라바이트 규모의 데이터 웨어하우스가 포함될 때 불필요한 데이터를 저장하면 값이 비싸질 뿐 아니라 시스템 자원을 고갈시켜 응답시간의 지연을 초래할 수 있다는 것을 우리 사용자들이 이해해주었다는 점도 우리로서는 행운이었다.
