태터데스크 관리자

도움말
닫기
적용하기   첫페이지 만들기

태터데스크 메시지

저장하였습니다.

현재 EA 관련 프로젝트를 하고 있습니다. 관련 논문도 쓰고, 컨설팅도 여러 번 수행했지만 EA는 여전히 쉽지 않네요. 정해진 게 없어서 그럴 것입니다.

 

오늘은 EA가 무엇인지 중심 잡는 데 도움이 될만한 얘기들을 두서없이 쓰겠습니다.

 

EA는 우선 ISP와 다소 헷갈립니다.

하나는 업무(Business) 위주고 하나는 기술(Technology) 위주인데요.

 

고객측의 참여 주체가 다르다는 게 핵심일 거 같습니다.

ISP는 고객의 업무 현업이 주도적인 역할을 합니다.

반면에 EA는 고객의 IT 현업이 주도적인 역할을 하고요.

물론 핵심 주체가 분명하지 않을 때도 많습니다. 경험상 이럴수록 프로젝트가 힘들어집니다.

 

EA라는 용어를 사용하기 전의 공식 용어가 ITA(Information Technology Architecture)였는데요(ITAEA로 바뀜). 이 용어가 더 와닿습니다. Enterprise 아키텍처는 왠지 모호합니다.

 

EA 타스크는 크게 현행 아키텍처 분석과 향후 아키텍처 구축으로 나눌 수 있습니다.

개인적으로 현행 아키텍처 분석만을 수행하는 것도 좋다고 생각합니다. 이것만 제대로 있어도 위력을 발휘하기 때문인데요. 특히 DA가 그렇습니다.

 

현행 아키텍처 분석 단계에서는 상세한 수준의 현행 실체를 분석해야 합니다. 예를 들어 DA는 테이블을 분석하는 것이죠.

차세대 프로젝트에서 모델링을 하는 것과 크게 다르지 않습니다. 다만 상세화 수준이 다를뿐입니다.

어프리케이션/메뉴, ERD/테이블, 장비/소프트웨어 등 실체를 들여다보고 그대로 그리는 것이 중요합니다.

 

그리고 향후 아키텍처 구축 단계에서는 제안/개선 등 TOBE에 대한 내용이 들어갑니다.

이 제안이나 진단은 근거가 있어야 합니다.

선진사례나 원칙 등의 기준이 있고 그것과 비교해서 어떻게 해야한다는 내용이 있어야 합니다.

근거없이 결론이 나오면 안 되고, 논리의 비약이 있어도 안 됩니다.

여기에 전문가다운 통찰력(Insight)이 근거에 더해져야 합니다.

 

EA에서는 상세한 실체를 들여다보면서도 큰 틀을 유지해야 합니다.

큰 틀을 프레임웍(Framework)이라고 부르는데 DA 프레임웍는 [그림1] 같습니다.

 

요소

Standards

Structures

Interfaces

Manage-

ments

Contextual

Planner

(경영자)

데이터표준화 지침서

주제영역 정의서

업무흐름지침서

DA관리지침서

Conceptual

Owner

(책임자)

모델링지침서

DB표준화지침서

데이터참조모델

  (DRM)

개념모델

데이터흐름지침서

서비스&주제영역관계정의서

DA조직R&R

Logical

Designer

(설계자)

단어정의서

용어정의서

논리모델

업무&엔터티관계정의서

데이터공유정의서

DA프로세스

Physical

Builder

(구축자)

도메인정의서

코드정의서

물리모델

DB스키마정의서

테이블&어플리케이션 관계정의서

데이터품질

System

Enterprise Data Architecture Management System

[그림1] EDADF 프레임웍1)

 

데이터 아키텍처를 수행하려면 위와 같이 표준(Standards)과 구조(Structures), 인터페이스(Interfaces), 관리(Management)라는 큰 틀 내에서 검토해야 합니다. 상세 항목은 변할 수 있지만 어떻게 수행하는지, 어떤 산출물이 나오는지를 알면 혼란은 없을 것입니다. 큰 그림과 결과 그림을 알면 EA를 수행하기 수월합니다.

 

컨설팅 프로젝트는 다양한 참여자들의 다양한 의견 때문에 힘이 드는데 정답이 없는 것도 힘든 요소 중 하나입니다.

모델링도 정답이 없다는 점 때문에 힘들 때가 있지만 EA는 모델링보다 더 추상적이니까요.

수행하기 힘들더라도 중심을 잡고 있는 것과 그렇지 않은 것은 차이가 많이 납니다.

 

개인적으로 EA 프로젝트의 핵심은 주제영역이라고 생각합니다.

EA 프로젝트는 시스템을 구축하기 전 단계라고 볼 수 있습니다.

현행을 분석해서 방향을 정하는 것으로만 끝내기엔 부족하고 차세대 시스템 구축에 사용해야 합니다.

 

차세대 프로젝트에서 초반에 혼란을 겪는 것이 주제영역입니다. EA에서 주제영역만 명확하게 정의하면 이어지는 차세대에서 유용하게 사용할 수 있습니다.

 

그리고 주제영역을 도출하기 위해서는 개념 모델이 필요합니다. 주제영역에는 데이터 통합이 주요 관점이고 이는 개념 모델에서 보일 수 있습니다.

 

EA 프로젝트와 구축 프로젝트는 연속성이 있어야 합니다. 구축 프로젝트에서 이어서 사용할 수 있는 EA 산출물을 만드는 게 바람직합니다.

 

 

1) 김기창, “전사적 데이터 아키텍처 프레임웍에 대한 개념모델 개발”, 2007




블로그 이미지

블루퍼필

댓글을 달아 주세요

  • 정유성 2012.10.15 17:28  댓글주소  수정/삭제  댓글쓰기

    오랜만에 들렀습니다. 새로운 프로젝트를 하고 계시나 봅니다. 작년에 EA관련 공부를 잠깐 하던 때가 생각나네요. 좋은 가을 되시고, 행복한 프로젝트 기간 되세요 ^^

    • 블루퍼필 2012.10.15 23:39 신고  댓글주소  수정/삭제

      감사합니다.

      그런데 행복한 프로젝트가 있을까요... ㅎㅎ
      좀 재밌는 프로젝트는 있지만요..

      많이 읽고 많이 생각하는 행복한 가을 되세요.

  • 허민석 2014.01.28 08:19  댓글주소  수정/삭제  댓글쓰기

    구구절절 옳은 말씀이시네요.

    일전 프로젝트시
    AS-IS EA 현행화 과정이 쉽지 않았으나,
    TO-BE 모델링, 시스템 설계시 무척 도움되었고, 또한 누락없이 잘 마무리 지었습니다.

    하여,

    말씀처럼 주제영역에 대한 중요성과
    AS-IS 현행화는 무척이나 주요한 과정이라 동의에 동의 합니다..^^