DA_1전사아키텍처 이해

전사아키텍처(상)

• 정의
  • 기업의 모습을 다양한 측며에서 분석하고 표현하여 이해하기 쉽도록 정보체계를구축하고활용
  • 현제모습과 향후 추구할모습을 정의한 청사진
• 목적
  • 기업의 목적을 가장 잘 달성할 수 있는 인프라 구성
  • 비지니스 , IT 유기적 연계
  • 비지느스 환경 벼노하에 대한 신속한 대응
  • IT투자 대비 효과 최대화
  • IT관리 효율성 제고
• 전사(엔터프라이즈)
  • 공동의 목표를 추구하기 위해 고객,상품 또는 서비스가 존재하고 이를 지원하기 위한 조직,자원,기술을 보유하며 필요한 업무 프로세스를 수행하는 조직의 집합체
  • 다 : 1 가능
• 아키텍처의 정의
  • IEEE왈 구조, 사이의 관계, 설계, 원리와지침
• 아키텍처 구성요소
  • 규칙
  • 모델
  • 계획
• 추진현황
  • 범정부적 과제임 , therefore 개발해서 보급하고 있음
• EA 프로세스
  • 비전수립> 구축, 관리 ,활용

전사아키텍처 프레임워크(중)

• 전사 아키텍처 활동에서 얻어지는 산출물을 분류,조직화,유지관리하기 위한 전체적인 틀을 정의하는 것.
  • BEFORE 전사아키텍처 정의, 전사아키텍처 프레임워크 선정
• 여러 참조모델이 있음
  • 참조 모델은 아키텍처를 수립할때 참조하는 추상활 모델

구성

• 정책 : 기업이 전사 아키텍처 수립을 어떻게 할 것인지 방향을 정의한 것
• 정보 : 기업이 구축하는 전사 아키텍처 정보의 구체적인 모습
• 관리 : 구축된 전사 아키텍처를 어떻게 관리하고 활용할 것인가를 정의한 것
  

정책

전사 아키텍처 구축 목적과 방향을 정의하는 것

• ==아키택처 매트릭스==
  • 전사 아키텍처의 정보를 체계적으로 분류한 틀
  • 일반적인 구분
    • 뷰 : 정보 수준
      • 비지니스,어플리케이션,데이터,기술 etc
    • 관점 : 활용 계층
      • 계획자, 책임자 , 설계자 ,개발자 등

  

• 전사 아키텍처 비전
  • 수립을 통하여 기업이 궁극적으로 달성하고자 하는 모습
  • 구축의 목표, 목표를 효과적으로 달성하기 위한 전략과 방향
• 전사 아키텍처 원칙
  • 전사 아키텍처 정보를 효율적으로 구축하고 기업의 목적에 맞게 전사 아키텍처 정보를 효과적으로 활용하기 위해서 조직원이 공유해야할 규범을 이야기함

정보

아키텍처 매트릭스에서 정의한 각 아키텍처 산출물에 대하여 현재 상태와 목표상태의 정보를 구축 & 이행계획 수립

• BEFORE THAT, 아키택처 정보의 영역(= 아키텍처 도메민)을 구분해야 함
  • 아키텍처 도메인은 아키텍처 메트릭스에서 뷰관점으로 영역을 구분함
  • 일반적인 도메인
    • 비지니스 아키텍처
      • 조직의 목적 입무를 지원하기 위해 수행하는 업무를 분석한걸 업무활동 단위로 분할해 표현한것
    • 데이터 아키텍처
      • 효과적인 업무처리 및 의사결정을 위해 어떤 정보가 사용되고 전달되어야하는지 표현한 것
      • 전사 데이터 구성을 분류하고 데이터 모델을 정의하는 것
    • 어플리케이션 아키텍처
      • 조직의 임무를 수행하는데 필요한 어플리케이션의 기능 및 이들과의 관계를 정의한것
      • 기업의 어플리케이션 단위를 분류, 애플리케이션 간의 인터페이스를 정의
    • 기술 아키텍처
      • 위의 3가지 아키텍처를 지원하는데 필요한 정보기술 인프라요소 및 구조 , 이들간의 관계를 표현한 것
      • 전사의 기술영역을 분류, 표준 프로파일과 기술아키텍처 모델 정의
