MCI/MCA 편집하기

IT위키

경고: 로그인하지 않았습니다. 편집을 하면 IP 주소가 공개되게 됩니다. 로그인하거나 계정을 생성하면 편집자가 사용자 이름으로 기록되고, 다른 장점도 있습니다.

편집을 취소할 수 있습니다. 이 편집을 되돌리려면 아래의 바뀐 내용을 확인한 후 게시해주세요.

최신판 당신의 편집
1번째 줄: 1번째 줄:
[[분류:소프트웨어 공학]]
[[분류:소프트웨어 공학]]
[[분류:금융]]
* 상위문서: [[시스템 연계 솔루션]]
Multi Channel Integration / Multi Channel Architecture
* 주로 기업 내부 동기종 또는 유사기종 시스템을 연계시키는데 사용된다.
* 예를 들어 은행에서 여신 업무와 수신 업무는 MCI/MCA를 통해 연계된다.


*위문서: [[시스템 연계 솔루션]]
== MCA와 MCI ==
* MCA는 멀티 채널로 된 아키텍처를 지칭하며, MCI는 멀티 채널로 구성된 아키텍처의 통합(서비스 연계)를 지칭
* 실무에선 MCA와 MCI를 잘 구분하지 않으므로, 본 문서에서는 포괄하여 표현
* 향후 이 차이에 대해서 기술하고자 할 경우 [[MCI]]와 [[MCA]] 문서 구분 요망


;Multi Channel Integration / Multi Channel Architecture
== 같이 보기 ==
;기업 시스템 구조에서 다양하게 구분된 업무 채널을 효율적으로 관리하기 위한 체계 또는 이를 실현하기 위한 솔루션, 또는 이를 구현한 프로토콜을 가리킨다.
* [[EAI]]
 
* [[ESB]]
*다양한 채널(단말,자동화기기,콜센터,모바일 등) 을 통합하는 기술기반을 구축하여 업무시스템의 채널 의존성을 제거하고, 모든 채널이 정보를 공유하는 채널 통합 시스템
* [[FEP]]
 
[[파일:MCI 사용 전후 개요도.jpg]]
 
==분류==
 
*대내 MCI: 영업점 단말, 인터넷, 스마트폰 및 자동화기기등 고객과의 접점 연계
*대외 MCI: 카드사, 보험업계 및 VAN 사와 같은 대외기관
 
==MCA와 MCI==
 
*MCA는 멀티 채널로 된 아키텍처를 지칭하며, MCI는 멀티 채널로 구성된 아키텍처의 통합(서비스 연계)를 지칭
*실무에선 MCA와 MCI를 잘 구분하지 않으므로, 본 문서에서는 포괄하여 표현
*향후 이 차이에 대해서 기술하고자 할 경우 [[MCI]]와 [[MCA]] 문서 구분 요망
 
==주요 기능==
{| class="wikitable"
!'''주요 기능'''
!'''세부 내용'''
|-
|거래처리
|
* 프로토콜 요청 접수 : HTTP,TCP/IP, X.25 프로토콜 등
 
* 메시지 변환 기능 : XML방식 메시지 정의, 다양한 포맷지원, 메시지 변환, 코드변환
* 메시지 라우팅 : 메시지 전송/조립, 거래맵 상의 스크립트지원 등을 통한 룰의 동적 변경지원
|-
|
인터페이스 및 대용량 관리
|
* Channel 별 인터페이스 방안 제공
 
* 호스트 및 서버 인터페이스(SNA, TUXEDO 등 프로토콜제공)
|-
|통합개발환경 및
 
운영환경 지원
|
* Message 및 Workflow Designer
 
* 사용자 관리(채널시스템 관리자)
 
* 관리자에 대한 권한 관리
 
* 파일 송수신 기능
 
* Transaction 분석 및 제한
|-
|장애 복구 서비스
|
* 멀티 Clustering Server 환경에 가용한 장애 메커니즘
 
* 보안 인프라 연계
 
* 채널서비스(거래제어, 승인, 저널링 등)
|-
|채널 서비스
|
* 채널세션을 관리하는 기능
 
* RULE 및 CONFIG DATA 저장소 관리
 
* 로그, 에러정보 관리
|}
 
