DA 가이드

DA, SQL, DB보안 등 실무자를 위한 위한 DB기술 바이블!

전사아키텍처 정보 구성 정의

전사아키텍처 이해
전사아키텍처 구축
전사아키텍처 정보 구성 정의
작성자
admin
작성일
2021-02-10 12:37
조회
4192

전사아키텍처 정보 구성 개요

전사아키텍처 정보는 기업을 잘 이해하기 위해 필요한 업무와 정보기술에 대한 정보로서 활용할만한 가치가 있고 관리가 용이한 정보라고 정의할 수 있다. 또한 전사아키텍처 정보는 업무와 정보기술의 구성요소와 구성요소 간의 관계를 포함한다.

전사아키텍처 정보는 가능한 변화하지 않은 구성요소를 도출하여 정의하는 것이 이상적이다. 전사아키텍처 정보는 관리비용 대비 효과를 고려해야 한다. 궁극적으로 전사아키텍처 정보를 활용하여 얻을 수 있는 이익보다 관리하는 데 비용이 더 많이 소요된다면 전사아키텍처 정보로 관리하는 의미가 없다고 할 수 있다. 전사아키텍처 정보의 각 구성요소가 현실적으로 관리가 가능한지는 기업의 상황을 판단하여 관리 가능한 정보를 식별한 후 그 정보를 전사아키텍처 정보로 구축하여야 한다.

전사아키텍처 정보를 표현하기 위해서는 우선 전사아키텍처 산출물과 이를 구성하는 요소를 분류하는 것이 필요하다. 흔히 매트릭스 형태로 작성하는 데 이를 아키텍처 매트릭스라고 한다. 이는 기업의 업무와 정보기술을 보다 통합적으로 볼 수 있고, 전체를 이해할 수 있게 한다.


아키텍처 매트릭스 정의

아키텍처 매트릭스 개념

아키텍처 매트릭스는 전사아키텍처 프레임워크의 핵심 구성요소로 전사를 설명하는 모델과 원칙정보를 통일된 시각으로 볼 수 있는 논리적 틀이다. 전사아키텍처 프레임워크가 전사아키텍처 계획, 실행, 운영에 필요한 모든 구성요소와 구성요소간의 관계를 포함하는 것이라면, 매트릭스는 협의의 프레임워크로 아키텍처 도메인의 산출물을 식별하고 정의하기 위한 논리적 체계를 정의하는 것이다.


아키텍처 매트릭스 구성

아키텍처 매트릭스는 일반적으로 의사결정 유형(관점)과 아키텍처 정보 유형(뷰)의 두 축을 기준으로 2차원의 매트릭스 형태를 띠고 있다. 아키텍처 정보의 활용 방안을 토대로 의사결정 유형과, 아키텍처 정보 유형으로 구분하여 각 항목에 필요한 산출물을 도출하여 아키텍처 매트릭스를 정의한다.

의사결정 유형은 조직의 의사결정 구조와 시스템의 생명주기와 관련된 이해관계자를 파악하여 각 조직 사이의 이해 관점을 정의한다. 아키텍처정보 유형은 정보시스템을 이해하기 위해서 필요한 정보를 유사한 것끼리 그룹화하고, 기업의 환경에 맞도록 추상화의 레벨을 맞추는 것을 의미한다.


의사결정 유형

의사결정 유형은 조직의 의사결정 유형을 계층적으로 구분한 것으로, 조직이 수행하는 업무의 의사결정 특성에 따라 단계를 정의한다. 업무와 IT 조직의 이해관계자를 식별하고, 이를 바탕으로 정보화 의사결정 계층의 구조를 분석하여 의사결정 유형을 정의한다. 전사아키텍처를 구축하는 목적에 따라 3~5단계로 나눌 수 있는데, 이는 전사아키텍처 정보의 관리 수준과 범위에 영향을 준다.

의사결정 단계가 많을수록 보다 상세한 전사아키텍처 정보가 관리되며 이는 전사아키텍처 정보 구축과 관리의 비용에도 영향을 준다.

[그림 1-2-3] 아키텍처 매트릭스 구성 정의 예


아키텍처 정보 유형

아키텍처 정보 유형은 특성이 비슷한 아키텍처 정보를 그룹화 한 것으로, 기업이 관리하는 모든 아키텍처 정보를 수집하여 분류한다. 아키텍처정보 유형에는 업무 영역과 정보기술 영역으로 구분한다. 업무 영역은 조직, 사업 영역, 업무 기능, 업무 프로세스 등을 포함하고 정보기술 영역은 데이터, 애플리케이션, 기술 인프라 등을 포함한다. 흔히 업무, 데이터, 애플리케이션, 기술로 나눈다.

