2024.09.06 주문

2024.09.11 받음

제1부 데이터 아키텍처의 수립전략

1장 정보기술 아키텍처의 등장과 그 후

1.1 정보기술 아키텍처의 등장배경

1.1.1 경영환경의 기상변화

1.1.2 산업 전반의 IT 주요쟁점

1.2 정보기술 아키텍처의 개념

1.2.1 정보기술 아키텍처의 개요

1.2.2 정보기술 아키텍처의 성공요인

정보시스템 구축에서 조차 나무만 보고 숲을 보지 못하는 일이 비일비재하게 일어난다.
그것은 '왜 해야 하는가?' 와 '무엇을 해야 하는가?' 를 생각하기 보다 '어떻게 해야 하는가?' 에 대해서만 집착하는 잘못된 접근방법 때문이다.
'왜 해야 하는지' 를 결정하지 않은 상태에서 '무엇을 할 것인지' 를 결정할 수 없고, '무엇을 해야 하는지'도 모르면서 '어떻게 할 것인지'를 고민한다는 것은 이치에 맞지 않다.

1.2.3 전사적 아키텍처의 구성

1.2.4 전사적 아키텍처의 프레임워크

1.2.5 주요 아키텍처의 개념 비교

여러 아키텍터중 특히 Business Architecture(역할, 업무), Application Architecture(기능, 애플리케이션), Data Architecture(뼈대, 데이터)는 상호간 서로 독립적(M:M) 관계이다.

상호간에 독립적인 개체라함은 각자의 본질적인 모습에 따라 상호 연관성이 크게 달라질수 있음을 의미한다.

1. Business Architecture(역할, 업무) VS Application Architecture(기능, 애플리케이션) : 하나의 역할을 위해서 여러 기능이 필요하고, 반대로 하나의 기능이 여려 역할에 사용될 수 있다.(M:M)

2. Business Architecture(역할, 업무) VS Data Architecture(뼈대, 데이터) : 업무(비즈니스)를 수행하기 위해 필요한 데이터가 여러개일 수 있고, 하나의 데이터는 여러 업무에 활용될 수 있다.(M:M)

3. Application Architecture(기능, 애플리케이션) VS Data Architecture(뼈대, 데이터) : 어떤 기능을 수행하려면 여러 데이터를 사용해야 하고, 하나의 데이터는 여러 기능에 활용될 수 있다.(M:M)

1.2.6 데이터 아키텍처가 중요한 이유

데이터 아키텍처가 왜 근본적인가? 본질에 해당하는 부품(엔터티)의 집적도를 개선하지 않고 아무리 회로(애플리케이션)을 개선하더라도 한계가 존재한다.

근본적으로 데이터를 개선하지 않고서는 어떤방법을 써도 미봉책이 될 뿐이다.

1.3 아키텍처 수행결과에 대한 평가와 반성

1.3.1 수행한 내용에 대한 고찰

1.3.2 수행한 조직에 대한 고찰

1.3.3 관리와 통제에 대한 반성

1.3.4 데이터 아키텍처의 도입 수준

(2024.09.16)

2장 데이터 아키텍처의 개요

2.1 데이터 아키텍처의 개념

데이터 아키텍처는 데이터에 관한 모든 계층과 영역을 총망라해서 객관적이고 구체적인 전략이나 적용기준을 명시한 체계적인 방법론이다.

2.1.1 데이터 아키텍처의 구성

2.1.2 데이터 아키텍처와 데이터 모델링의 비교

2.1.3 데이터 구조영역의 단계별 개념

2.1.3.1 개괄적(Contextual) 모델
데이터 주제영역 도출

2.1.3.2 개념적(Conceptual) 데이터 모델
엔터티, 서브타입, 관계, 속성 도출

2.1.3.3 논리적(Logical) 모델
물리적인 요소를 제외한 모든 데이터 관련 상세 규칙 도출 → 논리적 모델링은 데이터 모델링의 최종적으로 완료된 상태.

논리적 모델이 현실적 요소에 의해 본질이 희석되었다면 이는 곧 진정한 본질과 그 본질로써 만들어진 것에 대한 관련성이 모호해짐으로써 진정한 본질이 왜곡되고 데이터의 일관성이 훼손됨은 물론 정보의 혼돈으로 인해 프로그램의 복잡성까지 증가시키게 된다.

2.1.3.4 물리적(Physical) 모델
논리모델에서 도출한 요소들을 어떤 단위로 물리적 모델로 전환할지 결정하는 단계

2.1.3.5 부가적(Out-of-context) 단계
그외에 물지적 데이터베이스 구성에 필요한 결정(index, view, PCTFREE, PCTUSED 등등)

(2024.09.28)

