잭맨 프레임워크

Zachman Framework
Zachman Framework of Enterprise Architecture

Zachman Framework는 엔터프라이즈 온톨로지로서, 공식적이고 구조화된 기업 보기 및 정의 방법을 제공하는 엔터프라이즈 아키텍처의 기본 구조다.온톨로지(Ontology)는 2차원 분류 스키마로, 두 역사적 분류 사이의 교차점을 반영한다.첫 번째 질문은 원시적인 질문이다.뭐, 어떻게, 언제, 누가, 어디서, 왜.두 번째는 재화의 철학적 개념, 즉 추상적인 사상을 인스턴스화(instimation)로 변형시키는 데서 파생된 것이다.Zachman Framework 재조정 변환:식별, 정의, 표현, 사양, 구성 및 인스턴스화.[1]null

Zachman Framework는 그것이 설명하는 정보를 수집, 관리 또는 사용하기 위한 어떤 특정한 방법이나 과정을 의미하지 않는다는 점에서 방법론이 아니다.;[2] 오히려, 그것은 온톨로지로서, 건축 유물을 조직하기 위한 스키마(즉, 설계 문서, 규격 및 모델)를 사용하여 누가 유물의 대상자(예: 사업주와 건설자)와 어떤 특정한 문제(예: 데이터 및 기능)를 다루고 있는지를 모두 고려한다.[3]null

이 프레임워크는 1980년대 IBM에서 처음 이 개념을 개발한 크리에이터 존 잭맨의 이름을 따서 명명되었다.그 후 여러 차례 업데이트되었다.[4]null

개요

제목 "Zachman Framework"는 버전 3.0이 가장 최신인 "The Zachman Framework for Enterprise Architecture"를 가리킨다.Zachman Framework는 30년 역사에서 다음을 포함하도록 발전했다.

  • John Zachman이 IBM Systems 저널의 1987년 기사에 발표한 "A Framework for Information Systems Architecture"라는 이름의 초기 프레임워크.[5]
  • 엔터프라이즈 아키텍처를 위한 Zachman Framework 1990년대 1987년 원본의 업데이트로 확장되고 이름이 바뀌었다.[6]
  • Zachman International이 업계 표준으로 제공하는 이후 버전의 Zachman Framework 중 하나.
1997년부터 2005년까지 엔터프라이즈 아키텍처에 관한 여러 저서에서 제시된 Zachman 프레임워크의 콜라주.

다른 출처에서는, Zachman Framework가 프레임워크로서 소개되고, 수많은 방법으로 대표되는 John Zachman의 이름을 따서 명명되고, 이미지를 보라.이 프레임워크는 예를 들면 다음과 같이 설명된다.

  • 데이터를 구성하고 분석하기 위한 프레임워크,[7]
  • 엔터프라이즈 아키텍처의 [8]프레임워크
  • 분류 체계 또는 분류 체계[9]
  • 종종 6x6 매트릭스 형식으로 된 매트릭스
  • 2차원 모델[10] 또는 분석 모델
  • 기업의 상세한 표현을 정리하는 데 사용되는 2차원 [11]스키마

존 잭맨에 의해 개발된 프레임워크 외에도, 때로는 잭맨 프레임워크라고도 불리는 수많은 확장 및/또는 어플리케이션이 개발되었지만, 그것들은 일반적으로 실제 프레임워크 자체의 그래픽 오버레이인 경향이 있다.null

Zachman Framework는 엔터프라이즈 아키텍처에 관련된 여러 관점을 요약한다.이러한 관점은 이해관계자의 유형과 열과 함께 행을 따라 아키텍처의 측면을 정의하는 2차원 매트릭스로 표현된다.프레임워크는 구조에 대한 방법론을 정의하지 않는다.오히려 매트릭스는 조직에서 특별히 요구하는 목표/규칙, 프로세스, 자료, 역할, 위치 및 이벤트로 채워져야 하는 템플릿이다.프레임워크의 기둥들 사이의 매핑을 통한 추가 모델링은 조직의 문서화된 상태의 차이를 식별한다.[12]null

프레임워크는 기업의 기술 표현을 분류하고 조직하기 위한 논리적 구조다.그것은 기업의 경영과 기업 시스템 개발에 관여하는 행위자 모두에게 중요하다.[13]프레임워크의 열에 우선순위는 없지만, 행의 하향식 순서는 비즈니스 개념과 실제 물리적 기업의 정렬에 중요하다.프레임워크의 상세 수준은 각 셀(행은 아님)의 함수다.IT에 의해 수행되는 경우, 낮은 수준의 초점은 정보 기술에 집중되지만, 그것은 물리적 재료(예: 볼 밸브, 배관, 변압기, 퓨즈 박스)와 그러한 항목과 관련된 물리적 프로세스, 역할, 위치 등에 동일하게 적용될 수 있다.[citation needed]null

역사

