Docstoc

_1_EA 최신동향 및 전망

Document Sample
_1_EA 최신동향 및 전망 Powered By Docstoc
					1장. Enterprise Architecture 개념

   1   기존 정보화의 한계점

   2   Architecture 란?

   3   주요 EA 도입 동기

   4   EA에 대한 필요성 인식 수준

   5   EA 정의

   6   EA 개념의 진화

   7   EA 주요 내용
기존 정보화 한계점



  전사적 차원의 기준 미비                 기업전략과 IT전략의 연계 미비
      - 정보화 투자의 재원조달 및 관리           - 기업전략 설정에 IT조직의 미 참여
          통제                        - 과거회귀적 평가에 의존
      - IT투자의 기업가치화                 - 프로젝트내에서의 요소기술 선정에 치중
      - 기술의 일관되고 체계적 활용




  “one project at a time” 접근    Hyper competition 의 시대
     - Ad-hoc 요청에 대한 수동적 수행         - 기업 경쟁의 가속화 및 경영환경의 급변
                                    - 그러나 현재의 정보화 패러다임으로는 이에
                                    대응하기 힘듬[Boar, 1998]
Architecture란?
 아키텍처는 건축물 설계도 또는 도시의 지도와 같이 어떤 대상의
  주요한 특징을 추상화 하여 묘사한 것.




                          •단순하게 표현
                         •의사소통이 확대
                        •변화된 요구의 효과
                            적 수용
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 quality software
   Lack of data sharing
   Difficult change management
   Long development cycle
   Non-interoperable applications
   Limited strategic information
주요 EA 도입 동기
 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 : Meta Group 2002
EA에 대한 필요성 인식 수준

 Q: What makes existing, new,
   and packaged application
   come together successfully
 응답자의 70%가 EA구축이라
   고 답하였다.
 EA는 비즈니스 혁신을 이룰
   수 있는 하나의 수단이다.
 단, EA 개발에 있어 문제가
   될 수 있는 것은 시간의 부족
   이다.




                                 Source : Informationweek Research of IT Mangers
                                 [1999]
TOP 10 Concerns of CIO
                  연방정부 CIO 대상, 2002년 실시


1. Formulating or implementing an agency Enterprise Architecture
2. Implementing IT capital planning and investment management across
   the agency Ensuring Year 2000 operations
3. Measuring IT contribution to mission performance
4. Aligning IT and organizational goals
5. Providing effective IT infrastructure and related services
6. Using IT to improve service to customers/stakeholders/citizens
7. Developing agency-wide IT accountability
8. Obtaining adequate resources
9. Championing business process reengineering as a precursor to IT
   decisions and Implementing cross-government IT projects
 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 quite specific skills and techniques in their formulation
EA의 정의
 EA는 조직의 비즈니스, 정보, 응용시스템, 기술 기반구조를 정의하고, 이러한 요소
  상호 연계되는 모습을 총괄적으로 표현한다.

 또한, EA 조직이 나아가야 할 방향에 대한 지침을 포함하는 실체이다.


     구 분                                 정 의

 Zachman [1987]   기업의 지식 기반구조를 구성하는 기본적이며 설명적인 산출물(Artifact)의 집합

      Rood        기업 및 조직의 전사적 환경의 구성 요소들이 어떻게 위치되고 상호 관계가 있으며, 서로
     [1994]       반응하는 사항들을 표현하는 개념적 프레임워크

     Raines
                  비즈니스 및 관리 프로세스와 정보기술사이의 흐름과 바람직한 관계의 명시적 묘사
     [1997]

      OMB         비즈니스 업무, 관리활동, 정보 기술 간의 관계를 현재와 향후 추진해나갈 모습에 대해 명
     [2000]       확히 묘사해 둔 내용

      Ohio        정보기술 자원의 획득, 구현, 관리를 체계적으로 지원해주는 표준(standards),정책
     [2000]       (policies),지침(guideline)등의 집합

이태공, 박성범, 이헌중     조직에 사용되는 정보기술을 활용한 구조와 체계들을 총괄한 것으로 , 업무 및 관리 프로
     [2001]       세스 와 정보 기술 간의 관계를 표현한 것

  김성근 [2002]      전략적 의사결정에 바탕이 되는 조직의 구조적 모습, 의사결정 원칙, 참조모형의 집합
EA와 ITA란?
 1996년 OMB에서 ITA (Information Technology Architecture)에 대한 정의를
  제시



        ITA
               =       EA
                                   +   TRM
                                                +     SP
                                                           ?!!
   2000년도 부 터 OMB에서도 Enterprise Architecture를 일반적인 용어로 적용



                      Enterprise Architecture

                        Business Architecture

                    Information        Application
                    Architecture       Architecture

                       Technology Architecture
 EA개념의 진화
                                   App. 6
           App. 1
                                                   App. 2                    ……        Time
Non ISP                 App. 3



           App. 1                App. 3             App. 5
  ISP               App. 2                App. 4              App. 6         ……        Time


               App. 1              App. 2                App. 3


  ITA                                          요소3
                        요소1                                            요소3
                                     요소2                  요소3                ……   Infrastructure


               전략

          업무            데이터
  EA                                App. 2               App. 3
               App. 1

                                                   요소3
                         요소1                                           요소3
                                      요소2                   요소3              ……   Infrastructure