• 현행 아키텍처
  • 도메인별로 정의된 산출물에 대해 기업의 현재 상태를 정의한것
• 목표 아키텍처
  • 도메인 별로 정의된 산출물에 대해 기업이 궁극적으로 달성하고자 하는 목표 아키텍처의 상태를 아키텍처 정보로 정의한거
• 전사 아키텍처 이행계획
  • 아키텍처 도메인 별로 현재모습에서 바람직한 목표 모습으로 이행하기 위한 이행전략과 이행계획을 정의한 것

관리

정의된 아키텍처 정보를 지속적으로 유지 관리하고 효과적으로 활용하기 위해서 아키텍처 관리체계 정립, 시스템 구축이 필요
꾸준히 평가하고 개선해야함

• 전사아키텍처 관리 체계
  • 구축된 전사 아키텍처를 유지,개선하기 위한 제도적 기반을 수립하는 것
  • 전사 아키텍처 원칙을 준수하도록 확인하고 통제하기 위한 조직과 프로세스를 정의하는 것을 포함
• 전사아키텍처 관리 시스템
  • 정보 관리의 효율성을 제고하고 정보 공유활성화하기 위해 구축하는 정보시스템
  • 일반적으로 전사 아키텍처 정보를 정의하는 모델링 도구, 정보를 저장하는 리포지터리, 사용자에게 배포하는 포털이있음
• 전사 아키텍처 평가
  • 관리와 활용 수준을 제고학 위해서(윗것들을하기위해서) 평가를 해야함
  • 이를 위해선 전사아키텍처 수준을 객관적이고 정확하게 평가할 수 있는 전사 아키텍처 성숙 모형이 필요

아키텍처 도메인 구성

기업이 아키텍처 매트릭스를 어케 정의하냐에 따라 다름
아래는 도메인(== 뷰 ) 에 따른 모델들이다

비지니스 아키텍처

• 계획자 관점
  • 전사 사업 모델
    • 전사의 범위를 정의하는 것에서 부터시작함
    • 전사를 둘러썬 내외부의 이해관계자를 분석
    • 외부 객체와의 가치사슬을 분석하여 전사를 정의
    • like 전사 가치 사슬
  • 조직 모델
    • 기업의 사업모델을 지원하기 위한 기업의 조직구조를 정의하는 것
    • 비지니스를 수행하는 지리적 위치와 내부 객체를 도출하여 기업의 조직구조와 업무 분장을 정의
• 책임자 관점
  • 업무 기능 모델
    • 기업의 업무 기능을 계층적으로 분할, 기능 내용을 정의
    • 분할 시 조직기준 ㄴㄴ, 업무기능의 유사성과 연관성을 기준으로 정의
    • 상의 업무기능은 하위업무기능의 합으로 표현가능해야함
    • 데이터와 어플리케이션의 상호비교를 통한 연관 분석이 이뤄짐
• 설계자 관점
  • 프로세스 모델
    • 업무 기능을 상세화하여 계층적으로 프로세스를 분할하고 프로세스의 활동내용을 정의하는 것
    • 프로레스란 업무수행을 위해 정보를 입력받아 활동을 통해 산출물을 생성하는 과정임
    • 데이터와 어플리케이션의 상호비교를 통한 연관 분석이 이뤄짐
• 개발자 관점
  • 업무 메뉴얼
    • 업무 기능이나 프로세스별 업무내역을 상세히 기술한 자료

어플리케이션 아키텍처

• 계획자 관점
  • 전사 어플리케이션 영역 모델
    • 기업 업무 지원하는 app식별 &app 특성 분석하여 전사 수준에서 구조화
    • app 기능과 특성에 따라 독립되어 구현되고 운영될 수 있는 app 정의
    • app 관련 업무 ,데이터 IT특성을 감안하여 app을 그룹화하여 app영역을 정의
• 책임자 관점
  • 어플리케이션 모델
    • 각 app이 지원하는 기능과 데이터 정보를 정의
    • app이 제공하는 서비스를 도출
    • app간의 연관관계 정의
    • app이나 서비스가 어느 업무 프로세스에서 사용되는지
    • 개발 방법론에 의존적
