엔터프라이즈 아키텍처 프레임워크

Enterprise architecture framework
NIST Enterprise Architecture Model은 1989년에 시작되었으며, 엔터프라이즈 [1]아키텍처의 초기 프레임워크 중 하나입니다.

엔터프라이즈 아키텍처 프레임워크(EA 프레임워크)는 엔터프라이즈 아키텍처를 만들고 사용하는 방법을 정의합니다.아키텍처 프레임워크는 시스템의 아키텍처 설명을 만들고 사용하기 위한 원칙과 관행을 제공합니다.아키텍처의 설명을 도메인, 레이어 또는 뷰로 나누어 설계자의 사고를 구조화하고, 각 뷰를 문서화하기 위한 모델(일반적으로 매트릭스 및 다이어그램)을 제공합니다.이를 통해 시스템의 모든 구성요소에 대한 체계적인 설계 결정을 내리고 새로운 설계 요건, 지속 가능성 및 [2]지원에 대한 장기적인 결정을 내릴 수 있습니다.

개요

엔터프라이즈 아키텍처는 기업을 크고 복잡한 시스템 또는 [3]시스템 시스템으로 간주합니다.이 시스템의 규모와 복잡성을 관리하기 위해 아키텍처 프레임워크는 건축가가 빌더가 작업하는 세부 수준에서 추상화할 수 있도록 지원하는 도구와 접근 방식을 제공하며, 엔터프라이즈 설계 태스크에 초점을 맞추고 귀중한 아키텍처 설명 문서를 작성합니다.

아키텍처 프레임워크의 구성요소는 다음과 같은 세 [4]가지 주요 영역으로 구분된 구조화된 지침을 제공합니다.

  • 아키텍처 설명: 여러 관점에서 기업을 하나의 시스템으로 문서화하는 방법.각 뷰는 아키텍처의 한 조각을 기술한다. 아키텍처는 특정 이해관계자의 특정 관심사를 다루는 엔티티와 관계를 포함한다. 리스트, 표, 도표 또는 그러한 복합물의 상위 수준의 형태를 취할 수 있다.
  • 아키텍처 설계 방법: 설계자가 따르는 프로세스.일반적으로 단계로 구성된 중요한 엔터프라이즈 아키텍처 프로세스는 세분화된 활동으로 구성된 하위 프로세스로 나뉩니다.프로세스는 목표, 입력, 단계(단계 또는 활동) 및 출력으로 정의됩니다.접근법, 기법, 도구, 원칙, 규칙 및 실무에 의해 지원될 수 있습니다.
  • 아키텍트 조직: 필요한 스킬, 경험, 트레이닝을 포함한 팀 구성과 팀의 통치에 관한 가이던스.

역사

엔터프라이즈 아키텍처 프레임워크의 진화 개요(1987~[4][5]2003)왼쪽:Zachman Framework 1987, NIST Enterprise Architecture 1989, EAP 1992, TISAF 1997, FEAF 1999 및 TEAF 2000.오른쪽: POSIX, JTA, JTAA, TOAF 1995, DoD TRM[6] 및 C4의 영향을 받는 TAFIMISR 1996 및 DoDAF 2003.

Open Group Architecture Framework(TOGAF) 및 기타 EA 프레임워크가 현재 주창하고 있는 단계별 계획 방법론의 초기 기초는 Marshall K의 기사로 거슬러 올라갈 수 있습니다.에반스와 루 R.헤이그는 1962년 하버드 비즈니스 [8]리뷰에 '정보시스템 [7]마스터플랜'이라는 제목으로 발표했다.

1970년대부터 IS/IT에서 일하는 사람들은 기업의 광범위하고 장기적인 이점을 고려하여 비즈니스 담당자를 참여시키고 비즈니스 역할과 프로세스를 지원하며 비즈니스 정보 시스템 및 기술에 대한 투자에 영향을 미치는 방법을 모색해 왔습니다.현재 EA 프레임워크에 채용되고 있는 목적, 원칙, 개념 및 방법의 대부분은 1980년대에 확립되어 있으며, 그 10년 및 [9]그 이후에 발표된 IS 및 IT 아키텍처 프레임워크에서 확인할 수 있습니다.