1980년대에 존 잭맨은 IBM에서 조직의 정보 아키텍처를 분석, 정의 및 설계하는 방법인 비즈니스 시스템 계획(BSP)의 개발에 관여했었다.1982년에 Zachman은[14] 이미 이러한 분석이 시스템 설계 및 관리 자동화를 넘어 전략적인 비즈니스 계획 및 관리 과학의 전반적 영역까지 도달할 수 있다는 결론을 내렸다.그것은 기업 아키텍처, 데이터 중심 시스템 설계, 데이터 분류 기준 등의 (그 때 보다 난해한) 영역에서 사용될 수 있다.[14]null

"정보 시스템 아키텍처" 프레임워크

최초의 1987년 "정보 시스템 아키텍처 프레임워크".
1992년 프레임워크의 간단한 예.

1987년 기사 「정보 시스템 아키텍처의 프레임워크」[15]에서, Zachman은 「건축」이라는 용어가 정보 시스템 전문가에 의해 느슨하게 사용되었으며, 기획자, 설계자, 프로그래머, 커뮤니케이션 전문가 등에게는 다른 것을 의미한다고 언급했다.[16]정보 시스템 아키텍처의 프레임워크를 개발하기 위한 객관적이고 독립적인 기반을 찾는데 있어서, 자크만은 고전적 아키텍처의 분야와 산업계의 다양한 복잡한 엔지니어링 프로젝트를 살펴보았다.그는 유사한 접근법을 보고 아키텍처가 여러 수준에서 존재하며, 원재료 또는 데이터, 프로세스의 기능, 위치 또는 네트워크의 최소한 세 가지 관점을 포함한다고 결론지었다.[16]null

정보 시스템 아키텍처는 아키텍처 모델을 구성하기 위한 분류 스키마가 되도록 설계되었다.그것은 엔터프라이즈 아키텍처에 필요한 모델의 시놉틱 뷰를 제공한다.정보시스템 아키텍처는 모델이 무엇을 포함해야 하는지를 구체적으로 정의하지 않으며, 각 모델에 사용되는 모델링 언어를 강제하지 않으며, 이러한 모델을 만드는 방법을 제안하지 않는다.[17]null

연장 및 공식화

1992년 기사 "정보 시스템 아키텍처의 프레임워크 확장 및 공식화"에서 존 F. Sowa와 John Zachman은 프레임워크와 최근의 확장을 제시하고 개념 그래프의 표기법으로 어떻게 공식화할 수 있는지를 보여준다.[18]1992년에도:

John Zachman의 공동저자인 John Sowa는 '계획가'의 범위 관점(기업과 그 환경에 공통되는 경계 목록)과 '하위 계약자'의 상세 표현 관점(문맥상 공급업체 솔루션 구성요소)을 추가할 것을 제안했다.'누가, 언제, 왜'란 칼럼을 대중에게 공개했는데, 4단계 메타프레임워크의 개념과 관점에 걸친 통합 연관성 서술이 모두 논문에서 윤곽을 드러냈다.케리 앤더슨 힐리는 기사에 포함된 모델(프레임 메타모델)의 모델을 만드는 것을 도왔다.

— Stan Locke, Enterprise Convergence in Our Lifetime, from THE ENTERPRISE NEWSLETTER[19]

1990년대[19] 후반에

  • Clive Finkelstein과 같은 방법론자들은 그가 Enterprise Engineering이라고 이름 붙인 상위 두 개의 프레임워크 행에 다시 집중했고, 비즈니스 요구를 정보기술 엔지니어링 구현과 융합시키고, 조각들의 논리적 빌드 순서를 결정하는 가장 성공적인 방법 중 하나를 가지고 있다.

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

잭맨은 1997년 논문 "기업 아키텍처 프레임워크의 개념"에서 프레임워크를 "기업 아키텍처를 위한 프레임워크"라고 언급해야 하며 처음부터 그렇게 해야 한다고 말했다.그러나, 1980년대 초 Zachman에 따르면, "엔터프라이즈 리엔지니어링 또는 엔터프라이즈 모델링의 아이디어에 대한 관심이 거의 없었고, 일반적으로 정보 시스템 커뮤니티 내에서 형식과 모델의 사용은 애플리케이션 개발의 일부 측면에 한정되었다."[20]null

2008년에 Zachman Enterprise는 Zachman Framework를 도입했다.새로운 Zachman Framework 표준으로서의 공식 간결한 정의.null

확장 및 수정된 프레임워크

1990년대 이후 다음과 같은 확장된 프레임워크가 제안되었다.

  • 매튜 앤 맥기(1990)[21]는 초기 3가지 관점인 "무엇", "어떻게", "어디"를 이벤트("언제"), 이유("왜"), 조직("누구")[16]으로 확장했다.
  • Evernden(1996)은 대안적인 Information FrameWork를 제시했다.
  • 캡제미니가 1996년부터 개발한 통합건축 프레임워크.[22]
  • 블라단 조바노비치 외 모든(2006)은 자흐만 프레임워크를 다차원 자흐만 큐브로 확장한 자흐만 큐브를 제시한다.[23]

잭맨 프레임워크 항목

개념