• 설계자 관점
  • 컴포넌트 모델, 클래스 모델
    • 실제 어플리케이션 개발에 필요한 설계정보를 관리하는 것
    • 컴포넌트 정의 , 클래스 정의, 데이터 흐름도(DFD)등이 해당
    • 개발 방법론에 영향을 많이 받음
    • 업무 영역별(정보계냐 운영계냐 이런거)로 다른 모델 쓸 수 있음
• 개발자 관점
  • 프로그램 목록
    • app의 최종단위인 프로그램에 대한 정보를 관리

데이터 아키텍처

• 계획자 관점
  • 전사 데이터 영역 모델
    • 상위 수준의 전사데이터 영역을 분류하여 표현한 것
    • ex) 상위 주제 영역 수준의 데이터 구성도
      • 주제 영역 : 유사 데이터를 그룹화, 업무기능과 대응 되는 개념
    • aka 개괄 데이터 모델
• 책임자 관점
  • 개념 데이터 모델
    • 전사수준의 데이터 모델
    • 단위 주제 영역 or 핵심 엔티티 정도를 표현한 모델
    • 전체적으로 표현하는 기본틀
• 설계자 관점
  • 논리 데이터 모델
    • 개념데이터 모델을 기본정보로해서 업무요건을 충족시키기 위한 데이터의 상세구조를 논리적으로 구체화한것
    • 수집된 업무 관련 데이터정보 및 사전에 작성된 산출물을 기반으로 필요한 모든 엔티티를 도출
    • 식별자 속성 관계와 서브타입등을 정의
    • 엔티티 속성에 대한 명칭,정의 형식,규칙,코드 등을 전사적인 차원의 표준으로정의하여 관리해야함
• 개발자 관점
  • 물리 데이터 모델
    • 기술적환경과 특성을 고려하여 물리적 데이터 구조를 설계하고 데이터메이스 객체를 정의한 것
    • 논리 데이터모델 > 물리적인데이터 구조
    • 데이터 무결성을 보완하여 정의
      • 데이터 분산설계에 따른 데이터 무결성 등
    • 추가적인 무결성 규칙을 정의
    • 데이터 접근향상을 위한 인덱스설계 비정규화 과정 등을 수행

기술 아키텍처

위에서 정의된 요건을 지원하는 전사의 기술 인프라 체계를 정의하는 것
이식성,확장성을 강화하거나 독립성을 확보하거나 상호운용성을 강화하는 효과를 기대 가능
개별 기업에서도 기술참조 모델을 정의하는 것이 일반적

• 계획자 관점
  • 전사 기술 영역 모델
    • 기업이 업무활동에 필요한 정보기술의 영역을 상위수준에서 분류한 것
  • 기술 참조 모델
    • 기업이 업무활동에 필요한 기능들을 수행하기 위해 요구되는 기술정보를 상위수준에서 논리적으로 분류한 틀
    • 전사 기술 영역 모델과 같은 범주로 볼 수 있다
      • BUT 일반적인 표준을 최대한 수렴하여 정의하는 것이 특징
• 책임자 관점
  • 표준 프로파일(SP)
    • 기술 참조 모델에 명시된 서비스를 지원하기 위한 정보 기술 표준의 집합
    • 기업의 모든 기술 아키텍처 요소들에 영향을 미치는 표준을 포함
    • 표준들은 시스템의 이식성, 확장성,상호운영성,호환성을 제고하게됨
    • 일반적으로는 기술 표준을 프로파일 대상
      • 최근엔 제품도 포함시킴
• 설계자 관점
  • 기술 아키텍처 모델
    • 계획자 관점에서 정의한 모델에서 서비스 카테고리별로 아키텍처 패턴을 정의하거나 구성요소(SW, HW,NETWORK 등)에 대한 배치도를 정의
• 개발자 관점
  • 기술자원 목록, 제품목록
    • 표준 프로피일이나 기술아키텍처별로 관련된 기술자완목록, 제품목록을 기술아키텍처 정보로 관리

전사아키텍처 프레임워크 사례

선진모델 참고하되 기업의 특성에 맞는것을만들어야함 (유연한 사고)

• ZEAF (자크만 프레임워크)
  • 5가지관점과 6사지 묘사방법으로 정의
  • 대표적인 예임
• FEAF (미연방정부)
  • 8개 구성요소 , 4단계에 걸쳐 점진적으로 진행
  • 마지막단계에 자크만 프레임워크 모델내용을 관리
  • 세그먼트 접근법을 채택