1980년까지 IBM의 BSP(Business Systems Planning)는 다음과 같은 목표를 가지고 조직의 정보 아키텍처를 분석하고 설계하는 방법으로 승격되었습니다.

  1. 현재의 애플리케이션 및 기술 아키텍처의 문제와 기회를 이해한다.
  2. 기업을 지원하는 테크놀로지의 미래 상태 및 이행 경로 개발
  3. IT 자본 지출에 대한 방향과 의사결정 프레임워크를 비즈니스 임원에게 제공한다.
  4. 정보시스템(IS)에 개발 청사진을 제공한다.

1982년, IBM과 BSP에서 일할 때, John Zachman은 엔터프라이즈 수준의 "정보 시스템 아키텍처"에 대한 자신의 프레임워크를 개략적으로 설명했습니다.그 후, 이후의 논문에서, Zachman은 비즈니스의 동의어로 Enterprise라는 단어를 사용했습니다.「인기 있는 정보 시스템의 계획 방법론, 설계 어프로치, 및 다양한 툴과 테크닉의 대부분은,[10] 엔터프라이즈 레벨의 분석을 배제하거나 일관성이 없는 것은 아니지만, 엔터프라이즈 아키텍쳐를 명시적으로 다루거나 정의하려고 하는 것은 거의 없습니다.」그러나 이 기사에서는 "엔터프라이즈 아키텍처"라는 용어가 특정 정의 없이 한 번만 언급되었으며 이후 Zachman의 모든 저작물에서는 "정보 시스템 아키텍처"[11][12]라는 용어가 사용되었습니다.

1986년, IBM을 포함한 여러 회사가 후원한 연구 프로젝트의 결과로 PRISM 아키텍처 프레임워크가 개발되었습니다. 이 프로젝트는 최초의 EA [13]프레임워크로 보입니다.

1987년 IBM의 마케팅 전문가였던 John Zachman은 A Framework for Information Systems [11]Architecture라는 논문을 발표했습니다.이 문서에서는 정보 시스템의 내용, 방법, 장소, 누구, 시기 및 이유를 설명하는 (여러 추상화 수준에서) 아티팩트에 대한 분류 체계를 제공했습니다.IBM이 이미 BSP를 채용한 상황에서 Zachman은 계획 프로세스를 제공할 필요가 없었습니다.이 문서에서는 엔터프라이즈 아키텍처에 대해서는 언급하지 않았습니다.

1989년 NIST(National Institute of Standards and Technology)는 NIST 엔터프라이즈 아키텍처 [14]모델을 발표했습니다.이는 비즈니스, 정보 시스템 및 기술 도메인의 상호 관계를 보여주는 5개 계층 참조 모델입니다.그것은 미국 연방 정부 내에서 홍보되었다.EA 프레임워크는 현재 우리가 보는 것처럼 아니지만, EA를 아키텍처 도메인 또는 계층으로 분할하는 개념을 확립하는 데 도움이 되었습니다.NIST Enterprise Architecture Model은 "Enterprise Architecture"[13]라는 용어를 일관되게 사용한 최초의 출판물인 것 같습니다.

1990년에 "엔터프라이즈 아키텍처"라는 용어는 "아키텍처가 필요로 하는 전체적인 물리적 구조를 유지하기 위해 필요한 지원 조직뿐만 아니라 데이터, 하드웨어, 소프트웨어 및 통신 리소스를 정의하고 상호 관련짓는 아키텍처"로 공식적으로 정의되었습니다.[13][15]

1992년 Zachman과 Sowa의[12] 논문은 "John Zachman은 시스템 분석가 및 데이터베이스 설계자에 의해 널리 채택된 정보 시스템 아키텍처(ISA)의 프레임워크를 도입했다"고 시작하였습니다.엔터프라이즈 아키텍처라는 용어는 나타나지 않았습니다.이 백서는 ISA 프레임워크를 사용하여 "...전체 정보 시스템과 그것이 기업 및 주변 환경과 어떻게 관련되어 있는지"를 설명하는 데 관한 것이었습니다.기업이라는 단어는 비즈니스의 동의어로 사용되었다.

