비즈니스 아키텍처는 다른 요소와 명확한 관계를 갖고 구성된 요소 세트(기능성에 의해 정의된 완전체(whole)를 구성)로 정의됩니다. 요소는 비즈니스 시스템의 조직 및 동작 구조를 나타내며 비즈니스의 핵심 프로세스
및 구조에 대한 추상을 나타냅니다. [NDL97], [ERI00]
사람마다 배경과 관점이 다릅니다. 조직만큼 복잡한 사항(프로세스, 구조 및 전략 포함)에 대한 공통 이해를 달성하려고 시도하는 경우에는 아키텍처 및 구조적으로 중요한 문제를 영향받는 각 그룹이 이해할 수 있는
방법으로 설명하기 위한 방법이 필요합니다. 이는 이 문서에 표시되고 설명된 대로 세 개의 다르지만 관련된 아키텍처를 설명하여 수행됩니다.
비즈니스 아키텍처는 조직의 중요한 측면에 대한 설명입니다. 응용프로그램 아키텍처는 해당 응용프로그램 사용 방법 및 서로 상호작용하는 방법을 포함하여 비즈니스를 지원하는 소프트웨어
응용프로그램에 대한 설명입니다. 기술 아키텍처는 소프트웨어 응용프로그램을 지원하는 하드웨어 하부 구조에 대한 설명입니다.
비즈니스 아키텍처는 응용프로그램 아키텍처를 지배해야 하며, 응용프로그램 아키텍처는 기술 아키텍처를 지배해야 합니다. 이는 비즈니스 아키텍처가 응용프로그램 아키텍처를 규정하고 응용프로그램 아키텍처는 기술 아키텍처를
규정하는 계층 구조 관계를 의미하지는 않습니다. 그보다는 목적과 제한조건(구동 요소라고 함)이 한 방향으로 커뮤니케이션되고 지배 아키텍처에 영향을 주는 아키텍처 결정(절충이라고 함)을 지배 아키텍처 레벨에서 내려야
함을 의미합니다. 아키텍처 목적은 원하는 조건을 의미하는 반면, 아키텍처 제한조건은 필수 준수를 의미합니다. 그러나 제한조건을 의도적으로 무시할 수 있습니다. 예를 들어, 준수에 필요한 변경사항 작성 비용이
비준수로 인해 초래되는 불이익을 훨씬 초과하므로 비즈니스가 법령을 준수해야 한다는 제한조건을 무시할 수 있습니다.
아키텍처화는 힘의 밸런스를 조절하고 절충을 모색하여 충돌하는 요구사항을 최적으로 충족시키는 솔루션을 작성하는 것입니다. 이는 비즈니스 아키텍처가 응용프로그램 아키텍처로부터 요구하는 지원을 설명하는 목적과 제한조건을
정의함을 의미합니다. 응용프로그램 아키텍처와 기술 아키텍처에도 마찬가지로 적용됩니다. 항상 그렇듯 충돌이 발생하는 경우, 최적의 전체 솔루션을 보장할 수 있도록 로컬화된 하위 최적 솔루션을 찾아야 합니다. 이런
결정이 광범위한 영향을 미치는 경우 이를 아키텍처 문제라고 하며, 아키텍처 위원회가 대표하는 이해 당사자(stakeholder)가 공식적으로 동의해야 합니다.
이해 당사자(stakeholder)와 커뮤니케이션할 때 이런 다른 아키텍처를 항상 고려해야 합니다. 양식, 응용프로그램 또는 표기법을 이해하지 못하는 개인과 이 아키텍처 중 하나만 논의하게 되면 효과적인
커뮤니케이션이 되지 못합니다. 뿐만 아니라, 해당 개인이 다른 아키텍처와 관련된 자신의 결정 결과를 오해하게 될 수도 있습니다. 아키텍처 중 하나에 대해 내리는 결정이 미치는 영향을 다른 아키텍처에 대해 해석해야
합니다. 이렇게 하면 이해 당사자가 절충의 이점과 단점을 이해하여 아키텍처를 맞출 수 있습니다. 아키텍처 맞추기를 통해 결정 결과를 이해할 수 있습니다.
다른 이해 당사자(stakeholder)와 비즈니스에 대한 커뮤니케이션을 통해 공통의 일치된 이해를 도출하는 데 비즈니스 아키텍처를 사용합니다. 비즈니스 아키텍처를 프레임워크로 설명할 수 있는데, 그림에 표시된
대로 프레임워크 내에서 비즈니스가 비즈니스 아이디어를 궁극적으로 실현할 수 있도록 조직에 대한 변경사항을 작성합니다.
비즈니스 아키텍처는 측정하기 어렵고 복잡하기 때문에 이를 다수의 다른 보기로 나눕니다. 소프트웨어 아키텍처가 개념: 소프트웨어
아키텍처에 정의된 것과 같이 비즈니스 아키텍처 보기가 여기에 정의됩니다.
각 보기는 전체 비즈니스의 하나의 측면을 설명합니다. 따라서 구조적으로 중요한 전체 정의 서브세트를 포함합니다. 즉, 아키텍처 보기는 비즈니스의 해당 측면에 실제로 중요한 20%만 포함합니다. [ROY98]
아키텍처 보기는 다른 이해 당사자(stakeholder)와 비즈니스 아키텍처를 논의할 때 유용합니다. 각 이해 당사자는 특정 관심사에 대한 하나 또는 여러 개의 보기를 갖고 있기 때문에 다른 모든 것을 이해하지
않고도 해당 보기와 연관된 조직의 해당 측면에 초점을 맞출 수 있습니다.
모든 보기가 모든 상황에 적용되는 것은 이닙니다. 가치를 부여하지 않는 경우에는 일부 보기를 무시할 수 있으며, 새 보기를 정의하는 데 필요할 수도 있습니다. 몇 가지 일반적인 아키텍처 보기는 다음과 같습니다.
-
시장 보기는 비즈니스가 운영되는 시장, 고객 프로파일 및 오퍼링 또는 비즈니스가 대상 시장의 고객에게 제공하는 제품 및 서비스를 설명합니다.
-
비즈니스 프로세스 보기는 비즈니스의 중요한 목적을 설명하고 이런 목적을 지원하는 핵심 비즈니스 유스 케이스를 개괄적으로 설명합니다. 비즈니스 유스 케이스를 사용하여 비즈니스 프로세스를
문서화할 때 이 보기를 비즈니스 유스 케이스 보기라고 합니다.
-
조직 보기는 비즈니스 내 역할과 책임의 그룹화 및 비즈니스 유스 케이스 실현(realization)을 설명합니다.
-
인적 자원 보기는 보상 프로파일 및 인센티브 메커니즘, 핵심 문화적 특성 및 메커니즘, 역량 프로파일, 교육 및 훈련 메커니즘을 설명합니다.
-
도메인 보기는 주요 비즈니스 개념 및 비즈니스에 사용되는 정보 구조를 설명합니다.
-
지리 보기는 구/군/시, 국가와 같은 실제 위치 전반의 조직 구조, 기능 및 자원 분포를 설명합니다.
-
커뮤니케이션 보기는 비즈니스 내 커뮤니케이션 경로를 설명합니다.
비즈니스 아키텍처 보기를 RUP 시점에 맵핑
RUP 시점은 개념: 시스템 아키텍처에 설명되어 있습니다. 일반적으로 시스템 개발에 이 시점을 적용할 수 있습니다. 고려 중인 '시스템'이 비즈니스인 경우, 비즈니스
아키텍처 보기는 일반 시점에 대한 보다 적절한 전문화를 구성합니다. 다음 표는 비즈니스 아키텍처 보기 관련 방법을 표시합니다. 개념: 시스템
아키텍처에 제공된 정의에 의해 비즈니스 아키텍처 보기는 일부 경우 다중 보기를 포함합니다(여기서 보기는 시점 및 추상 레벨의 교차점임).
비즈니스 아키텍처 보기
|
RUP 시점
|
시장 보기
|
시장 보기는 적어도 부분적으로 비즈니스 컨텍스트를 정의합니다. 선택한 시장에서 고객에게 제공되는 실제 및 잠재 제품과 서비스에 초점을 맞춥니다. 논리 시점과
컨텍스트 레벨의 교차점에 맵핑됩니다. 중간 산출물: 비즈니스 아키텍처 문서를 위해 시장 보기는 아키텍처에 영향을 주는 해당 요인 및
아키텍처 변경사항이 선택한 시장의 성능에 영향을 주는 영역으로 제한됩니다.
보다 일반적인 시장 논의 및 비즈니스 전략 선택 근거는 중간 산출물: 비즈니스 비전에 있습니다.
시장 보기를 사용하여 새 중간 산출물: 비즈니스 목적을 설정할 수 있으며, 이는 다시 비즈니스 아키텍처에 영향을
줄 수 있습니다.
|
비즈니스 프로세스 보기
|
이 맵핑은 간단한데, 프로세스 시점과 컨텍스트 레벨의 교차점에 맵핑됩니다.
|
조직 보기
|
조직 보기는 비즈니스 유스 케이스를 실현할 수 있도록 비즈니스를 구조화하는 방법에 대한 것이며, 직책 또는 인력 계층 구조 및 네트워크에 대한 것이 아닙니다. 예를 들어, 이
보기에서 중간 산출물: 비즈니스 시스템의 협업을 볼 수 있습니다. 따라서 논리 시점과
분석 레벨의 교차점에 맵핑됩니다.
|
인적 자원 보기
|
인적 자원 보기는 작업자 시점을 잠재적으로 모든 레벨에서 확장하며, 가장 중요하게는 정책이 정의되는 컨텍스트 레벨에서 확장하지만 분석 및
디자인 레벨에서는 예를 들어, 역량 프로파일 적용을 통해 확장합니다.
|
도메인 보기
|
도메인 보기는 정보 시점과 컨텍스트 레벨의 교차점에 아주 잘 맵핑됩니다.
|
지리 보기 및 커뮤니케이션 보기
|
이 보기는 지리적 측면과 관련된 지역성 및 커뮤니케이션 측면과 관련된 커넥터를 사용하여 분포 시점과 컨텍스트 레벨(엔터프라이즈 지역성 보기)의
교차점에 함께 맵핑됩니다.
|
|