• TEAF (미재무성)
  • 임마가 메트릭스
• DoDAF (미국방성)
• TOGAF(오픈그룹)
  • 아키텍처 개발방법,기술참조 모델,표준정보기반(표준요약정보를 정의한 DB)
  • 빌딩 블록 정의에 의한 접근 방식 (= 구성단위의 문제해결 방식)
• 한국정보 AF()

전사 아키텍처 참조모델(상)

• 아키텍처 구성요소를 식별하여 표준화한 것
• 기관이나 기업의 전사 아키텍처를 수립할 때 참조하는 추사오하된 모델
• 개념적인 모델을 추상화, 구성요소를 재사용 가능한 방식으로 생성
  • 다양한 관점을 충족시킬수 있도록함
• wellknown 참조모델
  • 업종별 : 국방 ,공공
• 미연방정부 전사 아키텍처에서 처음 제시된 개념
  • 기준을 제시하기 위해 생김
• 기술 참조모델(TRM)
  • 가장 잘 활용 되고 있는 것
  • 비교
    • 미연방
      • 지방주정부간의 연동을 고려한 접근
        • 내부 IT서비스를 위한 참조 모델로 활용하기 빡셈
      • 프레임워크에서 업무,서비스,데이터와의 연관성이 높음
      • 내외부 3계층 구조로 되어있음
        • 대내외 여녜설명이 용이함
      • 많은 기술 체계를 폭넓게 수용
    • 오픈그룹
      • 어플리케이션 이식성 지원을 위해 필요한 기반 플랫폼의 구조와 서비스에 중점
      • 통신 기반의 인터페이스를 중시
      • 어플리케이션에 대한 상세한 분류 체계를 제공
      • 표준위주의 이론적접근으로 플랫폼 네트워크 통신기반에 대해서는 상세한 분류가 이뤄지지 않음
    • 가트너
      • 데스크톱 app, 엔터프라이즈 app 구분
      • 실용적인 분류체계 제공
      • BUT 상세 분류 기준 미흡
    • 정보화 진흥원
      • 상호연계성 운용성을 보장
      • 컴포넌트 기반 아키텍처 및 서비스 기반 아키텍처를 지향
      • 업무, 서비스, 데이터 참조모델 등과 함께 범정부 참조 모델중 하나
      • 국내의 정보화 환경을 고려하여 유망하고 안정된 기술 산정
• 참조 모델 구축 방법
  1. 공통적 특성을 추출하여 산업군에 맞게 범용적으로 만듬
     • 단점 : 요소간 경계불명확 , 정의 불명확
  2. 복잡하고 대표적인 기업 선정후 표본으로삶기
     • 단점 : 기업은 하위수준까지 공개안됨.

법정부 EA참조 모델

성과 말고든 도메인 별로 참조모델이 있음 그리고 그 나머지는 각 아키텍처에 기준이됨

업무

아키텍처 대상기관의 사업,업무 등을 전체적으로 분류,정의 하는 것
비지니스 아키텍처의 기준

• 독립적인 업무 기능을 중심으로 정의한 모델
• 업무 영역(목적 기준) > 업무 단위 > 세부업무 순으로 나눔
• 정부 영역의 분류
  • 정책분야, 정책영역, 대중소기능 등
• 일반 기업의 분류
  • 사업영역, 업무 영역, 업무 기능
    

서비스

응용 서비스의 기능을 분류하고 정의
응용아키텍처의 기준

• 업무와 서비스 연계및 재사용을 촉진하고 중복개발을 방지하기 위함
  • 이럴려면 단윌화, 통합된 분류체계를 제공해야함
• 업무 및 조직에 독립적인 표준 서비스 분류체계
• 업계 정부간의 컴포넌트 개발, 축적 ,유통 활성화를 촉진 및 식별 용의
  

데이터

기관간에 교환되는 주요 데이터 요소를 분석하여 이를 정의하고 표준화
데이터 아키텍처의 기준