Zachman Framework 이면의 기본 개념은 서로 다른 유형의 설명(예: 텍스트, 그래픽)을 사용하여 동일한 복잡한 사물이나 항목을 다른 목적으로 설명할 수 있다는 것이다.Zachman Framework는 모든 것을 완전히 설명하는데 필요한 36가지 범주를 제공한다. 특히 제조물(예: 가전제품), 건축 구조물(예: 건물), 기업(예: 조직과 조직의 모든 목표, 인력 및 기술)과 같은 복잡한 것.이 프레임워크는 여섯 가지 다른 관점에서 추상적인 아이디어의 여섯 가지 변형(세부하게 증가하지 않고 변형)을 제공한다.[24]null

그것은 다른 사람들이 다른 관점으로 같은 것을 바라볼 수 있게 해준다.이것은 환경에 대한 전체론적인 관점을 만들어내는데, 이것은 그림에서 묘사된 중요한 기능이다.[25]null

행 보기

각 행은 특정 관점에서 솔루션의 전체 보기를 나타낸다.상행이나 원근법은 반드시 낮은 원근법보다 전체를 포괄적으로 이해하는 것은 아니다.각 행은 구별되고 고유한 관점을 나타내지만, 각 관점의 산출물은 원근 수준에서 해결책을 정의하기에 충분한 세부사항을 제공해야 하며, 다음 행으로 명시적으로 번역해야 한다.[26]null

각 관점은 다른 관점의 요건과 그러한 관점이 부과하는 구속을 고려해야 한다.각 관점의 제약은 부가적이다.예를 들어, 상위 행의 제약조건은 아래 행에 영향을 미친다.하위 행의 제약조건은 상위 행에 영향을 미칠 수 있지만 반드시 영향을 미치는 것은 아니다.요구사항과 제약을 이해하려면 지식과 이해를 원근법에 따라 소통해야 한다.이 프레임워크는 관점들 간의 의사소통을 위한 수직적 방향을 지적한다.[26]null

재향군인회 잭맨 프레임워크는 그 행에 대한 설명을 곁들였다.[27][28]

현재 Zachman Framework 버전 (3)은 행을 다음과 같이 분류한다.

  • 집행관 관점(스코프 내용) - 첫 번째 건축 스케치는 "버블 차트" 또는 벤 도표로, 최종 구조의 크기, 형태, 부분적 관계, 기본 목적을 총체적으로 묘사한다.시스템 범위, 비용, 운영될 일반 환경과 어떻게 관련될 것인지에 대한 개요 또는 추정치를 원하는 설계자나 투자자에 대한 개요에 해당한다.
  • 사업관리 관점(사업개념) - 다음은 사업자의 관점에서 최종건물을 묘사하는 건축가의 도면으로, 사업 일상에서 이를 가지고 살아가야 할 건축가의 모습이다.그것들은 사업 설계를 구성하고 사업체 및 프로세스와 그들이 어떻게 관련되는지를 보여주는 기업(사업) 모델에 해당한다.
  • 설계자 관점(시스템 논리) - 설계자의 계획은 설계자의 관점에서 도면을 세부 요구사항으로 변환하는 것이다.이들은 데이터 요소, 논리적 프로세스 흐름 및 비즈니스 실체와 프로세스를 대표하는 기능을 결정해야 하는 시스템 분석가가 설계한 시스템 모델에 해당한다.
  • 엔지니어 관점(기술 물리학) - 계약자는 도구, 기술 및 재료의 제약을 이해하기에 충분한 세부사항을 가지고 건축가의 관점을 대표하도록 설계자의 계획을 다시 그려야 한다.건설업자의 계획은 정보 시스템 모델을 프로그래밍 언어, 입출력(I/O) 장치 또는 기타 필요한 지원 기술의 세부사항에 맞춰 조정해야 하는 기술 모델에 해당한다.
  • 정비사 관점(도구 구성품) - 하청업체는 부품 또는 하위 섹션의 세부 사항을 명시하는 정비사 계획에서 작업한다.이는 시스템의 전체적인 컨텍스트나 구조와 관계 없이 개별 모듈을 코드화하는 프로그래머에게 주어지는 상세한 사양에 해당한다.대안적으로, 그것들은 건설되기 보다는 조달되고 구현되는 모듈형 시스템 소프트웨어의 다양한 상용 기성품(COTS), 정부 기성품(GOTS) 또는 구성요소에 대한 상세 요구사항을 나타낼 수 있다.
  • 엔터프라이즈 관점 또는 (운영 인스턴스)

열의 초점

요약하자면, 각 관점은 동일한 근본적인 질문에 집중한 다음, 그 관점에서 그 질문에 답하여 높은 관점에서 낮은 관점으로 번역되는 서로 다른 서술적 표현(즉, 모델)을 만든다.초점(또는 제품 추상화)에 대한 기본 모델은 일정하게 유지된다.각 열의 기본 모델은 고유하게 정의되지만 행렬 전체와 아래쪽에 연관되어 있다.[26]또한, 6가지 범주의 기업 아키텍처 요소와 그들이 대답하는 기본적인 질문들은 Zachman Framework의 칼럼을 형성하며,[24] 이것들은 다음과 같다.

  1. 인벤토리 세트 - 무엇
  2. 프로세스 흐름 - 방법
  3. 배포 네트워크 - 위치
  4. 책임 할당 - 사용자
  5. 타이밍 사이클 - 시기
  6. 동기 부여 의도 - 왜