Enterprise Architecture 노력의 목표

 신속한 프로세스 변화가 가능하게끔 IT활용

 논리 정연한 시스템 개발 및 기술 선정을 위한 프레임워크 제공

 기존 IT자원의 효력을 극대화

 단위 조직내부 및 단위 조직간 정보 공유

 실행 및 지원 가능하고, 유연하고 변경 가능한 Architecture 확립
 Enterprise Architecture 주요 내용
EA는 Blueprint, Principle, Reference Model 등으로 구성되며,
또한, 이들을 바탕으로 업무 및 정보기술 환경이 구현된다.

   Strategy
   Vision
   Mission                                             목표 or 효과
   …
                                                  •Alignment
                                                  •Integration
                                                  •Flexibility
                                                  •Interoperability
                                                  •Reduced Time-to Market
                                                  •Quality
                                                  •Seamlessness
                                                  •Adaptability
                                                  •User-Friendliness
                                                  •Usability
                                                  •Reusability
                                                  …
다양한 환경의 변화
업무, IT, 조직, 정책…
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 구성요소

     Structural                           Temporal (Roadmaps)
                             Models
                                of
                               Key
                             Aspects
                              of EA
    What & Where                                 When
                   Heuristic (Decision Trees)




                           How & Why
Principle 예: 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.
                                            …
Technical Reference Model
 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.




 TRM Organizes the
 Standards Profiles
 and any standards or
 technology forecast
 documents.




                                                   TRM ( US Customs Service)
     Technical Reference Model (Example)


Service Area   Common Services

    Domain     Operating Systems




                      Desktop/Client OS
                        Maintenance OS
 Sub-Domains                                Each sub-domain contains the
                           Network OS       detailed information on the following
                                            topic areas
                            App Server OS   • Definitions
                                            • Key Roles and Points of Contact
                                            • Technical and Product Specifications
                                            • Selection Criteria
                                            • Benefits
                                            • Technical Architecture Reference


                                                  TRM ( US Customs Service)
2장. EA 프레임워크 및 방법론

  1   EA 프레임워크 및 방법론의 진화

  2   EA 방법론의 비교

  3   EA와 EA Framework

  4   Zachman의 EA Framework

  5   EA Framework의 구분

  6   EA Methodology의 구분

  7   Strategic Enterprise Architecture Methodology(SEAM)의 개요
EA 프레임워크 및 방법론의 진화
     개발년도   1980                              1990                          2000
구분

            ZISAF    ZEAF                                        FEAF


     방                                                  C4ISR             TEAF
     법
     론
     및                                                  TISAF
     프
     레                                                                     IAF
     임
     워
     크                                                                      Togaf8

                                        TAFIM                    Togaf7
                                                                          PGFEA
                        EAP                             TADP      META



                                                                          OMB
                                         ITMRA        OMB97
 법안                                                                       2000
  및
                                                                IEE1003
 표준           NIST                      RM-ODP                            IEEE1471



                              참조(Reference)          개정(Revised)
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)를 제시
EA 프레임워크 및 방법론의 비교
          ITA                        [활용]                 EA

         1                              2     EAP
프로세스                                                      PGFEA
 중심
                           TADP


                                                META
         TAFIM                                         TOGAF 8
                                        IAF
                 TOGAF 7

[구성요소]
         3                              4

                             C4ISR AF
                                                       TEAF

                                                FEAF
프레임워크           Index
                             ZISAF
  중심         Framework                                        ZEAF
  EA와 Framework


                       DATA          FUNCTIO N      NETWO RK         PEOPLE         TIME       MOTIVATIO N
                       What?           How?          Where?           Who?          When?         Why?             EA
                                                                                                  List of
                                                                      List of       List of
     SCOPE                             List of         List of                                  business
                    List of things                                 organization    business
    (Planner)                         process        locations                                    goals,
                                                                   and agents       events
                                                                                                strategies

 ENTERPRSISE
                      Semantic
                                      Business       Business
                                                                    Workflow        Master      Business       Framework
    MODEL                             process        logistics
                       model                                         model         schedule       plan
   (Owner)                             models         system

    SYSTEM                                          Distributed       Human
                    Logical Data     Application                                  Processing     Business
    MODEL                                             system         interface
                       model         architecture                                  structure    rule model
   (Designer)                                       architecture   architecture

 TECHNOLOGY
                     Physical          System       Technology     Presentation     Control
                                                                                                                 Model
    MODEL                                                                                      Rule design
                    Data model         design       architecture   architecture    structure
   (Builder)

 COMPONENTS             Data                          Network        Security      Tuning         Rule
                                      Program
   (Vendor)           definition                    architecture   architecture   Definition   specification

Functional System
                        Data          Function        Network      Organization   Schedule       Strategy
    (Product)