의사결정 유형의 구성요소는 기업의 정보화 관련 의사결정 계층 구조를 업무 분장이나 전결 규정, 면담 등을 통하여 파악하고, 의사결정 범위, 주기, 간격에 따라서 각 이해관계자별로 계층 구조를 정의한다. 아키텍처 정보 유형의 구성요소는 선진 사례의 뷰 구성을 바탕으로 기업의 정보 관리 요건을 반영하여 조직간 조정과 합의를 거쳐 결정한다.

[그림 1-2-4] 관점(Persective) / 뷰(View) 도출 절차

아키텍처 매트릭스 정의시 선진 사례의 무조건적인 도입보다는 선진 사례에서 프레임워크를 참조하되, 기업의 현황을 고려하여 기업의 전사아키텍처 목표 달성에 필요한 구조로 아키텍처 매트릭스를 정의하는 것이 바람직하다.


산출물 정의

의사결정 유형과 아키텍처정보 유형으로 구성된 매트릭스의 각 셀에 필요한 산출물을 정의한다. 산출물의 정의는 어떤 방법론을 사용하는가와 기업의 업무 특성이나 문화에 의하여 좌우된다. [표 1-2-1]과 [표 1-2-2]은 정보통신부와 전산원에서 발표한 아키텍처 매트릭스와 표준 산출물 예이다. 이 예는 하나의 가이드일 뿐 기업이 반드시 따라야 하는 것은 아니다.

[표 1-2-3] 공공 부문 아키텍처 매트릭스 예(공통, 보안 부분 제외)


뷰(View)/관점(Perspective) 업무 데이터 응용 기술
계획자 - 조직 구성도/
정의서
- 업무 구성도/
정의서
- 데이터 구성도/
정의서
- 응용 시스템 구성도/
정의서
- 표준 프로파일
- 기반 구조 구성도/
정의서
- 기술 자원 목록
책임자 - 업무 관계도/
기술서
- 업무 기능 분할도/
기술서
- 개념 데이터 관계도
/기술서 - 데이터 교환 기술서
- 응용 시스템 관계도
/기술서 - 응용 기능 분할도/
기술서
- 기반 구조 관계도/ 기술서
설계자 - 업무 절차 설계서 - 논리 데이터 설계서
- 데이터 교환 설계서
- 응용 기능 설계서
- 응용 분산 시스템 설계서
- 기반 구조 설계서
- 시스템 성능 설계서
개발자 - 업무 메뉴얼 - 물리 데이터 모델 - 응용 프로그램 목록 - 제품 목록

[표 1-2-4] 공공 부문 아키텍처 산출물 예(공통, 보안 부분 제외)