자흐만의 의견에서, 그의 틀을 독특하게 만드는 단 하나의 요인은 매트릭스의 어느 축에 있는 각 원소들이 그 축에 있는 다른 모든 원소들과 분명히 구별할 수 있다는 것이다.매트릭스의 각 셀의 표현은 단순히 증가하는 세부사항의 연속적인 수준일 뿐만 아니라, 사실 다른 표현이다. 맥락, 의미, 동기 및 용도가 다르다.각 축의 각 원소는 다른 축과 명백히 다르기 때문에 각 셀에 속하는 것을 정확하게 정의할 수 있다.[24]null

세포 모형

Zachman Framework는 일반적으로 통신 질문서를 컬럼으로 하고 Reifification Transformation을 행으로 하는 경계 6 x 6 "매트릭스"로 묘사된다.프레임워크 분류는 셀, 즉 질문서와 변환 사이의 교차점에 의해 억제된다.[29]null

셀 설명은 Zachman Framework 3.0 버전에서 직접 취합한다.null

경영진의 관점
  1. (무엇) 재고 식별
  2. (방법) 프로세스 식별
  3. (위치) 분포 식별
  4. (누구) 책임 식별
  5. (When) 타이밍
  6. (왜) 동기식별
비즈니스 관리 관점
  1. (무엇) 인벤토리 정의
  2. (방법) 프로세스 정의
  3. (Where) 분포 정의
  4. (누구) 책임 정의
  5. (When) 타이밍 정의
  6. (왜) 동기 정의
건축가 관점
  1. (무엇) 인벤토리 표현
  2. (방법) 공정 표현
  3. (위치) 분포 표현
  4. (누구) 책임 표현
  5. (When) 타이밍 표현
  6. (왜) 동기부여 표현
엔지니어 관점
  1. (무엇) 재고 사양
  2. (방법) 공정 규격
  3. (어디서)배부
  4. (누구) 책임 명세서
  5. (When) 타이밍
  6. (왜) 동기부여 명세서
정비사 관점
  1. (무엇) 인벤토리 구성
  2. (방법) 프로세스 구성
  3. (Where) 배포 구성
  4. (누구) 책임 구성
  5. (When) 타이밍 구성
  6. (이유) 동기 구성
엔터프라이즈 관점
  1. (무엇) 인벤토리 인스턴스화
  2. (방법) 인스턴스화 처리
  3. (어디서) 분포 인스턴스화
  4. (누구) 책임 인스턴스화
  5. (When) 타이밍 인스턴스화
  6. (왜) 동기부여 인스턴스화

각 셀의 제품 개발(즉, 건축적 인공물)이나 셀에 의해 구체화된 문제 해결책은 관점으로부터 질문에 대한 답이기 때문에, 전형적으로 모델이나 설명은 셀의 표면적 해답이나 보다 높은 수준의 묘사일 수 있다.그 대답을 뒷받침하는 정교한 모델 또는 설계는 셀 내부의 상세한 설명이다.분해(즉, 보다 상세한 수준으로 드릴다운)는 각 셀 내에서 이루어진다.셀이 명시적으로(정의되지 않음)되지 않으면 암묵적(정의되지 않음)이다.그것이 암묵적이라면, 이들 세포에 대해 가정을 할 위험이 존재한다.만약 그 가정이 타당하다면, 시간과 돈은 절약된다.그러나 가정이 유효하지 않으면 비용이 증가하여 시행 일정을 초과할 가능성이 높다.[26]null

프레임워크 규칙 집합

Zachman 프레임워크 규칙의 예.

이 프레임워크에는 다음과 같은 규칙들이 함께 제공된다.[30]

  • 규칙 1 열은 순서가 없음: 열은 교환할 수 있지만 줄이거나 만들 수 없음
  • 규칙 2 각 열에는 단순한 일반 모델이 있음: 모든 열에는 자체 메타 모델이 있을 수 있음
  • 규칙 3 각 열의 기본 모델은 고유해야 한다: 각 열의 기본 모델, 관계 객체 및 구조는 고유해야 한다.각각의 관계 개체는 상호의존적이지만 대표 목적은 독특하다.
  • 규칙 4 각 행은 구별되고 고유한 관점을 기술한다: 각 행은 특정 기업집단의 관점을 기술하고 있으며 그것에만 고유한 것이다.대부분의 계층 구조에는 일반적으로 모든 행이 존재한다.
  • 규칙 5 각각의 세포는 독특하다: 2,3과 4의 조합은 각각의 세포가 특정한 경우를 나타내는 독특한 세포를 생성해야 한다.예: A2는 결국 건설될 것을 나타내기 때문에 사업 산출물을 나타낸다.
  • 규칙 6 한 행에 있는 모든 셀 모델의 복합 또는 통합은 그 행의 관점에서 완전한 모델을 구성한다: 행과 열을 추가하지 않는 것과 같은 이유로, 이름을 변경하는 것은 프레임워크의 근본적인 논리적 구조를 바꿀 수 있다.
  • 규칙 7 논리는 재귀적이다: 논리는 동일한 실체의 두 인스턴스 사이에 관계성이 있다.