1993년 Stephen Speak의 저서 Enterprise Architecture Planning(EAP)은 비즈니스를 지원하는 정보 사용에 대한 아키텍처 정의 프로세스와 이러한 아키텍처 구현 계획을 정의했습니다.비즈니스 미션이 주된 원동력입니다.그리고 임무를 완수하기 위해 필요한 데이터입니다.그런 다음 해당 데이터를 저장하고 제공하기 위해 구축된 애플리케이션입니다.마지막으로 애플리케이션을 구현하는 기술입니다.엔터프라이즈 아키텍처 플래닝은 아키텍처 계획에 대한 데이터 중심의 접근법입니다.목표는 데이터 품질, 데이터 액세스, 변화하는 요구사항에 대한 적응성, 데이터 상호 운용성 및 공유, 비용 억제를 개선하는 것입니다.EAP는 IBM의 BSP([13]Business Systems Planning)에 뿌리를 두고 있습니다.

1994년 Open Group은 TOGAF 개발의 기초로서 미국 국방부의 TAFIM을 선택했습니다.여기서 아키텍처는 IT 아키텍처를 의미합니다.TOGAF는 전략적이고 전사적이지만 기술 지향적인 관점을 취하기 시작했습니다.그것은 복잡한 IT단지를 합리화하려는 욕구에서 비롯되었습니다.버전 7까지 TOGAF는 기업 전체가 비즈니스 [9]애플리케이션을 지원하기 위해 사용하는 테크놀로지에서 필요한 플랫폼 서비스를 정의하기 위해 테크니컬 레퍼런스 모델(또는 기반 아키텍처)을 정의하고 사용하는 데 중점을 두고 있습니다.

1996년, 일반적으로 Clinger-Cohen 법으로 더 잘 알려진 미국 IT 관리 개혁법은 미국 연방 정부 기관의 IT에 대한 투자를 식별할 수 있는 비즈니스 이익에 매핑해야 한다고 거듭 지시했습니다.또한 기관 CIO는 "...집행 기관을 위한 건전하고 통합된 IT 아키텍처의 개발, 유지보수 및 구현을 촉진해야 할 책임이 있습니다."

1997년까지 Zachman은 자신의 ISA 프레임워크의 이름을 바꾸고 EA 프레임워크로 다시 초점을 맞췄습니다. 이는 시스템 계획이나 시스템 변경을 위한 프로세스가 아니라 기술적 아티팩트에 대한 분류 체계로 남아 있었습니다.

1998년 연방 CIO 평의회는 Clinger-Cohen에 명시된 우선순위에 따라 연방 엔터프라이즈 아키텍처 프레임워크(FEAF)의 개발을 시작하여 1999년에 발표했습니다.FEAF는 TOGAF의 ADM과 매우 유사한 프로세스로, "아키텍처 팀은 [기준 아키텍처와 타깃 아키텍처 간의] 상세 격차 분석을 전제로 시스템, 애플리케이션 및 관련 비즈니스 프랙티스의 전환을 위한 시퀀싱 계획을 작성합니다."

2001년 미국 최고 CIO 평의회는 "엔터프라이즈 아키텍처(EA)는 효율적인 정보기술(IT) 환경에서 핵심 비즈니스 프로세스의 최적의 수행을 통해 기관의 사명을 달성하기 위한 기관 차원의 로드맵을 수립합니다."라고 시작하는 '연방 엔터프라이즈 아키텍처(Federal Enterprise Architecture)'를 발간했습니다.그 시점에서 TOGAF, FEAF, EAP 및 BSP의 프로세스는 명확하게 관련되어 있었습니다.

2002년 3월 Enterprise Edition에서 TOGAF 8은 기술 아키텍처 계층에서 상위 비즈니스, 데이터 및 애플리케이션 계층으로 초점을 전환했습니다.IT엔지니어링 이후 조직단위의 비즈니스 기능 및 데이터 엔티티의 비즈니스 기능 매핑을 특징으로 하는 구조화 분석을 도입했습니다.오늘날 비즈니스 기능은 종종 비즈니스 기능이라고 불립니다.또한 많은 엔터프라이즈 설계자는 자신의 비즈니스 기능/기능 계층/맵을 기본적인 엔터프라이즈 아키텍처 아티팩트로 간주합니다.데이터 엔티티, 사용 사례, 애플리케이션 및 기술을 기능/기능과 관련짓습니다.

2006년, 인기 있는 책 「Enterprise Architecture[16] As Strategy」는, MIT의 정보 시스템 연구 센터의 연구 결과를 보고했습니다.이 책에서는 엔터프라이즈 아키텍트가 핵심 비즈니스 프로세스에 주력할 필요가 있음을 강조합니다(「기업은, 어느 프로세스를 적절히 실행할 필요가 있는지를 결정해, 그러한 프로세스를 디지털화하기 위한 IT시스템을 실장하고 있기 때문에 우수합니다.」).또, 비즈니스 매니저에게 조직간 프로세스 통합의 전략적 이점을 제공할 필요가 있습니다.및/또는 표준화가 제공할 수 있습니다.