2.1.4 데이터 흐름영역의 단계별 개념

2.1.4.1 개괄적 데이터 흐름 단계
각 시스템 간 혹은 각 기관 간의 데이터 흐름을 정의

2.1.4.2 개념적 데이터 흐름 단계
엔터티 레벨 간 데이터 흐름 정의

2.1.4.3 논리 교환규칙 정의 단계
속성 레벨까지 구체적으로 흐름 정의

2.1.4.4 물리 변환규칙 정의 단계
애플리케이션의 구체적인 기능과 프로세스를 결합한 흐름을 정의

(2024.10.07)

2.1.5 데이터 관리체계의 수립
데이터에 대한 체계적이고 지속적인 품질관리를 위한 정책수립이 필요하다.

2.1.5.1 데이터 관리정책 수립
데이터를 관리하는 목적은 비즈니스의 전략적 요구사항을 효과적으로 지원할 수 있도록 데이터를 최적의 상태로 유지시키고, 이를 위해 소요되는 비용의 발생을 최소화하고 데이터의 활용성을 극대화하기 위함이다.

2.1.5.2 데이터 관리체계의 정의
2.1.5.3 데이터 관리 프로세스의 정의
2.1.5.4 데이터 관리조직의 역할 정의
2.1.5.5 데이터 거버넌스 시스템 구축

(2024.10.17)

3장 데이터 구조의 혁신 전략

3.1 데이터 구조의 혁신화 방안

3.1.1 데이터 구조의 혁신이 필요한 이유

3.1.2 데이터 구조혁신을 위한 고려요소

3.1.3 주목받기 시작한 데이터 아키텍처의 신역할론 (P227)

데이터가 확정된 다음에 처리 프로세스가 설계되어야한다.
애플리케이션은 개발자가 설계하지만 데이터는 전사적 차원에서 설계해야 한다.

현실에서 데이터설계보다 애플리케이션 설계가 우선되는 이유는 전사차원의 전문적인 데이터 아키텍트나 모델러가 존재하지 않기 때문이다. 애플리케이션 개발자가 필요한 데이터를 스스로 설계하는 자급자족형 개발방식이 가장 큰 원인이다.

개발자는 애플리케이션 중심적인 시각을 갖고 있는 사람들이므로 데이터를 중시하지 않는 경향이 짙다. 그들에게 데이터는 그저 처리과정의 일부에 지나지 않는다. 전사적 차원에서 데이터의 구조를 결정할 능력도, 자격도 없는 사람들이다. 지금도 극히 일부의 프로젝트를 제외한다면 개발 담당자나 단위시스템의 P/L급 담당자가 자기 영역의 데이터를 설계하는 실정이다.

전문적 데이터 관리조직이 없이 각 단계마다 다른 조직이 수행시의 특성  

• 데이터 아키텍처 단계
  • 비용적인 문제로 데이터 아키텍체에 많은 비중을 둘 수 없음
  • 따라서 현행 데이터의 상세한 분석을 엄두도 못내고 단지 담당자의 경험이나 지식에 의존한 데이터 아키텍처가 수립 됨.
  • 결과적으로 산출물 중심으로 접근하므로 매우 일반론적이고, 원론적인 내용의 데이터 아키텍처가 수립될 수 밖에 없음.
• 데이터 모델링 단계
  
  • 데이터모델링이 늦어지면 전체 개발 일정이 늦어지므로 단기간에 모델링을 할 수 밖에 없어 현행 모델을 심층적으로 분석할 시간이 절대적으로 부족함.
  • 결국 현행 모델의 문제점을 일부 개선한 정도의 목표 모델이 생성됨, 따라서 현행 모델이 상세화 되지않고 현행과 유사한 구조이기에 상세한 목표 데이터 모델도 작성되지 못함.
  • 이런 경험으로 프로젝트를 수행한 조직은 기존 경험을 재활용하기 위해 데이터 구조 혁신을 반대하는 가장 강력한 저항세력이 됨. 
• 프로그램 개발 단계
  • 상세화되지 않은 설계는 개발자의 자의적 해석의 여지를 주게되어, 설계자의 설계사상을 완벽이 이해하지 못한 상태에서 개발하게 됨.
  • 불완전한 분석으로 빈번한 데이터 구조변경이 발생하고 이로 인해 반복된 애플리케이션 수정, 개발 품질 저하, 낮은 개발 생산성을 유발.
  • 개발이 끝날 때까지 목표 모델로 데이터 이행이 완료되지 않아 개발자가 만든 소량의 데이터로 개발이 진행됨으로써 애플리케이션의 완성도가 떨어지고, 수행속도의 문제가 겉으로 더러나지 않아 잠재적 위험이 계속 증가함.