프레임워크는 기업과 같은 개념 객체뿐만 아니라 물리적 객체의 기술 표현을 분류하는 데 사용될 수 있다는 점에서 일반적이다.그 자체의 건축 구성을 분석하는 데 사용할 수 있다는 점에서도 재귀적이다.비록 프레임워크가 한 열에서 다른 열로 관계를 전달하겠지만, 그것은 여전히 근본적으로 기업의 구조적인 표현일 뿐 흐름의 표현은 아니다.null

세부적인 수준의 유연성

Zachman Framework의 강점 중 하나는 엔터프라이즈 아키텍처가 다룰 수 있는 포괄적인 뷰 집합을 명시적으로 보여준다는 것이다.[12]일부 사람들은 이 모델을 완전히 따르는 것은 프레임워크의 30개 셀마다 공예품이 필요하기 때문에 문서화에 너무 많은 중점을 둘 수 있다고 생각한다.그러나 Zachman은 분석 중인 문제를 해결하는 데 필요한 사실만 기재하면 된다는 것을 나타낸다.null

John Zachman은 문서, 프리젠테이션 및 세미나에서 프레임워크로서 주어진 조직에 대한 중요성에 기초하여 매트릭스의 각 셀에 대해 어떤 깊이와 폭의 세부 정보가 필요한지 융통성이 있다고 분명히 말한다.사업 목표를 달성하려면 재고와 프로세스 중심의 집중이 필요할 수 있는 자동차 회사는 문서화 작업을 What과 How 열에 집중하는 것이 유익할 수 있다.이와는 대조적으로, 사람과 이벤트 시간에 더 신경을 쓰는 여행사 회사는 문서화 작업을 Who, When, Where 열에 집중하는 것이 유익할 수 있다.그러나 다른 모든 열에 비즈니스 동인을 제공하기 때문에 Why 칼럼의 중요성에서 벗어날 수 없다.null

응용 프로그램 및 영향

1990년대 이후, Zachman Framework는 정보기술 공학 스타일의 엔터프라이즈 모델링을 위한 구조를 제공하는 수단으로 널리 사용되어 왔다.[31]잭맨 프레임워크는 상업적 기업과 정부 기관 모두에 적용될 수 있다.정부 조직 내에서 프레임워크는 추상적인 수준에서 전체 기관에 적용될 수도 있고, 다양한 부서, 사무실, 프로그램, 서브유닛 그리고 심지어 기본 운영 주체에 적용될 수도 있다.[32]null

사용자 지정

Zachman Framework는 유사한 프레임워크인 TEAF 매트릭스를 중심으로 구축된 TEAF와 같은 맞춤형 프레임워크에 적용된다.null

  • TEAF 시각 및 관점의 매트릭스.null

  • EA 방향, 설명 및 달성 개요를 위한 프레임워크.null

  • TEAF 제품.null

  • EA 방향, 설명 및 성과를 위한 TEAF 작업 제품.null

기타 출처:

  • TEAF 매트릭스를 사용자 정의 샘플이라고 한다(여기서 22페이지 참조).

Zachman 프레임워크 기반 표준

Zachman Framework는 의료 및 의료 정보 시스템의 표준과 같은 표준을 기술하는 프레임워크로도 사용된다.프레임워크의 각 셀에는 의료 및 의료 정보 시스템에 대한 일련의 표준이 포함되어 있다.[33]null

다른 프레임워크 매핑

Zachman Framework의 또 다른 적용은 다른 엔터프라이즈 아키텍처의 참조 모델로서 다음과 같은 4가지를 참조한다.

  • 1999년 잭맨 프레임워크에 매핑된 EAP

  • C4 매핑ISR, 1999

  • DoD Products Map to the Zachman Framework Cells, 2003.null

  • DoDAF의 일부분 매핑, 2007.null

기타 예:

  • 프로세스로서의 합리적 통합 프로세스 분석,[34]
  • MDA(모델 중심 아키텍처) 모델이 소프트웨어 개발에 사용된 방법을 Zachman Framework에 매핑하는 방법.[35]
  • 제품 정보 추적성을 분석하기 위해 IEC 62264 모델을 Zachman 프레임워크에 매핑.[36]
  • TOGAF 아키텍처 개발 방법(예:[6] 방법론)을 Zachman Framework에 매핑.

다른 엔터프라이즈 아키텍처 프레임워크의 기반