Zachman의 EA Framework
다양한 EA Framework Matrix
                    Inventory   Principle   Model      Standards                     Values   Principle   Process   Standard   Buy List
                                                                    Executive
 Infrastructure                                                     Direction
                                                                   Organization
     Data
                                Index                              Architecture


  Application
                                                                   Application
                                                                   Architecture                    Gartner
                                                                      Data
                                                                   Architecture
  Organization
                                                                   Service Layer
                        Data        Applications    Technology
                                                                     Facilities
                     Architecture   Architecture    Architecture
                                                                      Layer
 Planner’s View                                                      Platform
Objectives/ Scope
                                                                     Netw ork
 Ow ner’s View
Enterprise Mode                                                                   Functional Information Organizational Infrastructure
 Designer’s View                                                                    View        View         View           View
   Information
 Systems Model                      FEAF                            Planner

  Builder’s View
                                                                                                          TEAF
                                                                     Ow ner
Technology Model

 Subcontractor’s                                                    Designer
     View
    Detailed
                                                                    Builder
  Specification


                   프레임워크 마다 Focus와 Goal이 다르기 때문에
                     각각 View와 Perspective가 차이가 난다 .
   View (2D Matrix)의 비교

        ZEAF          TOGAF          TAFIM          C4ISR AF      FEAF          TEAF
                                                                  (PGFEA)
View    Data          Technical      Intelligence   Operational   Business      Organization
Or                    Architecture   Systems        View          (People)      al View
Arch.   Function      Views                                       Architectur
                      (engineering                                e
                      views,                                      Data          Information
                      operations     Command        Systems       Architectur   View
        Network       views          And            View          e
                      Acquires       Control
        People        views)
                                     Systems                      Application   Functional
                                                                  Architectur   View
        Time                         Combat         Technical     e
                      Business       Support        View
                      Architecture   Systems
        Motivation    Views                                       Technology    Infrastructur
                                                                  Architectur   e View
                                                                  e
       EA
비고 IT-Specific        ITA
                     Biz-Specific    ITA            EA            EA            EA
방법론 (Process-Centric)

 미 연방정부 기관 및 컨설팅 업체에 의해 개발된 방법론 및 국내외

 에서도 다양한 방법론 등장하기 시작.

 이들 방법론들은 EA 활용을 위한 다양한 접근 방법과 범위를 제시

 한다.

 이들 방법론들을 크게 두 가지로 분류

   EA Life Cycle 지원 방법론

   EA 정의 방법론
EA 정의 방법론

 계획 수립, 모델링 등 다양한 접근이 소개되고 있음
 도입 목적에 적합한 접근의 선정이 중요

             개발자 또는
방법론의 종류                            주요특성
              제안기관
   EAP        Spewak      7단계 계획 방법론
                          버전 7에서는 ITA구축에 Scope를 가
  TOGAF      Open Group     지고 있었으나 최근 개발 중인 8버
                            전에서는 EA로 Scope를 확대

                          EA구축 절차 및 기술 참조 모델로 구성
 C4ISR AF
              미 국방성       EA프레임워크 매트릭스 제시
 (TAFIM)
                          TAFIM에서 C4ISR AF로 대체

                          EA 프레임워크 매트릭스 제시
TADP(TEAF)    미 재무성
                          개발 절차인 TADP제시
EA Life Cycle 지원 방법론
 조직에서 아키텍처 개념을 도입하기 위한 전략수립, 아키텍처 정
  의, 활용 및 유지 보수의 전 과정을 지원해 주는 방법론

                                     Obtain           EA프로그램
 EA유지보수                             Executive          도입 단계
                     Maintain the   Buy-In and
   단계                                Support
                Enterprise                         Establish
              Architecture                        Management
                                                   Structure
                                                    and Control
          Use
          the               Practical Guide
       Enterprise                  To                               EA프로세스 및
                                                    Define an       접근의 선정단계
       Architecture Federal Enterprise Architecture Architecture
                                                     Process
                                                   and Approach
EA활용                                                               EA의 활용 목적, 범
 단계        Develop the                                             위에 적합한 EA정의
           Sequencing Plan                          Develop
                                                Baseline             방법론을 선택
                                Develop       Enterprise
                                Target       Architecture
                              Enterprise
                              Architecture              EA정의단계
3장. Enterprise Architecture 도입방안

  1    다양한 EA 도입방안

   2   EAP의 개념

  3    Enterprise Modeling의 개념

   4   IT 자산관리의 개념

   5   EAP, EM, ITAM 의 비교
  다양한 Enterprise Architecture 도입 방안

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


                                         정보공학(Information Engineering)
                                   4.EA 도입방안
EAP의 개념
 정의 및 특성
   EA의 개념을 조직에 도입하는 가장 초창기 방법중의 하나
   정보시스템의 전사적 계획 수립 뿐만 아니라 정보기술아키텍처의 계
    획까지 포함 하는 노력
   정보기반 기술 구조를 보다 중점적으로 반영
 한계점
   정보기술 아키텍처의 구현 만을 중요시 하고 기타 다른 아키텍처들의
    구현 및 활용에 소홀히 하였다.
   노력의 근원적 목표는
   EA활용이 제한적이어서 Silo(건조 창고형) 응용시스템의 추가 개발
   원칙들이 일반적 성격
   EAP의 결과물의 지속적 활용도가 낮아 전략적인 자산으로 활용도가
    낮음
 Spewak‟s EAP 방법론이 대표적
