엔터프라이즈 아키텍처

Enterprise architecture
이 글은 기술/방법론에 관한 것이다.Sparx Systems Enterprise Architect에 대해서는 Enterprise Architect(소프트웨어)를 참조하십시오.

엔터프라이즈 아키텍처(EA)는 분석 대상 기업을 특징짓는 특정 중요 비즈니스 영역(물리적, 조직적, 기술적 등)의 관점에서 조직의 구조와 상호 관계를 포괄적으로 정의, 구성, 표준화 및 문서화하는 방법을 제공하는 분석 분야입니다.EA의 목표는 실제 상황에 대응하여 비즈니스를 안내, 최적화 및 전환하기 위해 모든 수준의 책임에서 사용될 수 있는 비즈니스 기업을 효과적으로 표현하는 것입니다.EA는 도메인 요소의 프로세스, 기능, 애플리케이션, 이벤트, 데이터 및 채용된 테크놀로지에 의해 기술된 바와 같이 도메인 요소 간의 관계와 상호작용을 포착하는 역할을 합니다.[1]

개요

엔터프라이즈 아키텍처의 실무자로서 엔터프라이즈 아키텍트는 인력, 프로세스 및 테크놀로지의 의사결정을 실행 가능한 목표와 연계하여 그 비전을 달성하기 위한 수량화 가능한 개선을 실현함으로써 조직의 전략적 비전을 지원합니다.엔터프라이즈 아키텍처의 프랙티스:

는 조직 내 또는 조직 간에 공통적인 활동 영역을 분석합니다.이 영역에서는 전략, 비즈니스 및 테크놀로지의 통합된 관점에서 정보 및 기타 리소스가 교환되어 미래 상태를 안내합니다.[2]

엔터프라이즈 아키텍처(EA)는 바람직한 비즈니스 비전과 결과를 향한 변화의 실행을 특정하고 분석함으로써 엔터프라이즈가 혁신적 힘에 능동적이고 전체적으로 대응할 수 있도록 하기 위한 분야입니다.EA는 비즈니스 리더와 IT 리더에게 정책 및 프로젝트를 조정하여 관련 비즈니스 중단을 활용하는 목표 비즈니스 결과를 달성하기 위한 즉시 권장 사항을 제시함으로써 가치를 제공합니다.EA는 미래 상태 아키텍처의 [3]진화로 의사 결정을 유도하기 위해 사용됩니다.

비즈니스 매니저와 IT매니저는 비즈니스에 의존하는 비즈니스 정보 시스템과 관련하여 비즈니스 개발 및 비즈니스 변화를 지원하고 지원하는 최적의 전략을 찾을 수 있습니다.

토픽

엔터프라이즈와 아키텍처라는 용어

엔터프라이즈라는 용어는 일련의 공통 목표를 공유하고 고객에게 [4]특정 제품 또는 서비스를 제공하기 위해 협업하는 조직 단위, 조직 또는 조직의 집합을 나타내는 것으로 정의할 수 있습니다.

그런 의미에서 엔터프라이즈라는 용어는 규모, 소유 모델, 운영 모델 또는 지리적 분포에 관계없이 다양한 유형의 조직을 포함합니다.여기에는 사람, 정보, 프로세스 및 기술을 포함한 조직의 완전한 사회 기술 [5]시스템이 포함됩니다.

아키텍처라는 용어는 요소, 관계 및 설계 및 [6]진화 원리에 구체화된 환경에서 시스템의 기본 개념 또는 속성을 나타냅니다.

사회 기술 시스템으로 이해되는 엔터프라이즈라는 용어는 엔터프라이즈 아키텍처의 범위를 정의합니다.

범위