• 기관간의 공통 정보 파악과 활용을 지원하기 위함
• 표준화 재사용을 지우너하기 위한 범정부 데이터 분류 및 표준화 관리를 위한 기준과 체계를 정의
• 세부요소
  • 범정부 데이터 모델
    • 범정부에서 구축, 활용하고 잇는 데이터 식별 및 관계 도식화
  • 데이터 분류
    • 범정부의 데이터는 분류에 따라 그룹핑, 매핑
    • 관리 검색에 용의
  • 데이터 구조
    • 스키마 생각하면됨, 소유주 항목정의 ,관계 요소정보 저장
    • 데이터 요소에 대한 표준화 항목과 가이드 제시
  • 데이터 교환
    • 전송 프로토콜생각하면됨
  • 데이터 관리
    • 데이터 품질 보안 ,표준화 등의 유지를 위한 정책규칙프로세스 조직구조 등을 정의

기술

정보 기술을 분류 및 식별
기술아키텍처의 기준

• 업무와 서비스 구성요소의 전달과 교환, 구축을 지원해주는 표준, 명세, 기술 요소를 표현하기 위함
• 정보화 추진을 위한 기술을 식별,정의하고 관련 기술의 표준과 동향관리
• 재사용 제고 ,안전한 전달의 기반환경을 구축, 상호운영성을 확보
• 유사성 판단 기준으로도 사용 가능
  

성과

정보화 성과의 측정을 위한 항목과 지표 및 방법을 제시

• 성과 관리를 위한 구성요소와 관계를 정의
• 입출력 및 과정 최종성과간의 인과간계를 명확히 하여 계층과의 연계를 증진시킴
• 개선가능성을 파악
• IT자원 효율적으로 관리
  

전사 아키텍처 구축(-)

방향수립(프레임워크 정의 포함) > 정보 구성정의 > 정보 구축

정보 구성 정의(중)

전사 아키텍처 정보는 업무 구성요소 와 관계를 포함함

• 정보는 가능한 변한지 않는 구성요소를 도출하여 정의하는 것이 이상적
  • 이익 >> 관리하는데 비용 이어야 하기 때문
    아래 순서대로 이루어지는 것 같다.

아키텍처 매트릭스 정의

산출물과 구성하는 요소를 분류 하기 위함

• 모델과 원칙 정보를 통일된 시각으로 볼 수 있는 논리적인 틀
• 도메인의 산출물을 식별,정의하기 위한 논리적 체계를 정의
• 모든 구성요소 관계포함 ㄴㄴ
• 구성
  • 2차원 매트릭스형태임
  • 관점 : 의사결정 유형
    • 업무와 IT조직의 이해관계자를 식별
    • 3-5단곈데 자세할수록 상세하게 관리
  • 뷰 : 아키텍처 정보 유형
    • 특성이 비슷한 아키텍처 정보를 그룹화
• 메트릭스의 각셀에 산출물을 정의한다.
  
• DB형태로 구축되어 지속적으로 갱신할라면 산출물을 구성요소단위로 분류하고 관계를 명확히해야함
  • 연관관계가 많을 수록 활용가치가 높아짐
• 목적에 맞게 정의 되의 되었는지 확인 잘 해야함
  • 이걸로 커뮤니케이션하기 때문

참조 모델 정의

기업의 기준모델로 정의할 참조 모델의 체계와 구조를 정의하고 컨텐츠를 구축

• 큰기업이나 정부가 참조 모델정의하면 조만한 기업들이 참고해서 전사아키텍처 구성요소의 타당성을 확인
• 체계적 분류, 표준화 > 통합성, 중복 ㄴㄴ , 상호운용성향상 등을 목적으로 되어잇음
• therefore 고대로 쓰지말고 참고만하셈ㅇㅇ

전사 아키텍처 원칙 수립

목표 달성위해 구성원들이 공통적으로 지켜야할 규칙을 정

• 의사결정의 객관적 기준 제시 > 효과적으로 업무 협조와 조정가능, 투명성제공
• 연결성 강화
• 구성요소
  • 원칙 : 원칙의 내용을 간략하게
  • 의미 : 원칙이 가지는 의미를 설명
  • 근거 : 원칙이 채택된 원인과 배경
  • 기대효과 : 원칙이 전사아키텍처 수립에 미치는 영향 및 기대효과
• 범위에 따른 구분
  • 전체 적용 : 방향수립단계서 정의 ㄱㄴ(꼭그런건아닌듯?)
    • 상반되는 지향점을 갖지 않도록해야함
  • 아키텍처별 적용 : 아키텍처 메트릭스 결정이후에 정의 가능
    • 도메인 별로 원칙을 정의함

정보 구축(상)