2008년 영국컴퓨터학회(BCS)가 실시한 엔터프라이즈·솔루션·아키텍처에서의 프로페셔널 자격증 개발의 연구 프로젝트에서는, 기업인이 의사결정을 하거나 비즈니스를 실시하기 위해서 정보가 필요하기 때문에, 기업 아키텍처는 항상 정보 시스템 아키텍처와 불가분의 관계에 있는 것이 밝혀졌습니다.프로세스입니다.[9]

2011년 TOGAF 9.1 규격에는 "전략 수준에서의 비즈니스 계획은 엔터프라이즈 [17]아키텍처에 대한 초기 방향을 제시합니다."라고 명시되어 있습니다.일반적으로 조직의 비즈니스 원칙, 비즈니스 목표 및 전략적 추진 요인은 [9]다른 곳에서 정의됩니다.즉, 엔터프라이즈 아키텍처는 비즈니스 전략, 계획 또는 관리 방법이 아닙니다.엔터프라이즈 아키텍처는 비즈니스 정보 시스템 기술을 주어진 비즈니스 전략, 목표 및 추진 요인에 맞추기 위해 노력하고 있습니다.TOGAF 9.1 사양에서는 다음과 같이 명시하고 있습니다.「엔터프라이즈 아키텍처의 완전한 기술에는, 4개의 아키텍처 도메인(비즈니스, 데이터, 애플리케이션, 테크놀로지)이 모두 포함되어 있을 필요가 있습니다.그러나 자원과 시간의 제약으로 인해, 톱 다운형의 포괄적인 아키텍처의 기술 구축에 충분한 시간, 자금, 또는 자원이 없는 경우가 많습니다.n 엔터프라이즈 범위가 전체 엔터프라이즈 범위보다 작더라도 4개의 아키텍처 도메인을 모두 포함합니다."[18]

2013년에 TOGAF는[19] 가장 인기 있는 아키텍처 프레임워크(공개된 인증 번호에 따라 판단됨)이며, 일부에서는 [9]EA를 정의한다고 가정합니다.그러나 일부에서는 여전히 비즈니스, 데이터, 애플리케이션 및 테크놀로지 등 4가지 아키텍처 도메인을 모두 포괄하는 것이 아니라 비즈니스 아키텍처의 동의어로 엔터프라이즈 아키텍처라는 용어를 사용하고 있습니다.

EA 프레임워크 토픽

아키텍처 도메인

엔터프라이즈 [20]아키텍처의 레이어.

1993년 Stephen Speak의 EAP(Enterprise Architecture Planning) 이후(아마도 그 이전에는) 엔터프라이즈 아키텍처를 4개의 아키텍처 도메인으로 분할하는 것이 일반적이었습니다.

애플리케이션 아키텍처는 단일 애플리케이션의 내부 아키텍처(종종 애플리케이션 아키텍처라고 함)가 아니라 기업의 애플리케이션 포트폴리오에 포함된 애플리케이션 선택과 관계에 관한 것입니다.

많은 EA 프레임워크는 데이터 도메인과 애플리케이션 도메인을 하나의 (디지털화된) 정보 시스템 계층으로 결합하여 비즈니스(통상은 휴먼 액티비티 시스템)와 테크놀로지(플랫폼 IT 인프라스트럭처) 위에 배치합니다.

엔터프라이즈 아키텍처 레이어

5개의 아키텍처 [21]레이어를 정의한 연방 기업 아키텍처의 예.

오랫동안 아키텍처 도메인은 계층으로 간주되어 왔으며, 각 계층에는 프로세스를 실행하고 위의 계층에 서비스를 제공하는 컴포넌트가 포함되어 있습니다.이러한 아키텍처 도메인의 견해는 TAFIM 및 POSIX의 철학에 따라 "Technical Reference Model"에서 정의된 플랫폼 서비스의 배후에 기술 컴포넌트 계층을 캡슐화한 TOGAF v1(1996)에서 명확히 드러났습니다.

