건축 도메인

Architecture domain
2001년에 제시된 "FEAF(Federal Enterprise Architecture Framework)"의 구조로, 4개의 아키텍처 도메인이 결정되었다.[1]

엔터프라이즈 아키텍처의 아키텍처 도메인은 기업이나 시스템의 넓은 시야이다.그것은 여러 이해관계자의 여러 가지 우려를 해결하는 전체 시스템의 부분적인 표현이다.기술된 시스템의 다른 관점이나 측면을 숨기는 서술이다.비즈니스, 데이터, 애플리케이션 및 기술 아키텍처는 기업 아키텍처의 정의와 관련된 대부분의 제안된 개념에서 핵심 도메인으로 인식된다.[2]

개요

EA의 층

1993년 스티븐 스펙의 저서 엔터프라이즈 아키텍처 계획(EAP) 이후,[3] 그리고 아마도 그 이전부터, 네 가지 유형의 아키텍처 도메인을 인식하는 것이 정상적이었다.브리티시 컴퓨터 소사이어티의 "기업 및 솔루션 아키텍처에 대한 참조 모델"도 이 소분류를 따르지만, 애플리케이션 아키텍처 바로 아래의 (단일) 애플리케이션 아키텍처 수준뿐만 아니라 정보 아키텍처, 정보 시스템 아키텍처 또는 보안 아키텍처(크로스)의 영역도 추가로 언급한다.s 절단 우려:[4]

  • 비즈니스 아키텍처:비즈니스 시스템의 구조와 행동(컴퓨터와 반드시 관련이 있는 것은 아님)비즈니스 목표, 비즈니스 기능 또는 역량, 비즈니스 프로세스 및 역할 등을 다룬다.비즈니스 기능과 비즈니스 프로세스는 종종 필요한 애플리케이션과 데이터에 매핑된다.
  • 데이터 아키텍처:기업 및/또는 애플리케이션에서 사용하는 데이터 구조.저장소의 데이터 및 이동 중인 데이터에 대한 설명.데이터 저장소, 데이터 그룹 및 데이터 항목에 대한 설명.이러한 데이터 아티팩트를 데이터 품질, 애플리케이션, 위치 등에 매핑
  • 애플리케이션 아키텍처:비즈니스에서 사용되는 응용프로그램의 구조와 행동은 응용프로그램이 상호 및 사용자와 상호작용하는 방법에 초점을 맞췄다.내부 구조보다는 애플리케이션에 의해 소비되고 생산되는 데이터에 초점을 맞춘다.애플리케이션 포트폴리오 관리에서 애플리케이션은 대개 비즈니스 기능 및 애플리케이션 플랫폼 기술에 매핑된다.
    애플리케이션(또는 구성요소) 아키텍처:응용 프로그램 내의 내부 구조, 소프트웨어의 모듈화.이것은 가장 낮은 세분화 수준의 소프트웨어 아키텍처다.일반적으로 솔루션 설계자가 정의하는 모듈화 수준보다 낮다.그러나 경직된 구분선은 없다.
  • 기술 아키텍처 또는 인프라 아키텍처:IT 인프라의 구조와 행동.하드웨어 구성의 클라이언트 및 서버 노드, 하드웨어 구성에서 실행되는 인프라 애플리케이션, 애플리케이션에 제공하는 인프라 서비스, 애플리케이션과 노드를 연결하는 프로토콜 및 네트워크를 다룬다.

애플리케이션 아키텍처는 애플리케이션 포트폴리오에 관한 것이지 종종 애플리케이션 아키텍처라고 불리는 단일 애플리케이션의 내부 아키텍처에 관한 것이 아니라는 점에 유의하십시오.

많은 EA 프레임워크는 데이터 및 애플리케이션 도메인을 단일 계층으로 결합하여 비즈니스(일반적으로 휴먼 활동 시스템)와 기술(플랫폼 IT 인프라) 위에 위치한다.이 주제에는 많은 변화가 있다.

참고 항목

참조

  1. ^ 최고 정보 책임자 위원회(2001) 연방 기업 아키텍처에 대한 실무 지침.2001년 2월
  2. ^ N. Dedic, doi: 10.1109/EMR.2020.3031968의 IEEE 엔지니어링 관리 검토에서 "FEAMI: 기존 조직 프로세스에 엔터프라이즈 아키텍처 프로세스를 포함시키고 통합하기 위한 방법론".
  3. ^ Steven Spewak; S. C. Hill (1992). Enterprise Architecture Planning: Developing a Blueprint for Data, Applications, and Technology. Boston, QED Pub. Group. ISBN 978-0-471-59985-2.
  4. ^ "Reference Model for ISEB Certificates in Enterprise and Solution Architecture Version 3.0" (PDF). bcs. 2010.