ISP와 EAP비교


                ISP           EAP

                           응용시스템 및
계획 수립의 범위    주로 응용시스템
                           정보기술 인프라


                         정보관리 전체에 적용될
 원칙의 정의       하지 않음
                            원칙 정의


응용시스템의 도출     모호한 편          명확한 편


                         기술참조모델 및 표준프로
기술 표준의 활용    비 체계적인 방법
                          파일을 체계적으로 활용
ISP와 EAP의 비교

       ISP                                                EAP
       Process                                           Process
                                 IT Infra                                          IT Infra




DATA               Application              DATA                     Application




                                                         “Clear”
       “Unclear”
                                                     “Data-Driven”
                                             “But, insufficient architecture”
Enterprise Modeling의 접근
 조직의 현 모습 및 향후 나아갈 모습을 아키텍처 요소별로 정의하
  는 노력
 다양한 접근이 실제로 가능/조직의 요구에 따라 필요한 내용과 접
  근이 달라져야 함.
 Tool Vendor시각
   나름대로 고안한 Process 제공
 효과적이면서 합리적인 접근이 필요
   조직 목적 등에 따라 Scope/Depth 결정
   Framework의 Column 1,3,6 및 Perspective 1-3까지
 조직의 지적 자산화
   EAMS
EA관리 시스템[USDA]
IT자산 관리
 개념
    현재 보유하고 있는 정보기술 자산을 체계적으로 관리하기 위한 노력
    보유하고 있는 정보자산 및 이들간의 상호 관계 등을 체계적으로 묘사
     하고 이들 자산이 지원하는 업무 및 조직과 이들간의 상호관계를 묘사
     한다.
 특성
      계획 수립보다는 IT 자산 관리의 의의
      Bottom-UP방식
      CASE도구의 활용
      CASE도구를 통해 모델링 된 산출물은 다른 조직에 참조모델로서 활
       용가능
 대규모 조직에서 점진적 개선 및 개량 노력의 일환으로 추진
 다양한 CASE Tool의 활용
 Prudential 보험사, Nations 은행, Sears 백화점, barnes &
  Nobles 서점, SwissCom 등의 사례
EAP, EM, ITAM의 비교
  단계          EAP             EM             ITAM
주요 목표
          정보기술 아키텍처       모든 아키텍처 요소      IT자산 아키텍처
아키텍처
                         효과적인 조직변환을 위    보유 정보자산의 체계
            향후 추진할
주요 목표                    한 실상의 묘사 및 방안   적 묘사 및 이와 업무와
          IT프로젝트 도출
                             의 도출          의 상호관계 묘사
             일반적인         개별 또는 요소 별로
  원칙                                     IT자산 관리 원칙 도출
            원칙의 정의           원칙 정의
          주요 개념적 모델      구체적 모델 수준까지
모델링 수준                                   현 모습의 구체적 수준
           수준에 국한             가능
                            장기간 소요
            상대적으로
소요기간                       (그러나 점차적          단기간
          매우 짧음(5~6개월)
                             접근가능)
                         EA프레임워크의 활용이
프레임워크     보통 활용되지 않음                      선택적으로 활용
                           기본적으로 전제됨
CASE 도구   보통 활용되지 않음     적극적인 도구의 활용      관련도구의 활용
지속적 활용                                   총괄계획 수립 전까지
              낮음              높음
 가능성                                         활용가능
4장. EA 사례 및 효과

  1   미 정부기관의 EA 추진 내용

  2   EA관련 미국 부처 역할

  3   EA 성숙도(GAO)

  4   미 연방정부의 EA효과(GAO)

  5   구체적 EA 국외사례

  6   기타 EA도입효과 사례
 미 정부기관의 EA 추진 내용
             이름                   년도                주요 내용
정부 수행과 결과 법안
(GPRA: Government                 1993   •전반적인 IT자원의 운용과 활동을 측정
Performance and Results Act)
문서 감축법(개정안)
                                  1995   •전자 문서 체계에 도입
(Paper Reduction Work)
정보관리기술개혁법안                               •주 비즈니스 영역의 설정(CIO의 도입 )
(ITMRA: Information                      •기존의 정보기술을 유지 개발하고 새로운
Technology Management             1996   기술을 수용할 수 있는 프레임워크도입
Reform Act 또는                            •정부의 전력적 목표를 반영한 정보자원
Clinger-Cohen Act )                      관리 목표들
                                         •ITA의 도입 (ITA에는 EA와 TRM/SP가 포
Raines Rule(OMB-97-92)            1997
                                         함되어야 한다고 명시)
OMB Circular A-130                       •EA 의 도입 제시
(Management of Federal            2000   •연방 부서들의 종합적 정보자원관리 지침
   Information Resource)                 제시
Incorporating and Funding
                                         •보안강화를 위해 정보 아키텍처 및 기술 아
Security in Information Systems   2000
                                         키텍처 구현 의무화
Investment (OMB M-00-07)
  EA 노력의 진화 [미 연방 정부]