• 아키텍처 메트릭스의 전범위에 걸처 수행하는게 바람직함
• 각셀의 산출물 기준으로 현제 모델,문서를 보완하여 현행화하는 작업수행
• 구축 방식
  • 상향식
    • 최하위에있는 구성요소 조사분석 > 공통점파악
    • 점점 추상화시킴
    • 최상위 업무 분류의 수준 (레벨)이 다를 수 잇음(추상화정도가 다를듯)
  • 하양식
    • 점점 구체화시킴
    • 일반적인 분류기준이나 목적에 따라 분류기준을 따름
      • 관점이 명확함
    • 업무가 누락되거나 어디에도 포함되지 않을 수 있음

현행 정보 구축

상위 수준 업무 or 시스템에 대한 분류를 우선적으로 수행하는게조음
why? 그이후엔 병렬적으로 정보구축수행가능ㅋ

• 비지니스
  • 도출된 업무 기능으로 조직 주고와 연계성을 파악
  • 추훼 어플리케이션이나 데이터 연관관계 파악해서 상호 검증을 수행함
  • 업무 기능 도출
    • 상향식 : 단위 업무를 조사 후 유사성 기준으로 묶어 업무 기능 도출
    • 하양식 : 가치 사슬 분석을 통해 최상위 업무기능을 도출
  • 업무 프로세스 정의도 매한가지
  • 정의 내역
    • 전사 사업모델 분석
    • 조직 모델분석
    • 업무 기능 모델 정의
    • 프로세스 모델 정의
    • 업무 매뉴얼 파악
• 어플리케이션
  • 어플리케이션 구조, 서비스, 응용기능 등을 도출
  • 다른 구성 요소와의 연관관계를 분석하여 상호 간 정합성을 검증함
  • 업무 기능 분류를 기반으로 어플리케이션 분류 & 연관관계 분석에서 시작
  • 정의 내역
    • 전사 어플리케이션 영역 식별
    • 어플리케이션 모델 정의
    • 프로그램 목록 파악
    • 애플리케이션 원칙,표준 파악
• 데이터
  • 업무 기능과 어플리케이션과의 분석을 통하여 정확성 검증
  • 상향식 : 각 시스템에서 사용하는 데이터 정보를 분석하여 데이터 모델로 정렬하여 표현
    • 데이터베이스의 물리 테이블에 대응되는 논리개체를 정의함 > 논리개체를 주제별로 묶어 개념개체로 정의 > 개념개체의 관계 정의
    • 실무자 수준의 정보를 구축할 경우 상향식이 더 적합
  • 하양식 : 기업의 업무수행을 위해 필요한 데이터 요건을 식별하여 데이터 모델로 표현
    • 의사결정,현황파악의 정보요건을 바탕으로 필요데이터 도출 > 정보 요건을 상세화 하면서 세부 데이터 모델을 정의
    • 계획자 수준의 상위정보만 구축할경우 더 적합
  • 정의 내역
    • 전사 데이터 영역 식별
    • 개념, 논리 물리 데이터 모델 정의
    • 데이터베이스 객체 파악
    • 데이터 원칙 ,표준, 관리 프로세스 파악
• 기술
  • 기업의 전산장비, 시스템소프트웨어 네트워크 등 기술 인프라 구성을 체계적으로 분류하여 표현한 것
  • 전사의 인프라영역 분류 > 영역별 구성요소 도출> 구성요소간 관계 식별
  • 기술 참조 모델을 사전에 정의하면 전체적인 일관성 확보 가능
  • 정의 내역
    • 전사 기술정보 식별
    • 기술참조모델 정의
    • 기술 표준 분석
    • 기술 아키텍처 요소 식별
    • 기술 자원목록, 제품 목록 파악

목표 정보 구축

현재 문제점 개선사항 도출 후 목표아키텍처에 반영하는식
비지니스 아키텍처 정의 > 이를 효율적으로 지원하는 아키텍처 정의
어플, 데이터 둘다 비지니스와 서로의 연관관계를 비교하여 검증
현행 아키텍처와 달리 아키텍처 매트릭스의 개념적 수준까지 정의
이하는 일반적으로 실제 시스템 구축단계에서 수행(유연성확보위해)
참조 모델과의 연계성을 파악햐여험