엔터프라이즈 아키텍처의 의미와 관련하여 엔터프라이즈 아키텍처 실무자와 학자들이 가지고 있는 견해 또는 신념은 일반적으로 다음과 같은 세 가지 생각의 [7]학파로 구성된 한 가지 또는 잡종을 중심으로 합니다.

  1. 엔터프라이즈 IT 설계– EA의 목적은 IT와 비즈니스 문제 간의 보다 긴밀한 조정을 도모하는 것입니다.엔터프라이즈 아키텍처의 주요 목적은 원하는 조직 목표를 달성하기 위해 기업의 IT/IS 기능을 계획하고 설계하는 프로세스를 안내하는 것입니다.일반적으로 아키텍처의 제안과 결정은 기업의 IT/IS 측면에만 한정되며, 그 외의 측면은 입력 정보 역할을 할 뿐입니다.
  2. 엔터프라이즈 통합 – 이 학파에 따르면 EA의 목적은 전략 수립과 실행의 연계 등 기업의 다양한 관심사(HR, IT, 운영 등) 간에 보다 일관성을 확보하는 것입니다.일반적으로 아키텍처 제안 및 결정은 기업의 모든 측면을 포함합니다.
  3. 엔터프라이즈 에코시스템 적응– EA의 목적은 기업의 학습능력을 육성 및 유지하여 기업의 지속가능성을 높이는 것입니다.따라서 기업의 자체 개선, 혁신 및 환경과의 공동 진화를 위한 역량 향상에 많은 중점을 두고 있습니다.일반적으로 제안과 결정은 기업과 그 환경 모두를 포함합니다.

엔터프라이즈 아키텍처의 의미에 대한 신념은 아키텍처의 목적, 범위, 달성 수단, 실행에 필요한[7] 기술 및 책임 소재에 영향을 미칩니다.

기업의 아키텍처 설명

다음 항목도 참조하십시오.아키텍처 도메인

표준 ISO/IEC/IEEE [6]42010에 따르면 시스템의 아키텍처를 기술하기 위해 사용되는 제품을 아키텍처 기술이라고 합니다.실제로 아키텍처 설명에는 다양한 목록, 테이블 및 다이어그램이 포함됩니다.이들은 뷰로 알려진 모델입니다.엔터프라이즈 아키텍처의 경우 이러한 모델은 논리적 비즈니스 기능 또는 기능, 비즈니스 프로세스, 인적 역할 및 행위자, 물리적 조직 구조, 데이터 흐름 및 데이터스토어, 비즈니스 애플리케이션 및 플랫폼 애플리케이션, 하드웨어 및 통신 인프라를 [citation needed]설명합니다.

UK National Computing Center EA의[8] 베스트 프랙티스 가이던스에는 다음과 같은 내용이 기재되어 있습니다.

일반적으로 EA는 기업의 구조와 기능을 설명하는 포괄적인 통합 모델의 형태를 취합니다.EA의 개별 모델은 기업에 대한 상세 수준을 지속적으로 높일 수 있는 논리적인 방식으로 배열됩니다.

기업의 아키텍처는 비즈니스의 관리성, 효과성, 효율성 또는 민첩성을 향상시키고 IT(정보 기술)에 지출되는 비용이 [citation needed]정당하도록 하기 위해 기술되어 있습니다.

엔터프라이즈 아키텍처를 변경하는 데 있어 가장 중요한 것은 스폰서를 특정하는 것입니다.고객의 미션, 비전 및 전략과 거버넌스 프레임워크는 예상되는 전환에 관련된 모든 역할, 책임 및 관계를 정의합니다.일반적으로 엔터프라이즈 아키텍트가 고려하는 변경 사항은 다음과 같습니다.

  • 조직의 구조나 프로세스의 혁신
  • 정보 시스템 또는 기술 사용의 혁신
  • 비즈니스 프로세스의 통합 및/또는 표준화
  • 비즈니스 정보의 품질과 적시성을 향상시킵니다.

베이스라인 상태에서 타깃 상태로의 비즈니스 전환을 유도하기 위한 아키텍처를 개발하고 사용하는 방법론은 보통 엔터프라이즈 아키텍처 프레임워크로 알려져 있습니다.프레임워크는 프로세스, 기술, 아티팩트 설명, 참조 모델 및 엔터프라이즈별 아키텍처 설명의 생산 및 사용에 대한 지침을 체계적으로 제공합니다.

혜택들

