#title ITA/EA 서론 [[TableOfContents]] ==== IT 플랜의 역할 ==== '''플랜의 중요성''' * 만약 정보가 금이라면, 그래서 그 금을 캐는데 전 재산(혹은 회사)를 걸었다면 틀림없이 어떻게 할 것인가에 관한 Plan을 가지고 착수하였을 것이다.[* 소비자 행동에서도 "관여도"를 이렇게 설명한다] * "플랜이 잘못되어 실패하는 것이 아니라, 플랜이 없어서 실패하는 것이다" * 규모가 크고, 복잡합고, 전략적으로 매우 중요한 프로젝트를 사전 플랜 없이 진행하면 때로는 참단한 결과를 낳는다 '''플랜은 실현 가능성을 높여준다''' * 계획한 것은 실제로 일어나기 쉽다 * 플랜에 포함된 작업이 실제로 집행될 가능성이 높다 * 플랜에 들어 있지 않은 일은 햇빛을 보지 못할 가능성이 높다 '''플랜은''' * 부실하지 않아야 한다 * 통합적이어야 한다 * 업무와 일치해야 한다 '''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)하는 한 세트의 플랜 * 엔터프라이즈의 모든 데이터, 업무기능, 기술, 사람(데이터를 정보로 전환하고 접근하고 사용하는), 궁극적으로는 비즈니스를 위한 지식을 포함 엔터프라이즈 아키텍처의 구성 요소 attachment:ea_toolkit.jpg * 비즈니스 프레임워크 * 엔터프라이즈에 관한 핵심 지식을 수집하고 분석하기 위한 로드맵 제공 * 아키텍처의 방향을 이끌게 할 것임 * IT 프레임워크 * IT아키텍처와 아키텍처간의 관계에 대한 산출물을 생성하기 위한 로드맵 제공 * 기업의 목표 달성을 가능하게 함 * 이행 프레임워크 * 아키텍처 구현을 위한 핵심적인 영역을 다루는 베스트 프랙티스가 포함됨 ==== 자크만 프레임워크의 비교 ==== attachment:zachman.jpg attachment:zachman-poster1.pdf attachment:zachman-poster2.pdf || ||Data(what)||Function(How)||Network(whare)||People(Who)||Time(When)||Motivation(Why)|| ||Scope[[BR]](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[[BR]](Conceptual)||Semantic Model||Business Process Model||Business Logistic System||Work Flow Model||Member Schedule||Business Plan|| ||System Model[[BR]](Logical)||Logical Data Model||Application Architecture||Distributed System Architecture||Human Interface Architecture||Processing Structure||Business Rule Model|| ||Technology Model[[BR]](Physical)||Physical Data Model||System Design||Technology Architecture||Presentation Architecture||Control Structure||Rule Design|| ||Detailed Representations[[BR]](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플랜에 프로젝트/프로세스/인력에 초점을 둔 플랜이나 활동이 포함되지 않으면 아무리 최상의 아키텍처일지라도 결코 구현될 수 없다 ==== 핵심성공요소 ==== * 비즈니스가 가고자 하는 방향과 그에 대비되는 현재 상태에 대한 명확한 이해 * 가장 단순하고 효과적인 방법으로 모든 기본적인 사항을 아우르는 아키텍처 범위 * 범위가 잘 설정되어 비즈니스 지향적인 소수의 프로젝트로 아키텍처의 전환 * 각 프로젝트별 성과 지표의 개발 및 추적 * 아키텍처의 패키징과 마케팅 * 아키텍처/아키텍트를 지원하는 프로세스 ==== 툴킷 프로세스 흐름 ==== attachment:process.jpg