[The Power Of Event 요약] 2장 Managing the Electronic Enterprise in the Global Event Cloud

2장에서는 엔터프라이즈 시스템에서 어떻게 정보를 관리, 감독하고 있는지의 현황과 앞으로의 기술적 이슈들에 대해서 다루며 구체적으로 다음의 내용들을 설명한다.

  • Global Event Cloud
  • Global Event Cloud 속에서 엔터프라이즈의 운영
  • 작업플로우를 넘어 관리 프로세스
  • 자동화된 병렬, 비동기 프로세스
  • 엔터프라이즈 시스템
  • 엔터프라이즈 시스템을 사용자 측면에서 다루는 법
  • 엔터프라이즈 시스템을 관리하기 위한 기술적 요구사항

2.1 How the Global Event Cloud Forms

인터넷 기반의 정보처리 시스템은 계속해서 증대되며 거스를 수 없는 추세임을 설명한다.

2.1.1 The Open Enterprise

단일 엔터프라이즈 내부에서만 이벤트가 생성되어 소비되는 구조는 존재하지 않는다. 이전 장에서 설명한 계층을 통해 바라보면 Collaboration 계층에서의 기업 간의 경계가 모호해 지고 있다. 이러한 기업의 IT 시스템 구조의 상황을 개방형 엔터프라이즈라고 표현할 수 있다. 상호간의 협력적 관계를 통해 기업내부 뿐 아니라 외부와의 이벤트 흐름도 생성되는 것이다. 따라서 이러한 외부와의 이벤트 교류를 모니터링할 수 있는 정교한 보안 및 인증, 관리, 감독 기술이 필요하다.

2.1.2 The Global Event Cloud

개방형 엔터프라이즈와 함께 이제는 전 세계적으로 복잡하고 막대한 이벤트의 더미 속에서 엔터프라이즈 시스템이 운영된다. 네트워크에 연결된 수많은 엔터프라이즈 시스템이 생성하는 이벤트들의 총체를 Global Event Cloud라고 한다. Cloud라는 표현을 쓰는 이유는 네트워크 상의 이벤트들이 제대로 로 정돈되어 있거나 구조화 되어 있는 것이 아니기 때문이다. 또한 이벤트의 생성 시점이나 전송 순서에 따라 이벤트가 반드시 순차적으로 도착하는 것도 아니다. 조직화 되지 않은 이벤트 클라우드로부터 개방형 엔터프라이즈는 개별적으로 이벤트의 입력을 다룰 수 있어야 한다.

2.1.3 The Electronic Enterprise

영어 표현을 직역하면 전자 엔터프라이즈이지만 의미는 오늘날의 엔터프라이즈 시스템을 의미한다. 좀 더 구체적으로는 이벤트 기반의, 자동화된 정보 처리 시스템을 말한다. 책이 쓰여진 2002년과 달리 현재는 전세계적으로 네트워크로 통합되어가는 엔터프라이즈 시스템은 선택사항이 아닌 필수이다.

2.2 Operating in the Global Event Cloud

Example Workflow

이 그림은 어떻게 기업 내의 업무가 실제 엔터프라이즈 시스템으로 표현되는지를 보여주는 예이다. Process Order라는 하나의 선형 작업흐름은 4개의 단계를 가지고 있다. 이 작업흐름을 완료하기 위해서는 엔터프라이스 시스템의 경계를 넘어 많은 이벤트 들이 오고가야 한다.

 Event-Driven Business Process Figure

이 그림은 Process Order의 작업흐름을 엔터프라이즈 시스템 내에서 운영하기 위한 구현의 한 예시이다. 가운데 영역의 Event Cloud에는 네트워크 상의 존재하는 무수한 이벤트들이 포함되어 있다. 이 이벤트들 가운데 Process Order 작업과 연관이 있는 이벤트는 빨간색 배경을 가진 이벤트들이다. 엔터프라이즈에서 정의한 업무의 규약들은 Process Rule로 구현되어 있다.

각각의 이벤트가 발생하였을 때 좌측의 프로세싱 룰에서 수신된 이벤트의 정보에 따라 새로운 이벤트를 생성하여 다음 스텝으로 작업이 넘어갈 수 있도록 대처한다. 위의 과정은 기업 내의 활동의 흐름을 보여주는 전형적인 예이다. 엔터프라이즈 시스템의 내외를 이벤트들이 통과하면서 하나의 작업흐름이 수행된다. 물론 프로세스의 작업  단계나 이벤트 클라우드 혹은 프로세스 룰에서 예외상황이 나타날 수 있다. 이 떄 적절하게 어느 부분의 어떤 과정에서 문제가 발생하였는지 파악해야 한다.

이 모델에서 발견할 수 있는 핵심은 프로세스는 이벤트 기반이라는 점이다. 이벤트의 발생과 도착 유무에 따라 사전에 정의된 적절한 프로세스 룰이 실행되어 새로운 이벤트를 생성시켜 다음 절차로 넘긴다.

2.3 Going Beyond Workflow