덜 분명한 것은 원래의 Zachman 프레임워크가 NIST Enterprise Architecture Model C4와 같은 다른 엔터프라이즈 아키텍처 프레임워크의 개발을 자극한 방법이다.ISR AE, DOE AE 및 DODAF:

  • NIST 엔터프라이즈 아키텍처 모델.[26]null

  • C4ISR AE, 1997.null

  • DOE AE, 1998.null

  • DODAF, 2003.null

예: One-VA 엔터프라이즈 아키텍처

예를 들어 Zachman Framework 방법론은 2001년 미국 보훈처(VA)가 One-VA Enterprise Architecture를 개발하고 유지하기 위해 사용해 왔다.이 방법론은 비즈니스 프로세스, 데이터, 기술, 위치, 인력 및 요구사항 관점에서 VA 기업의 모든 측면을 정의해야 했다.방법론을 구현하는 다음 단계는 각 비즈니스 프로세스와 관련된 모든 기능을 정의하고 관련 데이터 요소를 식별하는 것이었습니다.일단 식별되면, 기능의 중복과 데이터 정의의 불일치를 확인하고 해결할 수 있다.[38]

  • VA IT 프로젝트를 위한 통합 프로세스 흐름(2001)

  • VA Zachman Framework 포털

  • VA EA 저장소 소개(2008)

  • Zachman 건축 프레임워크에 관한 튜토리얼

21세기[when?] 초 보훈부는 자흐만 프레임워크를 기반으로 한 기업 건축을 전면적으로 시행할 계획이었다.null

  • Zachman Framework는 2001년에 엔터프라이즈 아키텍처 계획을 시작하기 위한 참조 모델로 사용되었다.
  • VA Zachman Framework Portal 사이 어딘가에 건설되었다.
  • 이 VA Zachman Framework Portal은 다양한 비즈니스 및 프로젝트 출처 문서에서 수집된 EA 정보의 결정에서 예를 들어 참조 모델로 여전히 사용되고 있다.

결국 엔터프라이즈 아키텍처 저장소는 Zachman 프레임워크에 의해 매크로 레벨에서 그리고 아래에 설명된 메타 모델에 의해 셀 레벨에서 만들어졌다.[39]null

VA EA 메타 모델 셀 세부 정보 확대.

이 도표는[40] VA-EA에 통합되어 그것이 사용한 변광성의 상징적 표현을 제공하고, One-VA 엔터프라이즈 아키텍처를 설명하며, 상용 EA 리포지토리 소프트웨어를 사용하지 않고 EA 리포지토리를 건설하기 위해 사용되었다.그것은 Caliber-RM 소프트웨어 제품 내의 객체 지향 데이터베이스를 사용하여 개발되었다.Caliber-RM은 EA 리포지토리가 아닌 소프트웨어 구성 관리 툴로 사용하도록 되어 있다.null

그러나 이 도구는 엔티티와 관계를 정의하고 엔티티와 관계 모두에 대한 속성을 정의할 수 있도록 허용하였고, 이는 2003년 초 이용 가능한 기술을 고려하여 EA 저장소를 구축하기에 충분하였다.이 도구를 선택할 때 개인적인 동기는 당시 사용 가능한 상업용 리포지토리 도구들 중 어느 것도 진정한 Zachman Framework 표현을 제공하지 않았으며, 매우 독점적이어서 다른 벤더나 오픈 소스로부터의 컴포넌트를 통합하는 것이 어렵다는 것이었다.null

이 도표는 Zachman Framework와 정보기술 투자 관리에 대한 적응에 대한 몇 가지 중요한 해석을 강조한다.null

  1. 위에서 아래로 줄을 따라 진행하면서 정보산업 전반에 걸친 사실상의 표준인 시스템 개발 수명주기(SDLC)를 추적할 수 있다.
  2. 이 도표는 종종 무시되는 Zachman Row-Six (Integrated, Operational Enterprise View)의 중요성을 강조한다.Zachman 행 6에 대한 Zuech씨의 해석에 나타난 표현은 주로 2열에서 5열까지 걸쳐 개발된 비즈니스 프로세스와 기술 혁신에서 기인하는 측정 가능한 서비스 개선과 비용 절감/회피성이다.

6행은 개별 프로젝트 및 잠재적으로 전체 투자 포트폴리오에 대해 측정된 투자 수익률을 제공한다.6행 없이 6행은 침몰 비용만 식별하지만, 6행 ROI는 이를 통해 이익을 측정하고 지속적으로 개선되는 과정에 사용할 수 있도록 허용하며, 모범 사례를 포착하고 2행까지 이를 다시 적용할 수 있다.null

비판