엔터프라이즈 아키텍처의 이점은 조직의 목표에 대한 직접적 및 간접적 기여를 통해 달성됩니다.엔터프라이즈 아키텍처의 가장 주목할 만한 이점은 다음 영역에서 [9]확인되었습니다.

  • 조직설계 – 엔터프라이즈 아키텍처는 합병, 인수 또는 일반적인 조직변경 [10][11][12][13]시 조직구조의 설계 및 재설계에 관련된 영역에서 지원을 제공합니다.
  • 조직 프로세스 및 프로세스 표준– 엔터프라이즈 아키텍처는 비즈니스 프로세스의 규율과 표준화를 강화하고 프로세스 통합, 재사용 및 [14][15]통합을 가능하게 합니다.
  • 프로젝트 포트폴리오 관리– 엔터프라이즈 아키텍처는 투자 의사결정 및 작업 우선순위 [11][16][12]부여를 지원합니다.
  • 프로젝트 관리 – 엔터프라이즈 아키텍처는 프로젝트 관계자 간의 협업과 커뮤니케이션을 강화합니다.엔터프라이즈 아키텍처는 효율적인 프로젝트 범위 지정과 보다 완전하고 일관된 프로젝트 [13][14]성과물 정의에 기여합니다.
  • 요건 엔지니어링 – 엔터프라이즈 아키텍처는 엔터프라이즈 아키텍처 [17]문서의 공개를 통해 요건 도출 속도와 요건 정의 정확도를 높입니다.
  • 시스템 개발 - 엔터프라이즈 아키텍처는 시스템 개발 및 테스트 [11][12]시 최적의 시스템 설계와 효율적인 자원 할당에 기여합니다.
  • IT관리 및 의사결정 – 엔터프라이즈 아키텍처는 IT계획 액티비티의 규율과 표준화를 강화하고 테크놀로지 관련 의사결정 [12][15]시간을 단축하는 데 도움이 되는 것으로 나타났습니다.
  • IT 가치 – 엔터프라이즈 아키텍처는 시스템 구현 및 운영 비용을 절감하고 사업부 [15][18]간 IT 인프라 서비스 복제를 최소화할 수 있도록 지원합니다.
  • IT의 복잡성– 엔터프라이즈 아키텍처는 IT의 복잡성 경감, 데이터와 애플리케이션의 통합 및 시스템의 [14][15][18]상호 운용성 향상에 기여합니다.
  • IT의 개방성– 엔터프라이즈 아키텍처는 데이터 접근성이 향상되어 법령 준수를 실현하고 인프라스트럭처 [15][19]변경에 대한 투명성이 높아짐에 따라 IT의 개방성과 응답성이 향상됩니다.
  • IT 리스크 관리– 엔터프라이즈 아키텍처는 시스템 장애 및 보안 침해로 인한 비즈니스 리스크 감소에 기여합니다.엔터프라이즈 아키텍처는 프로젝트 [15][20]제공에 따른 리스크를 줄이는 데 도움이 됩니다.

예

기업의 아키텍처는 미국 연방정부[21] 내에서 자본계획 및 투자관리(CPIC) 프로세스와 관련하여 문서화됩니다.

FEA(Federal Enterprise Architecture) 참조 모델은 연방 기관이 아키텍처를 [22]개발할 때 안내합니다.

Independence Blue Cross, Intel, Volkswagen[23] AG, InterContinental Hotels Group 등의 기업은 엔터프라이즈 아키텍처를 사용하여 비즈니스 아키텍처와 비즈니스 퍼포먼스 및 생산성 향상을 도모하고 있습니다.

다양한 이유로 인해 상업 조직은 실질적인 엔터프라이즈 아키텍처에 대한 설명을 거의 발표하지 않습니다.그러나 정부기관들은 자신들이 개발한 건축설명을 발표하기 시작했다.예를 들어 다음과 같습니다.

과제들

엔터프라이즈 아키텍처의 확립은 현재 엔터프라이즈 아키텍트가 직면한 가장 큰 과제 중 하나이자 많은 EA-Initiative가 [25]실패하는 주요 이유 중 하나로 인식되고 있으며, 인정되고 기능적으로 통합되며 완전히 관여하는 개념을 운용 및 전술적 수준에서 확립하는 것입니다.

비판

