260 likes | 458 Views
2006. 10. 17 ㈜ 엔코아컨설팅 컨설팅사업본부장 김 동 훈 이 사. 목차. SOA 구축에 통합 MASTER 데이터의 출현 배경 SOA 구축에 통합 MASTER 데이터의 필요성 SOA 환경의 통합 MASTER 데이터의 추세 통합 MASTER 데이터의 필수 요건 통합 MASTER 데이터의 구축 범위 통합 MASTER 데이터 구축에 필요한 핵심 기술 통합 MASTER 데이터 구축 방안 통합 MASTER 데이터 구축에 따른 기대 효과
E N D
2006. 10. 17 ㈜엔코아컨설팅 컨설팅사업본부장 김 동 훈 이 사
목차 • SOA 구축에 통합 MASTER 데이터의 출현 배경 • SOA 구축에 통합 MASTER 데이터의 필요성 • SOA 환경의 통합 MASTER 데이터의 추세 • 통합 MASTER 데이터의 필수 요건 • 통합 MASTER 데이터의 구축 범위 • 통합 MASTER 데이터 구축에 필요한 핵심 기술 • 통합 MASTER 데이터 구축 방안 • 통합 MASTER 데이터 구축에 따른 기대 효과 • 통합 MASTER 데이터의 향후 발전 방향 • Q&A
1. SOA 구축에 통합 MASTER 데이터의 출현 배경(1) 통신사 K사는 업무별로 특성화된 시스템이 구축되어 있고 각 시스템간에 데이터의 연계 작업을 수행하고 있지만 다량의 데이터로 인한 정합성과 성능 등 많은 한계를 가짐 복잡한 서비스 개발 필요 특정 시스템에 한정된 MASTER 데이터 WISE • 데이터의 적재량 • 시스템간의 커뮤니케이션 저해 • 중첩된 데이터 관리 EDW ERP 동일한 통합 One View 제공 CRM 시스템 • 마스터 데이터간의 불일치 • 중복에 의한 인지 불가 • 전체 시스템을 통한 분석의 어려움 Rating Portal 시스템 서비스의 재활용 부분 • 기술적인 제한으로 정보의 흐름 저해 • Point–to–point Process Link • 정합성 유지를 위한 비용 증가 기타 Billing 시스템 인사
KTF Members 통합 UI UFO Client CTI ARS KTF Members Monitor Monitor .. CRMM ERP .. .. .. .. Administration Administration Management Management 1. SOA 구축에 통합 MASTER 데이터의 출현 배경(2) 이러한 환경을 극복하기 위한 현실적인 최선의 방법은 SOA 구축과 동시에 고객 접점에서 발생되는 데이터를 통합하여 통합 고객 MASTER DB를 구축하는 것 통합 운영/ 모니터링 Presentation 계층 / 채널 계층 APM SLA Presentation Server Monitor Channel Gateway Management SOA 계층 SOA Governance Service Composition Layer 서비스 저장소 Service Enablement Layer Service Registry & Repository Process-Based Shared Business Service Shared Business Service Information & Access Service 통합 고객MASTER DB Legacy 시스템 EAI [ SOA 기반의 계층구조도 ]
기업 전반의 운용현황에 대한 일관성,가시성 제공 부족 각각의 시스템은 각각의 Master data를 관리 신규 상품 판매 기회 손실 Master Data에 대한 통합적 이해결여 구축 시스템과 실시간 협업 부족 정보 및 데이터 품질에 대한 신뢰도 저하 Master data 관리를 위한 통합 관리 방안 부재 2. SOA 구축에 통합 MASTER 데이터의 필요성 SOA 구축을 극대화하기 위해서는 반드시 통합 MASTER 데이터 구축은 필수 요소이고 특히 SOA 환경에서 운영 비용 최소화를 위한 방안은 통합 MASTER 데이터를 구축함 고객 채널 가시성 부족 Information Management Problem Customer Data Problem 고객 주도 서비스 부족 Product Data Problem 문제의 해결책은 SOA 환경의 통합 MASTER 데이터 구축 Data Quality Problem 동일 서비스이지만 별도의 서비스 구축 유연성과 성능 감소
3. SOA 환경의 통합 MASTER 데이터 추세 SOA 환경하에서 전사 MASTER 데이터를 통합 관리하는 Architecture를 많은 외국 Package에서 지향하고 있고 필연적으로 갈수 밖에 없음 [SAP사] [I사]
명의단위 가입계약의 정립 유연한 고객 구조 고객, 청구계정, 가입계약간 독립구조 다양한 고객 관계 고객, 청구계정, 가입계약 상호 관계 정보의 통합화 새로운 사업모델 수용 서비스 계약 정의의 확장 가입계약 Billing 체계 가입계약 기준의 청구, 수납, 미납 4. 통합 MASTER 데이터의 필수 요건 통신사 K사의 경우 SOA 환경하에서 통합 MASTER 데이터는 신규 구축 시스템에서 Ownership의 가지고 각 Legacy 시스템에 관련 데이터를 제공하는 역할을 담당해야 함 해 결 [ SOA 기반의 고객 MASTER DB] • SOA 환경에서 고객 MASTER DB에서 신규 요건과 기존의 요건을 모두 수용할 수 있도록 구축하여 각 시스템이 부분적으로 수용하면 비용과 시간이 절감 됨 • 향후 KTF의 각 시스템은 영역의 특성에 맞게 독립적으로 변화에 대처함으로써 각 시스템은 유연성이 증가 됨
고객 고객기본 정보 상품 계약 계정 통합LOG S/R Asset 상품Agreement 5. 통합 MASTER 데이터의 구축 범위(1) 통신사 K사는 SOA 환경에서 통합 MASTER 데이터의 데이터 모델 구축 범위는 고객 접점에서 발생되는 모든 데이터를 수용해야만 함 데이터 모델 구축 범위 • 행위의 주체가 되는 개체 통합 • 개체의 기본 정보의 통합 • Agreement, Asset 통합 • 고객 S/R 부분의 통합 • 이력 데이터 통합 • 주제 단위의 이력 통합 • 유연한 고객,계정,계약 관계 정의 OLTP CRM EDW Portal ERP
5. 통합 MASTER 데이터의 구축 범위(2) 통합 MASTER 데이터에 대한 관리 부분에 대한 구축 범위는 비즈니스 서비스와 데이터 처리 서비스를 분리하는 경우 각각 독립적으로 재활용이 가능해야 함 데이터 관리 범위 SOA 계층 • 독립적인 데이터 액세스 Layer 구축 • 비즈니스 서비스와 데이터 액세스Layer가 독립적인 기능을 통해 상호 유연성과 서비스 개발 생산성 극대화 • 데이터 액세스 Layer에 대하여 전략적으로 옵티마이징 전략 수립 및 관리 체계 구축 • 고성능의 데이터 액세스 Layer 구축 • 각 테이블의 데이터 처리 정보와 각Legacy 시스템과 데이터 Mapping정보를 Repository 저장 및 관리 • 서비스 저장소와 연계한 데이터 메타 관리 체계 구축 Service Composition Layer 서비스 저장소 Service Enablement Layer Service Registry & Repository Process-Based Shared Business Service Shared Business Service Information & Access Service Data Access Service Master DB CRUD 관련 SQL 각 테이블간의 데이터 처리Dependency
6. 통합 MASTER 데이터 구축에 필요한 핵심 기술 통합 MATER 데이터 구축은 단순한 데이터의 통합에 대한 기술력이 아닌 전문가, Technology, Knowledge 등 3가지의 요소가 반드시 필요함 • 데이터 모델링, 데이터 처리, 데이터 관리 등의 데이터에 전문적인 지식 • 기업 각 분야의 업무와 기준정보관리에 관한 전문적인 지식을 실체로 제공할 수 있는 검증된 최신 기술 • 해당 3가지를 지식을 가지고 프로젝트를 추진해갈 수 있는 전문가 필수 • Business를 잘 이해하고 추진력 있는 고객PI • 분석, 설계, 위기관리, 변화관리 등 능력 있는 컨설턴트 • 기술력과 고객지향의 열정을 지닌 전문 업체 전문가 성공적인 통합 MASTER DATA 구축 • SOA를 위한 Architecture • DA Architecture • Global 기술Leadership • 중장기IT 기술기반제공 • 통합 MASTER 데이터에 대한 전문지식 • 통합 MASTER 데이터 구축에 대한 프로젝트 실제 경험 Technology Knowledge
7. 통합 MASTER 데이터의 구축 방안(1) 통합 MASTER 데이터 구축을 위해서는 ① 개체 통합, ② Rule 기반, ③ 데이터 허브, ④ 전사 표준화 준수 등의 4가지에 대한 부분에 대한 기술적인 방안이 있어야 함 SOA의 핵심인 서비스의 통합 구현 통합 MASTER 데이터 MASTER 데이터의 One View 제공 통합 MASTER 데이터 구축 방안 개체 통합 ① ② Rule 기반 • 단순 Key 통합이 아닌 실질적인 정보(집합)를 통합 • 향후 기업의 비즈니스 객체를 고유하게 정의할 수 있어야 함 • 모델 변경 없이 데이터 추가만으로 신규 업무의 수용 가능하도록 구축 • 데이터 모델의 변경을 최소화할 수 있도록 데이터 관리 RULE 정의 ③ 데이터 허브 전사 표준화 준수 ④ • 전사에서 발생되는 MASTER성 데이터에 대한 Ownership을 가진 데이터 허브 모델 구축 • 데이터 제공하는 시스템의 변경에 영향을 최소화할 수 있도록 데이터 모델 구축 • 표준 데이터 구조 및 데이터 표준 규칙 적용 • 적용된 표준 규칙이 데이터 품질 관리와 연계되도록 수행 • MASTER 데이터 관리 Repository 구축
세대정보 법인/사업자 패밀리 대리인 ……… 보증인 기본정보 소득정보 접촉포인트 직업정보 직장정보 주소정보 주택정보 담보정보 성향정보 자격정보 세대정보 신용정보 7. 통합 MASTER 데이터의 구축 방안(2) ① 개체 통합은 일반적인 Package의 단순한 Key를 통합하는 것이 아니라 개체가 가지고 있는 부가적인 정보까지 통합하여 구축되어야만 함 집합 통합의 장점 최대한으로 통합된 집합 고객(광의,논리적) • 업무 변경에 대한 유연성과 복잡한 업무를 단순화 • 개발 단계의 생산성 향상과 난이도가 감소 • 수행속도 향상과 유지보수 비용의 감소 새로운 집합이 발생되어도 서브타입만 증가를 통해 모델 변경이 없음 다양한 유형의 고객 분류 통합 고객 통합고객 고객 관계 잠재고객 - 고객 개체 확장 - 관리 속성 확장 집합 통합의 단점 • 집합 본질을 희석하여 모호한 집합 • 집합의 의미를 정확하게 파악해야만 운영 고객 Profile 집합 형태 결정의 대원칙 • 가능한 집합을 최대로 통합 • 집합을 통합 하여도 통합된 각 집합의 의미가 희석되지 않아야 함
7. 통합 MASTER 데이터의 구축 방안(3) ① 개체를 통합하기 이전에 개체에 대한 정확한 분류 기준을 정의하고 이러한 정의 기준이 Repository에 저장되어 관리될 수 있도록 구현함 • 고객이란 실명 (주민등록번호, 여권번호, 법인번호)이 존재하는 개인, 법인, 공공기관을 의미 • 회사와 비즈니스 행위를 발생시키는 모든 주체를 고객으로 통합 • 현재의 고객뿐만 아니라 타사 또는 신규 사업의 고객까지 수용 가능 정의 관리 기준에 의한 분류 사용유무에 의한 분류 관계 유형에 의한 분류 고객을 구분하는 식별자로 사용되는 주민번호, 여권번호, 법인번호 여부에 따라 구분되는 고객분류 KTF와의 관계 유형으로서 명의 고객, 실사용 고객, 실납부 고객, 미성년자에 대한 법정대리인 등 고객이 당사의 서비스를 사용하는 개통 여부에 따른 고객 분류임. 개인 고객 법인 고객 명의 고객 실사용 개통(이용)고객 잠재(해지)고객 개인 외국인 개인사업자 공공기관 법인 납부고객 법정대리인
7. 통합 MASTER 데이터의 구축 방안(4) ① 개체 통합에 대한 SAMPLE 사례 SAMPLE • 행위의 주체가 되는 개체를 통합 고객으로 통합한 데이터 모델 구축 • 고객간의 다양한 관계, 세크먼트, Profile 정보를 통합한 데이터 모델 구축 • 각 업무별로 필요한 정보를 참조
배타적용관계 #배타그룹번호 #시작일 #종료일 o 선택가능수 판촉 여부 정산 여부 정규 일반 접속 판촉 배타유형 사용 배타 제공 배타 부가서비스 기본 선택 7. 통합 MASTER 데이터의 구축 방안(5) ② Rule 기반은 프로세스 중심의 데이터 모델이 아닌 데이터 중심의 데이터 모델을 구축하는 것을 의미함 서비스 Relation #관계유형 #시작일 #종료일 o 관계연산자 상품과 서비스간의 관계 관리 모든 유형의 서비스통합 관리 단말기모델 #모델ID 상품 #상품코드 사용가능관계 기준 단말기 서비스 유형 기준 부가서비스 상품과 서비스간의 배타적 관계 관리 단말기 서비스 대상 요금상품 요금 상품 조건 PP 전환가능관계 기준 요금상품 전환 요금상품 정규서비스 판촉 정규관계 판촉서비스 구성관계 구성 유형 요금 상품 기준 요금상품 기준 요금상품 상품/서비스 사용배타는 ALL 제공 서비스 부가서비스 단일 묶음 제공 단일서비스 부가서비스 단일/묶음 기준 묶음서비스
7. 통합 MASTER 데이터의 구축 방안(6) ② Rule 기반의 고객, 청구 계정, 서비스계약 간의 독립적인 구조와 다양한 모든 관계를 데이터로 정의할 수 있는 관계 구조 고객 : 계약 M : M 고객 1 고객 2 고객 3 고객 4 계약 : 청구계정 M : M 계약 5 계약 1 계약 2 계약 3 계약 4 일반청구 분리청구 A 분리청구 B 일반청구 청구계정 : 납부고객 M : 1 납부고객 1 납부고객 2 납부고객 3 청구계정 : 청구계정 M : M 고객 : 고객 M : M 계약 : 계약 M : M • 독립적인 고객구조 (고객, 청구계정, 가입계약) • 다양한 유형의 통합 고객, 순수 납부 주체인 청구계정 • 청구계정에 독립적인 가입계약 • 고객구조 상호간의 다양한 관계 수용 • 가입계약 단위의 업무체계 • 개통계약(CN) 기준의 가입계약 단위 정보 • 전화번호,단말기,상품 등은 계약의 부속물 • 신규 서비스에 대한 유연한 수용 가능 • 계약 기준 빌링의 단순화 유도
7. 통합 MASTER 데이터의 구축 방안(6) ② Rule 기반의 고객, 청구 계정, 서비스계약 간의 독립적인 구조와 다양한 모든 관계를 데이터로 정의할 수 있는 데이터 모델 사례 SAMPLE
7. 통합 MASTER 데이터의 구축 방안(7) ② Rule 기반의 고객 접점에서 발생되는 비즈니스 서비스에 대한 EVENT 통합 데이터 모델 SMAPLE 사례 SAMPLE • 행위의 주체가 되는 단위별로 발생되는 모든 비즈니스 Event를 통합한 데이터 모델 • 비즈니스 Event별로 서로 변경 컬럼이 다른 경우를 컬럼 메타 데이터 방식으로 모델 구축 • 해당 데이터를 각 Legacy 시스템에 제공
Access Services 7. 통합 MASTER 데이터의 구축 방안(8) ③ 데이터 허브는 기존 EDW와 같이 데이터에 대한 Ownership이 없고 단순 데이터를 통합하는 수준이 아니라 Ownership을 가진 데이터의 통합을 말함 통합 Service Bus Legacy 서비스 저장소 과금 Enterprise Service Bus Channel G/W 영업 Process Orchestration Service 개 통 MID 공 통 서 비 스 상품추천 CRM Connectivity Service … EDW 통합 운영/모니터링 SLA APM 통합 Business Rule 통합 Data Master DB SOA Governance Business Rule Engine [ 기존의 EDW형 데이터 허브 ] [ SOA환경의 통합 MASTER 데이터 허브 ]
MCG Queue JAVA API DB Wrapper 7. 통합 MASTER 데이터의 구축 방안(9) ③ 데이터 허브 역할을 하는 통합 MASTER DB와 각 Legacy 시스템간의 데이터 현행화 Architecture UI Channel XForms Service 통합 Data 고객Master Sync A-Sync 현행화 현행화 현행화 현행화 Service Legacy 과금 영업시스템 CRM 시스템 table1 table2 table3 table3 교환기 table1 table2 table3 table3 외부연동 … …
Access Services 서비스 저장소 Service Registry & Repository 7. 통합 MASTER 데이터의 구축 방안(10) ④ 전사 표준화 준수는 SOA환경하에서 통합 MASTER 데이터 구축하는데 데이터의 거버넌스를 실현과 데이터 품질이라는 두 마리의 토끼를 잡을 수 있는 기회를 가져 옴 Enterprise Meta Data Repository Meta 포탈 통합 Service Bus 개발자 DQ Repository 통합 IT 운용 Repository Repository 운용 Channel G/W Enterprise Service Bus 현업 사용자 표준화 운용 Process Orchestration Service 개 통 공 통 서 비 스 Database 운용 Data Model Repository Application Architecture Repository 상품추천 DBA Connectivity Service Model Viewer … Repository 활용 Modeler Meta Data Mart Database Repository 액세스 패턴분석 영향도 분석 품질관리자 사용자 관리 AS-IS V TO-BE Mapping Repository Data 표준화Repository IT 관리자 데이터 품질관리 용어사전 도메인사전 통합 및 연동
7. 통합 MASTER 데이터의 구축 방안(11) ④ 전사 표준화 준수를 위한 통합 MASTER DB의 Repository 구현 이미지 사례 임 구현 이미지 데이터 기준 데이터 분류 체계 ④ LegacyTable 주제영역 MASTER DBRepository ① 권한 레벨 분류 기준 MASTER데이터 모델 Table 데이타베이스 정보 정보를 데이터로 저장 사용 목적 정보 MASTER 데이터와Legacy 데이타간의 Mapping정보 보존주기 표준 항목 ③ 표준화 및 데이터 Rule 정보 데이터 액세스SQL MASTER DB 관리 시스템 ② 데이터 흐름도
8. 통합 MASTER 데이터 구축에 따른 기대 효과 SOA 환경에서 통합 MASTER 데이터를 구축하는 경우 최소의 비용으로 Legacy 시스템의 변경에 유연할수 있음 • IT 거버넌스 실현 • 시스템 관리의 부담을 최소화 • 운영자 및 관리자의 편의성을 고려한 통합 운영 아키텍쳐 • 비즈니스 서비스 중심의 시스템 구현 • 비즈니스의 변화에 신속하게 대응 체제 구축 2 1 비즈니스 관점 IT 관점 3 4 데이터관점 고객관점 • 고객 중심의 서비스 • 고객 접점의 정보 One View 제공으로 신회성 향상 • 데이터 중심의 데이터 모델 • 데이터 표준화와 품질관리 용이성 증가 • 확장성 및 유연성 증가
9. 통합 MASTER 데이터의 향후 발전 방향 향후 국내 대부분의 기업이 SOA 구축과 빅뱅 방식의 시스템 구축이 아닌 각 업무 시스템을 두고 그 상위에 고객 접점에서 발생되는 MASTER성 데이터만 통합 함 [ 빅뱅 방식 ] [ SOA & 통합 MASTER 데이터 구축 ] 추가 • 전체 시스템을 재개발함으로 비용과 시간이 많이 소요 • 기업의 M&A시 해당 기업의 시스템을 폐기하고 데이터의 통합에 많은 어려움이 존재함 • 기업 M&A시 통합 MASTER 데이터만 통합하고 기존 업무 시스템 최대한 재활용이 가능 • 각 Layer별로 독립적인 구조이기 때문에 유연성이 최대한 보장 받을 수 있음
10. Q&A 많은 질문 부탁 드립니다.