관점 산출물명 설명
업무 조직 구성도/정의서 기업의 조직 또는 조직의 유형, 역할 간의 관계를 표현한 것으로 관련된 이해 당사자의 관계와 상위 조직과 하위 조직 간의 관계를 식별함
업무 업무 구성도/정의서 기업 비즈니스 아키텍처의 개념적 모습을 도형으로 묘사한 산출물.
기업의 업무 기능을 사용자가 이해하기 쉽게 도식화하여 표현함으로써 비즈니스 아키텍처에 대한 이해와 이해 당사자 간의 대화 수단으로 활용
업무 업무 관계도/기술서 업무 기능 간에 의존 관계를 도식화하여 표현. 업무 기능 간의 정보 흐름을 추적할 수 있음
업무 업무 기능 분할도/
기술서
조직의 업무 기능을 계층 구조로 분류하여 표현한 것으로, 업무 기능을 식별하여 그 구조와 업무의 활동 내용을 기술함
업무 업무 절차 설계서 업무 활동의 흐름을 기술한 산출물로, 각 업무 활동이 어떤 역할과 이벤트에 의하여 수행되고, 어떠한 정보를 주고받는지 등을 기술함
업무 업무 매뉴얼 업무 기능과 업무 활동별로 세부 내역을 설명한 매뉴얼 정보 또는 그 목록
응용 응용 시스템 구성도
/정의서
기업의 응용 시스템을 상위 수준에서 분류하고 표현함으로써 전체적으로 응용 시스템의 구조를 파악할 수 있는 산출물
응용 응용 시스템 관계도
/기술서
응용 시스템 상호 간의 연계성을 표현한 것으로 응용 시스템 상호 간의 데이터 흐름을 파악할 수 있음
응용 응용 기능 분할도/
기술서
응용 시스템의 기능을 계층적으로 표현한 것으로, 응용 기능의 업무 연관성과 재사용성을 파악하도록 함
응용 응용 기능 설계서 응용 시스템의 기능을 정의하고 응용 기능 간의 상세 구조와 데이터 흐름을 표현한 것으로, 기능 간의 완전성 확인 가능
응용 응용 분산 시스템
설계서
시스템의 분산 계층을 정의하고 분산 자원을 계층별로 할당하여 표현한 산출물
응용 응용 프로그램 목록 응용 시스템에 정의된 응용 기능을 제공하는 프로그램의 정보 또는 목록. 시스템 개발 비용 산정을 위한 기반 자료로 활용됨
데이터 데이터 구성도/
정의서
기업의 전체 데이터를 상위 수준에서 표현한 것으로 데이터베이스 구성현황을 한눈에파악할수있도록함‘( 개괄데이터모델’과유사함)
데이터 개념 데이터 관계도
/기술서
업무 수행을 위해서 필요한 데이터의 구조를 개념적 수준에서 표현 한 것. 주제 영역 또는 중요 엔터티 수준의 데이터 관계도. 업무 수행 에 필요한 데이터를 통합적으로 파악할 수 있음‘( 개념 데이터 모델’ 과 유사함)
데이터 데이터 교환 기술서 업무 기능 간에 교환되는 데이터 교환 요구 사항을 식별하여 표현한 것
데이터 논리 데이터 설계서 업무를 수행하기 위해서 필요한 데이터의 구조를 논리적 수준에서 충분히 표현한 것으로, 데이터 유형(엔터티 타입), 식별자, 속성, 관계, 데이터 업무 규칙 등을 포함
데이터 데이터 교환 설계서 응용 기능 간의 데이터 교환의 요건을 식별하여 이를 상세화하며 표현한 산출물
데이터 물리 데이터 모델 업무 기능 또는 응용 시스템에 의하여 사용될 데이터를 실제 데이터 베이스로 구축하기 위해 필요한 물리적 특성을 정의한 모델. DBMS의 특성이나 거래 특성, 성능 요건 등을 고려한 설계가 됨
기술 표준 프로파일 기술 참조 모델에서 정의한 기술 요소별로 아키텍처 구현에 적용되어야 하는 표준과 규칙, 제품 평가 기능 등을 기술한 자료
기술 기반 구조 구성도/
정의서
기업의 기반 기술 구조에 대하여 상위 수준에서 그래픽하게 표현한 것으로 기반 기술 아키텍처를 한눈에 파악할 수 있도록 함
기술 기술 자원 목록 기업의 기술 자원에 대해 전체적으로 현황을 파악할 수 있도록 작성된 현 시스템에 대한 현황서
기술 기반 구조 관계도/
기술서
애플리케이션 또는 기술 서비스별 시스템 구성을 표현한 것으로, 시스템 간의 연결 관계 및 시스템 사양을 표현
기술 기반 구조 설계서 시스템의 지리적 분포를 조망할 수 있는 산출물. 하드웨어, 소프트웨어, 네트워크 등이 표현 대상
기술 시스템 성능 설계서 시스템에 요구되는 성능 요건을 충족시키기 위해 어떤 특성이 가장 핵심적인지를 식별하여 표현
기술 제품 목록 정의된 기술 서비스와 표준을 지원하는 제품에 대한 정보 또는 목록
매트릭스 셀 정의 내역
  • 현행 산출물 분석
  • 목표 산출물 정의
  • 산출물간 연관성 정의
  • 산출물 표현 방법 및 세부 구성 정의
전사아키텍처 정보 구성요소 정의
전사아키텍처 정보 구성요소 식별

전사아키텍처 정보를 공유정보로 구축하기 위해서는 전사아키텍처 산출물에 포함된 정보를 중복이 없고 상호관계가 유기적으로 연결되도록 구성요소를 정의해야 한다. 전사아키텍처 정보가 문서 형태로만 관리될 경우에는 이러한 작업이 필요 없지만, 전사아키텍처 정보가 데이터베이스 형태로 구축되어 지속적으로 갱신되기 위해서는 전사아키텍처 산출물을 구성요소 단위로 분류하고 구성요소 간의 관계를 명확히 할 필요가 있다.

[그림 1-2-5] 전사아키텍처 정보 구성 요소 식별 예

[그림 1-2-3]과 같이 식별된 구성 요소는 산출물의 종류와는 다른 형태를 보인다. 전사아키텍처 구성 요소는 전사아키텍처 정보를 구성하는 기초 단위라고 할 수 있으며, 산출물은 여러 개의 전사아키텍처 정보 구성 요소로부터 도출된 복합적인 정보라 할 수 있다.