엔터프라이즈 아키텍처가 제공하는 이점에도 불구하고 작가와 조직은 10년 이상 엔터프라이즈 아키텍처가 효과적인 방법이라는 우려를 제기했습니다.다음은 이러한 이의의 일부 목록입니다.

  • 2007년 컴퓨터 과학자 Ivar Jacobson(UML에 기여하고 OO 소프트웨어 개발의 선구자)은 엔터프라이즈 아키텍처에 대해 다음과 같이 평가했습니다. "엔터프라이즈 아키텍처 EA는 지난 5년 동안 대부분의 금융 기관(은행, 보험 회사, 정부 등)을 위한 이니셔티브였습니다.아직 끝난게 아니야저는 그런 회사들과 함께 일해왔고, 그 회사들 중 몇몇은 최악의 실수를 하지 않도록 도왔습니다.대부분의 EA 이니셔티브는 실패했습니다.90% 이상이 실제로 [26]유용한 결과를 가져온 적이 없다고 생각합니다."
  • Gartner는 엔터프라이즈 아키텍처에 관한 2007년 보고서에서 "... 2012년까지 [2007년] 엔터프라이즈 아키텍처 프로그램의 40%가 [27]중단될 것"이라고 예측했습니다.
  • Erasmus University Rodterdam과 소프트웨어 회사인 IDS Scheer가 실시한 2008년 조사에서는 엔터프라이즈 아키텍처 프로젝트의 3분의 2가 비즈니스와 IT의 [28]연계를 개선하는 데 실패했다고 결론지었습니다.
  • 업계 논객 Dion Hinchcliffe는 2009년 기사에서 기존의 엔터프라이즈 아키텍처가 "파탄"될 가능성이 있다고 지적했습니다.「최적의 엔터프라이즈 아키텍처는, 비즈니스의 모든 가능성을 명확하게 나타내는 밝은 선을 제공하고, 거기에 도달하는 방법도 설명하고 있습니다.」오늘날 흔히 행해지고 있는 기존의 엔터프라이즈 아키텍처가 어떤 중요한 방식으로든 무너질 수 있다는 인식이 최근 확산되고 있습니다.무엇이 문제인지, 어떻게 고치느냐가 문제입니다.[29]
  • 2011년 연방정부 엔터프라이즈 아키텍처 컨설턴트 Stanley Gaver는 미국 연방정부의 엔터프라이즈 아키텍처 프로그램 내의 문제를 조사한 보고서를 발표했습니다.Gaver씨는 연방 기업 아키텍처 프로그램이 대부분 실패했다고 결론내렸습니다.이 결론은 연방 정부가 2010년 10월 연방 기업 아키텍처 프로그램이 [30]"과거처럼 영향력이 있고 성공적이지 못한" 이유를 밝히기 위해 열린 회의에서 이루어진 유사한 결론에 의해 입증되었습니다.

EA의 주요 우려 사항은 EA 프로젝트의 [31]광범위하고 불투명한 특성 때문에 성공의 지표에 도달하는 데 어려움이 있었습니다.

다른 분야와의 관계

엔터프라이즈 아키텍처 프로페셔널 조직 연맹(FEAPO)에 따르면 엔터프라이즈 아키텍처는 비즈니스 환경에서 흔히 볼 수 있는 다양한 분야와 상호 작용합니다.FEAPO에 따르면:

엔터프라이즈 아키텍처 실무는 퍼포먼스 엔지니어링 및 관리, 프로세스 엔지니어링 및 관리, IT 및 엔터프라이즈 포트폴리오 관리, 거버넌스 및 컴플라이언스, IT 전략 계획, 리스크 분석, 정보 관리, 메타데이터 관리 및 다양한 기술 등 상호 연결된 많은 분야와 협업합니다.ical 분야와 조직 개발, 혁신, 학습 등의 조직 분야.많은 실무자들이 엔터프라이즈 아키텍처와 디자인 사고, 시스템 사고, 사용자 경험 [32]설계와 같은 새로운 전체론적 설계 관행과의 중요한 관계를 강조해 왔습니다.

다양한 조직에서 엔터프라이즈 아키텍처가 등장함에 따라 이 비즈니스 역할이 많은 조직의 IT 거버넌스 프로세스에 포함되게 되었습니다.이는 엔터프라이즈 아키텍처가 IT와 밀접하게 관련되어 있음을 의미할 수 있지만 비즈니스 아키텍처, 성능 관리 및 프로세스 아키텍처 및 더 많은 기술적 주제를 다룬다는 점에서 비즈니스 최적화의 넓은 맥락에서 보아야 합니다.

