1 IT 플랜의 역할

2 소규모 사레연구

3 엔터프라이즈 아키텍처 툴킷 소개

4 자크만 프레임워크의 비교

5 핵심성공요소

6 툴킷 프로세스 흐름

플랜의 중요성

• 만약 정보가 금이라면, 그래서 그 금을 캐는데 전 재산(혹은 회사)를 걸었다면 틀림없이 어떻게 할 것인가에 관한 Plan을 가지고 착수하였을 것이다.[1]
  
• "플랜이 잘못되어 실패하는 것이 아니라, 플랜이 없어서 실패하는 것이다"
  
• 규모가 크고, 복잡합고, 전략적으로 매우 중요한 프로젝트를 사전 플랜 없이 진행하면 때로는 참단한 결과를 낳는다
  
  

플랜은 실현 가능성을 높여준다

• 계획한 것은 실제로 일어나기 쉽다
  
• 플랜에 포함된 작업이 실제로 집행될 가능성이 높다
  
• 플랜에 들어 있지 않은 일은 햇빛을 보지 못할 가능성이 높다
  
  

플랜은

• 부실하지 않아야 한다
  
• 통합적이어야 한다
  
• 업무와 일치해야 한다
  
  

IT구축 성공 가능성 높이기

• 현업이 IT플랜에 참여하고, 기업의 목표를 IT가 명확히 알고 있을 때
  
• 기업 환경의 변화(인수/합병, 구조조정 등)에 따른 기업의 다양한 니즈와 이에 대응하는 IT솔루션들이 각각 무엇인지 인식 할 때
  
• 내부 조직간의 상충되는 목표가 드러나고, 중요한 문제를 협력적으로 해결할 수 있을 때
  
• 문제의 해결책을 포착하여 이를 IT 플랜에 반영할 때
  
• IT플랜에 따라 애플리케이션과 데이터 저장방안이 개발되고 기술이 선택될 때
  
  

낡은 메인 프레임 인프라와 운영 방법의 개선

• 현업과의 연계는 아주 잘 되었으나, 기술과의 연계가 부족해서 심각한 문제가 대두된 경우
  
• 조직소개
  
  • 3만명 직원의 고객 서비스 사업부
    
  • 8명의 분석가/아키텍처 팀
    
  • 60명의 IT팀
    
• 접근방법
  
  • 아키텍처팀은 대규모 현업 사용자 포험(100명 이상)을 분기별로 개최
    
  • 아키텍트는 비즈니스와 아키텍처 모델에 대해 상위수준에서 현재와 목표 상태를 개발하고, 프로토타입을 작성하고, 사용자 포럼에서 이를 검증
    
  • 아키텍트는 아주 상세한 기능 및 데이터 설명서를 작성
    
  • 별도의 조직에서 기술을 선정
    
• 잘된 점
  
  • 현업의 적극적인 참여
    
  • 인프라 개선안의 내용과 범위는 모델, 프로토타입 측면에서 아주 명확, 현업은 개선 내용에 대한 충분한 이해와 지원
    
• 잘못된 점
  
  • 기능과 데이터가 너무 상세하여 아키텍트는 개발 부서와 결탁. 즉, 아키텍트가 충분하지 않았음
    
  • 선정된 기술이 아키텍처를 지원하지 못하여 수년 동안 개선사업이 지연됨
    
    

필수 애플리케이션의 메인 프레임에서 클라이언트/서버 아키텍처로의 전환

• 거의 모든 일이 제대로 돌아간 경우
  
• 조직소개
  
  • 1.2만명의 직원으로 이루어진 고객 서비스 회사
    
  • 500명의 IT직원
    
  • IT에 보고하는 소규모 파트타임 아키텍처팀
    
• 접근방법
  
  • 각 사업부의 대표자들(마케팅 및 운영부서)들이 모델링 팀에 참여
    
  • 모델링팀은 IT사업 계획서를 작성하고 상위 수준 프로세스, 데이터 및 기술 모델을 개발
    
  • 아키텍트는 모델링 결과를 사용하여 아주 상세하 아키텍처 프레임워크를 구성하고, 아키텍처 구술, 데이터 및 기술 표준 작성 및 하드웨어와 소프트웨어 구매등을 수행
    
  • 아키텍처팀은 지원 교육을 마련하고, IT직원 채용을 관리
    
  • IT조직은 표준을 관리하고 표준의 준수를 검토하는 팀을 구성
    
• 잘된 점
  
  • 현업 사용자들은 프로세스와 데이터 모델을 이해하고 기꺼이 받아들임
    
  • 개발자들은 상세한 아키텍처 모델과 기술 표준을 통해 작업할 수 있었음
    
    