• 비지니스
  • 현행 추가 업무와 개선 요구사항을 반영함
  • 사전에 업무프로세스 재설계(BPR) 같은 작업이 이뤄져야함
  • 참조모델 > 관계를 파악
  • 비즈니스 아키텍처 정의에 따라 다른것들이 결정되서 매우중요
    • 적합성을 판단하는데 중요한 기준이됨
  • 정의 내역
    • 전사 사업 모델 정의
    • 조직 모델 정의
    • 업무 기능 모델 정의
    • 프로세스 모델 정의
    • 업무 매뉴얼 정보 구축
• 어플리케이션
  • 목표 비지니스 아키텍처를 지원하는 전사 어플리케이션 구조를 정의하는 것
  • 목표 업무의 개선요구나 추가적인 어플구축요구 , 어플 자체 개선요구를 아키텍처에 반영
  • 참조 모델 > 상위 기업,유관기업과의 인터페이스를 제고할 수 있도록함
  • 정의 내역
    • 전사 어플리케이션 영역 정의
    • 애플리케이션 모델 정의
    • 컴포넌트 모델 정의
    • 프로그램 목록 정보 구축
• 데이터
  • 목표 비지니스 아키텍처를 지원하는 데이터를 식별하여 모델로 표현하는것
  • 업무 개선,추가,자체개선 요구를 데이터 아키텍처에 반영(like app)
  • 참조모델 > 상위 기업,유관기업과의 인터페이스를 제고할 수 있도록함
  • 정의 내역
    • 전사 데이터 영역 모델 정
    • 개념,논리,물리 데이터 모델 정의
    • db 개체 정보구축
    • 데이터 원칙 표준 관리 프로세스 정의
• 기술
  • 어플리케이션, 데이터 아키텍처를 잘 지원할 수 있는 기술아키텍처를 정의
  • 최근 기술 추이와 기업특성을 고려해야함
  • 참조모델 > 전체 기술 인프라의 상호운영성을 제고할 수 있도록함
    • 일반적으로 기술참조모델 바탕으로 상세화함
  • 표준프로파일은 조직수준에 따라 달라짐
    • but동일 기업내 사용되는 표준은 표준프로파일과 일관성을 가져야함
    • 개방형시스템구현과 국제 표준을 항상 고려해야한다
      • 개방형환경을 보장하는건 아님
        • 따로 추가로 정의하긴해야함
    • 기술발전,환경,비전, 업무에 따라 계속 갱신해야함
  • 정의 내역
    • 전사 기술 영역 모델 정의
    • 기술 참조 모델 정의
    • 표준 프로파일 정의
    • 기술 아키텍처 모델 정의
    • 기술 자원 목록, 제품 목록 정보 구축

전사 아키텍처 관리(-)

EA 관리 체계(중)

• 거버넌스라고도함
• 정보 아키텍처 정보를 활용할 수 있는 체계를정립하는 것
• 유지관리하기 위한 조직과 프로세스측면의 기반을구축하는것을 의미
• 의사결정 과정에서 전사아키텍처 정보를 활용함
  • 일관성과 합리성이 증대되는 것이 목적
• IT 거버넌스 vs EA 거버넌스
  • IT : IT관리의 효율성과 효과성 증대를 위한 IT전반에 대해 정립
  • EA : EA를 유지하고 지속적으로 개선하기 위해 제도적 기반을 구축하는 것을 의미
  • EA 거버넌스 ⊂ IT 거버넌스
• 정착을 위해서는 장기적인 접근이 필요함
• IT관련 조직의 노력만으로 달성 불가, 전사적인 추진체계가 되어야함
• 관리 체계(= 거버넌스)의 구성요소
  • 조직
  • 프로세스
  • 인력

조직

• EA 관리를 위해 필요한 직무와 직무간의 관계, 업무 분장을 정립하는것
• 계획 ~ 실무자까지 다양한 시각에서 책임과 역할이 정의되어야함
• 관리 조직 정의 시 고려사항
  • IT조직의 규모
  • EA 구축의 목적
    • 신시스탬 구축위해라면 프로젝트관리조직도 정의해야함
  • IT 조직과 현업과의 관계
• 예시(앞에 EA붙어있음)
  • 담당 임원 : 수립의 의사결정, 전사적지원확보
  • 아키텍트 : EA 원칙 방향정의및 총괄
  • 영역별 담당자
  • 관리시스템 관리자 : 관리시스템 관리구축,운영담당
  • 추진 위원회 : 자문단