NIST EA모델                   C4ISR AF
DoD TRM                     Zachman Framework
Zachman Framework           Spewak EAP                                                         PMRM
                            IEEE 1471                                                    DOD ACRM
                                                                                          AF    DRM
                                                                                   FEA   개발     개발
                                                                                   BRM [2003]    …
                                                                              GAO  개발        [2003년도
                                                                            EA 성숙도[2002]      이후 개발
                                                                      FEAC    측정
                                                                       교육 [2002]                예정]

                                                         Practical   [2002]
                                                          Guide
                                                 TEAF    To FEA
                                                 개발       [2001]
                                      OMB       [2000]
                                     Circular
                             FEAF     -130
                             개발      [2000]
                            [1999]
                   Raines
                   Rule
         Clinger   [1997]
         Cohen
GPRA     [1996]
[1993]



           발아기                       개별 구축 지원                         성숙화 지원              성숙
EA관련 미국 부처 역할
                       OMB
                       •정책의 결정
                       (지침, 가이드라인)
                       •각 부의 EA관리, 점검
                       •EA운용 지원


CIO Council                                       GAO

EA프레임워크 및 방법                                      정보자원관리 및 투자에
론 등과 같은 구체적 개                Enterprise           대한 평가
발 방안 제시                     Architecture



       민간 SI업체                             Agencies
       •기타 방법론 및 기술적
       방안 제시                               •EA개발 프레임워크
       •OpenGroup,Zachman                  •EA 개발 산출물
       Spewak,MetaGroup등
         EA 성숙도 (GAO)
                                                                      핵심 요소
                   Demonstrate            Provides capability to   Demonstrates satisfaction of commitment           Verifies
       단계          Commitment             meet commitment                                                            satisfaction of
                                                                                                                     commitment
    Leveraging     Written/approved                                Either EA steering committee, investment          Metrics exist for
    the EA for     policy exists for EA                            review board, or agency head has approved         measuring EA
5   Managing       maintenance                                     EA                                                benefits
    Change
    Completing     Written/approved                                EA products
    Architecture   policy exists for                               Describe enterprise‟s business-and the data,
    Products       information                                     applications, and technology that support it
                   technology                                      Describe “as-is” environment, “to-is”
                   investment                                      environment and sequencing plan
                   compliance with EA                              Agency chief information officer has
4                                                                  approved EA

    Developing     Written/approved       EA products are under    EA products
    Architecture   policy exists for EA   configuration            Describe or will describe enterprise‟s
    Products       development            management               business-and the data, applications, and
                                                                   technology that support it
                                                                   Describe or will describe “as-is” environment,
                                                                   “to-is” environment and sequencing plan
3                                                                  EA scope is enterprise-focused

    Building the   Committee or group     Program office           EA plans
    EA             representing the       responsible for EA       Call for describing enterprise in terms of
    Managemen      enterprise is          development exists       business, data, applications or technology
    t              responsible for        Chief architect exists   Call for describing “as is” environment “to be”
    Foundation     directing,             EA being development     environment or sequencing, or sequencing
                   overseeing, or         using a framework and    plan
2                  approving EA.          automated tool
    Creating EA Agency is aware of
    Awareness   EA
1
미 연방정부들의 EA 성숙도 분포

                 MATURITY FRAMEWORK STAGES
             5    Leveraging EA for managing change
             4    Completing architecture product
             3    Developing architecture product
             2    Building EA management foundation
             1    Creating EA awareness
미 연방정부의 EA 효과 (GAO)
미 연방정부의 EA 효과 - 농무성

       종류                절약 유형           예산절감(추정치)

   Brio Tech. S/W        전사적 구매          현재까지 $470K


    Novell S/W        Multi-agency BPA      $50K

                     산림청 IBM계약을 기초로
     Lotus S/W                           조달가격 10%이하
                     전사적 라이센스로 확장

 Crunchy Tech. S/W   전사적 구매 및 3년 BPA        $1.4M

         .                   .                .
         .                   .                .
         .                   .                .
         .                   .                .

*농무성 EA프로젝트는 초기단계를 마친 상태
   EA사례 - Department of Veterans Affair
 Stage     Description                                                                  Satisfied?
           Written/approved policy exists for EA maintenance                                NO
           Either EA steering committee, investment review board, or agency head
Stage 5:   has approved EA                                                                  NO
           Metrics exist for measuring EA benefits                                         YES
           Written/approved policy exists for information technology investment
           compliance with EA                                                              YES
           EA products describe enterprise‟s business-and the data, applications, and
           technology that support it                                                       NO
Stage 4:   EA products describe “as-is” environment, “to-is” environment and
           sequencing plan                                                                  NO
           Agency chief information officer has approved EA                                YES
           Written/approved policy exists for EA development                               NO
           EA products are under configuration management                                  YES
           EA products describe or will describe enterprise‟s business-and the data,
Stage 3:   applications, and technology that support it                                    YES
           EA products describe or will describe “as-is” environment, “to-is”
           environment and sequencing plan                                                 YES
           EA scope is enterprise-focused                                                  YES
           Committee or group representing the enterprise is responsible for
           directing, overseeing, or approving EA.                                         YES
           Program office responsible for EA development exists                            NO
           Chief architect exists                                                          NO
