Microsoft PowerPoint - EA의 이해.ppt

Transcription

1 I. EA 의이해 -1-1 EA 의이해 시간에는 EA 에대한이해를돕기위하여 EA 에대한개괄적인내용을알아본다. 이번장의목적은 : 1. EA 의개념과효과에대하여간략히알아보고, 2. EA 의구성요소를정의하고각구성요소의역할을살펴본다. 3. EA 의도입방안에대하여주요고려요소등을살펴본다. 4. 국내외의 EA 사례와동향을살펴본다. 5. EA 추진전략및성공전략에대하여토의해본다. 이번장을통해 EA 의개념으로부터동향에이르기까지전반적인이해를높일수있을것이다 1

2 목 차 1-1. EA 개념과효과 1-2. EA 구성요소정의와역할 1-3. EA 도입방안 1-4. 국내외 EA 사례분석및동향 1-5. EA 추진전략및성공전략

3 1 1. EA 의개념과효과 -3-3 본장에서는 EA 의개념과효과 의題下에 1. EA 의태동과필연적인등장배경에대해알아보고 2. EA 와관련한다양한정의를중심으로 EA 를이해해본다. 3. 그리고, 한단계더나아가개념적으로 EA 를구성하는주요내용이무엇인지알아보며, 4. ITA 가태동하여 EA 로진화하는과정에서미연방정부를비롯하여산업계에서진행되었던 EA 의결과로서의효과에대하여알아본다 3

4 2002/2003 의미국 CIO 의관심 [Top 10 CIO Concerns for 2003] 1. Security 2. Enterprise Architecture 3. Defining and Demonstrating the business value of IT 4. Business Management of IT 5. Datawarehousing and business intelligence 6. Budget reduction/cost containment 7. Mobile/ wireless strategies and technology 8. Application integration and middleware 9. Various staffing/retention and middleware 10. IT service issues and decision EA 도입이시급함 [Federal 10 CIO Concerns for 2002] 1. Formulating or implementing an agency Enterprise Architecture 3. Implementing IT capital planning and investment across the agency ensuring Year 2000 operation 4. Measuring IT contribution to mission performance 5. Aligning IT and organizational goals 6. Providing effectiveness IT infrastructure and related service 7. Developing agency-wide IT accountability 8. Obtaining adeuate resource 9. Championing business process reengineering as precursor to IT decisions and implementing cross-government IT project -4-4 미국방성에서 1992 년경시작하여지속해온 ITA 활동과국방성의 ITA 활동이어느정도가시적인결과가드러나던 1996 년, ITMRA(IT Management Reform Act : Clinger- Cohen Act) 의제정무렵미재무성, 특허청, 농무성등의연방정부와민간기업들에서는 ITA 활동이활발하게진행되었으며, 그결과전반적인이해도가높아짐에따라 ITA/EA 는미국내 CIO 들의주요관심사의수위를차지하게되었으며, 예산집행의우선순위에 Rank 되었다. 4