*그 외
**대외전문관리
**대외전문변환(표준전문↔대외전문)
**메시지 유효성 검사
**메시지 조회 및 추적(전문 로깅, 거래메시지 trace, 에러로깅)
**회선 별 집계
**B2Bi(ebXML, RosettaNet, EDI 등)
**타발/당발 요청 시뮬레이터
**당발 요청 시뮬레이터
**재처리 및 오류 처리
**채번/결번 관리
**센터컷 처리
**개시/마감전문 스케쥴러
**영업일 관리
 
==프로젝트 관리==
===일정 관리===
 
*금융권 프로젝트 기간은 최소 1년 이며 길게는 2년
*각 벤더 사들의 비표준, 표준 전문 개발 및 테스트가 일정 관리 핵심 요소
*전문 테스트 시뮬레이터를 제대로 갖고 있을 수록 프로젝트의 성패를 좌우
 
===기타 고려사항===
 
*채널의 집중화로 인한 성능 관리 강화
**모든 채널이 집중됨에 따른 성능관련 이슈가 대두될 수 있으므로 이에 대한 대응방안  강구
*무장애 지원을 위한 대응 방안 마련
**다중채널의 장애는 고객입장에서는 전체 시스템의 장애와 직결되므로 장애 대응에 방안확보가 중요
 
==필요성과 기대효과==
===구축 필요성===
{| class="wikitable"
|-
!항목!!필요성
|-
|업무의 채널 종속성||
*시스템 개발 시 모든 채널을 고려하여 업무 프로그램을 구현
*채널의 변경이나 추가에도 업무 프로그램의 변경 필요
|-
|채널기능의 중복 개발||
*각 채널은 모든 업무 시스템에 대한 채널의 기능을  중복 개발
*업무시스템이 변경되면 모든 채널을 같이 변경해야하는 역 의존성 발생
|-
|인터페이스 중복 개발||
*각 채널은 모든  업무 시스템에 대한 인터페이스를 중복하여 개발
*업무시스템 추가 시 채널 인터페이스 추가 개발 필요
|-
|정보의 일관성 부재||
* 전 채널을 대상으로 하는 인프라 부재로 일관성 있는 정보 제공의 어려움
|}
 
===기대 효과===
{| class="wikitable"
!'''구현 효과'''
!'''세부 내용'''
|-
|채널개발 비용 절감
|
* 프로그램내 분산, 중복 개발된 채널기능을 통합
* 중복 기능을 제거하여 추가 개발 및 관리 비용 절감
|-
|고객 중심 채널
 
인프라 확보
|
* 고객의 채널 선택에 무관하게 동일한 수준의 서비스를 제공
* 채널의 제약사항에 따른 고객불편 감소
|-
|비즈니스 경쟁력 강화
|
* 채널 독립적이고 비즈니스 중심적인 업무시스템 구축
* BPM과 연계하여 프로세스 가속화, 비즈니스 자동화 및 최적화
|-
|업무시스템 인터페이스 통합
|
* 채널 별로 분산된 업무 시스템 인터페이스를 통합, 단순화함으로써 채널을 경량화
* 시스템 도입 및 운영 비용을 최소화함으로써 TCO를 절감
* 각 채널 별로 배치해야 했던 IT 요원의 수요를 최소화하여 효율적 인력 운용 가능
|-
|고객 서비스 품질 향상
|
* 고객의 채널별 접근 이력을 수집하여 확장된 마케팅 자료 확보 가능
* 고객의 채널 이용 정보를 통해 Cross Sale 및 Up sale의 기회가 확대
|}
<br />
==같이 보기==
 
*[[EAI]]
*[[ESB]]
*[[FEP]]
 
==참고 문헌==
 
*http://sanggu.blogspot.com/2011/10/mci-multi-channel-integration.html
*http://blog.naver.com/jbu1505?Redirect=Log&logNo=40131504010
*http://blog.naver.com/PostView.nhn?blogId=santalsm&logNo=110177658337
IT위키에서의 모든 기여는 크리에이티브 커먼즈 저작자표시-비영리-동일조건변경허락 라이선스로 배포된다는 점을 유의해 주세요(자세한 내용에 대해서는 IT위키:저작권 문서를 읽어주세요). 만약 여기에 동의하지 않는다면 문서를 저장하지 말아 주세요.
또한, 직접 작성했거나 퍼블릭 도메인과 같은 자유 문서에서 가져왔다는 것을 보증해야 합니다. 저작권이 있는 내용을 허가 없이 저장하지 마세요!
취소 편집 도움말 (새 창에서 열림)