아키텍처 도메인을 계층으로 볼 수 있는 뷰는 다음과 같습니다.

  • 환경(비즈니스가 감시, 지원 또는 지시하는 외부 주체 및 활동).
  • 비즈니스 계층(상대방 및 외부 실체에 서비스를 제공하는 비즈니스 기능).
  • 데이터 레이어(비즈니스 정보 및 기타 귀중한 저장 데이터)
  • Information System Layer(상대방 및 비즈니스 기능에 정보 서비스를 제공하는 비즈니스 애플리케이션)
  • 테크놀로지 레이어(일반적인 하드웨어, 네트워크 및 플랫폼 어플리케이션으로 플랫폼 서비스를 상호 및 비즈니스 어플리케이션에 제공).

각 레이어 딜러는 다음 레이어로 작업합니다.각 계층에서 구성요소, 프로세스 및 서비스를 대략적인 수준에서 정의하고 세분화된 구성요소, 프로세스 및 서비스로 분해할 수 있습니다.그래픽은 이 주제에 대한 변형을 보여줍니다.

엔터프라이즈 아키텍처 프레임워크의 컴포넌트

위에서 설명한 3가지 주요 프레임워크 컴포넌트 외에

  1. 설명 조언: 아키텍처 아티팩트 맵 또는 시점 라이브러리
  2. 프로세스 어드바이스: 어떤 종류의 아키텍처 개발 방법(지원 가이던스 포함).
  3. 조직에 대한 조언: EA 거버넌스 모델 포함

이상적인 EA 프레임워크의 특징은 다음과 같습니다.

  1. 비즈니스 가치 측정 지표
  2. EA 이니셔티브 모델
  3. EA 성숙도 모델
  4. 엔터프라이즈 커뮤니케이션 모델

대부분의 최신 EA 프레임워크(예: TOGAF, ACNEPLER, EAF)는 위의 대부분을 포함합니다.Zachman은 항상 아키텍처 설명 조언에 집중해 왔습니다.

엔터프라이즈 아키텍처 도메인 및 하위 도메인

하위 도메인이 있는 엔터프라이즈 아키텍처 레퍼런스 아키텍처

애플리케이션 및 테크놀로지 도메인(비즈니스 도메인과 혼동하지 말 것)은 도메인 기능과 도메인 서비스로 특징지어집니다.이 기능은 서비스에서 지원됩니다.애플리케이션 서비스는 SOA(서비스 지향 아키텍처)에서도 언급됩니다.기술 서비스는 일반적으로 소프트웨어 제품에 의해 지원됩니다.

데이터 보기는 데이터 개체로 분해할 수 있는 데이터 클래스로 시작하여 데이터 개체로 추가로 분해할 수 있습니다.가장 일반적으로 사용되는 기본 데이터 모델 유형은 merda(주요 엔티티 관계도 평가, 엔티티-관계 모델 참조)라고 합니다.클래스, 주체 및 엔티티는 데이터의 계층 뷰를 형성합니다.기업에는 수백만 개의 데이터 엔티티 인스턴스가 있을 수 있습니다.

엔터프라이즈 아키텍처 레퍼런스 기존 모델은 아키텍처 도메인(비즈니스, 정보/데이터, 애플리케이션/통합 및 기술/인프라)을 명확하게 구분합니다.이러한 도메인은 하위 도메인 규칙으로 더 나눌 수 있습니다.EA 도메인과 서브도메인의 예를 오른쪽 이미지에 나타냅니다.

많은 엔터프라이즈 아키텍처 팀은 엔터프라이즈 아키텍처 도메인 및 하위 도메인에 맞는 기술을 가진 개인으로 구성되어 있습니다.다음은 엔터프라이즈 비즈니스 설계자, 엔터프라이즈 문서 설계자, 엔터프라이즈 애플리케이션 설계자, 엔터프라이즈 인프라 설계자, 엔터프라이즈 정보 설계자 등의 몇 가지 예입니다.

애플리케이션 및 정보 아키텍처 도메인의 참조 아키텍처 패턴 목록의 예는 아키텍처 패턴(컴퓨터 과학)에서 확인할 수 있습니다.

모델 표시

아키텍처의 4+1 뷰 모델을 나타냅니다.

뷰 모델은 시스템 분석, 시스템 설계 또는 엔터프라이즈 아키텍처 구축에 사용되는 뷰 또는 접근 방식을 정의하는 프레임워크입니다.