5 세계 EA 활동현황 (2003 년기준 ) -5-5 IFEAD (Institute For EA Developments: 의조사결과에따르면, 2003 년기준으로한국은 EA 활동이가장많은국가순위 5 위에 Rank 되긴하였으나, 절대적인활동은실제미미한것으로드러났다. [IFEAD 의소개 ] IFEAD 는 EA 에대한 R&D 와전세계 EA 아키텍트들의정보교환을위해, Jaap Schekkerman 에의해 2001 년설립된비영리단체로서, EA 관련정보운영싸이트 ( 를운영하고있으며, 해당싸이트는 EA 와관련하여가장중요하고많은자료들을전세계인들이공유하고교환하는곳으로알려져있다. EA 에대한중요한정보가망라되어있으므로아키텍트들은물론이고 EA 를공부하고자하는모든이는반드시한번쯤들러봐야할싸이트라할수있다. 5

6 ITA/EA 등장배경 Department of Defense, USA 미래의전쟁 : 정보전, 통합전 인력과물자중심의소모적인전면전이아닌, 어떤정보를어떻게활용하느냐에따라승패가좌우되는정보전 정보우위를토대로정밀타격, 연동통합력, 과학적모의력을활용통합정보화능력필요 각군의전장기능을통합관리및운용하는것이승패의관건 통합 C4ISR/AF 체계필요 최고지휘관으로부터병사에이르기까지전장에대한동일한상황인식 각상황에맞는의사결정과행동실행 작전수행을위한정보수집, 융합, 지휘통제, 타격체계의표적공격등전과정을연동한자동화 -6-6 ITA 는, 1992 년걸프전이후미국방성 (DoD : Department of Defense) 에서시작되었으며, 걸프전에서드러난전쟁수행에서의문제점을해결할해결책을찾고자하였다. 이는, 기본적으로국방의수뇌부에서수립한전쟁수행전략이전장에있는병사의무기의작동과행동에정확히반영되어전쟁목적을가장효율적이며효과적으로달성하는데있으며, 전략과전술의변화에유연하게대처할수있는국방체계를수립하는데있었다. 미국방체계는, 정보체계및수많은무기체계의 IT 의존도가가장높은만큼, 정보기술 (Information Technology) 관련체계가국방의업무와전쟁수행전략체계와한치의어긋남이없이잘정렬되어야함은국방본래의목적달성을위하여는필수적인요소로인식된다. 6

7 ITA/EA 등장배경 연방정부법의제정, USA Paper Reduction Act of 1995 : 문서감축법 OMB(Office of Management and Budget : 예산관리처 ) 에서추진 클린턴정부승인 Information Technology Management Reform Act (1996 Clinger-Cohen Act) : 법령 Memorandum for the Heads of Executive Departments and Agencies ( OMB Circular A-130 ) : 회람 1990 년대초정보화예산의확충에의한정보화요구해결 1990 중반 ~ 정보화예산의편성과운영의효율성과합리성지향 EA 도입추진 -7-7 ITA 의제도화는 1996 년미연방정부가소위 IT 관리혁신법 ( IT Management Reform Act 또는 Clinger-Cohen Act) 를제정하므로써시작되었으며, 1997 년 OMB 의회람에의해 IT 관련예산과 ITA 의수행이연계됨에따라 ITA 활동은가속화되었다. 연방정부의주요목적은늘어나는정보화예산을잘정의된체계내에서효율적이고효과적으로수행하므로써 IT 분야의필요예산을적재적소에적절하게사용하는것이었다고볼수있다. 7

8 ITA/EA 등장배경 경영환경과정보기술환경 정보기술변화속도가기업의급격한비즈니스의변화속도에적응하지못하고있다. Business Process Change Technology Life Cycle yrs 7yrs Technology Competition Economics Policy Leadership yrs 3yrs Technology Competition Economics Value Chains Globalization mths 2yrs Source : Meta Group Elapsed time Digital Innovation Competition Externalization Value Chains Globalization -8-8 그러면, 이런실제적인현상이발발하게된원인은크게몇가지로대별될수있지만, 가장직접적인경영환경과정보기술환경에서찾아본다면, 뛰어난정책및전략을수립하고조직을이끌어나가는탁월한리더쉽에의존하며경쟁하던시기에는비즈니스프로세스의변화는기술의생명주기에비해상대적으로장시간을필요로하였다. 하지만기술적으로급격한발전을이루던 1990 년대에이르러경영영환경은경쟁이심화됨에따라가치사슬이빠르게변화하면서복잡도가증가하고세계화의추세에따라무한경쟁시대로돌입하므로써, 비즈니스프로세스의유효기간이급속히짧아졌다 년대에들어서서는비즈니스의정보기술의존도는더욱증대하여디지털혁명을도외시할수없는상황에이르렀으며, 비즈니스프로세스의유효기간은더욱짧아져기술의생명주기보다상대적으로급변하는상황에이르렀다. 이는정보기술의변화가기업의비즈니스변화를따라잡지못함으로써, 정보기술의도입과운용및폐기에대한새로운시각이필요하게된것이다. 즉, 동일한비즈니스를수행하는동안어떠한기술변화를어떻게받아들이는것이비용효율과운영효과및경쟁우위에도움이될것인가라는 투자효과 (ROI) 에대한관점에서, 이제는급변하는비즈니스를잘지원하기위하여정보기술의구조를어떻게형성해야하는가 (Architecture) 라는관점으로시각의이동을가져오게된것이다. 8

9 ITA/EA 등장배경 기존정보화의한계점 전사적차원의기준미비 - 정보화투자의재원조달및관리통제 -IT 투자의기업가치화 - 기술의일관되고체계적활용 기업전략과 IT 전략의연계미비 - 기업전략설정에 IT조직의미참여 - 과거회귀적평가에의존 - 프로젝트내에서의요소기술선정에치중 one project at a time 접근 -Ad-hoc 요청에대한수동적수행 Hyper competition 의시대 - 기업경쟁의가속화및경영환경의급변 - 현재의정보화패러다임으로는이에대응하기힘듬 [Boar, 1998] -9-9 이런관점에서, 기존의정보화의문제점을돌아보면, (1) 기업전략과 IT 전략의연계 (Alignment) 가미비하고, (2) 투자에서평가에이르는전사차원의각종기준이정리되지않고있으며, (3) 이런이유로 IT 예산은중, 장기적계획이나준거틀이없이통제되지않은상태에서독립된프로젝트단위로중복투자및불요불급한부분에지출되고있다는것이다. 이는결과적으로무한경쟁시대에서기업의생존전략의일환이되어야하는 IT 분야가기업의비즈니스전략과동떨어져예산만낭비하는것처럼보이는현상을낳았고, 바야흐로정보기술분야도경영환경의패러다임의변화에맞추어 Paradigm Shift 가필요한시기에도달했다는것을의미한다. 9

10 ITA/EA 등장배경 요약 정보의자산개념등장 정보관리의필요성대두 정보기술관리를아키텍처의필요성 : ITA + CIO (1996, 1997) 비즈니스환경과정보기술의급격한변화 비즈니스 Life-cycle < 정보기술의 Life-cycle 기존정보화의한계노출 정보기술의변화관리를위한방법론이필요 정보기술아키텍처의태동 복잡도증가 비즈니스환경의무한경쟁돌입으로인한업무의복잡도증가 정보기술의발달과비체계적인기술도입으로인한복잡도증가

11 EA 도입 동기 (METAGroup) In difficult economic times, technology cost reduction is the primary driver for architecture in many companies Business/IT alignment and business adaptability maintain strong influence (Source : METAGroup 2002) Reduce Technology Costs 38% Reduce Time to Market 5% Reduce Project/Service Redundancy 5% Business Adaptability 21% Reduce Decision Risks 5% Business/IT Alignment 21% Process Harmonization 5% 년 MetaGroup의조사에따르면, (1) 정보기술비용의절감이라는경제적인이유와 (2) 비즈니스와 IT의정렬및비즈니스의적응성이 (3) 아키텍처를도입하는주요동기로지목되고있다. 11

12 EA 도입 동기 ( 필요성인식수준 ) 세부아키텍처에대한도입필요성조사 Business and information architectures are becoming more relevant to companies 100% 75% 50% 2002년까지는 TA에대한인식수준이가장높으나, BA와 IA 역 25% 시지속적으로상승 (Source : METAGroup 2002) 0% Business Information Application Technology

13 EA 도입 동기 ( 필요성인식수준 ) Q: What makes existing, new, and packaged application come together successfully 응답자의 70% : EA 구축 EA 비즈니스혁신을이룰수있는하나의수단 개발에있어문제가될수있는것은시간의부족

14 EA 도입 배경 사례 1 : 미연방 시스템의중복개발로인한예산낭비 데이터공유의어려움 시스템통합의어려움 일관된표준및지침의부족으로 IT자원관리의비효율성 사례 2 : 한국범정부 (Ref. 정통부,2004) 정보화효과에대한의문제기 정부와민간모두정보화투자가증가하고있으나업무효율성제고및서비스개선효과미흡 조직전체의비전, 미션과연계미흡 CEO 와 IT 전문가와의의사소통도구부재 IT 중복투자방지및시스템간연계필요성대두 부처별경쟁적인정보시스템도입에의한중복투자및자원낭비 각종정보화사업을통해도입된이기종시스템간의연계필요성대두

15 EA 도입 목적 사례 1 : IFEAD (2004,7) 기술적복잡성해결 (19%) 변화를위한 Roadmap 수립 (16%) 비즈니스와 IT 청사진확보 (15%) 의사결정지원 (13%) IT 예산우선순위결정지원 (13%) IT 자산관리 (11%) 시스템개발지침 (8%) 인수합병도구 (5%) 사례 2 : 한국범정부 (Ref. 정통부,2004) 체계적 / 종합적정보화추진 국가전체차원에서정보화현황및문제점파악용이 정보화정책수립및투자결정효율성증진 예산절감및상호운용성제고 ITA 도입으로정보화예산절감 표준화된기술및업무절차적용으로상호운용성확보및시스템의기능향상

16 Enterprise 정의 Enterprise = 조직, 정보, 응용, 기술의유기적집합체 조직중점 논리적활동단위 Performed at Performed by Using Using Perform Roles in 업무기능수동절차자동절차 응용중점 Supports Reuiring Reuiring Built from 정보중점 정보 Accessed through 업무장소 Provide Facilities for 사용자부류 Who Access 응용환경 기술중점 Placed in 기술플랫폼 Placed on 기술환경 Comprise of Source : SBA 표준기반의아키텍처 (Standard-Based Architecture) 는크게 4 가지의요소가유기체적으로결합하여 Enterprise 를구성한다고설명한다. 16

17 Enterprise 정의 (LTG) Information Technology Service Application Interoperability, Portability Scalability,Reusable,Share Alignment Quality Service Service Service Service Application Service Application Application System Architecture Service Application Applicat ion Service Application Application Vertical Integration Service Application Atomic Function Common Function Atomic Function Business Functional Area Business Operation Atomic Function Inter-Business Operation Domain Architecture Atomic Function Business Functional Area Business Operation Atomic Function Intra-Business Operation Function Domain Enterprise Horizontal Integration Enterprise Enterprise-based Architecture Copyright (Lee, Tae-Gong)

18 Enterprise 정의 (EA 관점 ) 장점 : Enterprise View 및요소들관계잘나타냄단점 : Perspective 및 Scope 개념없음 Enterprise Sub- Enterprise (Business e Operation) ( 부기능 ) Sub- Enterprise (Business Operation 조직중점 논리적활동단위 Performed at Performed by Using Using Perform Roles in 업무기능 Supports 수동절차 Reuiring Reuiring 자동절차 응용중점 Built from 정보중점 정보 Accessed through 업무장소 Provide Facilities for 사용자그룹 Who Access 응용환경 Sub- Enterprise (Business Operation 기술중점 Placed in Comprise of 기술플랫폼 Placed on 기술환경 Sources : SBA

19 Enterprise 정의 (IS 관점 ) 기능 기능 (Process) 개발방법론 정보시스템 정보정보기술기술 Enterprise ( 기능 ) Sub- Enterprise ( 부기능 ) 기능기능 기능 기능 기능 기능 (Process) 기능 (Process) 기능 (Process) 개발방법론 개발방법론 개발방법론 정보시스템정보시스템정보시스템 정보기술정보정보기술기술 정보정보기술기술정보기술 정보기술 Sub- Enterprise ( 부정보기술 ) Sub- 기능 Enterprise ( 부기능 ) Sub- Enterprise ( 부정보기술 ) Enterprise ( 정보기술 ) Sub- Enterprise ( 부기능 ) 기능 기능 기능 기능 (Process) 기능 (Process)... 개발방법론 개발방법론 정보시스템 정보시스템 정보정보기술기술 정보기술 정보기술 Sub- Enterprise ( 부정보기술 ) Copyright (Lee, Tae-Gong) 정보시스템 (IS) 관점에서본 Enterprise 의정의는 Process 로표현되는엔터프라이즈의기능을적절한개발방법론으로정보시스템화하여기능에부합하는각종정보시스템의집합체로서 Enterprise 를설명한다. 19

20 Enterprise 정의 (ITA 관점 ) 전사적기반정렬 시스템기반정렬 성취되어진다 비즈니스전략계획 1 비젼 / 미션 3 목적 / 목표 1 전사적기반기능정렬 2 전사적기반자료정렬 3 전사적기반전략계획정렬 4 전사적기반응용정렬 5 전사적기반정보기술정렬 6 전사적기반시스템정렬 비젼 / 미션 5 목적 / 목표정보기술전략계획 자료 수동 l 자동 통하여접근한다 성취되어진다 요구한다 지원한다 사용하여 으로부터만들어진다 2 4 기능 논리적운영단위 응용 구성된다 (2) 기술참조모델서비스 구성된다 (3) 표준프로파일표준 성취되어진다 이행되어진다 6 수행되어진다 이행하는역할을수행한다 정보기술 접근한다 (1) 전사적아키텍쳐 위에위치한다 사용자그룹 업무장소 위하여시설을제공한다 장소내에위치한다 기술플랫폼 Copyright (Lee, Tae-Gong) 정보기술아키텍처 (ITA) 관점에서본 Enterprise 의정의는 Alignment( 정렬 ) & Traceability( 추적성 ) 에맞추어져있다. Enterprise 의비전 / 미션으로부터목적 / 목표등에부합하는기능이정의되고이의일부분으로정보기술의비전 / 미션이도출되어야하며이는적절한기술플랫폼위에서응용 / 서비스의형태로구축되어사용자가정의된업무장소에서사용하는구조이다. 6 가지형태의정렬로풀이된다. 20

21 Enterprise 정의 (Zachman) Perspective: 시각 ( 수직통합 : 정렬, 질 ) (What) 데이터 (How) 기능 Enterprise( 조직 ) (Where) Network (Who) 사람 (When) 시간 (Why) 동기 - 정렬 (Alignment) - 질 (Quality) - 유연성 (Flxibility) - 상호운용성 (Interoperability) - 통합 (Integration) - 이식성 (Portability) - 확장성 (Scalability) - 개발시간단축 (Time-to-Reduce) Planner Owner Builder Designer 상세설명정도 범위통합 Sliver Sliver Scope (Contextual) Enterprise Model (Conceptual) System Model (Logical) Technology Model (Physical) 비즈니스분야 View: 관점 ( 수평통합 ) 정보기술분야 Sub Contract Component (Out-of Context) Scope: 범위 ( 범위통합 ) EA : Descriptive Model 측면사실상표준 TRM+S/P 표현할수없음 년 IBM 의 Zachman 의 A framework for Information Systems Architecture 라는제목과 1992 년 Extending and formalizing the framework for Information Systems Architecture 라는제목의 2 편의논문에서정의한내용으로 Zachman Framework 으로알려져있으며 De-facto Standard 로볼수있다. 5W1H 형태의 View 와건축 (Architecture) 에서의 Analogy 로정의한 5 가지의 Perspective 로구성되어있으며 5x6=30 개의각 Cell 에 Workproducts 를정의한다. 그림에서 Silver 라고표현되는부분은두개이상의 Cell 이수직 (Perspective) 혹은수평 (View) 으로통합된경우를나타낸다. 21

22 Enterprise 정의 Zachman 의정의공통의미션이나목표를지원하는모든통합된비즈니스기능과자산들의집합 Spewak 의정의 고객과상품및서비스가존재하며이를유지하고지원하기위한내부프로세스가정립된 최소한의단위 TOGAF 의정의 공통의목표를가진조직의집합체 EA 의구축과정에서가장중요한판단기준은 Enterprise 의범위정의이며, 모든정보기술활동에서항상 Enterprise 의전체적인성과와목표가최우선임

23 Architecture 정의 성가족성당 (Gaudi) vs. Winchester House (Sarah L. Winchester) [Source : [Source : 아키텍처 (Architecture) 를이해하기좋은두가지예 (1) 성가족성당 (The Temple of the Sagrada Familia) 천재건축가안토니오가우디의설계를기반으로 1882 년건설하기시작한스페인바르셀로나소재의성당으로, 가우디에의해개념부터상세까지설계된설계도를기반으로현재까지 120 여년을건설하고있으며완성까지는약 200 년정도더건축해나가야한다고한다, 현재건축을맡고있는건축가들은가우디의설계도를기반으로현재의건축기술을접목하여건축하고있다. 건축가들에게는교훈적인건축으로손꼽힌다. (2) 윈체스터미스테리하우스 San Jose 의 Moore Park 근처소재의건축물로서, 현재의모습에대한전체적인설계도없이 Sarah L. Winchester 부인에의해 1884 년처음건축되기시작한건물로서 Sarah 부인이죽은해인 1922 년까지 38 년간건축이계속되었다. 160 개의방과 3 개의엘리베이터및 47 개의벽난로가있으며, 미스터리하우스로불릴만큼복잡한건축물로 아키텍처의중요성을실감하게하는건축물이다. 23

24 Architecture 정의 아키텍처는건축물설계도또는도시의지도와같이어떤대상의주요한특징을추상화하여묘사한것. 청사진 (Blueprint) 과속성 (Characteristics) 으로작성 전통적인건축공학의개념 정보화측면에서는현실세계의추상화측면에서객체지향적인개념 단순하게표현 의사소통이확대 변화된요구의효과적수용

25 Architecture 정의 Architecture Every enterprise has an architecture. Most organizations simply let their architecture grow and evolve uncontrolled. It is always undocumented [A. Perkins] 결과 High maintenance cost Poor uality software Lack of data sharing Difficult change management Long development cycle Non-interoperable applications Limited strategic information

26 Architecture 정의 Definition 1. An outline master plan. 2. A Blueprint, covering current and future systems and associated information 3. A definition of those elements which are least likely to change in the face of change in business priorities or technology facilities 4. A basis for future flexibility Characteristics 1. Cheap to develop and maintain 2. Expensive to omit 3. Layered 4. Demanding of uite specific skills and techniues in their formulation

27 Information Technology Architecture (ITA) 정의 OMB Memorandum M97-16 (1997) ITA는첫째, 조직의목적과목표를지원하는정보시스템의요구사항들을확보하고, 둘째, 정보시스템의보안, 중복, 상호운용의적절성을보증하며, 셋째, 새로운시스템을확보하고평가하기위한표준들의유지, 응용을지원하기위하여정보기술, 관리프로세스, 비즈니스프로세스들간의관계를체계화한것이다. Federal CIO Council 의정의 ITA는새로운정보기술을획득하고기존의정보기술을유지, 진화시키기위한통합된프레임워크를정보흐름과작업프로세스를통합하여조직전략과목표를달성하는수단이다. Information Technology Architecture = EA + TRM + SP (by USA OMB Memorandum 97.02)

28 Enterprise Architecture (EA) 정의 Zachman 의정의 (1996) EA는기업또는조직 (Enterprise) 의지식기반구조 (Knowledge Infrastructure) 를구성하는자원들을묘사하는산출물들의집합 (Set of Artifact) Federal CIO Council 의정의 (2001) 조직의목표및그목표를달성하기위해필요한정보 / 목표를수행하는데에필요한기술 / 변화하는기업목표에대응하기위해필요한환경을구현하는데필요한전략및과정을정의해둔전략적정보자산 (Strategic information asset base) Meta Group 의정의 (2002) EA는조직또는기업의주요비즈니스, 정보, 어플리케이션, 기술전략및이들요소가업무프로세스에미치는영향등을총괄적 (Holistic) 으로표현해놓은실체

29 Enterprise Architecture (EA) 정의 IFEAD 의정의 (2006) EA는 Enterprise를이루는모든다양한요소와그러한요소들의상호연관관계를이해하는것에관한것이다. 'Enterprise Architecture is about understanding all of the different elements that go to make up the enterprise and how those elements interrelate' Enterprise any collection of organizations that has a common set of goals/principles and/or single bottom line. An enterprise can be a whole corporation, a division of a corporation, a government organization, a single department, or a network of geographically distant organizations linked together by common objectives. Elements :. all the elements that enclose the areas of People, Processes, Business and Technology. Examples of elements are: strategies, business drivers, principles, stakeholders, units, locations, budgets, domains, functions, activities, processes, services, products, information, communications, applications, systems, infrastructure, etc EA 의개념은계속변화 Enterprise Architecture = (BA + )DA + AA + TA (by USA FEAF)

30 Enterprise Architecture (EA) 정의 - 기타 EA는조직의비즈니스, 정보, 응용시스템, 기술기반구조의정의와이러한요소의상호연계구조의총괄적표현 EA 조직이나아가야할방향과수행업무의절차에대한지침등을포함하는실체 구분 Zachman [1987] Rood [1994] Raines [1997] OMB [2000] Ohio [2000] 이태공, 박성범, 이헌중 [2001] 김성근 [2002] 정의 기업의지식기반구조를구성하는기본적이며설명적인산출물 (Artifact) 의집합 기업및조직의전사적환경의구성요소들이어떻게위치되고상호관계가있으며, 서로반응하는사항들을표현하는개념적프레임워크 비즈니스및관리프로세스와정보기술사이의흐름과바람직한관계의명시적묘사 비즈니스업무, 관리활동, 정보기술간의관계를현재와향후추진해나갈모습에대해명확히묘사해둔내용 정보기술자원의획득, 구현, 관리를체계적으로지원해주는표준 (standards), 정책 (policies), 지침 (guideline) 등의집합 조직에사용되는정보기술을활용한구조와체계들을총괄한것으로, 업무및관리프로세스와정보기술간의관계를표현한것 전략적의사결정에바탕이되는조직의구조적모습, 의사결정원칙, 참조모형의집합

31 EA 적용추이

32 EA 활용 1. Provide a basis for investment planning 2. Improve business processes 3. Determine and improve the interoperability needs of the enterprise 4. Identify and eliminate redundancy in business processes and IT capabilities 5. Lay groundwork for transition planning and system design 6. Select hardware and software consistent with the business needs

33 EA 주요내용 EA 는 Blueprint, Principle, Reference Model 등으로구성되며, 또한, 이들을바탕으로업무및정보기술환경이구현된다. Strategy Vision Mission 다양한환경의변화업무, IT, 조직, 정책 목표 or 효과 Alignment Integration Scalability Flexibility Interoperability Reduced Time-to Market Quality Seamlessness Adaptability User-Friendliness Usability Reusability Portability

34 EA 주요내용 : What is a blueprint? 사전적정의 : An overall model or prototype Classical Architectural Usage: A graphical depiction of the key design elements, measurements, and topology of a structure IT 청사진 (Blueprints) 은실제적으로아키텍처에서빠뜨릴수없는중요한요소이다. 청사진은다음과같은역할을한다 : (1) 구조물 (Structure) 의핵심설계요소를나타낸다. 핵심설계요소가포함된청사진을보면구조물의기능과형태를쉽게이해할수있다. (2) IT 청사진은구조물에대한주요척도를제공한다. 이러한척도의표현을보면건축규모를가늠할수있고, 건축에소요되는인적, 물적자원을평가할수있다. 기술적인해결책이반드시충족해야할제약조건들에대한내용도포함되어있다. (3) 구조물의토폴로지를나타낸다. 이러한토폴로지의표현은공간계획을할수있고, 건축에필요한작업을논리적인단위로나눌수있다. 34

35 External User DC3 3 DNS HTTPS 3 DNS CC3 Internet afdfgsfdgsdf VLAN X24 DC1 Outer Bastion BIG IP BIG IP VLAN rr ID & PW Outer Bastion Web Connector Backup PW & ID Webseal Webseal VLAN Webseal DC* SSR New Servers DC) SSR VLAN tt Existing Servers Webseal VLAN kk Webseal Webseal Webseal DC& SSR Webseal DC^ Inner Bastion DC@Inner Bastion Webseal Certificate Authority Primary CDAS / EVA Certificate Revocation List Publisher Primary Certificate Revocation CDAS / EVA List Publisher Backup DC% DC# DC^ CDAS / EVA HTTPS HTTPS CDAS / EVA Intranet Core Services Master Core Services Replica HTTPS Certificate Authority Backup Internal User EA 주요내용 : IT blueprints 구성요소 Structural VLANmm VLAN kk V LA N gg V LA N l l VL A N ss VLAN mm Models of Key Aspects of EA Temporal (Roadmaps) 3/03 2/04 3/05 6/2 Migration Planning SDLC Rollout Server Consolidation Vision Complete Complete Complete Complete Jan 1, 2002 Dec 31, /04 9/2 CMM Level 2 Blueprint Complete Complete 11/03 Data Center Consolidation 8/05 Complete Platform Migration Complete What & Where Heuristic (Decision Trees) When Oracle 9i Size >1000 Special Security Res? >10000 Trans/Sec Db2 UDB How & Why IT 의청사진 (Blueprints) 은일반빌딩의청사진과는다르다. IT 의청사진은단순한토폴로지이외에도시스템에대한다른 Views 를나타낸다. IT 는단순한엔지니어링그자체만은아니며, 프로세스와운영과관련한사항들을포함하고있기때문에이러한 Views 는의미가있다. IT 청사진은일반적으로공통의토폴로지의재사용, 프로세스또는휴리스틱 ( 의사결정 ) 에관한것이다. 35

36 EA 주요내용 : Principle ( 예 ) Connecticut State 의 Conceptual Architecture Principles Business Oriented Principle 1 : Information is valued as an enterprise asset, which must be shared to enhance and Business Oriented accelerate decision making Principle 6 : The enterprise architecture must reduce integration complexity to the greatest Principle 1 : extent Information possible. is valued as an enterprise asset, which must be shared to enhance and accelerate decision making Principle 6 : The enterprise architecture must reduce integration complexity to the greatest Technology extent possible. Oriented Principle 13 : Applications, systems and infrastructure will employ reusable components across Technology the Oriented enterprise, using the an n-tier model Principle 15 :The interface between separate application systems must be message-based; this Principle 13 : Applications, applies to both systems internal and and infrastructure external systems. will employ reusable components across the enterprise, using the an n-tier model Principle 15 :The interface between separate application systems must be message-based; this applies to both internal and external systems. Business Continuity Oriented Business Continuity Oriented Principle 19 : IT solutions will use industry-proven, mainstream technologies. Principle 19 : IT solutions will use industry-proven, mainstream technologies

37 EA 주요내용 : TRM ( 예 ) A Technical Reference Model (TRM) is a taxonomy that provides: A consistent set of service areas, interface categories, and relationships used to address interoperability and open-system issues Conceptual entities that establish a common vocabulary to better describe, compare, and contrast systems and components A basis (an aid) for the identification, comparison, and selection of existing and emerging standards and their relationships. User Environment Productivity Workstation Tools Analysis Tools Application Services Data Services App Dev Env Web App Services Document Mgmt. Databases Data Warehouse Data Mgmt. Integration Services TRM Organizes the Standards Profiles and any standards or technology forecast documents. Middleware Workflow Communications Interchange Service Area Common Services Domain Operating Distributed Application Network Security Systems Computing Servers Infrastructure Power Mgmt. Storage Mgmt. Voice Technologies TRM ( US Customs Service)

38 EA 주요내용 : TRM ( 예 ) Service Area Domain Common Services Operating Systems Sub-Domains Desktop/Client OS Mainframe OS Network OS App Server OS Each sub-domain contains the detailed information on the following topic areas Definitions Key Roles and Points of Contact Technical and Product Specifications Selection Criteria Benefits Technical Architecture Reference TRM ( US Customs Service)

39 EA 효과 EA 를이용하면조직을 30 배저렴한비용으로 10 배빠른속도로개선할수있다 그러나, ~ 의 (of) 모델이아니라, ~ 을위한 (for) 모델을구축하고, ~ 때문에 (because) 가아니라, ~ 을하기위하여 (in order to) 모델을구축하라 By John Zachman

40 EA 효과 : 미연방정부 (GAO) Lower costs Enhanced productivity Improved management Greater interoperability

41 EA 효과 : 미연방정부 ( 농무성 ) 종류절약유형예산절감 ( 추정치 ) Brio Tech. S/W 전사적구매현재까지 $470K Novell S/W Multi-agency BPA $50K Lotus S/W 산림청 IBM 계약을기초로전사적라이센스로확장 조달가격 10% 이하 Crunchy Tech. S/W 전사적구매및 3 년 BPA $1.4M... * 농무성 EA 프로젝트는초기단계를마친상태

42 EA 효과 : Ohio 주 (1) 오하이오주 : 산업재해보상업무 요율산정 : 1,030 개의실체 2년반정도운영해오고있음 보상비지불시스템 : 720 개실체 ( 그중 470개재사용된것임 ) 운영중 보상비청구시스템 :230 개실체 ( 그중 220개재사용된것임 ) 운영중 결과 : 4년간의운영에서DB 오류 0건, 유지보수에 40시간미만소요 지금개발중인시스템 : Health Provider Mgmt. 415 개 (255개재사용 ) 한실체당총비용 : $25,000 Legacy 자료 cleansing 작업, 자료전환, legacy 시스템과의인터페이스비용포함 비용절감총액 : 945 ( 재사용된실체수 ) * $25,000 = $23,625,

43 EA 효과 : Ohio 주 (2) 최근의패키지구현비용자료 : $50,000/ 실체 ( 잠정치 ) 자료 cleansing, 자료전환, legacy와의인터페이스비용미포함, 일부중복저장, 총가용기능의 60% 만적용최근의시스템독자개발비용자료 : $100,000 ~ $150,000/ 실체 전형적 legacy 시스템개발비용의비교 독자개발 : 2,395 실체 * $140,000 = $335,300,000 패키지 : 2,395 실체 * $ 50,000 = $119,750,000 EA : ( ) 실체 * $ 25,000 = $36,000,000 코드재사용효과 현재운용중인세시스템에서 6,128개의 action blocks, 재사용율 = 7.0 기존애플리케이션개발 : 42,896개의 subroutines 의코딩, 테스팅, 유지 원인 : data model의 granularity( 입도 ) 와정확성에기인. 즉, 많은프로세스가동일데이터를사용함

44 EA 효과 : Ohio 주 (3) 오하이오주 타주 * 애플리케이션 산재보상 아동복지 사용도구 IEF/CoolGen IEF/CoolGen 사용방법론 Architecture 기반 전형적 실체수 소요기간 2.5년 12 년 개발비용 - $42Mil. 실체별비용 $25,000 $140,000 * 2 개의주사업자및 1 개하청업체가수행 ; 향후 3 년여의수정 / 보완작업소요됨

45 EA 효과 : 기타사례 대표적사례효과 재무적관점 프로세스관점 고객관점 학습과혁신관점 미교육성미금융서비스업체오하이오주 National 항공사 Zuellig Pharma Allegheny Energy KLM항공사 Document Management System 의중복투자제거 국립보건건원의 e-grants 를 Online grants 시스템으로활용 시스템개발및유지비용의절감효과 코드재사용을통한유지비용의절감효과 신속한대응력확보 고객의정보요청수요를 1/10 로감소 대고객이미지향상 부서간의협업기능확대 외부환경과의유기적접근이가능 IT 도입관련의사결정학습도구로활용

46 EA 효과 : EA 도입에따른 IT 비용절감효과 (CMM L3) 최근미국 CIO 조사결과 : 사용자 1 인당정보화비용은조직규모와아키텍처의존재여부에따라달라짐. 아키텍처와표준은 IT 비용의효율적활용에효과적이다. No Architected? Yes $22,534 $30,386 $6,185 $9,209 Small Org. Size Architectural Approach Benefits Results of META Group CIO Survey Jan Large Architecture planning and standards compliance reduce IT budget expenses by an average of 30%

47 1 2. EA 구성요소정의와역할

48 EA 구성요소 정의 EA Principles EA 를개발하고사용, 유지, 관리하는원칙 EA Framework 시각 (View) 과관점 (Perspective) 으로엔터프라이즈를분석하는체계, 자산이나 Work Product 을제시함 Architecture Domains EA 를구성하는각아키텍처의유형으로정의 ( 예 : BA, DA, AA, TA) Reference Model 주어진문제를해결하기위한각아키텍처도메인별분류체계를정의 ( 예 : PRM, BRM, DRM, SRM, TRM) Migration Plans 현재아키텍처에서미래아키텍처로전환하기위한일정및자원계획등을제시함. EA Governance EA 의유지 / 개선을위한제도적인기반 EA 정책 / 조직 / 프로세스 / 시스템 / 문서등으로이루어지며타구성요소의유지관리를담당함. EAMS with Repository EA 의유지관리효율성을극대화하고아키텍처정보의공유와변경관리를수행하기위한시스템

49 EA 구성요소별역할 EA Principles EA 를개발하고, 사용, 유지관리하는원칙 FEAF Principles (Ver 1.1, 1999) 1. Standards: Establish Federal interoperability standards. Rationale: The Federal Government has not achieved data, applications, and technology interoperability. Connectivity is often the last reuirement addressed. It is difficult to control lifecycle costs and schedules and improve performance, take advantage of commercial items and technology, and maintain and evolve systems. In addition, the Federal Government reuires connectivity between multiple processing environments and applications operating on a variety of technology platforms Implications: The Federal Government should adopt open system standards in which the interrelationships of components are fully defined by interface standards available to the public and maintained by group consensus. The Federal Government should adopt, acuire, and integrate those components that conform to specification. An open system architecture is the goal; however, initially only partially open systems will be attained. This principle could lead to use of JAVA and future JAVA-like protocols, which give a high priority to platform independence. The Federal Government should be able to ensure compliance with these standards. 2. Investments: Coordinate technology investments with the Federal business and architecture 7. Proven Technologies: Select and implement proven market technologies. 8. Privacy: Comply with the Privacy Act of

50 EA 구성요소별역할 EA Principles EA 를개발하고, 사용, 유지관리하는원칙 -Connecticut State 의 Conceptual Architecture Principles Business Oriented Principle 1 : Information is valued as an enterprise asset, which must be shared to enhance and accelerate decision making Principle 6 : The enterprise architecture must reduce integration complexity to the greatest extent possible. Technology Oriented Principle 13 : Applications, systems and infrastructure will employ reusable components across the enterprise, using the an n-tier model Principle 15 :The interface between separate application systems must be message-based; this applies to both internal and external systems. Business Continuity Oriented Principle 19 : IT solutions will use industry-proven, mainstream technologies

51 EA 구성요소별역할 EA Framework EA 의표현방식과운영방식에대한전체적인사고의체계 엔터프라이즈의복잡한정보를분류하고조직화하기위한논리적인틀또는구조 EA 활동에서얻어지는산출물을분류하고조직화하기위한틀. EA 를표현및구현, 운영하기위한모델과절차, 산출물을개념적으로정의한것 시각 (View) 과관점 (Perspective) 으로엔터프라이즈를분석하는체계

52 EA 구성요소별역할 EA Framework EA 의모든자원을표현하기위하여정보의범위 (View) 와정보의깊이 (Perspective) 로분류한체계로각셀을채우는기법을정의 각셀은전후좌우의셀과연관성을갖고있으므로, 셀간의추적성이확보되어야함 각셀은 EA 를구성하기위한 Work Products 및 EA 의구체적인산출물을포함한다. Perspective 와 View Perspective View 정보의깊이를기준으로, 직접적인이해당사자의관점으로분류 예 : 계획수립자, 업무수행자 ( 또는분석자 ), 설계자, 개발자등으로분류 정보의범위를기준으로, 다양한시각으로분류 예 : 비니지스, 애플리케이션, 데이터, 기술등으로분류 (FEAF 기준 ) 예 : Zachman Framework, Index Model, FEAF, TEAF 등

53 EA 구성요소별역할 EA Framework 조직 OMB (OMB, 2000) 미연방정부 (CIO Council,1998) 가트너그룹 (Boar, 1999) 미국방성 (US, DoD) Open Group (Open Group, 2002) KLM 항공 ( Hoogerborst, 2002 ) 엔터프라이즈아키텍처구성요소 업무아키텍처, 정보아키텍처, 응용아키텍처, 데이터아키텍처, 기술기반아키텍처 업무아키텍처, 응용아키텍처, 데이터아키텍처, 기술기반아키텍처 수행지침아키텍처, 조직아키텍처, 응용아키텍처, 데이터아키텍처, 서비스아키텍처, 설비아키텍처, 플랫폼아키텍처, 네트워크아키텍처 운영아키텍처, 시스템아키텍처, 기술아키텍처 업무아키텍처, 기술아키텍처 Commercial Architecture, Organizational Architecture, Technical Architecture 각주체별로구성요소에대한서로다른 View 가존재 이러한현상은조직의성격및아키텍처도입의목적등에따라다르다

54 EA 프레임워크및방법론의진화 JTA references DoD AF 2003 ISO/IEC influenced TAFIM influenced supported by adopted by DoD TRM references TOGAF 1995 references influenced C4ISR 1999 influenced Supported by TOGAF 2002 CIMOSA PERA Zachman 1987 influenced influenced influenced TEAF 2000 Zachman 2003 SAGA EAP 1992 influenced influenced FEAF 1999 supported by influenced FEAF 2003 influenced TISAF 1997 influenced influenced E2AF 2003 UVA Model 1994 influenced IAF v influenced IAF v3 EE 2001 XAF

55 EA 프레임워크및방법론의비교 아키텍처활용측면 Enterprise Architecture Business Architecture 를비롯하여, Information (Data) 비즈니스와 IT 의효과적조율을목표로한다. 구현및관리를위한하나의전략적자원으로인식 IT Architecture IT Infrastructure 가주요사항 Business Architecture (Model of Statement) 는 IT(IS) Architecture 구현을위한기초재료 정보시스템또는기반환경구현을전제로하는가이드라인 주요구성유형측면 Process- Centric 아키텍처를구축하기위한프로세스를제시 Framework Centric 아키텍처묘사에있어필요한 View Point 를제시 View point 에따라실질적으로구현하는 work product 를제시 경우에따라개념적인프로세스 (Method) 를제시

56 EA 프레임워크및방법론의비교 프로세스중심 ITA [ 활용 ] EA 1 2 EAP PGFEA TADP TAFIM TOGAF 7 IAF META TOGAF 8 [ 구성요소 ] 3 4 C4ISR AF TEAF FEAF 프레임워크중심 Index Framework ZISAF ZEAF

57 EA 프레임워크 DATA What? FUNCTION How? NETWORK Where? PEOPLE Who? TIME When? MOTIVATION Why? EA SCOPE (Planner) List of things List of process List of locations List of organization and agents List of business events List of business goals, strategies ENTERPRSISE MODEL (Owner) Semantic model Business process models Business logistics system Workflow model Master schedule Business plan Framework SYSTEM MODEL (Designer) TECHNOLOGY MODEL (Builder) Logical Data model Physical Data model Application architecture System design Distributed system architecture Technology architecture Human interface architecture Presentation architecture Processing structure Control structure Business rule model Rule design Model COMPONENTS (Vendor) Data definition Program Network architecture Security architecture Tuning Definition Rule specification Functional System (Product) Data Function Network Organization Schedule Strategy

58 EA 프레임워크예 Zachman ENTERPRISE ARCHITECTURE - A FRAMEWORK TM DATA What FUNCTION How NETWORK Where PEOPLE Who When MOTIVATION Why TIME SCOPE List of Things Important to the Business (CONTEXTUAL) List of Processes the Business Performs List of Locations in which the Business Operates List of Organizations Important to the Business List of Events Significant to the Business List of Business Goals/Strat SCOPE (CONTEXTUAL) Planner ENTITY = Class of Business Thing Function = Class of Business Process Node = Major Business Location People = Major Organizations Time = Major Business Event Ends/Means=Major Bus. Goal/ Critical Success Factor Planner ENTERPRISE MODEL (CONCEPTUAL) e.g. Semantic Model e.g. Business Process Model e.g. Business Logistics System e.g. Work Flow Model e.g. Master Schedule e.g. Business Plan ENTERPRISE MODEL (CONCEPTUAL) Owner Ent = Business Entity Reln = Business Relationship Proc. = Business Process I/O = Business Resources Node = Business Location Link = Business Linkage People = Organization Unit Work = Work Product Time = Business Event Cycle = Business Cycle End = Business Objective Means = Business Strategy Owner SYSTEM MODEL (LOGICAL) e.g. Logical Data Model e.g. Application Architecture e.g. Distributed System Architecture e.g. Human Interface Architecture e.g. Processing Structure e.g., Business Rule Model SYSTEM MODEL (LOGICAL) Designer Ent = Data Entity Reln = Data Relationship Proc.= Application Function I/O = User Views Node = I/S Function (Processor, Storage, etc) Link = Line Characteristics People = Role Work = Deliverable Time = System Event Cycle = Processing Cycle End = Structural Assertion Means =Action Assertion Designer TECHNOLOGY MODEL (PHYSICAL) e.g. Physical Data Model e.g. System Design e.g. Technology Architecture e.g. Presentation Architecture e.g. Control Structure e.g. Rule Design TECHNOLOGY MODEL (PHYSICAL) Builder Ent = Segment/Table/etc. Reln = Pointer/Key/etc. Proc.= Computer Function I/O = Data Elements/Sets Node = Hardware/System Software Link = Line Specifications People = User Work = Screen Format Time = Execute Cycle = Component Cycle End = Condition Means = Action Builder DETAILED REPRESEN- TATIONS (OUT-OF- CONTEXT) e.g. Data Definition e.g. Program e.g. Network Architecture e.g. Security Architecture e.g. Timing Definition e.g. Rule Specification DETAILED REPRESEN- TATIONS (OUT-OF CONTEXT) Ent = Field Reln = Address Proc.= Language Stmt I/O = Control Block Node = Addresses Link = Protocols People = Identity Work = Job Time = Interrupt Cycle = Machine Cycle End = Sub-condition Means = Step Sub- Contractor Sub- Contractor FUNCTIONING ENTERPRISE e.g. DATA e.g. FUNCTION e.g. NETWORK e.g. ORGANIZATION e.g. SCHEDULE e.g. STRATEGY FUNCTIONING ENTERPRISE John A. Zachman, Zachman International (810)

59 EA 프레임워크예 Zachman (Planner --- Sub-contractor) views perspectives Planner Planner Owner Owner Designer Designer Builder Builder Sub Sub contractor contractor Data View Function View Network View People View Time View Motivation View The perspective focusing on strategic plans, enterprise-level processes, key information and infrastructure important to the enterprise, and the structure of the organization and its operating locations The perspective focusing on conceptual-level models of business processes, information, business logistics, and IT infrastructure. The perspective focusing on the logical business process design, logical information model, component and application design, and system distribution and deployment approach The perspective considering the constraints of tools, technology, and material. The builder must translate the designer s specifications into plans for physical Implementation. The builder also focuses on integration and test

60 EA 프레임워크예 FEAF FEAF Architecture Framework

61 EA 프레임워크예 공공부문 ( 한국전산원 )

62 EA 프레임워크 비교 Infrastructure Data Application Organization Planner s View Objectives/Scope Owner s View Enterprise Model Designer s View Information Systems Model Builder s View Technology Model Subcontractor s View Detailed Specification Inventory Principle Model Standards Data Architecture Index Applications Architecture FEAF Technology Architecture Executive Direction Organization Architecture Application Architecture Data Architecture Service Layer Facilities Layer Platform Network Planner Owner Designer Builder Values Principle Process Standard Buy List Functional View Gartner Information View Organizational View TEAF Infrastructure View 프레임워크마다 Focus 와 Goal 이상이하므로 View 와 Perspective 의요소는차이가있음

63 EA 프레임워크종류비교 비교항목 Zachman FEAF TEAF C4ISR 한국전산원 매트릭스 ( 모델 ) 프로세스 ( 절차 ) 5x6 5x3 (Zachman) - 간략언급 5x4 3 Arch. 4x4 있음 (Activity) 있음 있음 산출물개념분류있음있음개념 지원도구 - - 있음있음개발중 TRM/SP - 적용범위 (Enterprise) TRM, 상호운용성모델 범용미국공공분야 TRM TAFIM,ITSG 개발중 미국재무부및산하기관 미국국방부및산하기관 범용

64 EA 프레임워크종류비교 ZEAF TOGAF TAFIM C4ISR AF FEAF (PGFEA) TEAF View Or Arch. Data Function Network People Time Motivation Technical Architecture Views (engineering views, operations views Acuires views) Business Architecture Views Intelligence Systems Command And Control Systems Combat Support Systems Operational View Systems View Technical View Business (People) Architecture Data Architecture Application Architecture Technology Architecture Organization al View Information View Functional View Infrastructure View 비고 EA ITA ITA EA EA EA IT-Specific Biz-Specific

65 EA 구성요소별역할 아키텍처도메인 (FEAF 기준 ) Business Architecture 기업의사업모델을토대로아키텍처모델을정의한것, 조직과프로세스를포함 비전, 미션, 목표의정의 비즈니스모델및구조정의 비즈니스모델을위한기능과프로세스의정의 Data Architecture 데이터단위를정의한것, 데이터표준과데이터통합방안을포함 기능, 프로세스, 응용에활용할데이터및정보의식별 논리및물리데이터모델의정의 사용자에대한데이터및정보관리체제 ( 표준 / 원칙 ) 정의

66 EA 구성요소별역할 아키텍처도메인 (FEAF 기준 ) Application Architecture 응용의단위를정의한것, API 와통합방안을포함할수도있음 기업전략에대한업무구조의매핑 프로그램차원의기능구조정의 응용과응용사이의의존성과상관관계정의 응용과정보, 응용과전략, 응용과기술의연계평가 Technical Architecture 기술컴포넌트분류체계, 기술참조모델, 하드웨어아키텍처, 시스템소프트웨어 엔터프라이즈전략과비즈니스환경에적합한기술요소의식별 비즈니스특성에따른기술요소의배치 기술이나제품의생명주기에의해분석할수있도록생명주기정보식별 응용, 정보및기술요소와의관계를정의

67 EA 구성요소별역할 Reference Model 주어진문제를해결하기위한각아키텍처도메인별분류체계를정의 Best Practices (FEAF) PRM (Performance Reference Model) BRM (Business Reference Model) SRM (Service Reference Model) DRM (Data Reference Model) TRM (Technical Reference Model)

68 EA Reference Model (FEAF) FEAF Reference Model View

69 EA Reference Model (FEAF) FEAF Reference Model Structure ( ) PRM Structure SRM Structure DRM Structure BRM Structure TRM Structure

70 EA Reference Model FEA PRM ( 예 ) PRM (Performance Reference Model) 성과측정을위한프레임워크 목적 전략적이면서일상적인결정을개선하기위하여향상된성과정보를생성하도록돕는다. 정렬 (alignment) 을개선하고, 출력물에대한입력물의기여를보다명료하게하여, 원하는결과에대한분명한 시선 (line of sight) 을확보한다. 이전의조직적구조와범위를확장하는성과개선기회를식별한다. 입력물과출력물의인과관계를명확히표현하도록설계된다. PRM Structure

71 EA Reference Model FEA PRM ( 예 ) PRM Framework

72 EA Reference Model FEA PRM ( 예 ) FEA BRM V

73 EA Reference Model FEA PRM ( 예 ) FEAF DRM Approach

74 EA Reference Model FEA PRM ( 예 ) FEAF TRM Overview

75 EA Reference Model USCS TRM ( 예 ) Technical Reference Model (TRM) 은일종의기술분류체계로다음을제공한다 : 상호운용성과오픈시스템이슈를해결하기위하여 서비스영역, 인터페이스범주 및 관계 로이루어지는일관된집합 시스템과구성요소를더욱잘기술하고, 비교하며대비하는공통의단어를확립하는개념엔티티 기존혹은새로운표준과그들의관계를 식별 하고 비교 하며 선별 하기위한기반 User Environment Workstation Productivity Analysis Tools Tools Application Services Data Services App Dev Env Web App Services Document Mgmt. Databases Data Warehouse Data Mgmt. Integration Services TRM Organizes the Standards Profiles and any standards or technology forecast documents. Middleware Workflow Communications Interchange Service Area Common Services Domain Operating Distributed Application Network Security Systems Computing Servers Infrastructure Power Mgmt. Storage Mgmt. Voice Technologies TRM ( US Customs Service)

76 EA Reference Model USCS TRM ( 예 ) Service Area Domain Common Services Operating Systems Sub-Domains Desktop/Client OS Mainframe OS Network OS App Server OS Each sub-domain contains the detailed information on the following topic areas Definitions Key Roles and Points of Contact Technical and Product Specifications Selection Criteria Benefits Technical Architecture Reference TRM ( US Customs Service)

77 EA 구성요소별역할 EA Governance 정의 구현된 EA를유지하고개선하기위한제도적기반목적 EA 활동을개발하고관리 EA의진행상황을통제하고모니터링 IT 프로젝트가 EA의기본원칙과정책을준수하도록하기위한것 EA로정의된내용을지키도록확인하고통제하기위한조직과프로세스로구성 EA 조직과프로세스 IT Governance 체계의일부 EA 에의하여 IT 의사결정과업무수행이이루어지도록 IT 프로세스에 EA 요건을반영

78 EA Governance 5 대핵심 IT 거버넌스의사결정 EA 구성요소별역할 EA Governance 비즈니스전략 IT 원칙 (IT 의비즈니스역할명확화 ) IT 아키텍처 ( 통합과표준요구사항정의 ) IT 인프라스트럭처 ( 공유 / 가능서비스결정 ) 응용시스템요구도 ( 구매 / 자체개발어플리케이션의현업요구명세 ) IT 투자및우선순위 ( 어떤발의에투자할것인지선택과비용을얼마나사용할것인지결정 ) 이들은모두상호연계된의사결정 EA 는이들의사결정을모두포함 ( Source : MIT Sloan School Center for Information Systems Research, 2003 ) IT 원칙 (Principles) 의사결정 비즈니스에있어서 IT 가가지는역할과가치설정 Clarifying the business role of IT - how IT is used in and contributes to business IT 아키텍처 (Architecture) 의사결정 IT 통합과표준을위한제반아키텍처정책선택 Organizing logic for data, application, and infrastructure captured in a set of policies, relationships, and technical choices to achieve desired business and technical integration and standardization. IT 인프라스트럭처 (Infrastructure) 의사결정 공유혹은인에이블링 IT 서비스결정 Centrally coordinated, shared IT services that provide thefoundation for the enterprise s IT capability. 응용시스템요구도 (Business Application Needs) 의사결정 비즈니스의응용시스템요구도파악 Specifying the business need for purchased or internally developed IT applications IT 투자및우선순위 (Investment and Prioritization) 의사결정 IT 투자지원대상, 범위, 규모, 순서결정 Choosing which IT initiative to fund and how much to spend 78

79 EA Governance 설계틀 [Sources : 국민대, 전성현교수 ]

80 EA Governance 지침 [Sources : 국민대, 전성현교수 ]

81 EA Governance 미국개별부처의 EA 관리체계 ( 예 ) Agency Head 업무부서 업무담당자 EA Executive Steering Committee CIO Capital Investment Council Staff Organization 업무전문가 Quality Assurance Technical Review Committee EA PMO Chief Architect Evaluation 평가 Configuration Management 형상관리 Risk Management 위험관리 Architecture Core Team EA 고유조직 미연방정부 EA 가이드

82 EA Governance 한국정부의 EA 관리체계 ( 예 ) 의사결정권자해양수산부장관 차관 ITA 추진단 ( 장 ) 업무지원반 정보화담당관실 기획예산담당관실 수산어업 항만, 물류 ITA 추진반 ( 전략정보화계 ) 정보지원반 ( 관리운영계 ) 기획예산관리 해양안전 자문위원회 - 정보시스템 - 기술표준 환경과학등 사업자 ITA 추진단 : 정통부, 전산원, 행자부등 자문위원회 : 정통부, 전산원,ITA 전문가

83 EA 구성요소별역할 EAMS 목적 EA 의유지관리효율성을극대화하고아키텍처정보의공유와변경관리를수행하기위해구축하는시스템 형태 전사아키텍처모델링기능을지원하는케이스툴, EA 리포지터리, EA 포탈등으로구성 범위 최소한 : 정보저장소의역할수행하며, 아키텍처에대한정보보관및검색, 변경등의기능 확대 : 아키텍처에의해운용되는프로세스의자동화즉, 정보시스템기획, 자산관리, 인력관리등의범주까지를포함 전사 ITMS 를지원하며, IT 지식포탈의형태로서방법론, 표준, 지침, 산출물등의공유까지포함

84 EA 구성요소별역할 EAMS : 도구구성 ( 예 ) Framework Framework Generator Meta Modeler ( 틀정의, 설계 ) ( 활용 ) 통합 Repository Enterprise Repository Viewer Modeler( 입력기 ) Modeling Queries Forms XML Generator Data Import Scripting Engine ( 입력 ) Object Impact Result Framework Meta Model Biz Arch. AP Arch. Tech Arch. D/D Master Data Rule Query Admin Security Q. 민간기업체에서많은사례가존재하는지? 84

85 EA 구성요소별역할 EAMS ( 예 ) EAMS : Architecture Framework Q. 민간기업체에서많은사례가존재하는지? 85

86 EA 구성요소별역할 EAMS ( 예 ) EAMS : Architecture Framework (Owner s perspective) Q. 민간기업체에서많은사례가존재하는지? 86

87 EA 구성요소별역할 EAMS ( 예 ) EAMS : Alignment & Traceability Q. 민간기업체에서많은사례가존재하는지? 87

88 1 3. EA 도입방안

89 EA 도입방안 EAP (Enterprise Architecture Planning) 아키텍처기반의정보계획수립노력 Enterprise Modeling 아키텍처기반의전사적모델링 IT 자산관리 아키텍처기반의 IT자산의묘사및관리 Enterprise Modeling EAP ISP ( 정보계획수립 ) BAA ( 업무영역분석 ) BSD ( 업무시스템설계 ) IT 자산관리 Construction ( 구축 ) 정보공학 (Information Engineering)

90 EA 도입방안 EA 작성절차 준비단계 개념적업무 ( 업무아키텍처 ) 를분석하고방향성을정립함 목적 (Mission) 과 원칙 (Principles) 대상 (Domain) 과 범위 (Level) EA 거버넌스체계및 EA 프레임워크의확정 구축단계 현행아키텍처구축 상세현행업무아키텍처및데이터아키텍처분석을수행함 상세현행응용아키텍처및기술아키텍처분석을수행함 목표아키텍처구축 차이분석을통한차기아키텍처구축 적용, 유지보수, 통제감독단계 실제프로젝트에적용하고, 참조모델을갱신하며, 진화작업을수행함

91 EAP 개념 Steven H. Spewak 의 EAP 정의 EAP 는업무지원을함에있어정보이용을위하여아키텍쳐를정의하고 이러한아키텍쳐를구현 / 구축하기위한계획을수립하는프로세스이다. EAP (Enterprise Architecture Planning) is the process of defining architectures for the use of information in support of the business and the plan for implementation those architectures. Spewak, Steven H. Enterprise Architecture Planning. New York: John Wiley & Sons,

92 EAP 개념 정의및특성 EA의개념을조직에도입하는가장초창기방법중의하나 정보시스템의전사적계획수립뿐만아니라정보기술아키텍처의계획까지포함하는노력 정보기반기술구조를보다중점적으로반영 한계점 정보기술아키텍처의구현만을중시하고기타다른아키텍처들의구현및활용에소홀함 EA활용이제한적이어서 Silo 응용시스템의추가개발 원칙들이일반적성격 EAP의결과물의지속적활용도가낮아전략적인자산으로활용도가낮음 Spewak s EAP 등이대표적

93 EAP 개념 (Framework)

94 EAP Methodology Level of EAP ( 7 Phases, 4 Layers) Rule Principles Layer 1 AS-IS Business Modeling Current Systems & Technology Layer 2 TO-BE Data Architecture Applications Architecture Technology Architecture Layer 3 How to Get There SEQUENCING & PRIORITIZATION / MIGRATION STRATEGY / IMPLEMENTATION PLAN Layer 4 Source : Steven H. Spewak

95 EAP Methodology Layer 1 Planning Initiation 범위및목적, 성공요소, 수용기준등추출 EAP 접근방법, 수행팀멤버선택 사용할 Tool 선정및준비 상세작업계획 확인및결정 PRINCIPLES CURRENT SYSTEMS BUSINESS & MODEL TECHNOLOGY DATA APPLICATIONS TECHNOLOGY ARCHITECTURE ARCHITECTURE ARCHITECTURE SEQUENCING & PRIORITIZATION - MIGRATION STRATEGY - IMPLEMENTATION PLAN Principles IT 관리의주요원칙설정과승인 원칙의조건 Understandable, robust, complete, consistent, stable PRINCIPLES BUSINESS CURRENT SYS& MODEL TECHNOLOGY DATA APPLICATIONS TECHNOLOGY ARCHITECTURE ARCHITECTURE ARCHITECTURE SEQUENCING & PRIORITIZATION - MIGRATION STRATEGY - IMPLEMENTATION PLAN

96 EAP Methodology Layer 2 Business Modeling 업무프로세스의활동과지원에사용되는업무기능및정보에대한지식기반의수집및편집 다양한업무기능의조사 / 정의 단위조직과업무수행위치의형태 엔터프라이즈상세조사 (CSF/CIR 포함 ) PRINCIPLES BUSINESS CURRENT SYS& MODEL TECHNOLOGY DATA APPLICATIONS TECHNOLOGY ARCHITECTURE ARCHITECTURE ARCHITECTURE SEQUENCING & PRIORITIZATION - MIGRATION STRATEGY - IMPLEMENTATION PLAN 현재사용중인정보 Activities 중심의파악 Current Systems & Technology 현재의응용목록, 주요입 / 출력정보와파일및기술플랫폼의정의 Information Resources Catalog (IRC) 작성 PRINCIPLES BUSINESS CURRENT SYS& MODEL TECHNOLOGY DATA APPLICATIONS TECHNOLOGY ARCHITECTURE ARCHITECTURE ARCHITECTURE SEQUENCING & PRIORITIZATION - MIGRATION STRATEGY - IMPLEMENTATION PLAN 시스템기능개요, 담당자, 필요자료획득처및제공처, 보유자료의영역, 시스템및자료규모, 사용빈도, 사용자 ( 요원, 조직, 위치 ) 정보, 비용정보, 이슈와기회등의내용을포함 아키텍처와계획을위한 Baseline

97 EAP Methodology Layer 3 Data Architecture 업무를지원하는데필요한주요데이터종류의정의 업무관련데이터정의, 특성, 관계등 Activities-to-Entities Matrix ( CRUD 매트릭스 ) PRINCIPLES BUSINESS CURRENT SYS& MODEL TECHNOLOGY DATA APPLICATIONS TECHNOLOGY ARCHITECTURE ARCHITECTURE ARCHITECTURE SEQUENCING & PRIORITIZATION - MIGRATION STRATEGY - IMPLEMENTATION PLAN Applications Architecture 업무기능을지원하고데이터를정리하는데필요한주요응용의종류를정의 응용의 Capabilities, Purpose, Benefit 등 사용하는데이터및지원기능등과의관계 현시스템과의관계 PRINCIPLES BUSINESS CURRENT SYS& MODEL TECHNOLOGY DATA APPLICATIONS TECHNOLOGY ARCHITECTURE ARCHITECTURE ARCHITECTURE SEQUENCING & PRIORITIZATION - MIGRATION STRATEGY - IMPLEMENTATION PLAN

98 EAP Methodology Layer 3, Layer 4 Technology Architecture Activities, data, application 구조의지원에필요한정보기술인프라구조 의정의 기술플랫폼의정의와선정 기술플랫폼과응용의연계 기술배치전략 / 계획 PRINCIPLES BUSINESS CURRENT SYS& MODEL TECHNOLOGY DATA APPLICATIONS TECHNOLOGY ARCHITECTURE ARCHITECTURE ARCHITECTURE SEQUENCING & PRIORITIZATION - MIGRATION STRATEGY - IMPLEMENTATION PLAN Implementation/migration plan 시스템의구현과이행을위한명확한과정의정의 우선순위결정 비용 / 효과분석 예산, 일정, 자원계획 CSF 및권고사항 사전이행계획 PRINCIPLES BUSINESS CURRENT SYS& MODEL TECHNOLOGY DATA APPLICATIONS TECHNOLOGY ARCHITECTURE ARCHITECTURE ARCHITECTURE SEQUENCING & PRIORITIZATION - MIGRATION STRATEGY - IMPLEMENTATION PLAN Finally, 현시스템의이행 결정 / 최종보고서및보고

99 ISP 와 EAP 의비교 ISP EAP 관점과목적 중, 장기적관점, 단기적이점 장기적관점, 장기적이점 계획수립의범위 주로응용시스템에치중 응용시스템및정보기술인프라 원칙정의 하지않음 정보관리전체에적용될원칙정의 응용시스템의도출 모호한편 체계적임 기술표준의활용 비체계적인방법 참조모델및표준을체계적으로활용 수행주체 외부컨설턴트에의존 내부주도, 외부지원 산출물 문서지향적인정적인산출물 프로젝트지향적인산출물 아키텍쳐 벤더중심의독점적인아키텍처 사용자소유의표준적오픈아키텍처 변화대응력 조직, 기술의변경시사용하지못함 일정기간별로지속적인수정

100 Enterprise Modeling 조직의 As-Is 와 To-Be를아키텍처요소별로정의하는노력 다양한접근이실제로가능 조직의요구에따라필요한내용과접근이달라져야함. Tool Vendor View 나름대로고안한Process 제공효과적이면서합리적인접근 조직목적등에따라 Scope/Depth 결정 Framework의 Column 1,3,6 및 Perspective 1-3까지 (ZAF 기준 ) 지적자산화 EAMS

101 Enterprise Modeling EAF EAF 상에서본 Models DATA What? FUNCTION How? NETWORK Where? PEOPLE Who? TIME When? MOTIVATION Why? EA SCOPE (Planner) List of things List of process List of locations List of organization and agents List of business events List of business goals, strategies ENTERPRSISE MODEL (Owner) Semantic model Business process models Business logistics system Workflow model Master schedule Business plan Framework SYSTEM MODEL (Designer) TECHNOLOGY MODEL (Builder) Logical Data model Physical Data model Application architecture System design Distributed system architecture Technology architecture Human interface architecture Presentation architecture Processing structure Control structure Business rule model Rule design Model COMPONENTS (Vendor) Data definition Program Network architecture Security architecture Tuning Definition Rule specification Functional System (Product) Data Function Network Organization Schedule Strategy

102 Enterprise Modeling - 예 EA 관리시스템 [HUD]

103

104

105

106

107 IT 자산관리 개념 현재보유하고있는정보기술자산을체계적으로관리하기위한노력 보유하고있는정보자산및이들간의상호관계등을체계적으로묘사하고이들자 산이지원하는업무및조직과이들간의상호관계를묘사한다. 특성 계획수립보다는 IT 자산관리의의의 Bottom-UP 방식 CASE 도구의활용 CASE 도구를통해모델링된산출물은다른조직에참조모델로서활용가능 대규모조직에서점진적개선및개량노력의일환으로추진 다양한 CASE Tool 의활용 Prudential 보험사, Nations 은행, Sears 백화점, Barnes & Nobles 서점, SwissCom 등의사례

108 IT 자산관리 EAP, EM, ITAM 의비교 단계 EAP EM ITAM 주요목표아키텍처 주요목표 원칙 모델링수준 소요기간 프레임워크 정보기술아키텍처모든아키텍처요소 IT 자산아키텍처 향후추진할 IT 프로젝트도출 일반적인원칙의정의 주요개념적모델수준에국한 상대적으로매우짧음 (5~6 개월 ) 보통활용되지않음 효과적인조직변환을위한실상의묘사및방안의도출 개별또는요소별로원칙정의 구체적모델수준까지가능 장기간소요 ( 그러나점차적접근가능 ) EA 프레임워크의활용이기본적으로전제됨 보유정보자산의체계적묘사및이와업무와의상호관계묘사 IT 자산관리원칙도출 현모습의구체적수준 단기간 선택적으로활용 CASE 도구보통활용되지않음적극적인도구의활용관련도구의활용 지속적활용가능성 낮음 높음 총괄계획수립전까지활용가능

109 1 4. 국내외 EA 사례및동향

110 국내 EA 사례 - 종합 공공부문 기술참조모델의도입 ITA/EA 기반의 ISP 국방부 C4ISR 추진 서울시, 한국은행 ITA 도입 정통부, 행자부시범사업 민간부문 통신회사, 금융권시범도입 Real Time Enterprise 결합 6 시그마성과개선활동결합 금융권본격도입및제조업확산 차세대정보화방법론으로고려 연구 / 표준 한국전산원, 국방과학연구소, 국방연구원등연구시작 개념, 프레임워크표준개발 참조모델개발 학계의주요연구테마로부상 ITA 법안 제정 제도환경변화 한국 ITA 학회등활발한활동 공공부문교육시행 민간교육과정시행 KIPA 교육시작 ITA 법안 제정

111 국내 EA 사례 공공부분민간부문 구분행자부정보통신부전산원서울시청한국은행 KT SKT 국민은행신용보증기금현대자동차 특성 전자문서유통업무부문에 Pilot EA 추진 EAMS (Enterprise Architecture Management System) 의개발및적용지속적인본프로젝트준비 / 진행중 전자민원시스템구축관련 ITA 수립 국내 ITA 참조모델및가이드라인개발 ITA 및 IT 자산관리시스템 EA 기반의정보전략계획수립 IT Asset Management 에초점을맞춘 EA 접근 일부아키텍처요소의개발 Infra 및 application architecture 추진중 ITA 기반의 ISP 프로젝트 전사적 EA 기반의정보관리계획수립

112 EA 구축사례 구분한국은행국민은행기술신보 시기 주사업자 LG CNS 매킨지,IBM, 액센추어삼성 SDS 비전 초일류수준의정보화구현 신기술기반시스템구축을통한세계 30 위권도약 경쟁력을갖춘신뢰받는중소기업서비스구현 목적 기존정보화과제효율적추진 NGBS 의성공적구축기반조성 체계적인정보기술도입전략수립 특징 작업결과의 Repository 화 ISP 와차별성부재 NGBS 추진전략의일환컴포넌트기반 ISP 와동시진행 SWOT 분석실시 CSF 도출

113 사례 1 한국은행 EA ( 추진체계 ) EA 원칙및 현재아키텍처 비전수 립 목표아키텍처수립 분석 전환 계획수립 Biz & IT 비즈니스 기능모델정 방향확인 의 EA 원칙및 비전수립 비즈 아키 EA Framework 정의 TRM 현황분석 모델 정의 니스 텍처 데이터 현황분석 수립 데이터 아키텍 아키 텍처 처수립 이행과제정의 어플리케이 션 어플리 케이션 향후 기술 현황분석 아키텍 처수립 수립 기술 EA 표정준보정기의술 전환계획수립

114 사례 1 한국은행 EA ( 원칙및비전수립체계 ) 조직의업무목표확인 EA 관련환경분석 경영전략정보화전략정책규제산업동향 IT동향 EA 비전수립 EA 원칙수립

115 사례 1 한국은행 EA ( 비전및원칙 ) EA 비전 초일류수준의정보화달성을지원하기위한아키텍처구현 Business Enabler Strategic Asset Tool of Governance 업무지향 업무수행및의사결정과정의적시적, 효과적지원 가치지향 업무역량강화 비용대비효과극대화 전략적정보관리 정보입수, 가공, 공유, 활용의전략화및체계화 EA 원칙 표준지향 표준기반의계획, 구축및관리 자율적변화지향 환경변화에유연한대처 지속적이고자율적인관리 사용용이성제공 정보시스템및정보의용이한접근및사용

116 사례 1 한국은행 EA (Framework) 아키텍처수립목적정의 모델링방법결정 프레임워크정의 EA 프레임워크 - 정보기술과환경변화에탄력적대응 - 관리체계및기술도입절차표준화 - 선진정보화구축기반마련 - 정보시스템간 연 계전략마련 - 통합을위한 청사 진제시 - Enterprise Business Modeling - Enterprise Data Modeling - EA 프레임워크선정 * FEAF 등기존프레임워크선택또는 Customizing 시각 구분 기획자 소유자 설계자 데이터 Data 아키 텍처 관점 (View) 응용 ( 업무 ) Business 아키텍처 Technology 아키텍처 기술 FEAF 를기본으로하되 TEAF 를일부반영하여정의

117 사례 1 한국은행 EA ( 현재아키텍처분석체계 ) 업무분석 가치사슬분석 업무를가치사슬모형을적용하여분석 정보기술분석 데이터현황분석 업무기능분석 기능체계분석업무기능분류 어플리케이션현황분석 업무기능모델정의 업무기능정의기능간의연관관계및대외인터페이스분석 기술현황분석 목표아키텍처수립 업무분석과정보기술분석결과를바탕으로목표아키텍처수립 데이터인터페이스, 정보공동활용, 데이터베이스구성현황분석 정보시스템구조, 활용현황분석기능및기술부문만족도평가 기술인프라를하드웨어, 소프트웨어, 네트워크분야로구분하여분석

118 사례 1 한국은행 EA ( 목표아키텍처수립체계 ) 아키텍처수립목적정의 EA 비전및원칙을토대로아키텍처수립의목적정의 비즈니스아키텍처원칙수립 비즈니스아키텍처수립 업무수행현황의적표현 체계 모델링방법결정 프레임워크도출 프레임워크에적용될모델링방법을결정 아키텍처수립목적을가장잘반영할수있는아키텍처프레임워크를도출 데이터아키텍처원칙수립 어플리케이션아키텍처원칙수립 기술아키텍처원칙수립 데이터아키텍처수립 어플리케이션아키텍처수립 기술아키텍처수립 데이터통합의관점 업무와데이터아키텍처의최적지원 어플리케이션아키텍처구현을위한기술요소를표준기반으로표현 전환계획수립 목표아키텍처구현을위한전환계획수립

119 사례 1 한국은행 EA ( 전환계획수립체계 ) 목표시스템이미지제시 전환기간및전환방법정의 전환과제정의 과제간우선순위및일정계획수립 자원계획수립 EA 기반 IT 관리체계수립 전환대상목표아키텍처를 To-Be 시스템이미지로형상화 목표아키텍처로의전환기간, 전환방법정의 목표아키텍처와현행시스템 Mapping 향후추진과제도출 우선순위결정기준정의 전환과제간우선순위정의 우선순위에따른일정계획수립 전환과제별, 단계별비용산정. 필요자원정의 IT 관리개념정의 EA 아키텍처관리방안수립

120 사례 1 한국은행 EA ( 우선순위평가체계 ) 평가방법 평가대상추진과제 경영관리 경영지원 정책지원 업무안정 KMS EIS EIP 사용자부서설문조사결과종합 + EA 구축컨설팅회의 추진과제순위결정및단계구분 평가항목 중요도 실현가능성 평가기준 가중치 설명 영향 / 효과 0.5 업무개선효과, 타영역에미치는영향의정도 유사성 0.15 기존시스템과의유사성 제도 / 법, 제도및조직문화적측면에서의 0.2 문화적용이성전환용이성 기술적구현성 0.15 개발의난이도및구현가능성의정도

121 사례 1 한국은행 EA (TRM/SP 개발절차 ) TRM Baseline Model 확정 전사적 TRM Draft 도출 기술실사를통한확인및보완 향후기술영역수용 View 기반모델도출 전사적 TRM 개발검증및보완미래기술영역추가 Action FEAF TRM 을 Baseline 모델로선정 기타 3 가지 TRM 참조, 보완 ( TEAF, 한국전산원, LG CNS) -EA framework 연계성 - 기술특성부합성 - 신기술수용정도 - 참조용이성 기술특성반영 -Main Frame 환경 - 분석, 통계관련 Tool 반영 기타 TRM 모델장점수용 -FEAF component view 활용 TRM 에대한의견공유 누락기술 / 제품확인 문제점및요구사항파악 시스템구성도및네트웍구성도를활용 TRM 최종검증 현재구축시스템 반영 향후구축시스템 반영 주요 emerging 기술수용 Web service.xml 관련기술반영

122 사례 1 한국은행 EA (TRM Draft) Service Access and Delivery Area Access Channels Delivery Channels Service Reuirements Service Transport Service Platforms and Infrastructure Operating System Supporting Platforms Delivery Services Software Engineering Management Software Database/Storage Hardware/Infrastructure Back Office / Legacy Assets Interface/Integration Component Framework Service Platform and Infrastructure Area Interface Service Access and Delivery Area Internal/External Area User Component Framework Security Presentation/Interface Business Logic Data Interchange Data Management 통합 Package Service Interface and Integration Integration Interoperability Interface

123 사례 1 한국은행 EA (EA 기반 IT 관리수립체계 ) IT 관리개념이해 과제수행범위선정 선진사례분석 EA 기반 IT 관리체계수립 등장배경 정의및목표 절차및대상 구성요소 EA 기반관리의필요성 EA 의역할 우선적고려대상선정 IT 관리체계수립및목적정의 분석대상및관점정의 분석및시사점파악 시사점종합및본과제적용방안도출 EA관련조직및기능정의 IT 관리프로세스정의 EA 기반의사결정기준정의

124 사례 1 한국은행 EA (EAMS 구축 ) 구분 시각 기획자 소유자 설계자 데이터 관점 응용 아키텍처 비즈니스데이터비즈니스어플리케이션데이터기술어플리케이션기술 기술 Web 기능을이용한정보공유 Enterprise Architecture Repository Back Office/Legacy Office Interface/Integration Component Framework Service Platform and Infrastructure Area Interface Service Access and Delivery Area Internal/External Area User 평가 기획 IT 관리절차 IT 관리체계에따른 EA 활용 기술참조모델 / 표준프로파일 실행 기능 아키텍처관리 기술참조모델 / 표준등록관리 아키텍처공유및검색 사용자그룹관리 아키텍처활용 설명 u 아키텍처등록및수정 u 아키텍처변경에따른추적및형상관리 ( 툴과연동 ) u 기술참조모델및표준관리 u Guideline 관리 u 아키텍처별정보공유및검색 u 사용자등록관리 u 사용자권한정의 u EA 기반의 IT 관리절차에따라아키텍처를활용

125 사례 2 국민은행 NGBS 추진체계 구분 KB 상위전략 2002/ /2 2003/6 2003/10 기업전략 BU 전략 / 운영과제정의 NGBS 기획 업무요건정의 NGBS 구축 구현방안선택 요구사항정의 컴포넌트기반비즈니스모델링 As-Is 분석 Biz Comp. 정의 Biz 모델링 Biz Case App. 아키텍쳐 NGBS Roadmap 분석 디자인 테크놀러지아키텍처 NGBS 구축예정 아키텍처요건정의 프로토타이핑 아키텍처청사진 벤치마킹테스트 구축 테스트 배치

126 사례 3 기술신보프로젝트추진체계 환경분석 AS-IS 아키텍처 TO-BE 아키텍처 전환계획수립 경영환경분석정보환경분석 C S F/ F/ C I R 아키텍쳐수립계획 비즈니스아키텍쳐데이터아키텍쳐어플리케이션아키텍쳐기술아키텍쳐정보화자산진단및 IT 관리체계분석 요구사항정의및개선방향정립 정보화전략수립및추진과제설정 비즈니스아키텍쳐 데이터아키텍쳐 어플리케이션아키텍쳐 기술아키텍쳐 IT 관리체계정의 이행계획수립구현계획수립 구축 AS-IS BA,AA,DA,TA 경영환경, 정보환경 TRM( 기술참조모델 ) 개발 아키텍처 Framework 개발 EA Repository 구축 SP( 표준프로파일 ) 개발 기술표준 반영

127 EA 동향 전체적인동향 지금까지의정보시스템은업무의편리성향상이목적 경쟁력을갖춘조직이되기위해, 시스템통합을통한 상호운용성 문제해결이중요 부분최적화 에서 전체최적화 를지향 개인의업무를특화하여전문성을가지는것에서진화 개인에서부문으로, 부문에서조직으로의관점에서발상을도출 조직뿐만아니라업무에서기술, 자원으로시야확산필요 해외정부기관동향 조직에서의자원의전체최적화방법 인 EA를행정의 자원배분을최적화하기위한통치방법 으로활용모색 ( 일본 ) Top-Down 주도권이강한행정기구또는공중통치를의식하는국가는솔선하여 Architectural Thinking 을도입 ( 싱가폴 )

128 EA 국내동향 국내금융권의 EA 도입동향 (I) 구분주요동향 농협 월차세대프로젝트추진을재개하기로결정하고이에앞서 EA 등필요한컨설팅의연내실시를검토중 우리은행 월차세대시스템가동후 EA 도입추진 신한금융그룹하나은행지방은행 조흥은행과의 IT 통합작업과병행하여 EA 프레임워크설계, 채널통합, EAI 구축등을추진중 차세대시스템추진을결정하기에앞서자체역량강화차원에서핵심노하우를정리중이며금년중EA 도입을추진 전국은행들의차세대시스템구축추이를주시하면서 BPR 위주의업무효율성제고에역량집중, EA 도입은시기상조

129 EA 국내동향 국내금융권의 EA 도입동향 (II) 구분주요동향 보험업계 삼성생명 : 2004 년중자체적으로 EA 를도입하고 EA 성과물을 IT 성과관리시스템과연계할계획엘지화재등손보사 : 2004 년말을전후하여차세대시스템구축을위한전단계로 ISP 와 EA 도입추진예정 증권업계 한국증권전산 : 차세대시스템구축을위한 ISP 수립컨설팅실시 ( 차세대아키텍처설계포함 ) 세종증권등일부를제외하고증권업계전반적으로 EA 구축과관련한특별한움직임은없음 카드사 BC 카드사 : 월차세대시스템구축을위한 ISP 수립컨설팅을실시 (2003 년부터내부적으로추진해온 ITA 를점검 )

130 EA 국외동향 미국 1996 년 : Clinger-Cohen Act 제정으로 IT 투자효율관리등에 EA 체제의기반구축을의무화 FEAF 운용강화위한체제정비 2002 년 FEAF 를책정, 관리기관으로 OMB 에 FEAPMO 발족 FEAPMO 전문가나행정가에의한 EA 책정워킹그룹운영 정식 FEAF 공표권한등 FEAF에기초한실제 EA 책정작업 각행정조직주도하에개별정보시스템도입프로젝트와복수의프로젝트를포함한프로그램의행정사업단위로시행 2003년현재 연방정부의 전자화 사업 30% 가 EA를이용하여예산을분배

131 EA 국외동향 영국 업무프로세스통제에중점을둔정부 EA 1997년 : 블레어정권하에서전자정부통제가본격화 : e-envoy 오피스설치 e-envoy의책무 전자정부의보안을유지, 전자정부정책의전략을입안 전자경제의활성화방안입안및전자정부의전자화방안입안등 e-gif(e-government Interoperability Framework) e-envoy 임무중하나인정부업무의전자화방안도입 정부업무의통제가아닌정부업무를시스템화할때상호운용성을보장 업무와기술만통제한 EA, 예산조치나정책, 행정평가연동예정없음 : e-gif Ver : Ver

132 EA 국외동향 캐나다및독일 캐나다동향 캐나다의 EA는 FA이며, 정부비즈니스케이스관리로부터시작 IM/IT의공공화, 공유화에관한수용력을유지하기위해FAP (Federated Architecture Program) 를책정 정보기술인프라스트럭처를현상과목표로하는정부비즈니스케이스와연동하는것을검토 독일동향 독일의 EA는기술표준화에중점을둔SAGA(2003년 ) 전자정부구축 2005년 G2G, G2B, G2C 등국내시스템의범용화가목표 참고 : SAGA = Standards and Architecture e-government Application

133 EA 국외동향 덴마크, 일본및뉴질랜드 덴마크동향 덴마크는가장범용적인 EA 를작성시도 EA 백서발표 ( ) 캐나다 (FA), 미국 (FEAF), 독일 (SAGA), 영국 (e-gif) 평가 통제아키텍처와유지를위한체제로기술과비즈니스트렌드로부터비전과의사결정, 비즈니스, 정보, 기술아키텍처를도출 일본동향 EA 사상을토대로업무, 시스템최적화계획작성 뉴질랜드 EA 도입을추진중

134 EA 추진현황의비교 [Source : 한국전산원 ]