• DB 이행 단계
  • 상세한 현행 분석을 하지 못했고, 목표 모델도 상세하게 작성하지도 않았기 때문에 이행을 위해 제공된 산출물은 이행설계에 실제로 도움이 않됨.
  • 결국 데이터를 눈으로 확인(Eye Checking)하는 방법으로 예외처리를 포함한 매핑규칙을 설계하게 됨.
  • 그 결과 매핑규칙에 허점이 많아 테스트 단계가 되어서야 문제가 발견되고, 이를 보완후 다시 이행하는 방식의 지행으로 프로젝트 종료시점 까지 끝임 없이 반복됨.
  • 현행 데이터의 정제규칙(Cleansing Rule)까지 이행 프로그램에 포함되다 보니 소스코드가 길고 복잡하며, 수행속도도 느려서 이행시간이 과도하게 소요됨.
  • 이행이 늦어진다는 건 개발 단계에서 목표 데이터를 사용하지 못하고 수십 건의 데이터로만 개발함으로써 애플리케이션의 완성도가 심각하게 낮아져 테스트 기간이 길어지고 천신만고 끝에 오픈을 했더라도 안정화 기간에 지속적으로 심각한 문제가 발생. 
• 테스트 및 튜닝 단계
  • 소소의 데이터로 개발을 진행했기 때문에 수행속도의 문제가 전혀 드러나지 않은 채 모든 개발이 진행.
  • 개발자가 예상해서 만든 샘플 데이터로만 개발했기 때문에 예외 경우에 대한 대처가 매우 미흡하여 테스트 단계에서 데이터 모델과 애플리케이션 모두에 많은 수정이 발생.
  • 실 데이터를 사용하지 않았기에 악성 SQL 도출 불가하여, 향후에 튜닝대상 SQL이 크게 증가.

이러한 문제를 안고서도 어쨌든 프로젝트를 종료할 수 있는 이유는 그나마 데이터 구조의 혁신없이 현행과 매우 유사한 구조를 선택했기 때문이다.

동일한 전문적 데이터 관리조직이 모든 단계를 수행시의 특성    

• 데이터 아키텍처 단계
  • 현행 데이터의 상세한 분석을 토대로 데이터 아키텍처를 수립할 수 있다. 이 단계에서 제대된 분석을 미뤄봐야 다음 단계에서 현행 분석을 다시 해야함.
  • 이때 분석한 결과는 데이터 아키텍처의 수립뿐만 아니라 데이터 모델링, 데이터의 정제 및 이해규칙 설계에 계속 참조되어야 함으로 분석을 미룰 이유가 없어짐.
  • 상세 분석인 비용이 많이 들긴하나, 정확한 분석은 다음 단계진행의 확신을 낳음. 많을것을 깊숙하게 꿰뚫어 볼 수 있는 능력을 가지 우수한 데이터 전문가를 활용하는 것이 절대적으로 필요함.
• 데이터 모델링 단계
  • 동일 조직이 데이터 모델링까지 진행하게 되므로 설계 사상이 더욱 진화됨.
  • 핵심 데이터 모델이 견고하므로 좀 더 많은 단위족으로 나누어서 모델링을 진행하더라도 일관성이 훼손될 우려가 거의 없음. 모델링 기간 단축.
  • 데이터 레벨의 상세분석까지 진행하므로 이행단계의 구체적인 규칙를 정의 및 설계를 할 수 있어서 이행 프로그램의 작성에도 크게 기여함.
  • 목표 데이틀 개수를 혁신적으로 감소시킬 수 있으나 그만큼 기존의 처리방식과 달라지기때문 고정관념을 깨지 못한 극심한 저항세력들의 반발이 유발될 수 있음. 
• 프로그램 개발 단계
  • 모델링에 참여했던 전문가들이 개발자가 데이터를 처리하는 부분에 대한 기술자문 및 지원을 해줄수 있음.
  • 난이도가 높은 핵심 SQL에 대한 구체적 개선안을 제공할 수 있고, 최적의 인덱스 설계를 할 수 있음.
  • 데이터 전문가들이 개발 과정에서 데이터 처리영역에 참여함으로써 요구사항의 변경으로 인한 데이터 모델의 형상관리도 체계화 되어, 최소한의 모델 변경과 데이터가 훼손되는 것을 방지할 수 있음.