엔터프라이즈 아키텍처와 다양한 IT 프랙티스의 교차점에 대한 논의는 다양한 IT 분석 회사에 의해 발표되었습니다.Gartner와 Forrester는 엔터프라이즈 아키텍처와 Design Thinking 및 User Experience [33][34][35]Design과 같은 새로운 전체론적 설계 관행과의 중요한 관계를 강조했습니다.분석 기관인 Real Story Group은 엔터프라이즈 아키텍처와 디지털 워크플레이스의 새로운 개념이 "동전의 [36]양면"이라고 제안했습니다.커터 컨소시엄은 엔터프라이즈 아키텍처를 정보 및 지식 기반 분야로 설명합니다.[37]

조직의 엔터프라이즈 아키텍처는 전체를 문서화하기에는 너무 복잡하고 광범위하기 때문에 지식 관리 기술은 이러한 숨겨진 영역, 암묵적인 영역 또는 암묵적인 영역을 탐색하고 분석할 수 있는 방법을 제공합니다.그 대신 엔터프라이즈 아키텍처는 지식 [38]관리를 보완하는 체계적이고 전체적인 방식으로 조직의 구성요소와 이들의 상호작용을 문서화하는 방법을 제공합니다.

다양한 [39]장소에서 엔터프라이즈 아키텍처는 특정 유형의 애플리케이션 통합인 서비스 지향 아키텍처와 관련이 있다고 논의되어 왔습니다.연구에 따르면 전사적 통합 패턴으로 SOA [40][41]사용을 촉진하는 엔터프라이즈 아키텍처가 지적되고 있습니다.

역사

엔터프라이즈 아키텍처라는 용어를 사용한 최초의 출판물은 정보 시스템 통합의 과제에 관한 미국 국립 표준 연구소 특별[42] 간행물입니다.개요에는 다음과 같이 기술되어 있습니다.이 패널에서는 기업 전체의 관리를 지원하는 아키텍처와 표준의 역할에 대해 설명했습니다."

이러한 본래의 용도는 종종 "엔터프라이즈 아키텍처"라는 용어를 사용하지 않은 John Zachman의 1987년 [43]논문에서 잘못 해석됩니다.NIST "엔터프라이즈 아키텍처" 패널의 보고서 범위는 1987년 기사에서 제시된 Zachman의 현재 생각과 직접 비교될 수 있습니다. "정보 시스템의 구현 규모와 복잡성이 증가함에 따라 정의 및 제어를 위해 논리적 구성(또는 아키텍처)을 사용할 필요가 있습니다.인터페이스와 시스템 모든 컴포넌트의 통합.논의는 아키텍처에 한정되며 전략적 계획 방법론은 포함되지 않습니다."

1989년 NIST 기사에서 엔터프라이즈 아키텍처는 몇 가지 수준으로 구성되어 있다고 설명했습니다.최상위 레벨은 "비즈니스 유닛 아키텍처"입니다.이 문서에서는 다음과 같이 설명합니다. "비즈니스 유닛은 전체 법인 또는 법인 서브 유닛 중 하나를 나타낼 수 있습니다.이 레벨의 아키텍처는 내부 정보의 요구와 외부 조직에 의한 정보 및 데이터의 요구를 모두 만족시키기 위한 프레임워크를 확립합니다.이러한 외부 조직에는 협력 조직, 고객 및 연방 기관이 포함됩니다.이 수준의 정보 및 데이터 요구는 아키텍처의 하위 레벨에서 충족되어야 하며 기술적인 고려사항에 대한 관심이 높아져야 합니다."

1989년 NIST 문서는 계속됩니다.「비즈니스 유닛 아키텍처의 표현은, 조직 단위와 그 관계, 및 전사적인 미션의 달성을 가능하게 하거나 제한하는 특정의 표준, 정책, 및 순서를 나타내고 있습니다.」

조사 결과, Zachman의 개념은 비즈니스 사례에 최적화된 하위 시스템으로 구성된 개별 정보 시스템을 만드는 것이었음을 알 수 있습니다.그러나 NIST의 개념은 기업 전체일 수 있는 사업부 내의 모든 정보 시스템의 관리를 기술한다.

Zachman은 몇 년이 지나기 전까지 출판물에서 "엔터프라이즈 아키텍처"라는 정확한 용어를 사용하지 않았습니다.

「 」를 참조해 주세요.