대기업 목표 아키텍처 이행 방안 모색

• 과유불급! 현업의 저조한 참여와 최악의 사례
  
• 조직소개
  
  • 대규모 통신회사
    
  • 4천명 이상의 IT직원들
    
  • 전체 IT조직에서 차출된 20명 이상의 아키텍트로 구성된 팀
    
• 접근방법
  
  • IT 지도부가 기업의 니즈를 나름대로 표현
    
  • 아키텍트가 정교하고 상세한 프레임워크와 컨텐츠를 개발함. 그 안에는 아주 목잡한 그래픽 모델 세트가 포함됨
    
  • 아키텍트는 거의 100개의 거대 프로젝트 리스트를 가지는 3년간의 상세한 구축 로그맵을 작성
    
• 잘된 점
  
  • 플랜은 매우 통합적이며 완벽했다
    
  • 아키텍트는 엄청난 깊이의 전사적 차원의 지식을 습득하였으며, 이런 지식은 재사용할 수 있었다
    
• 잘못된 점
  
  • 비즈니스 지도부가 아키텍처를 이해하지 못했다
    
  • IT지도부는 아키텍처의 범위가 위협적이며 자신들의 '영역'을 침범한다고 보았다
    
  • 너무 많은 프로젝트로 이루어진 아키텍처 범위가 스스로 실패를 자초했다.
    
    

대기업 목표 아키텍처 이행 방안 모색의 재시도

• 모든 것이 잘된 프로젝트
  
• 조직소개
  
  • 위 사례와 동일한 대규모 통신 회사
    
  • 4천명의 IT 직원들
    
  • 전체 IT조직에서 차출되었으나 위의 사례보다 적은 수의 인원(7명)으로 구성된 아키텍처팀
    
• 접근방법
  
  • 아키텍트는 공식적인 사업 기획 및 자금조달 프로세스에 참여함으로써 현업과 연결
    
  • 아키텍트는 아주 단순화된 프레임워크를 개발
    
  • 아키텍트는 기업 경영자들을 위한 상위 수준의 모델을 개발하고, 개발자들을 위해 그 모델을 분해
    
  • 아키텍트는 제안 대상인 상위 10개 프로젝트를 선정해서 프로젝트별 비즈니스 성과 지표 개발
    
  • 아키텍트는 아키텍처 준수(Compliance) 프로세스를 개발/제안 했다
    
  • 기본 아키텍처는 이전 프로젝트에 비해 변하지 않았지만 아키텍처의 핵심 구성요소가 어떤 의미를 가지는지 현업 및 IT지도부가 이해할 수 있도록 설명하기 위해 상당한 시간과 에너지를 쏟았음
    
• 잘된 점
  
  • 비즈니스 지도부가 플랜을 이해
    
  • IT 지도부가 플랜을 지원
    
  • 그들 모두 그 플랜의 내용과 성과지표를 좋아함
    
  • 상위 10개 프로젝트는 실행 가능
    
  • 프로젝트 관리자들과 개발자들이 아키텍처를 이해
    
  • 아키텍처팀은 아키텍처 위원회로 전환되어 개발 프로젝트가 아키텍처를 준수하는지 여부를 정기적으로 검토
    
  • 사업 계획 및 자금조달 프로세스와의 연계가 확립되고 계속 유지됨
    
• 잘못된 점
  
  • 아키텍처 준수 프로세스가 뿌리를 내리고, 공식적인 절차로 자리잡기 위해서 시간이 걸렸다.
    
    

EA의 목표

• IT 투자의 이점을 극대화
  
• 조직의 목적을 가장 잘 증진하는 방식으로 IT인프라를 조직과 연계(Aling)시키는 것
  
  

EA의 목표를 IT에 투자하는 모든 조직에 해당된다. 이 툴킷의 교훈은 다음과 같다.

• 현업의 참여는 필수!! 커뮤니케이션 채널이 활짝 열려있는 소규모의 협력팀이 이상적
  
• 다음의 경우 단순한 그리고 작은 아키텍처 접근방법이 유리
  
  • 대기업이거나 조직이 복잡한 경우
    
  • 기업의 지식이 넓게 퍼져있거나 부서별로 고립되는 경우
    
  • 아키텍트 시야와 경험이 좁거나, 아키텍트 수가 부족하거나, IT계획수립을 위한 시간/인내/자원/관심이 제한된 경우
    
• 아키텍처의 범위는 쉽게 이해할 수 있는 프레임워크와 표준 산출물을 가지고 설명되어야 한다
  