Zachman Framework가 널리 논의되고 있는 가운데, 그것의 실질적인 가치는 다음과 같은 의문이 제기되었다.

  • 그 틀은 순전히 추측성적이고 비흡연적이며, "[제조업과 건설업의 건축적 표현 사이의 평등성]이 a를 건설하는 과정에서 유사한 일련의 건축적 표현들이 생산될 가능성이 있다는 주장을 강화시킬 것이라는 개념적 주장에만 기초하고 있다.ny complex 엔지니어링 제품(정보 시스템 포함)"[5]
  • 실제적인 피드백은 Zachman Framework에서 제안하는 기업에 대한 포괄적인 설명을 만드는 일반적인 아이디어가 비현실적이라는[41] 것을 보여준다.
  • 2004년에 존 잭맨은 그 프레임워크가 이론적이고 완전히 구현된 적이 없다는 것을 인정했다: "만약 당신이 누가 전체 프레임워크를 성공적으로 구현하고 있는지 물어본다면, 그 해답은 우리가 아직 아는 사람이 아무도 없다."[42]
  • 프레임워크의[43] 성공적인 실용화를 보여주는 구체적인 예는 없다.
  • EA의 실무자인 스탠리 게버는 "존 잭맨이 처음 만든 고전적 건축에 대한 유추도 결함이 있고 불완전하다"[44]고 주장한다.
  • 제이슨 블룸버그는 "기업은 기계나 건물과 같은 평범한 시스템이 아니며, 그렇게 설계되거나 설계될 수 없다"[45]고 주장한다.
  • 상세한 조사 결과, Zachman Framework는 사실 허구적인 약속으로 추진된 순전히 추측성 주장에만 근거하고 있으며, 실제적인 활용 사례는 없으며, 역사적 관점에서 이전에[46][47] 누락된 혁신적인 아이디어는 전혀 도입하지 않았다는 것이 입증되었다.

이러한 비판은 Zachman Framework가 EA의 실제 모범 사례를 거의 반영할 수 없음을 시사한다.null

참고 항목