전사아키텍처 정보 구성요소 연관관계

전사아키텍처 정보 구성요소 간에는 많은 연관관계가 있다. 이러한 구성요소 간 연관관계를 통해 특정 업무를 지원하는 시스템이 무엇인지, 특정 시스템이 어떤 시스템과 연계되어 있는지를 알 수 있다. 또한 특정 시스템이 사용하는 데용되고 있?? 관리하면, 구성요소 간의 관계를 분석할 수 있기 때문에 특정 업무의 변화가 있었을 때 영향 받는 시스템, 데이터, 서버 등을 파악할 수 있다. 또한, 시스템 장애 발생시 연계된 시스템을 파악하여 장애 원인을 보다 쉽게 찾아낼 수 있다. 이를 통해 다양한 연관관계 매트릭스를 정의할 수 있으며, 필요한 보고서와 분석 자료를 생성할 수 있다.

연관관계가 많을수록 전사아키텍처 정보의 활용가치는 높아진다. 그렇지만, 전사아키텍처 정보의 유지관리 비용을 감안하여 현실적인 수준에서 연관관계 정보를 관리하는 것이 바람직하다.


아키텍처 매트릭스 정의시 고려사항

첫째, 아키텍처 매트릭스에 정의되는 산출물은 업무와 IT, 관리자와 실무자 사이의 중요한 커뮤니케이션 툴이다. 매트릭스를 정의할 때는 일반적인 아키텍처 개념을 포함하면서 조직 내 모든 계층의 사람이 매트릭스에 포함되는 산출물이 범위와 목적에 적합하게 정의되었음을 확신할 수 있어야 한다.

둘째, 조직적, 정치적, 지리적 특성, 조직의 편견 등 다양한 조직 문화와 의사결정 구조가 반영되어야 한다. 같은 아키텍처 정보라고 하더라도 기업의 조직문화, 의사결정에 따라 산출물이 정의되는 셀이 틀려질 수 있음으로, 기업의 조직문화와 의사결정 구조를 고려해서 추상화를 해야 한다.

셋째, 아키텍처 매트릭스는 실제 시스템과 아키텍처 개발 표준에 대한 준수성을 높이고 조직별로 통일된 접근이 가능하도록 정의되어야 한다. 이는 IT 조직의 성숙도를 충분히 고려해야 한다. 매트릭스는 추상화의 수준이 포함된 구조이기 때문에 서로 다른 개발 환경과 요건을 반영하는 동시에 통일성과 일관성을 유지할 수 있도록 되어야 한다.

넷째, 각 아키텍처 도메인은 상호 간에 연계성을 가져야 한다. 비즈니스 아키텍처에서 정의된 산출물은 상호연관성을 가지며 데이터-애플리케이션-기술 아키텍처에 반영되고, 전사 차원에서 통합적인 아키텍처 관리가 이루어지도록 한다.


참조 모델 정의

참조 모델 정의 작업에서는 기업의 기준 모델로 정의할 참조 모델의 체계와 구조를 정의하고 컨텐 츠를 구축한다.

이 공정은 다수 전사(Enterprise)를 가지고 있는 기업은 참조 모델을 정의하고, 개별 기업은 정의 된 참조 모델을 확인하는 과정이라고 할 수 있다. 즉, 이 단계에서 정부나 지주회사 또는 다수의 전사 를 가지고 있는 기관은 하위 전사나 소속 기업에서 참고할 참조 모델을 정의하게 되며, 개별 기업은 이러한 참조 모델을 참고하여 전사아키텍처 구성 요소의 타당성을 확인하게 된다.

참조 모델은 업무와 정보기술에 대한 체계적인 분류와 표준화를 통하여 정보화의 통합성, 중복 개 발 방지, 공유 정보의 발견, 상호운용성 향상 등의 목적으로 설계되어 있기 때문에, 개별 기업은 상 위기관이나 산업별 참조 모델을 참고하여 아키텍처 정보 구성 요소를 정의하는 것이 바람직하다.

참조 모델 정의는 기업이 속한 산업이나 가치 사슬 네트워크에 따라 그 범위가 달라질 수 있다. 기 업의 미션과 비전, 서비스의 특성, 기업 간 이해 관계 등을 고려해야 한다. 기술 참조 모델의 경우 개 별 기업도 기술 환경 변화에 대응하고 기술 요소 간 상호운용성을 고려하여 전사아키텍처 구축 시 정 의하여 활용하는 것이 바람직하다. 참조 모델에 대한 설명은 본 강좌의 3차 강의를 참고 바란다.


전사아키텍처 원칙 수립

