소개
비즈니스 시스템은 비즈니스 내부의 독립 기능을 나타냅니다. 비즈니스 시스템은 비즈니스 구조를 이해하고 관리 가능한 단위로 분할하는 데 사용됩니다. 이는 조직이 일반적으로 독립 단위로 분할되는 것과 같습니다. 그러나
다양한 조직 파트의 역할과 목적이 다른 파트와 명확히 구분되지 않는 경우도 있어 비즈니스 프로세스를 실행하는 데 있어 최적화되지 않은 상호작용이 발생할 수 있습니다.
비즈니스 시스템은 보다 세분화된 파티션 및 상호 종속성 개념을 사용합니다. 비즈니스 시스템은 역할 및 자원(다른 비즈니스 시스템 포함 가능)을 바인드하고 포함할 뿐만 아니라 인터페이스 또는 요청 가능한
서비스 또는 책임 세트를 명확히 정의할 수 있습니다. 서비스 레벨 계약을 정의하여 부서와 외부 협업자 사이의 상호작용을 공식적으로 지정하고 관리하는 조직은 실질적으로 비즈니스 시스템을 정의하는
것입니다. 비즈니스 시스템을 사용하는 것은 종종 다른 추상 레벨에서 비즈니스 모델을 사용하여 보조를 맞추는 것입니다(개념: 대규모 조직 모델링 참조).
"비즈니스 시스템"이라는 용어와 소프트웨어 시스템을 혼동해서는 안됩니다. 비즈니스 시스템에는 사람, 하드웨어 및 소프트웨어가 포함되므로 소프트웨어 시스템보다 추상 레벨이 높습니다.
비즈니스 시스템의 동적 구조
사용
Chris Marshall은 그의 저서 UML을 사용한 엔터프라이즈 모델링에서 빠르게 분화되고 동적인 특성을 갖는 새로운 비즈니스 세계에 상대적으로 정적인 전통 조직 구조를 더 이상 적용할 수 없음을
지적했습니다. 즉, 더 이상 조직의 특정 파트가 장기간 변하지 않은 상태로 유지될 수 없게 되었습니다. Chris Marshall은 또한 "시간 경과에 따라 형성과 해체를 반복하는 가치 사슬을 통해 가치가 창출되고
전달되는 것이며 가까운 시일 내에 이러한 가치 사슬이 단일 트랜잭션에 대해 형성될 것입니다"라고 주장합니다.
조직은 유기적 특성을 갖고 있습니다. 즉, 비즈니스 환경으로부터의 압력을 받으면 그에 적응함으로써 경쟁력을 유지할 수 있습니다. 극단적인 예를 들어, 매우 동적이고 냉혹한 비즈니스 환경에서는 정적인 조직 구조가
경쟁력을 잃게 되므로 회사는 생존 메커니즘으로 동적 구조를 채택해야 합니다.
전통적인 정적 조직 구조에서는 부서라는 경계가 개념적인 기능만 수행했습니다. 이는 곧 "개방적"이고 "비공식적"인 조직을 나타내며 결과적으로 조직의 모든 구성원과 세그먼트가 조직 내 나머지 요소와 서로 얽힌 상태가
됩니다. 이러한 경우 조직의 특정 파트를 변경 또는 관리하는 데 있어 다른 파트와 완전히 독립된 상태를 유지하기가 매우 어렵습니다. 비즈니스 시스템은 사전 정의된 인터페이스를 제외하고는 비즈니스 시스템 간
상호작용을 허용하지 않음으로써 파티션과 경계를 준수합니다. 이러한 인터페이스(형식화된 서비스 레벨 계약 포함)는 조직을 지원하는 연결 고리 역할을 수행합니다. 이러한 비즈니스 시스템 간 인터페이스의 가장 중요한
장점은 조직 내 각 파트가 서로 분리된다는 것입니다. 종속성은 책임 수행 방법이 아닌 해당 책임 관점에서 정의됩니다.
책임 스펙과 책임 실현(realization)을 구분하고, 비즈니스 시스템 사용자를 비즈니스 시스템 경계 내부의 실현 요소가 아닌 해당 경계에 지정된 서비스에 바인드하면 프로세스 성능을 저하시키지
않고 해당 구조를 빠르게 변경할 수 있는 신속한 조직을 얻게 됩니다. 이러한 조직에서는 비즈니스 시스템으로 정의된 기능 중 하나를 수정, 개선 또는 아웃소싱할 수 있으며 나머지 조직 파트에 대한 전반적인
영향을 최소화할 수 있습니다. 서비스 품질이 변경 후에도 동일한 경우 비즈니스 오퍼레이션은 계속 지속됩니다. 같은 작업을 소프트웨어 시스템, 한 명의 사용자 또는 전체 부서가 현장에서 또는 원격으로 수행할 수
있습니다.
비즈니스 이벤트를 사용하여 상호작용을 추상하는 경우 비즈니스 시스템 간의 직접적인 종속성을 더 줄일 수 있습니다. 비즈니스 이벤트는 시간과 공간을 투명하게 하므로 비즈니스 시스템은 간접적으로 상호작용할 수
있습니다(가이드라인: 비즈니스 이벤트 참조).
참고: 캡슐화에 대한 UML 모델링 안내
UML을 사용하여 비즈니스 시스템을 모델링하는 경우 중간
산출물: 비즈니스 시스템의 설명대로, 캡슐화를 중요하게 생각하지 않는 경우 비즈니스 시스템 경계가 추상적이고(위에서 설명한 전통적인 정적 조직 구조의 특성) 상호작용면에서도 비즈니스 오퍼레이션에서
비즈니스 시스템이 계속 존재하지 않게 됩니다. 이 내용은 비즈니스 시스템(일종의 UML 컴포넌트)이 직접 인스턴스화되지 않고 해당 파트의 인스턴스화를 통해서만 가능함을 강조하여 UML로 표시할 수
있습니다. 다음 섹션에서는 비즈니스 시스템의 서비스 제공에 대해 설명합니다. 이러한 경우 캡슐화를 고려하여, 비즈니스 시스템의 직접 인스턴스화를 통해 여러 추상적인 경계를 갖도록 표시할 수
있습니다. 이 과정에서 오퍼레이션의 경계가 보다 실질적으로 작성될 수 있을 것으로 예상하여 비즈니스 시스템을 분석 및 디자인 시간에 확인합니다.
올바르게 정의된 비즈니스 시스템 책임
비즈니스 시스템은 수행해야 할 책임(서비스라고도 함)을 명확하게 정의합니다. 이 동작 스펙은 이전 섹션에서 언급한 종속성 분리를 허용하므로 중요합니다. 해당 서비스를 정의하지 않는 비즈니스 시스템은 의미가
없습니다. 다른 비즈니스 시스템은 특정 시스템이 제공하는 서비스를 해당 이름에서 추론하는 방법 이외에는 알 수 없습니다. 예를 들어, 자원 비즈니스 시스템(부서 명칭으로는 자원 관리)은 일반적으로 자원을 요청하고
자원 가용성을 조회하며 자원 유형 또는 프로파일을 조회하는 서비스를 제공합니다.
책임(또는 서비스)은 비즈니스 시스템과의 상호작용 방법을 정의하며 해당 인터페이스의 오퍼레이션으로 지정됩니다. 이러한 인터페이스는 관련 서비스의 콜렉션이므로 비즈니스 시스템이 특정 상호작용에서 수행할 수 있는
역할에 대해 설명합니다. 다음 단락 밑에 표시되는 예제에서는 각 인터페이스가 논리적으로 관련이 있는 서비스의 콜렉션입니다. 이 인터페이스(책임 클러스터)는 책임을 수행하는 비즈니스 시스템에 지정됩니다. 비즈니스
시스템 외부에서 제공된 서비스 중 하나를 요청하면 요청된 해당 서비스 이행을 시작하는 이벤트가 비즈니스 시스템에서 발생합니다. 이 이벤트는 비즈니스 시스템의 내부 이벤트이며 비즈니스 이벤트로서 명시적으로 정의될 수
있습니다. 비즈니스 시스템의 역할과 자원(비즈니스 작업자 및 비즈니스 엔티티)은 내부적으로 서로 협업하여 요청된 서비스를 이행합니다. 설명에서 알 수 있는 바와 같이 이는 고객에 대한 비즈니스 수행 방법과 동일한
방식입니다. 실제로 비즈니스 시스템을 "비즈니스"로 모델링할 수도 있으며 이러한 경우 서비스 요청자가 비즈니스 시스템의 비즈니스 액터가 됩니다.
아래 예제는 일반 재무 서비스 기관의 비즈니스 시스템을 보여줍니다. 이해를 돕기 위해 비즈니스 시스템과 인터페이스 간의 종속성 중 일부만 표시됩니다. 이 다이어그램과 같이 다른 비즈니스 시스템에 인터페이스를
할당하여 책임을 다시 지정할 수도 있습니다. 이렇게 책임을 다시 할당하는 경우 해당 서비스를 이용하는 비즈니스 시스템에는 개념적으로 아무런 영향을 주지 않습니다.
참고: 서비스에 대한 UML 모델링 안내
앞에서 설명한 대로 비즈니스 시스템을 집적 인스턴스화 가능한 컴포넌트로 모델링하는 경우 비즈니스 시스템 경계가 개념적인 기능만 수행하는 것은 아님을 나타냅니다. 다음은 소프트웨어 서비스를 위한 UML 2.0 프로파일의 유사 응용프로그램으로
비즈니스 시스템의 책임을 모델링하는 방법에 대해 설명합니다. 이 프로파일의 기본 아이디어는 소프트웨어 서비스에 지시되어 있지만 비즈니스 시스템에도 동일하게 적용됩니다. UML 2.0 포트를 사용하여 서비스를
세부적으로 모델링함으로써, 올바르게 정의된 인터페이스로 사용자와 비즈니스 시스템 간에 명확한 상호작용 지점을 정의하여 비즈니스 시스템 경계를 확인할 수 있습니다. 이러한 상호작용 지점은 비즈니스
시스템의 책임 구현을 비즈니스 시스템 외부 소비자에 대한 인도물과 완전히 분리합니다. 이 방법은 또한 비즈니스 프로세스 분석가와 비즈니스 디자이너에게 서비스
컴포지션 및 Choreography를 유연하게 모델링하여 비즈니스 시스템 경계에서 부가 가치 서비스를 전달할 수 있는 방법을 제공합니다.
비즈니스 시스템과 역할 및 자원의 관계
비즈니스 시스템은 해당 책임을 수행하기 위해 함께 작업하는 사람, 하드웨어 및 소프트웨어의 추상 콜렉션입니다. "추상"이라는 단어를 사용하는 이유는 사람, 시스템 및 소프트웨어의 관점이 아닌 역할 및 자원의
관점에서 비즈니스 시스템의 내부 협업을 설명하기 때문입니다. 비즈니스 시스템에는 비즈니스 작업자와 비즈니스 엔티티가 포함됩니다. 비즈니스 작업자는 용어집에 정의한 대로 시스템을 나타내는 역할입니다.
비즈니스 모델링 노력 관점에서 볼 때 이 시스템은 '리프' 시스템이므로 비즈니스 모델링 노력에서 더 이상 분해되지 않습니다. 비즈니스 모델링 학습에서는 다음 사항을 결정합니다.
-
한 명 이상의 사용자가 특정 비즈니스 작업자 역할에 바인드되어 이를 <<작업자>> 스테레오타입으로 지정할 수 있습니다.
-
소프트웨어(및 연관된 계산 하드웨어)가 역할을 수행하고 이를 <<IT 시스템>> 스테레오타입으로 지정할 수 있습니다.
-
보다 복잡한 시스템에서 역할을 수행해야 합니다. 이 시스템은 사람, 하드웨어 및 소프트웨어 자원을 사용하지만 몇 가지 이유로 인해 비즈니스 시스템으로 간주되지 않습니다. 예를 들어
아래 공항 예제의 경우, 비즈니스 시스템 '비행'에 승객을 수송하는 비즈니스 작업자인 항공기가 포함되도록 모델링할 수 있습니다. 항공기는 원래 복잡한 시스템이지만 이를 분해하는 경우 해당 동작 및 디자인
측면에서 비즈니스 사고와 전혀 다른 패러다임의 전환이 필요합니다. 따라서 이러한 컨텍스트에서 시스템을 추상 상태로 유지하면서 <<시스템>> 스트레오타입으로 지정할 수
있습니다. 그러나 로드 전달 기능, 범위 및 연료 소비 등 일부 특성은 지정해야 합니다.
비즈니스 엔티티는 비즈니스 작업자가 작성 또는 조작하는 정보입니다. 이러한 비즈니스 작업자는 결과적으로 인적 자원이나 특정 하드웨어 또는 소프트웨어 시스템으로 맵핑될 수 있습니다. 이러한 추상을 통해 비즈니스
작업자의 역할 및 인터페이스에 중점을 두고 필요한 책임을 결정할 수 있으며 이 때 특정 사용자 또는 시스템의 실제 상황(일반적으로 불완전 상태)을 고려하지 않아도 됩니다.
비즈니스 시스템이 소유하는 자원 중 일부는 가상 자원일 수 있습니다. 예를 들어, 특정 비즈니스 시스템이 다른 비즈니스 시스템과 대형 메인프레임을 공유할 수 있지만 비즈니스 시스템 측면에서 볼 때 이는 가상
시스템을 소유하는 것입니다. 가상 자원의 맵핑은 실제 자원을 소유하는 레벨에 표시되며 이는 일반적으로 엔터프라이즈 레벨(전체 비즈니스)입니다.
비즈니스
유스 케이스와 비즈니스 시스템의 관계
비즈니스 유스 케이스를 비즈니스 시스템에 단순히 할당해서는 안됩니다. 비즈니스 유스 케이스는 여러 비즈니스 시스템, 파트너 및 공급자의 협업이 필요한 고객 대면 프로세스이며 이를 가치
사슬이라고 합니다. 비즈니스 시스템은 아래 그림과 같이 협업을 통해 비즈니스 유스 케이스를 수행합니다.
한 가지 예외는 다른 추상 레벨에서 비즈니스 모델링을 작성하는 경우(개념: 대규모 조직 모델링 참조) 비즈니스 유스 케이스를 비즈니스 시스템에 할당할 수 있는 경우입니다. 예를 들어, 비즈니스를 완전체(whole) 및
해당 비즈니스의 비즈니스 시스템 중 하나로도 모델링할 수 있습니다. 이러한 경우, 전체 비즈니스에 대한 비즈니스 유스 케이스 모델이 존재하며 이 모델에서는 위와 같이 전체 비즈니스 유스 케이스가 비즈니스 시스템에
영향을 줍니다. 하위 레벨에서는 특정 비즈니스 시스템에서 요청한 서비스를 비즈니스 시스템의 비즈니스 유스 케이스 모델에 속하는 비즈니스 유스 케이스로서 캡처할 수 있습니다. 비즈니스 유스 케이스를 비즈니스 시스템에
할당해서는 안된다는 가이드라인은 실제로는 "특정 레벨의 비즈니스 유스 케이스 전체를 하위 레벨의 하나의 비즈니스 시스템에만 할당해서는 안됩니다"로 이해해야 합니다.
비즈니스 유스 케이스의 이러한 다기능적 특성은 비즈니스 모델링 및 리엔지니어링과 비즈니스 프로세스의 비용 및 성과 분석이 중요한 이유 중 하나입니다(개념: 활동 기준
원가 계산 참조). 전체 비즈니스 유스 케이스의 비용과 고객에게 제공되는 부가 가치와의 관계를 이해하는 것이 특성 부서의 연간 예산과 전체 기업 예산과의 관계를 이해하는 것보다 중요합니다.
예제
가구점
아래 그림은 가이드라인: 비즈니스 목적 및 가이드라인: 비즈니스 유스 케이스 모델에서 예제로 사용되는 가구점의 비즈니스 시스템을 보여줍니다. 이 상점은 쇼룸과 인접한 창고에 많은 재고를 보관하고
있습니다. 따라서 고객은 쇼룸에 전시된 제품을 보고 구입한 제품을 창고에서 직접 운반할 수 있습니다. 고객은 부피가 큰 제품의 경우 배달 방법을 조정할 수 있습니다.
이 비즈니스는 세 개의 독립 비즈니스 시스템으로 나누어집니다. 각 비즈니스 시스템에는 명확한 목적이 있으며 잘 정의된 서비스(다이어그램에는 표시되지 않음)를 제공합니다. 이러한 상호 종속성과 상호작용을 명확하게
정의함으로써 비즈니스를 최적화하는 데 도움이 됩니다.
공항
공항은 항공사와, 항공사를 대신하여 승객과 방문객에게 서비스를 제공합니다. 공항 비즈니스는 규모가 크고 복잡한 모델링 대상이므로 여러 개의 독립 비즈니스 시스템으로 나누는 것이 바람직합니다. 각 비즈니스 시스템은
아래에 표시된 대로 하나의 독립 비즈니스로 모델링될 수 있습니다.
위의 예제에서 항공사는 승객 및 비행 비즈니스 시스템에 참여해야 합니다. 항공기 교통량은 항공 관제사(Air Traffic Control)가 관련 법률 및 규정에 따라 통제합니다. 격납고 설비는 항공사 지상
승무원에게 서비스를 제공합니다. 승객 및 비행 시스템 모두 출발 및 도착 시 수화물 처리에서 제공하는 서비스를 사용합니다. 엔터테인먼트 비즈니스 시스템은 공항 설비라고도 하며 상점, 대기실, 주차장 및 교통 시설
등이 포함됩니다.
|