참조

  1. ^ 존 잭맨의 Zachman 프레임워크의 간결한 정의, 2008년
  2. ^ "The Zachman Framework: The Official Concise Definition". Zachman International. 2008.
  3. ^ Microsoft Developer Network Architecture Center Roger Sessions의 4대 엔터프라이즈 아키텍처 방법론 비교
  4. ^ "The Zachman Framework Evolution". Zachman International. April 2009.
  5. ^ a b "A framework for information systems architecture" (PDF). IBM Systems Journal, Vol. 26. No. 3. 1987.
  6. ^ a b 오픈 그룹 (1999–2006)TOGAF 8.1.1 온라인에서 "ADM 및 Zachman Framework".2009년 1월 25일에 접속.
  7. ^ 윌리엄 H. Inmon, John A. Zachman, Jonathan G. Geiger(1997년).데이터 저장소, 데이터 웨어하우징 및 Zachman Framework: 엔터프라이즈 지식 관리맥그로힐, 1997년ISBN 0-07-031429-2.
  8. ^ 피트 소여, 바바라 패치, 패트릭 헤이먼스(2007).요구사항 엔지니어링: 소프트웨어 품질 기반.191페이지
  9. ^ 캐슬린 B.Has(2007년).전략가로서의 비즈니스 분석가: 비즈니스 전략을 가치 있는 솔루션으로 변환. 58페이지.
  10. ^ 해럴드 F.Tipton, Miki Krause(2008).정보 보안 관리 핸드북, 제6판, 제2권 263페이지.
  11. ^ 오루크, 피쉬맨, 셀코우(2003)Zachman Framework를 사용한 엔터프라이즈 아키텍처 9페이지.
  12. ^ a b 제임스 맥거번 외 연구진(2003).엔터프라이즈 아키텍처에 대한 실무 지침. 페이지 127-129.
  13. ^ 마크 란코르스트 외(2005).24페이지에 있는 엔터프라이즈 아키텍처.
  14. ^ a b "비즈니스 시스템 계획 및 비즈니스 정보 제어 연구: 비교.인: IBM Systems Journal, vol 21, no 3, 1982. 페이지 31-53.
  15. ^ 존 A. 잭맨(1987년)."정보 시스템 아키텍처 프레임워크".인: IBM Systems Journal, vol 26, no 3.IBM 간행물 G321-5298.
  16. ^ a b c 더워드 P. 잭슨(1992년)."정보 자원 관리의 프로세스 기반 계획".In: 경쟁 우위 및 경제 개발을 위한 신흥 정보 기술.1992년 정보자원관리협회 국제회의의 의사진행. 메흐디 호스로푸어(ed. ISBN 1-878289-17-9
  17. ^ 알랭 베그만 외(2008)."시스템적 개념화를 통한 Zachman 엔터프라이즈 아키텍처 프레임워크 강화"2008년 9월 15~19일 독일 뮌헨에서 열린 제12차 IEEE 국제 EDOC 컨퍼런스(EDOC 2008)에서 발표되었다.
  18. ^ John F. Sowa와 John Zachman(1992년)."정보 시스템 아키텍처를 위한 프레임워크 확장 및 공식화" In: IBM Systems Journal, Vol 31, No.3, 1992. 페이지 590-616.
  19. ^ a b 스탠 로크(2008)"Enterprise Convergence in our Life" 2008년 9월 16일, TEN42 엔터프라이즈 뉴스레터
  20. ^ 존 A. 잭맨(1997년)."엔터프라이즈 아키텍처 프레임워크의 개념: 배경, 설명 및 유틸리티"잭맨 인터내셔널.2009년 1월 19일에 접속.
  21. ^ R.W. 매튜스&. W.C. 맥기(1990)."소프트웨어 개발을 위한 데이터 모델링".in: IBM Systems Journal" 29(2). 페이지 228–234
  22. ^ 자프 셰커먼(2003년).엔터프라이즈 아키텍처 프레임워크의 정글에서 살아남는 방법 139-144페이지.
  23. ^ 블라단 조바노비치, 스테반 미스터달즈 & 아드리아누 가디너(2006)가 있다.잭맨 큐브.인: 정보 시스템의 문제.제7권 제2호 2006 페이지 257-262.
  24. ^ a b c VA 기업 아키텍처 혁신 팀(2001년).엔터프라이즈 아키텍처: 2001년 8월, 전략, 거버넌스 및 실행 보고서 부서.
  25. ^ W. H. Inmon에 의한 정부 정보 공장과 Zachman Framework, 2003. 페이지 4.2009년 7월 14일에 접속.
  26. ^ a b c d e 최고 정보 책임자 협의회(1999년).연방 기업 아키텍처 프레임워크 버전 1.1.1999년 9월
  27. ^ 미국 보훈처(2002) Zachman 건축 프레임워크에 대한 자습서.2008년 12월 6일에 접속.
  28. ^ 빌 인몬은 이 이미지를 "내가 아는 최고의 건축가 중 한 명 - 원래 2005년 11월 17일에 출판된 기사에서 "자흐만 프레임워크의 단순한 예"라고 불렀다.
  29. ^ Zachman, John A. "Official Home of The Zachman Framework™". Zachman International. Retrieved 14 February 2015.
  30. ^ 적응 대상:Sowa, J.F. & J.A. Zachman, 1992년, Inmon, W.H. J.A. Zachman, & J.G. 가이거, 1997년.오마하 대학교
  31. ^ 이언 그레이엄(1995년).객체 기술로 마이그레이션: 의미론적 객체 모델링 접근방식.애디슨 웨슬리, ISBN 0-201-59389-0. 페이지 322.
  32. ^ 제이 D. 화이트(2007)공공 부문의 정보 관리. 254페이지.
  33. ^ ZACHMAN ISA 의료정보학 표준 프레임워크, 1997.
  34. ^ DJ de Villiers(2001년)."합리적 통합 프로세스를 평가하기 위해 Zachman Framework 사용" 인: Rational Edge Rational Software 2001.
  35. ^ 데이비드 S. 프랑켈, 하몬, P, 무커지, J, 오델, J, 오웬, M, 리빗, P, 로젠, M... & Soley, R. M. 외.(2003) Zachman Framework 및 OMG의 Model Driven Architecture 백서.비즈니스 프로세스 동향.
  36. ^ 에르베 파네토, 살라 바아나, 제라드 모렐(2007)이다.제품 정보 추적성 분석을 위한 Zachman 프레임워크에 모델 매핑 : 사례 연구.
  37. ^ 롤랜드 트라운뮐러(2004)전자정부 페이지 51
  38. ^ 존 A 박사의 진술. 가우스 보훈처 정보통신부 차관보, 미국 하원 감독조사위원회 소위에 앞서 보훈처.2002년 3월 13일.
  39. ^ 2009년 12월 25일에 액세스한 메타 모델 셀 세부 정보
  40. ^ 이 도표는 2001년 공공영역에 배치한 아나폴리스 메릴랜드의 알빈 마틴 주흐의 배타적 작품이다.Al Zuech는 2000년부터 현재까지 그것의 개발의 수많은 단계에서 원래의 시각적 도표를 유지한다.알 주흐는 2001년부터 2007년까지 보훈처 기업건축서비스국장을 지냈다.
  41. ^ 김, Y.G.와 에베레스트, G.C. (1994년)IS 아키텍처 구축: 현장에서의 집단적 지혜.In: Information & Management, vol. 26, no. 1, 페이지 1-11.
  42. ^ 2016년 5월 19일 방문한 댄 루비 존 잭맨과의 인터뷰 "Framework 수정, 파트 3"
  43. ^ T.의 율마키와 V. (2006)의 할투넨.실제 방법 엔지니어링: 소규모 기업건축 중심의 프로젝트 맥락에서 Zachman Framework 적용사례인: 정보, 지식, 시스템 관리, vol. 5, 3, 페이지 189-209.
  44. ^ 스탠리 B, "연방 기업 아키텍처는 왜 작동하지 않는가?"가버, 2016년 5월 19일 방문
  45. ^ 제이슨 블룸버그는 2016년 5월 19일 "엔터프라이즈 아키텍처가 완전히 망가졌는가?"를 방문했다.
  46. ^ 2018년 4월 S. Kotusev, "Fake and Real Tools for Enterprise Architecture"
  47. ^ "Fake and Real Tools for Enterprise Architecture: 2019년 8월 S. Kotusev, Zachman Framework and Business Capacity Model"

외부 링크