• DB 이행 단계
  • 현행 데이터를 정밀하게 분석하고 목표 데이터 모델을 상세하게 설계했던 사람이 이행규칙을 설계함으로 아행규칙의 분석 및 설계에 필요한 별도의 추가 공수가 없으며, 완성도와 정밀도가 높은 설계가 보장됨.
  • 높은 이행 프로그램의 완성도로 인해 공수 절약과 정확성이 향상됨.
  • 개발 단계에서 이행이 완료도면 개발자 입장에서 대량의 고품질 실 데이터로 개발을 진행하므로 다양한 처리유형이 사전에 발견되고 즉시 조치할 수 있는 기회가 미리 주어짐. 
• 테스트 및 튜닝 단계
  • 실 데이터를 이용한 개발로 실제적으로 대부분 튜닝이 이무 수행되었음.
  • 주로 사소한 문제점들만 발견되는 정도의 테스트 단계가 진행됨.
  • 안정화 기간도 짧음.

동일한 전문가 조직이 전체 과정을 책임진다면 일관성의 유지와 생산성, 효율성, 품질의 향상에 크게 기여할 수 있음.
데이터는 본질적으로 시스템의 골격일 수밖에 없으므로 최소한 데이터 영역만이라도 프로젝트에서 굳건한 기둥의 역할을 할 수 있도록 해야함.

(2024.11.17)

3.1.4 마스터(Master) 데이터의 구조 혁신

3.1.4.1 마스터 데이터의 정의

• 기업 비즈니스의 수행에 핵심적인 데이터
• 자주 변하지 않는 기본정보로서 행위나 이력이 아닌 데이터
• 여러 프로세스에서 자주 사용하는 공통의 주요 데이터
• 전사적 차원에서 중앙 집중적으로 관리/통제 되어야 하는 데이터

3.1.4.2 마스터 데이터 관리의 필요성

행위 데이터인 '전화사용내역'이 생성될려면, 고객(Party)이 상품(Product/Service)을 가입(구매)계약(Account)하고, 전화기라를 장비(Resource)까지 존재해야 비로소 전화기를 사용하는 행위가 발생할 수 있다.

이처럼 비즈니스 행위를 발생시키기 위해 사전에 존재하고 있어야 할 기본정보들이 주로 마스터 데이터이다.

• 전사관계자(Involved Party) 영역 : 행위의 실질적 주체 - 행위주체
• 상품/서비스(Product/Service) 영역 : 행위의 대상이나 목적물 - 행위목적 혹은 행위대상
• 계정영역(Business Account) 영역 : 행위의 최상위 주체는 Party이긴 하나, Business영역에서 실절적인 행위를 하는 주체 - 행위주체
• 자원(Resource) 영역 : Business수행에 필요한 도구나 수단, Business Domain에 따라 다양 - 행위수단 혹은 행위장소

(2024.11.23)

3.1.4.3 CRM은 MDM의 반면교사

과거 CRM에서는  한 방향으로 데이터 흐름이 발생했지만, 양방향으로 데이터 흐름이 발생하는 MDM에서는 훨씬 정밀한 설계가 요구된다. 또 기존 시스템에 있는 마스터 데이터 처리여역의 데이터 모델은 반드시 통합된 MDM 데이터 모델의 형태로 변경되어야 한다.

3.1.4.4 MDM 시스템 구축의 성공전략

인조식별자로 생성되는 최상위 개체는 중복되거나 잘못되었다 하더라도 생성자가 그것을 인지하지 못하면 무조건적으로 생성된다는 것을 의미한다.
이러한 마스터 데이터는 전사적 차원에서 중앙집중식으로 관리되지 않으면 결코 데이터의 일관성과 품질을 유지하기 어렵다.
게다가 현행 시스템에서 이행(Migration)을 하기위해 데이터를 정비하여 중복없는 예쁜 실체 데이터를 추출하고, 기존 애플리케이션을 수정하는 작업이 MDM 시스템을 구축하는 것보다 훨씬 고통스러운 작업이다.

MDM 시스템 운영전략으로 분류

업무 프로세서를 감안하지 않고 구축한 MDM은 지속적인 데이터 품질 유지에 많은 어려움이 있다. 반드시 마스터 데이터 관리 조직을 수립운영하는 데이터 거버넌스가 도입되어야 한다.

3.1.4.5 MDM의 미래 가치

마스터 데이터 관리는 당장의 시급한 문제를 해결하기 위한 수단이기보다는 미래의 발전을 위한 작업이다.

원래 통합이라는 것은 상호간에 공통 분모가 많아야 제대로 된 효과를 얻을 수 있다.
기업간의 인수합평으로 인한 시스템 통합이 아무리 이질적인 업종간 발생한다 하더라도 반드시 존재할 수 밖에 없는 공통된 영역이 있다.
그것이 바로 마스터 데이터와 회계영역이고, 그 마스터 영역이 행위주체(Party), 상품(Product/Service), 계정(Account), 자원(Resource)이다.

(2024.12.14)