Stage 2:   EA being development using a framework and automated tool                       YES
           EA plans call for describing enterprise in terms of business, data,
           applications or technology                                                      YES
           EA plans call for describing “as is” environment “to be” environment or
           sequencing, or sequencing plan                                                  YES
Stage 1:   Agency is aware of EA                                                           YES
구체적 국외 EA 사례
            구분                                           특성
    개별 연방조직                   OMB 요구사항으로 자체 EA 개발 완료 및 추진 중
                              연방정부의 통상 무역 업무 프로세스에 대한 Cross Agency
               Internationa   /Department
               l Trade        EA개발
    E-Gov.                    FEAF를 기반으로 DOD Work Product를 정의하는 파일럿 프로젝트 수행
                              연방정부의 Grant 업무 프로세스에 대한 Cross Agency/Department EA
공              E-Grant        정의
                              FEAF를 기반으로 DoD Work Product를 정의하는 파일럿 프로젝트 수행
공
부   보훈성                       Health Administration 부분에 EA Baseline 및 Target EA 정의
분                             미 연방준비은행의 FRIT의 EA 정의
    미 FRB
                              Heuristic Blueprint의 적용
                              이민국 출입국 관리 업무에 대한 EA 정의
    이민국(INS)                  Spewak의 EAP를 발전시킨 방법론의 적용
                              Architectural Pattern Mapping을 통해 IT Architecture 명확한 도출
    State      오하이오/          Meta Group의 Principle 기반 방법론을 통한 EA 정의
    Gov.       코네티컷…          다양한 도메인 아키텍처(App. Network, Security…) 정의
    HP/Compaq                 EA를 통한 효과적 기업 합병
산   Chrysler                  EA를 기초로 한 웹기반 Technology Portal의 활용
업
    KLM 항공                    IT 도입에 대한 의사결정 학습도구로 활용
체
    Munich Re EA사례            Meta Group의 방법론 활용한 Principle –based Approach
                               *붉은 글씨는 구체적 Sample 제시
                                                 2.EA도입 필요성
기타 EA도입 사례의 효과
          대표적 사례                          효과

                          •Document Management System의 중복투자 제거
       미 교육성              •국립 보건건원의 e-Grants를 Online grants 시스
재무적                       템으로 활용
 관점
       미 금융서비스 업체         •시스템 개발 및 유지 비용의 절감효과

       오하이오 주             •코드 재사용을 통한 유지 비용의 절감 효과

프로세스
       National 항공사       •신속한 대응력 확보
 관점
                          •고객의 정보요청 수요를 1/10로 감소
고객
       Zuellig Pharma     •대 고객 이미지 향상
관점
                          •부서간의 협업 기능 확대

       Allegheny Energy   •외부 환경과 의 유기적 접근이 가능
학습과
혁신관점
       KLM항공사             •IT도입 관련 의사결정 학습도구로 활용
                                                               2.EA도입 필요성
EA 도입에 따른 IT비용 절감효과


 최근 미국 CIO 서베이 결과: 사용




                             Architected? Yes
   자 1인당 정보화 비용은 조직 규
                                                  $22,534           $6,185
   모와 아키텍처의 존재여부에 따

   라 달라짐.

 아키텍처와 표준은 IT비용의 효
                                                  $30,386           $9,209
   율적 활용에 효과적이다.

                               No
                                                Small       Org. Size   Large



Architecture planning and standards compliance reduce IT
         budget expenses by an average of 30%.
                                         2.EA도입 필요성