전사아키텍처 비전 달성을 위해 구성원들이 공통적으로 지켜야 하는 규범을 정의하는 것이다. 전사아키텍처 원칙은 전사아키텍처 목표 달성을 위한 의사결정의 객관적 기준을 제시하여 줌으로써, 의사결정을 효과적으로 지원해 주고 업무 협조와 조정을 위한 의사소통 과정의 투명성을 제공한다.

이는 비즈니스 전략과 정보화 전략의 연결성을 강화하는 것이고, 구성원들의 개별적인 의사결정이 조직의 목표에 쉽게g src="/publishing/img/dbguide/know/quiz/060222_edu_06.gif" alt="전사아키텍처 원칙 구성도 예" border="0">

전사아키텍처 원칙의 구성 요소는 다음과 같다.


  • 원칙 :원칙의 내용을 간략하게 기술
  • 의미 :원칙이 가지는 의미를 설명
  • 근거 :원칙으로 채택된 원인 또는 배경
  • 기대효과 :원칙이 전사아키텍처 수립에 미치는 영향 또는 준수시의 기대효과

전사아키텍처 원칙은 전사아키텍처 전체에 적용되는 기본 원칙과 아키텍처별 원칙으로 구분할 수 있다. 기본 원칙은 전사아키텍처를 추진하는 전사적 차원의 대원칙을 의미하고 개별 아키텍처별 원칙의 근거가 된다.

전사아키텍처 기본원칙은 전사아키텍처 방향 수립 단계에서 정의될 수 있고, 아키텍처별 원칙은 전사아키텍처 정보 구성 정의 단계가 수행되어 아키텍처 매트릭스가 결정된 후 아키텍처 도메인별로 정의될 수 있다.


[표 1-2-5] 전사아키텍처 기본 원칙 예
원칙 의미
업무 지향 기업의 정보화는 업무 개선과 상품 및 서비스 품질 개선에 기여할 수 있는 방향으로 추진되어야 한다.
성과 지향 기업의 정보화는 객관적인 성과 지표에 의해 관리되고 평가되어야 한다.
고객 지향 기업의 정보화는 고객의 만족도를 개선하는 방향으로 추진되어야 한다.
상호운용 기업의 정보화는 전사아키텍처에 정의된 원칙과 아키텍처를 준수하여 시스템 간의 연계성과 운영의 지속성을 확보할 수 있는 방향으로 추진되어야 한다.

아키텍처 원칙은 전사아키텍처 기본원칙을 기반으로 비즈니스 아키텍처, 데이터아키텍처, 애플리케이션 아키텍처, 기술 아키텍처 등의 아키텍처 도메인별로 원칙을 정의한다. 아키텍처 원칙은 각 아키텍처 정보를 정의하고 관리하는 기준이 되는 원칙으로, 각 아키텍처 정보 구축 시 준수되어야 한다.


[표 1-2-6] 아키텍처 원칙 예
아키텍처 원칙 의미
비즈니스 범위의 완전성 기업이 수행하는 모든 업무 기능을 누락하지 않고 중복 없이 파악하여 정의한다.
데이터 데이터 표준 준수 정의된 표준에 따라 생성·수정·활용되도록 한다.
아키텍처 모델 관리 전사 차원의 아키텍처 데이터 모델을 관리하여 전사적 데이터 통합성을 유지한다.
애플리케이션 지원 기능 유일성 응용 시스템의 기능은 유일해야 한다.
기술 기술의 표준화 모든 기술 아키텍처 설계 및 도입 시에는 정의된 TRM/SP를 반드시 준수한다.
운영의 안정성 시스템의 장애에 대한 대응 체계 구축으로 시스템의 안정성, 연속성을 보장한다.

[그림 1-2-7] 데이터아키텍처 원칙 수립 예

전사아키텍처 원칙을 수립할 때에는 다음과 같은 사항을 고려하도록 한다.


  • 원칙의 의도가 명확하게 제시되어 원칙 적용 시 혼돈의 발생을 최소화할 수 있어야 한다.
  • 아키텍처 및 계획 수립과 관련된 의사결정을 효율적으로 할 수 있도록 가이드할 수 있어야 한다.
  • 중대한 정보 기술 관련 의사결정 시 규범으로써 활용될 수 있어야 한다.
  • 전사아키텍처 조직의 모든 정보 관리 및 기술과 관련된 의사결정은 전사아키텍처 원칙을 기반으 로 수행하여야 한다.
  • 원칙 간에 서로 상반되는 지향점을 갖지 않도록 원칙 수립 시 사용되는 용어는 주의하여 선택하여 야 한다.