프로세스

• EA 관리하기 위한 활동을 정의하는 것
• 전체 정보관리 업무체계와 일관성이 확보되어야 함
• 괄리하는 세부 업무분류 저의 , 규정이나 표준화 된 수행절차 or 문서 양식을 정의하는 것도 포함함
• IT프로세스에 관리프로세스 추가해놓고 EA관리 프로세스라 하면안됨
  • 제대로 수행안될가능성이 높음
    • 이러면 최신성, 완전성이 떨어짐
  • 따라서 IT프로세스를 EA관점에서 식별해서 EA정보 중심으로 설계해야함
• 예시(앞에 EA붙어있음)
  • 기획
  • 변경관리
  • 준수 통제
  • 활용 지원
  • 관리 시스템 관리
  • 평가

인력

• EA 관리를 담당하는 직무별 역량을 정의하고이를 확보하기 위한 방안을 정의함
• 관리에 필요한 역량요소를 분류 > 직무별로 할당
• 역량요소를 확보하기 위한 교육계획을 수립
  • 리더십,기술적,활용 역량
• 역량 수준을 평가할 수있는 체계를 포함
• 영역별로 지속적으로 발전시킬 수 있는 아키텍트가 조직내부에있어야함
  • 즉 전문가 육성을해야함

EA 관리시스템(하)

구축관리하고활용되는 모든 EA프로세스에 대한 효율성을 제고하기 위한 정보시스탬
EA 모델링 >EA레포 > EA 포털 > 정보활용

EA 활용(상)

• 영역에 따른 분류
  • 목표 아키텍처 이행계획
  • 전사 아키텍처정보 상시활용
• 효과적 활용방안
  • EA자체가 좋아야함
    • 정보관리하고 통제할 수 있는 전담조직이있어야함
    • 정보를 전사적으로 공유활용할 수 있는 절차와 시스템이필요함
    • 정확한 기준이 있어야함

목표 아키텍처 이행계획

• 주로 새로운 시스템 추진을 목적
• 현행과 목표 EA차이를 분석하여 프로젝트를 정의
• 유사성과 상호연관성을 고려하여 우선순위 결정
• 이행전략과 세부이행계획 , 변화관리계획수립
  • 세부이행계획은
• 주요 활동/작업
  • 아키텍처 GAP(차이) 분석
  • 프로젝트정의
  • 이행전략 수립
  • 이행계획 수립
    • 필요인력, 자원리소스계획,추진일정, 비용계획 등이 포함
  • 변화관리 계획 수립

전사 아키텍처 정보 상시 활용

• EA정보를 활용하여 IT업무 지원하는 것
• 적용영역을 적극적으로 발굴해야함
• 정보활용 영역의 예
  • IT 기획 관리
    • 계획 수립시 EA활용해서 목표시스템정의하고 계획수립함
    • 투자에도도움을 줌
    • 정보화계획수립에 활용
    • 업무프로세스 혁신에 활용
  • IT 구축 관리
    • 프로젝트 계획에 활용
    • 시스템개발에 활용
    • 중복배제 , 재사용성, 통합성 제고 > IT비용 절약가능
    • EA대부분이프로젝트 관리의 기준이됨
  • IT 운영 및 통계
    • EA바탕으로 시스템변경을할때 반영
    • 문제생길시 EA가 큰도움이될수있음
    • 도입, 폐기의 근거자료가 될 수있음

전사아키텍처랑 데이터아키텍처

• 그래서 님 데이터아키텍처 배우는데 왜알아야함?
  • 전사아키텍처프레임워크 바탕으로 데이터아키텍처 설꼐해야함
  • 그리고 다아키텍처영역과 잘 연계가 되어야함요 ;
• 아키텍처 매트릭스아시죠? 그거졸라생각해야해용
  1. 범위 통합
     • 범위 전체에 대해 각모델 내의 불일치성을 제거
       • 중복을 제거한단소리임
  2. 수평 통합
     • 타 영역과 불일치성을 제거
       • 운영의 조화와 관련
  3. 수직 통합
     • 관점간의 불이치성을 제거
       • IT투자의 품질과 관련
       • 요구사항에 대한 일치 정렬개념과 연관