Ohio주의 EA 효과(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,000
                                                      2.EA도입 필요성
Ohio주의 EA 효과(2)

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

                    오하이오주            타 주*
   애플리케이션           산재보상            아동복지
     사용 도구         IEF/CoolGen     IEF/CoolGen
    사용 방법론       Architecture 기반     전형적
      실체수             1030            300
     소요기간             2.5년            12 년
     개발비용              -             $42Mil.
    실체별 비용           $25,000        $140,000

 * 2개의 주사업자 및 1개 하청업체가 수행; 향후 3년여의 수정/보완 작업 소요됨
5장. EA 향후전망

  1   EA노력의 진화배경

  2   EA 활용의 예

  3   EA Product Relationships

  4   Architecture Products by use

  5   정보화 노하우의 변화

  6   국내 EA도입을 위한 추진전략

  7   EA 향후전망
EA 노력의 진화배경

                                                   : DOD AF[2003]
                                                   방법론에서 새롭게
                                                      추가한 개념



                     “EA-Enabled”


          Architecture Product   Architecture
                selection          활용용도

                         Data-centric approach
     Reference Model 지원 of architecture products



    방법론 지원         EAMS 지원        FEAC 교육지원



              EA 제도적 기반 마련
EA 활용의 예
                                                                             1. Requirements Document Development &
Planning, Programming, Budgeting System(PPBS)                                   Interoperability Review
                                                                             2. System Development, Acquisition,
                                                                                &Integration
                                                   S ervice                  3. Resource Management(PPBS)
                                                   P OMa                     4. Interoperability Oversight & Integration
  De fense Planning
  G uidance[DPG]
                                                                 $
                        CC In tergrated
                        P r iority Liata[IPLa]




           Requirements Generation                                                             System Acquisition


  M ission-focused,                       PHASE 0
  c a pability-based
                                                                              PHASE 1                PHASE 2           PHASE 1
                                       •CONCEPT
         n e ed                        •EXP LORATION                        •P R OGRAM           •ENGINEERING       •P R ODUCTION
                                                              Ca pabilities •DEFINITION          •M ANUFACTURING    •FIELDING
                          In itial       M ission Area
                       Ca pabilities                          De velopment •R ISK R EDUCTION                        •DEP LOYMENT
                                          In te grated                                           • DEVELOPMENT
                       Document                               Document                                              •OP ERATIONAL-
                                         Ar chitecture                                                                S UPPORT




                                                 Interoperability Oversight & Integration

    Some Architecture Uses Related to the Requirements, Acquisition, and Budgeting
    Processes
 EA활용 : Planning, Programming, Budgeting Process


PPBS (Planning, Programming,    • provides a complete picture of the systems proposed in
    & Budgeting System)            programs, plan, and budgets.

                                • models the business process and IT support for the
Capability-Based Analysis for     business process.
  IT Investment Decisions       • measures improvements in critical success factors under
                                  varying IT investment levels and alternatives.

                                •Alternative architectures can be developed and compared to
   Modernization Planning        measure the degree to which they satisfy enterprise
                                 objectives

                                •Provide a complete picture of the systems(applications) in
          Portfolio             the portfolio and how they interact in terms of function,
                                performance, interfaces, data, installation, and standards
   EA활용 : Requirements Generation Process


                                 • provides a meams to assess the impact on operations of
  Determining Mission Needs
                                  shortfalls in system or technical functions, performance,
  and Identifying Deficiencies
                                 Interfaces, data, installation, or standards.


Concept of Operations(CONOPS)    • CONOPS and TTP can be modeled in the operations view
 and Tactics, Techniques, and    and assessed for effectiveness, particularly training, personel
       Procedures(TTP)           ,and materiel impacts.


                                •The business or operational process can be modeled in the
Business Process Re-engineering
                                operational view to determine overlaps, bottlenecks, and
 Functional Process Improvement
                                Other activity and organizational suboptimizations.
EA활용 : Acquisition Process(1)


  Program Definition and       • aids the Program Manager(PM) to use information in the
     Risk Reduction            architectural databases to identify the risk areas.


                               •specifies data requirements in a manner that supports
Approval to Begin a New
                                integrated assessments of the acquisition for efficiency,
  Acquisition Program
                               effectiveness, and interoperability.


                               •Facilitates understanding of the relationships and
Interoperability/Integration   dependencies among systems, data, information, material and
                               services that enable them to operate effectively together.

                               •Guides program execution from initiation through
 Acquisition Strategy and       procurement of systems, subsystems, components, spares,
    Source Selection            and services beyond the initial production contract award
                                and during post-production support.
 EA활용 : Acquisition Process[2]


Cost,Schedule and Performance •Includes the creation of program goals, thresholds and
      Risk Management          objectives, to include the risk involved over the life cycle
                               of the acquisition.


    Life-Cycle Support and       •Includes appropriate access to the Internet and other
Integrated Digital Environment   digital environments.


                                 •Provides for the application of sound, cost-effective
     System Engineering
                                 engineering principles to the requirements, design, and
  (Design and Development)
                                 eventual development of a system.

                                 •Identifies future technologies, in-progress or speculative,
Technology Insertion/Evolution   and relate them to systems that may need to employ them
                                 in the “to-be” architectures.
EA활용 : Operations


Operations Planning and   • describes how forces organize and interact and how material
       Execution          supports operations.


                          •Facilitates the design and development of exercise plans
 Exercise Planning and
                          and defines the environment where they can be executed or
       Execution
                          simulated.


                          •Address the organization, its elements, structure, data and
 Organizational Design    information requirements, system support, and environmental
                          issues.
Architecture Products by use
EA Product Relationships
 Operational
 Architecture                    Hig h-Level Operational Co ncept G raphic summary
 Products                        o f mission,organization and roles in p ictorial fo rm


 O p erational No de Co nnectivity Description                               O p erational Activity Model
          Re lates nodes to needlines                                       Mission Process and attitudes




                                 O p erational Event-Trace Description                O p erational information Exchange Matrix




System              Sys tems Interface                           O p erational Activity to systems
                       De scription                               Func tion Traceability Matrix             Sys tem Event-Trace
Architecture                                                                                                    De scriptions
Products
                      Sys tems Data                                      Sys tems Functionality
                   Exc hange Description                                      De scription



                                              Physical Schema




 Technical Standards
                                         T e chnical standards profile
 Architecture Products
국내 EA 사례
     구분                                     특성

             전자문서유통업무 부문에 Pilot EA 추진
    행자부      EAMS (Enterprise Architecture Management System)의 개발 및 적용
공            지속적인 본 프로젝트 준비 중
공
부   정보 통신부   전자민원 시스템 구축 관련 ITA 수립

분   전산원      국내 ITA 참조모델 및 가이드 라인 개발중

    서울시청     ITA 및 IT 자산관리 시스템 개발

    KT       IT Asset Management에 초점을 맞춘 EA 접근

             기술 아키텍처, 데이터 아키텍처, 어플리케이션 아키텍처 중심의 IT 아키텍
산            처 개발
    SKT
업            아키텍처 KB(Knowledge Base) 시스템 구축
체
    국민은행     Infa 및 application architecture 추진 중

    신용보증기금   ITA 기반의 ISP프로젝트 추진중
EA‟s Risk Factors




      •High Risk                                     •Problem defining the
      -Federal CIO Council                           proper scope of efforts
      Estimates only 20% of                          -Increases risk of failure
      efforts produce real benefits                  -Overwhelming
                                                     -Fear of starting




     •Enforcement difficulty                        •Inflexible Enterprise
     -Will fail unless EA enforcement                Architecture
      is done at low levels or in                   -Results in not meeting programmatic
      strongly centralized organization              needs or stifling innovation




                         Source : Department of Commerce, US
EA 성공요인
  The Best 10 on how to develop a successful EA

       1.Ensure architecture is business-driven

       2.Communicate plans and benefits

       3.Publicize shared architecture values

       4.Regularly publish progress updates

       5.Unify the enterprise architecture efforts

       6.Gain commitments at the grass-roots level

       7.Streamline the technical infrastructure

       8. Remain flexible

       9.Make small, incremental steps

       10.Identify quick hits
EA 평가 : Overall Quality
          Overall Quality-Enterprise Architecture Assessment
                    contents                   Organization
                                         1
                                         0
                                          8

                                         6

                                         4

                                         2
                                         0
   Research                                                   Communication and
                                                              Knowledge Management




                                                                   10 = Excellent
                                                                    0 = Poor

          Linkage to Business Planning        Clarity of Scope
EA 평가 : Overall Effectiveness

           Overall Effectiveness-Enterprise Architecture Assessment
                   Impact                       Ingrained in Culture
                                     1
                                     0
                                      8

                                     6

                                     4

                                     2
                                     0
   Scope                                                       Quantification of Value




                                                                       10 = Excellent
                                                                        0 = Poor

              Knowledge Management             Governance
EA 평가 : Overall Organization
             Overall Organization-Enterprise Architecture Assessment

                                   Reporting Level
                                        1
                                        0

                                         8


                                         6


                                         4
 Soft Skill Level                                           Inclusiveness

                                         2

                                         0




                                                                     10 = Excellent
                                                                      0 = Poor


             Technical Knowledge                     Size
                                              기존 정보화의 한계점
정보화 노하우의 변화




    Problem                 해결을 위한 접근

                          (절차, 가이드라인 등)
                                                 Solution




                                      향후 정보화 관련 노하우
  현재 정보화 관련 노하우
                                    •최종 Solution 에 중점
•방법론 적용                             •Reference 모델(아키텍처 등)의
•중간산출물 작성에 의존                        활용
•경험의 미 축적 (New Project,             •80-20 Rule
New Problem- Solving)               •경험 축적이 용이
•투입노력의 정확한 산정 어려움                   •투입 노력 산정이 용이
                                    •객체지향, 컴포넌트, SA, ITA 등
                                     이 주류
EA 도입을 위한 추진 전략
 조직의 현황, 목표, 요구사항에 적합한 architecture 도입 전략
   세가지 접근 중에서 가장 적합한 것은?
   EM 에도 매우 다양한 접근이 가능
 EA에 대한 시급성 설파
 Top의 전폭적 지원
 팀 노력/기술 및 업무 skill이 적절히 배합된 팀
 Architecture 에 대한 비전에 대한 의사소통 원활
 단기간의 유익한 결과를 만들어 낼 수 있도록!
 프레임워크 및 방법론의 확립
 가장 중요: „갑에 의한 주도’
국내 EA 향후전망

                       국내 EA 노력
                                                   •ISP 노력의 EA화 추진 확산
                       의 향후전망 ?                     - 참조모델 기반, 정보기술 아키텍처
                                                    - 전사적 아키텍처 등


                                                   •EAMS 활용 확산
                                                    - EA 산출물의 Repository화
                                                    - EAMS와 Modeling 도구의 연계
                                                    - 의사결정지원용 시스템과의 연계
                    “EA-Enabled”

                                                   •정보화 프로젝트 관리 수단
       Arc hitecture Product   Arc hitecture
             s election          활용용도              -정보화 프로젝트 적합성 평가 도구
                                                    -프로젝트 관리(일정, 비용 등) 도구로 활용
 Re fe rence Model 지원 oData-centric approach
                       f arc hitecture p roducts    -참조모델을 이용한 중소기업 정보화 지원

방법론 지원           EAMS 지원          FEAC 교육지원
                                                   •영역별 아키텍처 사업의 태동 가능성
                                                    -산업별 참조 모델 개발
            EA 제도적 기반 마련                            -Security Architecture 등 IT 핵심 영역의
                                                      아키텍처화
감사합니다.



     skim@cau.ac.kr
     02-820-6143
     011-479-5227

				
DOCUMENT INFO
Shared By:
Categories:
Stats:
views:95
posted:7/11/2011
language:Korean
pages:73