EA(Enterprise Architecture)에 대해서

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

 

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

 

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

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

 

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

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

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

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

 

EA라는 용어를 사용하기 전의 공식 용어가 ITA(Information Technology Architecture)였는데요(ITA가 EA로 바뀜). 이 용어가 더 와닿습니다. 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 프레임웍¹⁾

 

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

 

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

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

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

 

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

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

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

 

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

 

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

 

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

 

 

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