• 아키텍트는 산출물을 핵심적인 이행 프로젝트들로 전환해야 하며, 또한 각 프로젝트는 비즈니스 성과 지표를 가지고 있어야 한다
  
• 데이터, 기능, 기술, 인력, 프로세스 및 자금조달 계획은 밀접하게 연결되어야 한다
  
• 아키텍처 프로세스에는 어떤 형태로든 IT거버넌스가 포함되어 향후 개발을 인도하여야 한다
  
• 소규모(예:5~8명)의 아키텍처팀이 가장 효과적이다. 아키텍트는 광범위한 업무 지식과 깊이 있는 IT경험을 가지고 있어야 필요한 산출물을 만들 수 있다
  
• 아키텍트는 또한 아주 높은 수준의 개념적 산출물을 작성하여 조직 전반에 아키텍처를 이해시키고 지원을 얻을 수 있어야 한다
  
  

용어

• 엔터프라이즈: 회사의 모든 부서, 사업부, 대리점 혹은 조직을 의미
  
• 아키텍처
  
  • 엔터프라이즈의 니즈와 목표를 지원하기 위해 IT인프라의 모든 부분이 어떻게 되어야 하는지 자세히 설명(Describe)하는 한 세트의 플랜
    
  • 엔터프라이즈의 모든 데이터, 업무기능, 기술, 사람(데이터를 정보로 전환하고 접근하고 사용하는), 궁극적으로는 비즈니스를 위한 지식을 포함
    
    

엔터프라이즈 아키텍처의 구성 요소

• 비즈니스 프레임워크
  
  • 엔터프라이즈에 관한 핵심 지식을 수집하고 분석하기 위한 로드맵 제공
    
  • 아키텍처의 방향을 이끌게 할 것임
    
• IT 프레임워크
  
  • IT아키텍처와 아키텍처간의 관계에 대한 산출물을 생성하기 위한 로드맵 제공
    
  • 기업의 목표 달성을 가능하게 함
    
• 이행 프레임워크
  
  • 아키텍처 구현을 위한 핵심적인 영역을 다루는 베스트 프랙티스가 포함됨
    
    

zachman-poster1.pdf zachman-poster2.pdf

	Data(what)	Function(How)	Network(whare)	People(Who)	Time(When)	Motivation(Why)
Scope (Contextual)	List of Things Important to the Business	List of Processes then Business Performs	List of Locations in Which the Business Operates	List of Organiztions Important to the Business	List of Events/Cycles Important to then Business	List of Business Goals/Strategies
Enterprise Model (Conceptual)	Semantic Model	Business Process Model	Business Logistic System	Work Flow Model	Member Schedule	Business Plan
System Model (Logical)	Logical Data Model	Application Architecture	Distributed System Architecture	Human Interface Architecture	Processing Structure	Business Rule Model
Technology Model (Physical)	Physical Data Model	System Design	Technology Architecture	Presentation Architecture	Control Structure	Rule Design
Detailed Representations (Out of Context)	Data Define	Program	Network Architecture	Security Architecture	Timing Definition	Rule Expectation
Functioning Enterprise	Data	Function	Network	People	Time	Motivation

http://www.zachmaninternational.com/index.php/home-article/13#maincol

이곳의 내용은..

• 자크만 프레임워크의 목표/범위 항목에 대체적으로 대응됨. (데이터, 기능, 네트워크/기술, 인력, 시간 및 동기항목)
  
• 비즈니스와의 연계가 절대적으로 필요하기 때문에 비즈니스 니즈를 별도의 프레임워크로 나타냄
  
• IT프레임워크는 자크람 프레임워크의 비즈니스(개념적) 모델과 시스템(논리적) 모델에 해당. 기술(물리적) 모델로 진입을 과감히 시도
  
• 접근 방법의 범위는 IT플랜과 전략(자크만의 Planner, Owner, Desinger 관점). 분석과 설계(자크만의 Builder, Subcontactor 관점)는 포함하지 않음
  
• IT플랜에 프로젝트/프로세스/인력에 초점을 둔 플랜이나 활동이 포함되지 않으면 아무리 최상의 아키텍처일지라도 결코 구현될 수 없다
  
  

• 비즈니스가 가고자 하는 방향과 그에 대비되는 현재 상태에 대한 명확한 이해
  
• 가장 단순하고 효과적인 방법으로 모든 기본적인 사항을 아우르는 아키텍처 범위
  
• 범위가 잘 설정되어 비즈니스 지향적인 소수의 프로젝트로 아키텍처의 전환
  
• 각 프로젝트별 성과 지표의 개발 및 추적
  
• 아키텍처의 패키징과 마케팅
  
• 아키텍처/아키텍트를 지원하는 프로세스