1990년대 초반부터 시스템 아키텍처를 기술하고 분석하기 위한 표준 접근법을 정의하기 위한 많은 노력이 있었습니다.최근의 엔터프라이즈 아키텍처 프레임워크의 대부분은 뷰 세트가 정의되어 있지만, 이러한 세트를 뷰 모델이라고 부르는 것은 아닙니다.

표준화

소프트웨어 아키텍처 및 시스템 아키텍처 분야에서 가장 잘 알려진 표준은 2000년에 승인된 소프트웨어 집약적인 시스템의 아키텍처를 기술하기 위한 IEEE 표준인 IEEE 1471로 시작되었습니다.

최신 버전에서는 ISO/IEC/IEEE 42010:2011로 표준이 공개되어 있습니다.이 표준에서는 아키텍처 프레임워크를 특정 애플리케이션 및/또는 이해관계자 커뮤니티 내에서 확립된 아키텍처의 설명을 위한 규약, 원칙 및 관행으로 정의하고 아키텍처 프레임워크는 다음과 같이 명시할 것을 제안한다.

  1. 도메인 내 관련 이해관계자
  2. 해당 영역에서 발생하는 우려의 유형,
  3. 아키텍처의 관점에서 이러한 우려와
  4. 앞서 언급한 관점을 통합하는 통신 규칙.

표준을 준수하는 아키텍처 프레임워크에는 지정된 방법, 도구, 정의 및 작업 방식 이외의 추가 방법이 포함될 수 있습니다.

엔터프라이즈 아키텍처 프레임워크 유형

2011년 현재[22] 사용되고 있는 엔터프라이즈 아키텍처 프레임워크의 일부만

오늘날 EA 프레임워크는 아래 목록보다 훨씬 많은 셀 수 없을 정도로 많이 존재합니다.

컨소시엄이 개발한 프레임워크

  • ARCON – 콜라보레이티브 네트워크를 위한 레퍼런스 아키텍처– 단일 기업이 아닌 기업 네트워크에[23][24] 초점을 맞춥니다.
  • Cloud Security Alliance(Trusted Cloud Initiative) TCI 레퍼런스 아키텍처.[25]
  • Generalized Enterprise Reference Architecture and Methodology(GERAM)
  • RM-ODP – 오픈 분산 프로세싱의 레퍼런스 모델(ITU-T Rec. X.901-X.904 ISO/IEC 10746)은 오픈 분산 시스템의 사양을 구조화하기 위한 엔터프라이즈 아키텍처 프레임워크를 정의합니다.
  • IDEAS Group – 아키텍처 상호 운용성을 위한 공통 온톨로지 개발을 위한 4개국 협력
  • ISO 19439 엔터프라이즈 모델링을 위한 프레임워크
  • TOGAF – 오픈 그룹 아키텍처 프레임워크– 아키텍처 개발 방법 및 다양한 유형의 아키텍처를 기술하기 위한 표준을 포함하여 널리 사용되는 프레임워크입니다.

방위산업의 틀

  • AGATE – 프랑스 DGA 아키텍처 프레임워크
  • DNDAF[26] – DND/CF 아키텍처 프레임워크(CAN)
  • DoDAF – 미국 국방부 아키텍처 프레임워크
  • MODAF – 영국 국방부 아키텍처 프레임워크
  • NAF – NATO 아키텍처 프레임워크

정부 프레임워크

오픈 소스 프레임워크

오픈 소스로 출시되는 엔터프라이즈 아키텍처 프레임워크:

  • LAF(Lin [29]Architecture Framework)는 IT환경이 일관된 형태를 유지하면서 변화하는 비즈니스 상황에 일관되고 신속하게 대응할 수 있는 모범 사례의 집합체입니다.
  • MEGAF는[30] ISO/IEC/IEEE 42010에서 제공하는 아키텍처 프레임워크의 정의에 적합한 아키텍처 프레임워크를 실현하기 위한 인프라스트럭처입니다.
  • 오픈 엔터프라이즈 방법론인 Praxeme에는 엔터프라이즈 시스템 토폴로지(EST)라고 불리는 엔터프라이즈 아키텍처 프레임워크가 포함되어 있습니다.
  • TRAK – MODAF 1.2를 기반으로 GPL/GFDL로 출시되는 일반적인 시스템 지향 프레임워크.
  • Sherwood Applied Business Security Architecture(SABSA)[31]는 엔터프라이즈 보안 아키텍처 및 서비스 관리를 위한 개방형 프레임워크 및 방법론으로, 리스크 기반이며 보안을 비즈니스 및 IT 관리에 통합하는 데 중점을 두고 있습니다.