이전 장의 예제에서 확인할 수 있는 사실은 이벤트의 도착 여부에 따라 다음 이벤트가 발생하는 동기화된 흐름을 갖고 있다는 점이다. 또한 작업 흐름 내부의 사람의 개입이 많이 필요하다는 점이다. 선형의 단순한 작업흐름의 구조는 현재의 엔터프라이즈 시스템의 요구사항을 만족시키기에는 부족하다.

모든 작업을 사람이 개입이 전혀 필요없게끔 하는 것은 사실상 불가능 하지만 가능한 사람의 개입을 줄이고 자동화 하는 것이 엔터프라이즈 시스템에서는 중요하다. 비용과 효율성의 측면에서도 작업의 흐름을 비동기적으로 전환하고 여러 업무를 병렬적으로 실행하는 것이 필요하다. 또한 프로세스에 대한 주도권을 관리자가 갖고 있어 언제든지 상황에 따라 프로세스를 수정하며 의사결정을 위해 사용자에 맞는 정보를 제공할 수 있어야 한다.

2.4 Parallel and Asynchronous Processes

이전 예제의 2단계인 SelectVendor를 좀 더 세분화된 하위작업들의 집합으로 확장할 수 있다. 이 하위 작업들은 비동기적이면서 병렬적으로 동시에 실행가능하다.

Asynchronous-Parallel Process Figure

그림에서 보는 바와 같이 Select Vendor라는 이전 그림의 2번째 절차가 다음과 같이 병렬적으로 비동기적으로 프로세스를 구성하면서 완전히 자동화를 이루었다. 유효한 주문의 발생과 동시에  프로세스 룰에 기초해서 비동기적으로 여러 RFQ 이벤트를 전송하고, 벤더사들로부터 입찰을 받을 때도 비동기적이면서 병렬로 입찰정보를 받는다.

이와 같은 작업은 이전의 선형작업흐름보다 좀 더 복잡한 이벤트 패턴 매칭이 요구된다. 하나의 하위작업에서 여러개의 이벤트를 동시에 확인하고, 또한 여러 이벤트를 동시에 병렬적으로 출력해야 한다. 더불어 현재 작업의 상황에 따라 동적으로 이벤트를 출력할 수 있어야 한다. 이러한 기능을 우리는 보통 Context Checking이라고 한다.

결론적으로 엔터프라이즈 시스템 내부에서는 하위작업들인 Process Rule로 인터페이스화 되고 모든 실행은 외부의 Event Cloud를 통해서 자동으로 비동기, 병렬 실행된다. 또한 이와 같은 작업을 위해서는 여러 이벤트를 복합적으로 모니터링하고 패턴매칭할 수 있는 기술적인 요구가 포함된다.

2.5 On-the-Fly Process Evolution

비즈니스 환경은 정적이지 않고 항상 변화한다. 따라서 우리가 설계하고 정의한 작업흐름대로 비즈니스가 진행된다고 생각해서는 안된다. 따라서 엔터프라이즈 시스템은 언제든지 상황에 따라 변화할 수 있는 구조를 갖추고 있어야 한다. 특별히 시스템의 중지 없이 프로세스를 변화할 수 있어야 한다. 이러한 과정을 On-the-Fly 프로세스라고 할 수 있다. 아래 그림과 같이 RFQ 발행과 관련된 기존의 프로세스 룰을 실시간으로 변경하여 시스템에 적용할 수 있어야 한다

On-the-Fly Process Figure

. 실시간으로 변경된 룰에 이벤트들이 기준을 충족시키지 못할 경우가 있다면 시스템은 어떻게 될까? 이런 경우를 대비해서 사용자는 늘 전체 프로세스의 진행상황과 이벤트의 유출입, 로그정보 등을 확인해야 하고 이를 위해서 시스템은 사용자의 관심사항에 맞게 개인화된 모니터링 정보를 제공할 수 있어야 한다.

결론적으로 실시간으로 프로세스 룰(요구사항)을 변경시키기 위해서는 다음과 같은 기술적인 요구들을 검토할 필요가 있다.

  • 시스템 내 모든 레벨의 활동 정보를 실시간으로 개인화된 정보제공창을 통해 보여주는 것
  • 시스템의 중지 없이(On-the-fly) 프로세스의 수정
  • 변경이력을 실제 시스템에 적용하기 전에 시뮬레이션

2.6 Exceptions Must Be First-Class Citizens in Process Design

제목에서 말하는 바와 같이 시스템 설계에 있어서 핵심은 예외사항을 반드시 먼저 고려해야 한다는 점이다. 따라서 프로세스의 설계 과정에 있어서 정상적인 프로세스 룰과 예외 룰을 동시에 설계해야 한다. 다음의 그림은 이를 보여준다.

Exception Rule Process Figure

그런데 예외룰을 설계에 고려한다는 것은 사실 어려움이 따른다.

  1. 실시간으로 우리가 상정하지 않은 상황에 대해서 항상 인식해야 하며
  2. 문제를 일으키는지 원인이 무엇인지 반드시 알아야 한다.