레퍼런스

  1. ^ Dedić, Nedim. "EAFP: Enterprise Architecture Fusion Process". Journal of Information and Organizational Sciences. 45: 223–241. doi:10.31341/jios.45.1.10. S2CID 241327623.
  2. ^ "Planning an EA – Purpose". Enterprise Architecture Book of Knowledge. Mitre Corporation. Retrieved October 3, 2014.
  3. ^ "Enterprise Architecture (EA)". Gartner IT Glossary. Gartner. Retrieved July 29, 2013.
  4. ^ 국제비즈니스분석연구소 경영분석 지식기구
  5. ^ Giachetti, R.E., 엔터프라이즈 시스템 설계, 이론, 아키텍처 및 방법, CRC Press, Boca Raton, FL, 2010.
  6. ^ a b "ISO/IEC/IEEE 42010:2011 - Systems and software engineering - Architecture description". Iso.org. November 24, 2011. Retrieved August 6, 2013.
  7. ^ a b Lapalme, J., Three Schools of Think on Enterprise Architecture, IT Professional, vol. 14, No. 6, 페이지 37-43, 11월– 2012년 12월 doi: 10.1109/MITP.2011.109
  8. ^ Jarvis, Bob (2003) 엔터프라이즈 아키텍처: 전체적인 상황 이해– 영국 맨체스터, 영국 국립 컴퓨팅 센터, IT 의사결정자를 위한 베스트 프랙티스 가이드(9페이지)
  9. ^ 엔터프라이즈 아키텍처가 조직 목표 달성에 기여: 엔터프라이즈 아키텍처의 이점 프레임워크 구축, 기술 보고서, 위트레흐트 대학 정보 및 컴퓨팅 과학부, 네덜란드 위트레흐트(2010년 온라인)
  10. ^ 버트 아놀드, 마틴 오피트 랜드, 얀 디츠입니다2005년 독일 레겐스부르크 금융산업의 엔터프라이즈, 애플리케이션 및 서비스에 관한 제2회 국제 워크숍(FinanceCom05)에서 "공유 서비스 센터 구현에 대한 아키텍처 접근의 영향"
  11. ^ a b c d T. Bucher, R.피셔, S. Kurpjuweit 및 R. 겨울, "엔터프라이즈 아키텍처 분석 및 적용:조사 연구"를 참조해 주십시오.
  12. ^ a b Nilsson, "조직간 전자정부 프로젝트에서의 테크노캔지 관리", 제41회 하와이 국제시스템학회의 프로시딩스, 2008, 페이지 209.
  13. ^ a b c J. 바누스와 N. 파나이치TOGAF 9 엔터프라이즈 아키텍처 조사 결과.제23회 엔터프라이즈 아키텍처 실무자 회의에서 발표.[온라인]이용가능 : www.opengroup.org/public/member/proceedings/q309/q309a/Presentations/pl-varnus-panaich.pdf
  14. ^ a b c d e f Jeanne W. Ross와 Peter Weill, "엔터프라이즈 아키텍처의 이점에 대하여", CISR Research Briefings, 2005.
  15. ^ Quartel, Dick; Steen, Maarten W.A.; Lankhorst, Marc M. (May 1, 2012). "Application and project portfolio valuation using enterprise architecture and business requirements modelling". Enterprise Information Systems. 6 (2): 189–213. doi:10.1080/17517575.2011.625571. ISSN 1751-7575.
  16. ^ W. Engelsman, M. E. Iacob 및 H. M. Franken은 2009년 하와이 호놀룰루 ACM 심포지엄(SAC '09)에서 "아키텍처 주도 요건 엔지니어링"을 발표했습니다. 페이지 285-286
  17. ^ a b L. 카펠만, T. 맥기니스, A.펫타이트와 A.Sidorova, "엔터프라이즈 아키텍처:AMCIS 2008, 2008년 학술연구 영역도를 작성.
  18. ^ M. Pulkkinen, A. Naumenko, K.Luostarinen, "기계 유지보수 서비스 비즈니스 네트워크 정보 보안 관리 - 조정 도구로서의 엔터프라이즈 아키텍처"소프트웨어, 제80권, 페이지 1607-1620, 2007.
  19. ^ T. 오비츠와 M. K. 바부.(2009).엔터프라이즈 아키텍처는 전략적 비즈니스 혁신에서 그 역할을 확장합니다.Infosys 엔터프라이즈 아키텍처 조사 (2008/2009). (온라인[permanent dead link]).
  20. ^ 연방정부기관의 성공사례(2010), whitehouse.gov 2010년 4월 30일 Wayback Machine에서 아카이브
  21. ^ FEA 프랙티스 가이던스 Federal Enterprise Architecture Program Management Office OMB, (2007), whitehouse.gov 2010년 10월 16일 Wayback Machine에서 아카이브 완료
  22. ^ "Volkswagen of America: IT 우선순위 관리", Harvard Business Review, 2005년 10월 5일, Robert D.오스틴, 워렌 리치, 그레고리 개럿
  23. ^ DOD BEA
  24. ^ Dedic, N. (2020년)IEEE Engineering Management Review의 "FEAMI: 엔터프라이즈 아키텍처 프로세스를 기존 조직 프로세스에 포함 및 통합하는 방법론"제48권, 제4호.DOI: https://doi.org/10.1109/EMR.2020.3031968
  25. ^ 이바르 제이콥슨의 EA Failed Big Way!http://blog.ivarjacobson.com/에서 2013년 12월 4일, 2007년 10월 18일 Wayback Machine에서 아카이브되었습니다.
  26. ^ Gartner (2007) Gartner Enterprise Architecture Summit : 신속한 변화를 위한 조직의 구축, 2007년 9월 26일~27일 www.gartner.com 의 개요.2013년 11월 18일에 액세스.
  27. ^ S. Roeleven, Sven 및 J. Broer(2010).ARIS Expert Paper (온라인) "엔터프라이즈 아키텍처 프로젝트의 3분의 2가 실패하는 이유"
  28. ^ 엔터프라이즈 아키텍처 수정: 현대 조직의 변화의 힘의 균형, Dion Hinchcliffe, 2009년 9월 3일
  29. ^ "FEA가 작동하지 않는 이유"
  30. ^ 엔터프라이즈 아키텍처 효율성 측정: 주요 성과 지표에 대한 집중, Gunther, W 2014
  31. ^ 엔터프라이즈 아키텍처 프로페셔널 조직 연맹, "2016년 12월 20일 웨이백 머신에서 아카이브된 엔터프라이즈 아키텍처에 대한 공통 관점", Architecture and Governance Magazine, 제9-4호, 2013년 11월호(2013년)2013년 11월 19일 취득.
  32. ^ Clay Richardson, Forrester 블로그 – 역동적인 비즈니스를 위한 EA를 재설계하는 디자인 사고(2013) [1] 2013년 4월 19일 Wayback Machine에서 아카이브
  33. ^ Joe McKendrick, ZDNet – Gartner는 사일로에서 엔터프라이즈 아키텍처를 분리하기 위해 더 많은 '디자인 사고'를 촉구합니다(2010년) [2]
  34. ^ Leslie Owens, Forrester 블로그 – 정보 아키텍처 소유자는 누구입니까?All Of Us., (2010), 블로그.forrester.com 2010년 2월 5일 Wayback Machine에서 아카이브 완료
  35. ^ Tony Byrne, Real Story Group 블로그 – 디지털 워크플레이스와 엔터프라이즈 아키텍처: 동전의 양면(2012), [3]
  36. ^ 에버든, 로저"아키텍처 관점에서 너무 많은 데이터를 다루는 방법", 2012년 11월 13일 (온라인)
  37. ^ 에버든, 일레인, 에버든, 로저Information First - Butterworth-Heinemann, Business Advantage를 위한 지식과 정보 아키텍처 통합(온라인)
  38. ^ "SOA and Enterprise Architecture". The Open Group. Archived from the original on January 10, 2015. Retrieved December 18, 2014.
  39. ^ Christopher Kistasamy, Alta van der Merwe, Andre de la Harpe, (2012), 엔터프라이즈 아키텍처를 가능하게 하는 서비스 지향 아키텍처의 역할, AMCIS 2012, 시애틀 워싱턴
  40. ^ Rosa and Sampaio. "SOA Governance Through Enterprise Architecture". Oracle.com. Oracle. Retrieved December 19, 2014.
  41. ^ Fong, E. N.; Goldfine, E.H. (December 1989). "Information management directions: the integration challenge" (PDF). SIGMOD Record. 18 (4): 40–43. doi:10.1145/74120.74125. S2CID 23939840.
  42. ^ Zachman, John A. (1999). "A framework for information systems architecture". IBM Systems Journal (reprint ed.). 38 (2/3): 454–470. doi:10.1147/sj.382.0454.

외부 링크