독자적인 프레임워크

  • ACEPLER Framework – 2002년 Wipro의 Mandar Vanarse의 작업을 기반으로 한 아키텍처 프레임워크
  • Avancier Methods(AM)[32] 엔터프라이즈 및 솔루션 설계자를 위한 프로세스 및 문서 조언.훈련 및 인증에 의해 지원됩니다.
  • BRM(Build-Run-Manage) Framework - Sanjeev "Sunny" Mishra가 2000년 IBM 입사 초기에 만든 아키텍처 프레임워크입니다.
  • Capgemini 통합 아키텍처 프레임워크(IAF) – 1993년 Capgemini 회사에서 제공
  • Dragon1 - 오픈 그룹이 아키텍처 프레임워크로 인정한 오픈 Visual Enterprise Architecture 1
  • 2004년부터 Sogeti가 개발한 DYA 프레임워크.
  • Web 2.0 테크놀로지를 기반으로 한 다이내믹 엔터프라이즈 아키텍처 개념
  • 확장 엔터프라이즈 아키텍처 프레임워크 - 2003년 엔터프라이즈 아키텍처 개발 연구소
  • EACOE Framework [ 3 ]– John Zachman의 작업을 상세하게 정리한 엔터프라이즈 아키텍처 프레임워크
  • IBM Information FrameWork(IFW) – Roger Evernden이 1996년에 고안한
  • 인포메트 - 1990년 피터 빌조엔에 의해 구상된
  • Labnaf - 엔터프라이즈 혁신을 추진하는 통합 프레임워크
  • PEAF([34]Pragmatic Enterprise Architecture Framework) - 2008년부터 Kevin Lee Smith, Pragmatic EA에 의해 개발된 Pragmatic Family of Frameworks의 일부
  • Purdue 대학의 Theodore J. Williams가 개발한 Purdue Enterprise Reference Architecture.
  • SAP 엔터프라이즈 아키텍처 프레임워크
  • Michael Bell의 작업을 기반으로 한 서비스 지향 모델링 프레임워크(SOMF)
  • 솔루션 아키텍처 메커니즘(SAM)–[35] 일련의 [36]모듈로 구성된 일관된 아키텍처 프레임워크입니다.
  • Zachman Framework – 1980년대 IBM의 John Zachman의 작업을 기반으로 한 아키텍처 프레임워크

「 」를 참조해 주세요.

레퍼런스

  1. ^ 최고정보책임자회의(1999년).Federal Enterprise Architecture Framework 버전 1.1 웨이백 머신에서 2012-02-13 아카이브 완료.1999년 9월
  2. ^ "Tech Target". SearchCIO.
  3. ^ Open Group (2008) TOGAF 버전9 。Van Haren 출판사, 2008년 11월 1일.p. 73
  4. ^ a b Stephen Marley(2003).아키텍처 프레임워크NASA / SCIWebarchive.org에서 2015년 3월 4일 취득.
  5. ^ Jaap Schekkerman(2004) How to Survive in the Jungle of Enterprise Architecture Frameworks. 페이지 89도 이와 유사한 체계를 제공합니다.
  6. ^ 미국 국방부(2001) 국방부 기술 참조 모델.버전 2.0.9 2001년 4월 11일, DoD TRM도 POSIX의 영향을 받는다고 언급했습니다.
  7. ^ 에반스, M. K. 및 헤이그, L. R. (1962) 정보시스템 마스터플랜, Harvard Business Review, Vol. 40, No.1, 페이지 92-103.
  8. ^ Kotusev, Svyatoslav (2021) 엔터프라이즈 아키텍처 실천: 비즈니스와 IT에 대한 현대적인 접근법 (제2판).호주 멜버른: SK출판사.
  9. ^ a b c d e Graham Berrisford(2008-13) "EA의 간단한 이력: Wayback Machine에서 2013-09-18 아카이브되지 않은 것" (2013년 7월 16일 최종 업데이트)2003년 7월 16일에 접속
  10. ^ John Zachman(1982) Business Systems Planning and Business Information Control Study: IBM Systems Journal 21(1)의 비교 p32.
  11. ^ a b 존 A. 자크만(1987년). 정보 시스템 아키텍처의 프레임워크.수신: IBM Systems Journal, vol 26, no 3.IBM 출판물 G321-5298.
  12. ^ a b Zachman and Sowa(1992) 정보 시스템 아키텍처 프레임워크 확장 및 공식화 IBM Systems Journal, Vol 31, No 3
  13. ^ a b c d 스비야토슬라브 코투세프(2016).엔터프라이즈 아키텍처의 역사: 증거 기반 검토인: 엔터프라이즈 아키텍처 저널, 제12권, 제1호, 29-37페이지.
  14. ^ W.B. 릭던(1989)아키텍처와 표준정보 관리 지침:통합 과제(NIST 스페셜 출판물 500-167), E.N. Fong, A.H. Goldfine(Eds.), Gaithersburg, MD: National Institute of Standards and Technology(NIST), 135-150페이지.
  15. ^ Richardson, G.L.; Jackson, B.M.; Dickson, G.W. (1990). "A Principles-Based Enterprise Architecture: Lessons from Texaco and Star Enterprise". MIS Quarterly. 14 (4): 385–403. doi:10.2307/249787. JSTOR 249787.
  16. ^ Jeanne W. Ross, Peter Weill, 그리고 David C. Robertson (2006)전략으로서의 엔터프라이즈 아키텍처: 비즈니스 실행을 위한 기반을 만듭니다.하버드 비즈니스 리뷰 프레스
  17. ^ 오픈 그룹(2011) TOGAF® 9.1 > Part II: 아키텍처 개발 방법(ADM) > 예비 단계.2013년 7월 16일 액세스
  18. ^ The Open Group (2011) TOGAF® 9.1 > Part II: Architecture Development Method (ADM) > ADM 소개2013년 7월 16일 액세스
  19. ^ TOGAF 9.1 화이트 페이퍼 TOGAF 버전 9.1 소개 http://www.opengroup.org/togaf/
  20. ^ Niles E Hewlett (2006)USDA 엔터프라이즈 아키텍처 프로그램 2007-05-08년 Wayback Machine에서 아카이브.PMP CEA, 엔터프라이즈 아키텍처 팀, USDA-OCIO2006년 1월 25일
  21. ^ 2010-07-05년 웨이백 머신에 보관된 FEA 통합 참조 모델 문서.whitehouse.gov 2005년 5월
  22. ^ 데니스 E. Wisnosky (2011) Engineering Enterprise Architecture: Call to Action.in: Common Defense Quarterly.2011년 1월, 9페이지
  23. ^ L.M. Camarinha-Matos, H. Afsarmanesh, 협업 네트워크: 레퍼런스 모델링, Springer, 2008.
  24. ^ Camarinha-Matos, L.M.; Afsarmanesh, H. (2008). "On reference models for collaborative networked organizations". International Journal Production Research. 46 (9): 2453–2469. doi:10.1080/00207540701737666. S2CID 51802872.
  25. ^ "The CSA TCI reference architectue" (PDF). Cloud Security Alliance. Archived from the original on 11 June 2016. Retrieved 7 July 2020.
  26. ^ DNDAF 2011-04-24 Wayback Machine에서 아카이브 완료
  27. ^ Gianni, Daniele; Lindman, Niklas; Fuchs, Joachim; Suzic, Robert (2012). "Introducing the European Space Agency Architectural Framework for Space-Based Systems of Systems Engineering". Complex Systems Design & Management. Proceedings of the Second International Conference on Complex Systems Design & Management CSDM 2011. Springer. pp. 335–346. CiteSeerX 10.1.1.214.9671. doi:10.1007/978-3-642-25203-7_24. ISBN 978-3-642-25202-0.
  28. ^ 미국 재무부 최고정보책임자회의(2000년).재무부 엔터프라이즈 아키텍처 프레임워크 2009-03-18년 웨이백 머신에서 아카이브.버전 1, 2000년7월
  29. ^ https://lafinstitute.org/
  30. ^ 메가프
  31. ^ SABSA
  32. ^ Avancier 메서드(AM)
  33. ^ 랩나프 [1]
  34. ^ 실용 EA [2]
  35. ^ 솔루션 아키텍처 메커니즘(SAM)
  36. ^ 토니 산과 위니 화(2006).솔루션 아키텍처 메커니즘제10회 IEEE International EDOC Enterprise Computing Conference (EDOC 2006), 2006년 10월, p23-32.

외부 링크