목표

모든 아키텍처의 궁극적인 목표는 정해진 비즈니스 목표와 목적을 달성하는 방법에 관한 방침을 기업에 제공하는 데 있다. 일단 민첩성에 대한 비즈니스 지향의 요구가 확인되면 우수 사례를 사용하고 특정 제품을 지정하여 비즈니스 요구사항을 달성할 수 있으며 아키텍트는 완전히 자동화된 인텔리전트 솔루션을 빌드할 수 있다. 정책과 규칙의 적용 및 관리와 관련된 다양한 변수는 비즈니스 서비스에 대한 민첩성을 개선할 수 있는 기회로 보이지만 이러한 기회를 활용하려면 비즈니스 정책과 비즈니스 규칙을 관리하는 데 필요한 자체 거버넌스 원칙이 최상의 자산으로 비즈니스에서 확립되어야 한다.

Part 1의 기본 목표는 정책과 규칙의 정의에 대해 문제점을 제기하여 정책과 규칙 간의 관계 및 비즈니스 분석가, 아키텍트, IT 직원 간의 관계를 평가하는 데 필요한 배경을 제공하는 데 있다. 먼저, 비즈니스 정책과 비즈니스 규칙 간의 관계를 간단히 설명하게 되면 정책과 규칙을 개별적으로 또는 조합하여 사용하는 방법을 평가하는 데 필요한 배경을 설정하여 비즈니스 전략과 전술 및 산업 규정을 구현하거나 시행하는 데 도움이 된다. 이렇게 하는 이유는 정의된 특정 비즈니스 목표와 목적이 비즈니스와 IT에서 달성되도록 아키텍트가 어떻게 도움을 줄 수 있는지를 보여주기 위한 것이다. 이러한 목표를 달성하기 위해 이 기사의 첫 번째 섹션에서는 용어에 대한 정의를 하고 용어의 사용과 그들 간의 관계에 대한 몇 가지 주장을 살펴본다. 이 부분은 비즈니스 정책과 규칙 간의 관계 및 본래 동적인 비즈니스 민첩성 목표를 표현하는 데 집중하고 있다는 점에서 더 추상적인 것처럼 보일 수 있다.

위로

개요

Part 1에 있는 용어 정의 부분은 나머지 자료 전체에서 사용할 수 있도록 일반적인 일련의 용어를 정하려고 작성하였다. 정책과 규칙의 의미에 대해 일반적으로 정의해놓으면 독자가 이러한 정의에 전적으로 동의하든 안 하든, 정책 유형과 규칙 유형 간의 관계와 각 유형을 사용하는 데 적합한 시점을 살펴볼 수 있다.

이 기사를 쓰게 된 계기 섹션에서는 용어 정의를 위한 산업 표준 컨텍스트(OMG BMM 참조)를 살펴본다. 이 부분에는 참고자료에서 인용한 내용과 이 기사를 작성하기 위해 해석된 내용이 포함되어 있다. 산업 활동은 적용 범위가 넓으며 이 기사에서는 이러한 산업 활동을 집중적으로 살펴본다.

추상화 레벨 섹션에는 이러한 주장을 일련의 기술적 문제에 적용하는 전략이 반영되어 있다. 비즈니스 로직의 아키텍처는 새로운 것이 아니며 민첩성을 구현하는 데 필요한 새로운 요구사항의 대부분은 이전에 시도하였지만 달성하지 못한 목표에 근거를 두고 있다. 소프트웨어 개발은 혁신적인 과정이다.

하향식 시작 - 비즈니스 계층 섹션은 독자가 민첩성의 핵심 요소는 요소 간의 관계에 있다는 것을 인식하는 데 도움을 준다. 민첩해진다는 것은 하나의 행위가 다른 행위에 영향을 주기를 원한다는 것을 의미한다. 지침이 없으면 민첩성 때문에 신뢰할 수 없는 결과가 초래될 수도 있다. 우수한 성능을 기반으로 비즈니스 민첩성을 달성하려면 하나의 공통 목표를 달성하도록 비즈니스와 아키텍처 및 운영 기능을 조정해야 한다. 비즈니스 분석가는 이러한 비즈니스 지침과 비즈니스 목표를 정의한다.

목표를 설정하는 것과 달성하는 것은 차이가 있다. 아키텍처 계층에서는 비즈니스 분석가와 아키텍트 간의 주요 관계가 강조되며 비즈니스 목표를 해석하고 민첩한 아키텍처를 정교하게 디자인하는 과제를 살펴본다.

Part 1은 또 다른 주요 관계와 운영 계층을 살펴보는 것으로 마무리된다. 비즈니스의 성공 여부는 분업에 달렸다. 비즈니스 지침은 아키텍트가 해석하고 운영 직원이 유지보수한다. 운영 중에 발생하는 이벤트가 비즈니스에 영향을 줄 수도 있기 때문에 민첩성을 구현하여 기업을 지원하려고 하는 경우에는 비즈니스 컨텍스트 내에서 개별 요소를 확인할 수 있어야 한다.

위로

용어 정의

이 기사에서는 다음과 같은 용어 정의를 사용한다.

• "정책"은 일반적으로 합의문 또는 지침으로 정의된다. 컴퓨터 시스템에서는 "정책이 특정 조건에 따라 여러 가지 대안에서 선택된 작동 지침"이라는 점은 명확하다.
  • 그렇다면, "비즈니스 정책"은 기업이 일련의 비즈니스 조건에서 일어나기를 원하는 행동 지침을 표현하는 일종의 비즈니스 지침이라고 생각할 수 있다.
• "규칙"은 권한과 제어를 시행하는 것이다.
  • 확대하여 해석하면, 비즈니스 규칙은 비즈니스 거버넌스 모델에 따라 비즈니스 제어를 직접 시행한다.

정책과 규칙 간의 관계를 보면 다양한 비즈니스 규칙 중의 하나가 비즈니스 정책의 구현으로 이어질 수 있다는 점을 알 수 있다. 비즈니스 지침은 비즈니스 정책과 규칙을 조합하여 구현한다. 특정 비즈니스 정책에 의해 제어되는 비즈니스 프로세스와 같은 솔루션으로 구성된 환경에서는 해당 정책을 통해 적절한 비즈니스 규칙을 가져와서 프로세스를 관리한다.

위로

이 기사를 쓰게 된 계기

모든 비즈니스에는 비즈니스 애플리케이션에서 구현할 수 있는 특정 비즈니스 전략과 비즈니스 전술, 비즈니스 목표가 있으며 이러한 비즈니스 애플리케이션에는 특정 시점에서 측정할 수 있는 주요 비즈니스 지표가 있다. 그러나 현재는 비즈니스를 다른 유사한 비즈니스와 병합하거나 회사를 결합하여 전 세계로 재배치하는 것이 일반적인 현상이며 이로 인해 문제점이 발생할 수 있다. 각 조직에는 자체적인 지표가 있을 수 있으며, 비즈니스가 새로운 시장으로 확대되어 가면서 변화하는 산업 규정이나 새로운 규정에 직면해 있을 수 있다. 따라서 현재의 비즈니스 목표를 충족시키는 것과 시간이 지나면서 비즈니스에 단기적 변화나 잘 계획된 장기적 변화를 주기 위해 적용할 수 있는 전략을 디자인하는 것이 새로운 비즈니스 과제가 된다.

이러한 사실은 비즈니스 서비스가 최적화된 비즈니스 성능은 물론이고 변화하는 전체 환경에 연속성을 제공하려는 것인 경우에는 많은 비즈니스 소프트웨어 개발자들이 견고함과 유연성을 동시에 제공하는 것을 목표로 하는 비즈니스 애플리케이션을 디자인해야 한다는 것을 의미한다. 모든 프로젝트의 첫 번째 단계에는 일련의 공통 비즈니스 요구사항을 파악하고 확립하는 과정이 포함되어 있다. 이러한 요구사항 중 일부는 비즈니스 정책 지침으로 표현되어야 한다. 또한, 시간이 지나면서 어떤 요구사항을 상대적으로 일정하게 유지할 수 있고 어떤 요구사항을 자주 변경해야 하는지 파악하는 것이 중요하며 이것은 디자인 단계에서 초기에 알 수 있다. 변화가 예상되는 위치를 초기에 확인하게 되면 프로젝트 디자인과 구현 과정을 개선하여 앞으로 일어날 변화를 줄일 수 있으며 결과적으로 개발 비용을 낮출 수 있다.

대부분의 통치체에는 일련의 정책이 있으며 이러한 정책에 따라 일일 단위로 통치체가 운영된다. 예를 들면, 민주주의에서는 사람들이 투표를 하여 일련의 법률을 확립하며 사람들은 이러한 법률이나 규칙의 범위 내에서 특정 민사 정책이 시행된다고 믿는다. 개별 민사 정책은 정당에 따라 변화될 수 있으며 또한, 개인에는 임기가 있고 정당에는 특정 방법으로 정책을 적용하도록 선택할 수 있는 권한이 주어지지만 비록 사법 제도에서 지원되는 것이긴 해도 시행 법률은 대부분 유지된다. 비즈니스 민첩성을 구현하려면 마찬가지로 관심사항과 일련의 제어 기능을 분리하여 시스템이 정해진 비즈니스 정책 내에서 예상대로 운영되고 있는지 확인하여 균형을 맞추어야 한다.

첫 번째, 일련의 주장

1. 비즈니스에서는 일련의 비즈니스 지침이 설정되며 비즈니스 거버넌스 수명 주기에 따라 비즈니스 자원이 관리된다. 이러한 비즈니스 환경에서는 우수한 거버넌스를 확립하는 과정에 일련의 정책과 규칙을 정의하여 민첩성을 구축하는 과정이 포함되어 있다.
2. 민첩성은 일부 비즈니스 요구사항을 정책으로 표현하여 구현되며 비즈니스 조건이 변화될 수 있는 경우에 확인할 수 있다. 그리고 다양한 비즈니스 조건을 반영하는 일련의 지침을 정의할 수 있다. 비즈니스 조건의 변화에 따라 이러한 비즈니스 정책을 확인하고 제어할 수 있으면 특정 비즈니스 규칙이 더 민첩해지도록 차례로 실행하여 정책 범위 내에서 이러한 변화에 적응할 수 있다.
3. 비즈니스 정책에는 변화에 대한 자체 수명 주기가 있어서 비즈니스 조건의 작은 변화에 대해 비즈니스의 기능을 모니터하여 그 결과를 기반으로 기존의 비즈니스 프로세스 안전지대 내에서 비즈니스의 작동 범위를 변화시키거나 수정할 수 있다. 기술의 사용과 관련된 조직의 성숙도에 따라 규칙을 평가하고 실행하여 비즈니스 운영 프로세스를 자동화(이른바 "IT")함으로써 비즈니스를 강력하게 제어할 수 있는 곳이 있다.
4. 조직 전체(즉, 비즈니스 애플리케이션 및 "IT 프로세스")에 보완적인 기술을 갖춤으로써 운영 프로세스에서 비즈니스 정책을 시행할 수 있으며 이를 통해 필수 작동이나 준수 작동을 시행하는 과정에서 비즈니스와 IT의 균형을 효과적으로 조정할 수 있다.
5. 비즈니스 규칙과 비즈니스 정책에 필요한 포괄적인 전략을 관리하는 과정에서는 비즈니스 조건의 변화에 따라 적절한 제어 수단을 통해 수정될 수 있는 유연한 비즈니스 자산(정책과 규칙에 의해 사용 가능하게 된)의 범위를 정의할 수 있어야 한다. 민첩성은 분리하여 제어할 필요가 있지만 비즈니스 정책에 필요한 조정된 거버넌스 수명주기 및 인프라가 잘 설계된 비즈니스는 비즈니스 연계 개선, 가치 창출 시간 감소, 변화량 및 변화를 일으키는 비용의 감소 그리고 비즈니스 사용자에게 제공되는 제어 수단 증가와 같은 많은 비즈니스 혜택을 제공한다.
6. 비즈니스 규칙과 비즈니스 정책을 인스턴스화하면서 회사는 규칙과 정책이라는 운영 자산을 비즈니스 자산을 관리하는 것처럼 효율적으로 관리하고 조정하기 위해 자체 운영 정책(즉, 액세스 제어 정책)과 운영 규칙(즉, 서비스 레벨 계약)을 표준화해야 하는 상황에 직면하게 된다.

또한, 정책과 규칙을 관리하는 데 필요한 운영 자산과 비즈니스에 일관된 접근 방식을 취함으로써 기업은 비즈니스 자산을 변경할 수 있으며 이러한 변경에 대한 운영상의 시행에 관해 다시 기업에 보고할 수 있다. 기술은 다양한 세부 레벨에서 작동하기 때문에 특정 비즈니스 제한조건과 목적을 지원하려면 IT나 비즈니스 면에서 다양한 기술을 사용해야 하지만 이렇게 하는 궁극적인 목적은 특정 프로젝트나 비즈니스 전략 및 전술에 필요한 비즈니스 요구사항을 지원하는 운영 자산에 대한 관리를 조정하는 데 있다.

위로

정책과 규칙의 추상화 레벨

수년간, 비즈니스 운영을 자동화하려고 하는 다양한 고객을 접하면서 비즈니스를 작동하게 하는 현실 세계에 대한 분석 결과를 반영하는 패턴이 나타났다. 모든 비즈니스에는 달성하고자 하는 목표와 목적이 있으며 이러한 목표와 목적을 달성하려면 비즈니스 자산을 어떻게 관리해야 하는지를 모든 비즈니스에서 정책으로 표현해야 한다. 감사 정책, 비즈니스 측정 수단(지표) 또는 KPI(Key Performance Indicator)로 데이터를 수집하는 것을 비롯하여 다양한 방식으로 비즈니스 목표와 목적에 대한 달성 정도를 측정할 수 있다. 사업가들은 사업가가 되기를 원하며 또한 그렇게 되어야 하지 컴퓨터광이 되어서는 안 되며 제어 매트릭스에는 또 다른 축이 있다는 것을 인정해야 한다. 이 기사에서는 제어가 일반적으로 3가지 레벨(비즈니스 계층, 아키텍처 계층 및 운영 계층)에서 파악되고 조절된다고 주장한다.

전체 비즈니스 아키텍처의 무결성을 책임지는 아키텍트의 역할에는 비즈니스 목표를 비즈니스 프로세스와 비즈니스 서비스를 인스턴스화하는 현재의 하드웨어와 소프트웨어 자산(아키텍처 계층)에 맵핑하거나 변환하는 역할이 포함되어 있다. 또한, 아키텍트는 IT 분야의 다양한 전문가 그룹과 긴밀하게 작업하여 관리 환경(운영 계층)에서 하드웨어와 소프트웨어 세트를 효과적으로 실행하기 위한 방법을 지정한다. 아키텍트는 보안, 액세스 제어 및 서비스 레벨 계약에서 비즈니스 워크플로우, 이벤트 처리와 정보 관리 및 비즈니스 규칙에 이르기까지 다양한 지침을 다루어야 한다.

이러한 3가지 추상화 레벨을 사용하면 모든 솔루션에는 다양한 관점에서 바라본 여러 가지 요구사항이 포함될 수 있다는 점을 인정함으로써 모든 당사자가 민첩성 문제에 대한 일반적인 논의를 솔루션에 대한 더욱 강력한 논의로 초점을 맞출 수 있다는 것을 고객과의 작업 과정에서 확인했다. 솔루션마다 도구를 지정하고 결과를 보고하는 메커니즘이 다를 수 있기 때문에 어떤 사안이 비즈니스 계층과 관련되어 있다는 것을 알게 되면(즉, 비즈니스 자산을 보호하려면 상위 레벨의 표현이 필요하면), 요구사항을 지정하고 해당 솔루션에 필요한 자원을 모의는 데 집중할 수 있다(즉, 높은 레벨에 있는 모든 자원을 2진 파일로 표현하는 대신 비즈니스 대시보드를 개발). 따라서, 민첩성 문제에 대한 비즈니스 목표와 목적을 언제나 기억해야 한다.

위로

하향식 시작 - 비즈니스 계층

비즈니스 지침 및 목표

조직에서 비즈니스 프로세스를 자동화하기로 결정하면 첫 번째 단계에서는 비즈니스 요구사항을 수집하여 일련의 비즈니스 지침을 설정한다. 비즈니스 지침에는 구현할 일련의 목표와 이러한 목표에 대한 결과를 측정하기 위한 비즈니스 지표 세트가 포함된다. 비즈니스 지침을 표현하기 위해 사용할 수 있는 방법론은 다양하지만 OMG에서는 몇 가지 모델과 기술을 정의하였으며 여기에서는 이러한 모델과 기술을 해석하고 적용함으로써 비즈니스 정책과 비즈니스 규칙을 관리하는 데 필요한 솔루션을 목표로 하는 경우에 비즈니스에서 일반적으로 필요로 하는 이러한 공통 요소 세트를 분석하였다. 전체 세부사항은 OMG Business Motivation Model 문서를 확인한다. (여기에서는 비즈니스 목표와 목적을 파악하고 표현하기 위한 일반적인 경로가 있음을 표시하는 수단으로 이 문서를 참조했으므로 http://www.omg.org/spec/BMM/1.0/을 참조한다.)

비즈니스 지침, 비즈니스 정책 및 비즈니스 규칙

개념적인 레벨에서 OMG "Business Motivation Model"(BMM)은 비즈니스가 어떻게 조직화되고 비즈니스에서 어떻게 의사결정을 하는지에 대한 광범위한 개념적 프레임워크를 배경으로 규칙과 정책 간의 관계를 탐색하기 위한 수단을 제공한다. 이 모델은 이러한 방식으로 일부 거버넌스 원칙을 반영한다.

• BMM 모델에서는 "비즈니스에 대한 열망(비즈니스의 비전), 비즈니스 활동 계획(비즈니스의 임무), 목표와 목적을 향한 비전의 개선, 목표를 달성하기 위한 전략의 확인 및 목표를 달성하기 위한 전술의 확인을 이해하려고 한다.

지침은 비즈니스 정책과 비즈니스 규칙을 일부 결합하여 구성할 수 있다. OMG 문서에는 이 두 가지가 비교되어 있으며 다음과 같이 요약할 수 있다.

• 비즈니스 정책
  • 비즈니스 제어에 따라 관리된다.
  • 비즈니스 정책에서 비즈니스 프로세스를 제어한다.
  • 비즈니스 정책은 의미가 모호할 수 있는 자연어로 표현된다.
  • 자연어는 의미가 모호하다는 점 때문에 비즈니스 정책을 직접 실행하는 경우는 거의 없으며 해석을 한 다음 실행한다.
• 비즈니스 규칙
  • 비즈니스 제어에 따라 관리된다.
  • 비즈니스 규칙을 통해 비즈니스 프로세스 조치가 실행된다.
  • 비즈니스 규칙은 의미가 모호하지 않으며 표준 비즈니스 어휘(SBVR)로 표현된다.
  • 비즈니스 규칙은 정의와 조치에 부합하는 특정 자산과 비즈니스 조치를 반영하며 특정 SBVR로 정의되기 때문에 직접 실행할 수 있다.

처음에는 모든 비즈니스 요소(규칙 및 정책)를 확인하기가 어렵다. 대부분의 정책과 규칙은 시간이 지나면서 변화하기 때문에 우수한 방법론에서는 프로젝트에서 정책과 규칙을 반복해서 구현할 가능성이 높다는 사실을 처리한다. 아래에 있는 그림은 이러한 방법론을 개략적으로 표현한 것이며 특정 질문에 답변함으로써 앞서 지정한 요소를 정교하게 조정한다. 또한, 이 그림을 통해 정의된 규칙과 정책이 성공 여부를 측정할 수 있는 지표와 연관되어 있다는 것을 확인하는 것이 중요하다는 사실을 알 수 있다.

이러한 작업을 처음 시작하는 모든 그룹에서 일부 작동을 비즈니스 규칙으로 표현하고 일부는 비즈니스 정책으로 표현하려고 시도하는 것은 당연하다. 어떻게 시작하든지 간에 자세한 세부사항이 알려지게 되면 개념을 재확인하여 정교하게 조정할 수 있다. 비즈니스 지침을 확인하는 과정에서는 비즈니스 분석가와 비즈니스 아키텍트가 사용할 자산과 소비할 자산을 확인하는 것이 중요하다. 질문할 내용에는 다음과 같은 것들이 포함될 수 있다. 비즈니스 분석가가 정책을 어떻게 모니터할 것으로 예상되나? 이러한 모니터링 기능을 제공하기 위해 비즈니스 아키텍트는 어떻게 계획되나? 비즈니스 분석가가 자체 비즈니스 규칙을 작성할 것으로 예상되나? 이러한 예상을 이해하게 되면 아키텍트는 비즈니스 정책이나 비즈니스 규칙 또는 이들의 조합을 최상으로 지원하는 접근 방식을 평가하고 선택할 수 있게 된다.

이러한 기술이 적용된 간단한 사례로 자금세탁방지법(AML)과 같은 일반적인 비즈니스 지침을 들 수 있다. 이러한 법률이 도입되었다면 재정 부문의 비즈니스에서는 이러한 법률이 이미 작용하고 있는 것이다. 비즈니스에는 선택할 자유가 없으며 이는 새로운 법률에 맞도록 전체 비즈니스 전략을 갱신해야 하며 대부분의 경우에는 새로운 비즈니스 프로세스와 비즈니스 정책, 비즈니스 규칙을 추가하여 AML 법률을 구현하고 시행해야 한다는 것을 의미한다. 여기에는 전체 비즈니스에 적용할 현재의 감사 절차를 재조명하거나 감사하기 위한 지표와 새로운 비즈니스 목적을 추가하는 과정이 포함된다. 자금세탁방지법(AML)과 관련된 일반적인 비즈니스 지침에서 "금융 기관은 AML에 영향을 받는 자금 지불을 용인해서는 안 되며 AML을 위반한 사람은 벌금을 지불하거나 형벌을 받을 가능성이 있다"와 같이 일반적인 지침을 정할 수 있다.

AML과 관련된 이러한 지침 사례에서 일련의 강력한 비즈니스 정책과 비즈니스 규칙을 분석하는 방법을 조사하기 위해 처음부터 비즈니스 지침을 비즈니스 정책이나 비즈니스 규칙으로 표현할 수 있다. 그러나 대부분은 비즈니스 정책 세트로 표현하는 것이 일반적이다.

이러한 지침을 지원하는 비즈니스 정책은 "에이전트와 직원은 할부금을 지불하기 위해 사용된 고객의 자금에 대한 출처를 언제나 알아야 한다". 또는, "은행은 10,000달러 이상의 자기앞 수표, 우편환, 은행 어음 및 여행자 수표를 통한 일상적인 지불을 용인하지 않는다"라고 보일 수 있다.

일반적인 신용 조사 과정에서 비즈니스 분석가가 취할 수 있는 일반적인 비즈니스 지침의 또 다른 사례로는 "당사는 신용이 좋지 않은 고객에게는 아무것도 팔지 않는다"와 같은 일반적인 문구(비즈니스 지침)를 들 수 있다.

각 LOB에서 이러한 문구를 해석하여 더 명확하게 하며 일반적인 신용 평가를 제공하는 공통된 서비스가 있으면 정책은 다음과 같이 세밀하게 조정될 수 있다.

비즈니스 정책: XYZ에서는 신용이 좋지 않은 것으로 평가된 계정을 갖고 있는 고객에게는 아무것도 팔지 않는다.

이러한 모든 활동에서 비즈니스 정책의 효율성은 이러한 정책의 정밀도에 달려있으며 가능한 어디에서건 비즈니스 정책은 비즈니스 어휘에 따라 요구사항을 표현해야 한다는 사실을 인식하는 것이 중요하다. (즉, 비즈니스 분석가는 이러한 특정 비즈니스에서 어떤 자산 서브세트를 제어해야 하는지 알고 있지만 언제나 모든 비즈니스 항목이 표시되는 것은 아니다.) 지침이 특정 비즈니스 자산과 관련되어 있는 경우에는 지표를 수집하고 비즈니스 정책을 시행할 수만 있기 때문에 해당 비즈니스 어휘에는 세분화된 비즈니스 제어가 반영된다. 비즈니스 정책에서 "신용이 좋지 않은" "고객"에게는 "팔지 않는다"와 같은 제한을 둘 수 있지만 신용이 좋은 고객과 그렇지 않은 고객의 요청을 비즈니스에서 구별할 수 없는 경우에는 비즈니스 정책은 아무런 쓸모가 없게 된다.

우수한 비즈니스 어휘가 존재하는 경우에는 비즈니스 분석가와 아키텍트가 비즈니스 프로세스에서 해당 의미가 해석되어야 하는 자연어(즉, "신용이 좋지 않은 고객에게는 팔지 않는다")로 비즈니스 정책을 표현하는 대신, 비즈니스 정책이 훨씬 더 명확하게 되도록 규칙 표현을 선택하고 사용하여 해당 지침을 얻을 수 있다. "좋지 않은 신용"이 "신용 보고서"에서 추정된 것과 동일하게 구현된다고 비즈니스 어휘에 표시되는 경우(이 보고서에서 "좋지 않은"이란 500 이하의 등급을 의미)에는 규칙에서 해당 정책, 즉 "좋지 않은 신용"의 의미를 표현할 수 있다는 점을 아래 그림에서 확인할 수 있다. 위에 있는 비즈니스 정책에서 파생되는 비즈니스 규칙은 다음과 같이 표현될 수 있다.

신용 보고서 중 하나에 500 이하의 등급이 있는 경우에는 대출자를 요주의 인물로 표시한다.
고객이 요주의 인물로 표시된 경우에는 해당 비즈니스를 거절하고 설명 메시지를 사용하여 해당 고객에게 경고한다.

다시 말해서, 비즈니스 정책을 해석할 수 있는 비즈니스 애플리케이션이 있으면 그것으로 충분하다. 비즈니스 정책 또는 비즈니스 규칙 중 어느 것을 사용할 것인가? 이는 민첩성과 비즈니스 기능의 목표로 알려진 비즈니스 가치를 기반으로 비즈니스상에서 결정해야 할 문제이다.

OMG 정의에서 가져온 "실행 가능한" 특정 지침을 기반으로 규칙과 정책을 차별화하면 현재의 정책과 규칙 개념 간에 존재하는 모호성이 어디에서 왜 존재하는지 비즈니스 레벨에서 확인할 수 있으며 또한, 비즈니스 지침을 얻는 것이 왜 중요한 활동인지 알 수 있다. 비즈니스 레벨에서는 두 가지 개념(정책과 규칙)이 동등한 것이며 대부분의 비즈니스 솔루션에서는 이러한 개념이 모두 필요하다는 주장을 인정하면 올바른 접근 방식을 선택할 수 있도록 도움을 주는 기존의 다양한 표준 비즈니스 어휘를 사용할 수 있다. 비즈니스 분석가로부터 일련의 비즈니스 지침을 얻었다고 가정하면 그다음에는 해당 지침을 반영하여 비즈니스 목표를 달성하는 솔루션을 설계하는 방법을 평가해야 한다.

위로

비즈니스 목표와 결과

또한, OMG "Business Motivation Model"(BMM)은 개념적인 레벨에서 비즈니스 지침과 관련된 비즈니스 결과를 수집하고 추적하는 구조를 제공한다. BMM에서는 비즈니스 지침을 구현할 위치를 알려주며 또한 여기에는 비즈니스 결과를 추적하기 위한 다양한 전략이 있을 수 있다.

비즈니스 정책이 비즈니스 지침을 전달하는 수단이라면 시행 결과를 일부 확인하는 것은 이러한 지침이 효과적이며 비즈니스 목표와 목적에 일치한다는 사실을 확인하기 위한 주요 수단이 된다. 정책 시행 엔진은 감사 추적을 기록하거나 이벤트 메커니즘을 구현하여 시행 결과를 해당 비즈니스에 알려준다. BRMS를 통해 비즈니스 규칙이 구현되면 감사 추적이나 이벤트 메커니즘을 통해 해당 규칙의 실행 결과가 비즈니스에 통보된다.

비즈니스 결과나 지표를 질적 또는 양적으로 정의할 수 있다.

• 비즈니스 목표는 비즈니스 지침이 예상대로 효력을 발휘하는 경우에 예상되는 비즈니스의 상태나 조건을 표현한 것으로 정의할 수 있다. 이러한 비즈니스 목표는 일반적으로 질적 방식으로 정의되며 이러한 변경을 일어나게 하는 확장 기간이 주어진다.
  • 비즈니스 목표 - 내년에는 모든 시스템에서 새로운 AML 프로세스를 사용하도록 변경한다.
  • 비즈니스 목표 - 개인적으로 확인할 수 있는 정보가 보호되는지 확인한다.
• 비즈니스 목적은 비즈니스 지침을 달성하기 위해 특정 체크포인트에서 성능을 자세히 측정하는 것으로 정의된다. 이러한 목표는 보통은 정성적이며 달성해야 하는 소요기간이 매우 명확하다. 이러한 목표는 KPI(Key Performance Indicators)나 CSF(Critical Success Factors)로 정의할 수 있다.
  • 비즈니스 목적 - 새로운 AML 프로세스를 사용하는 첫 번째 달에는 AML 검사가 10,000번 수행될 것으로 예상된다. 월별로 수행된 AML 검사와 조사할 문제점의 몇 퍼센트가 확인되었는지 측정하기 위해 특정 KPI를 정의할 수 있다.
  • PCI 준수를 시행하는 과정에서는 실패한 로그인 시도를 추적하고 정상적인 값이 무엇인지 그리고 공격을 받고 있는 시스템을 구성하고 있는 것이 무엇인지 확인하여 선관주의 의무가 지켜지고 있는지 확인한다.

위로

아키텍처 계층

아키텍처 계층에서는 아키텍처가 설계를 "어떻게" 할 것인지에 집중한다. 수집된 지침이 실행 가능한 요소로서 규칙으로 구현될 수 있는지 그리고 수집된 지침이 어디에서 아키텍처 정책으로 표현될 수 있는지를 결정하려면 기존의 아키텍처 제어 기능을 이해해야 한다.

위에 있는 사례를 시발점으로 하여 아키텍트는 비즈니스 지침(즉, AML을 처리하는)을 "금전 출납원"에게 적용해야 하는지 평가할 수 있다. 은행에서는 "금전 출납원"이라고 하는 비즈니스 역할이 있으며 이 직원이 해당 역할을 수행한다는 사실이 지침에 내포되어 있다. 비즈니스 프로세스에 민첩성을 제공한다는 것은 아키텍처 안에 어떤 휴먼 태스크가 있고 어떤 태스크가 자동화되어 있는지 알고 있다는 것을 의미한다. 아키텍처의 일부로서 "금전 출납원"의 태스크를 정의할 수 있지만 새로운 지침을 사용하여 이 역할을 변경해야 할 수도 있다. 예를 들면, 이러한 태스크는 휴먼 태스크에서 자동화된 워크플로우로 변경될 수 있다. 아키텍처 레벨에서는 각 지시사항을 조사하여 다양한 기준을 근거로 지침을 정책으로 표현할지 여부와 지침을 시행할 수 있는 정책으로 표현하는 방법을 결정하는 것이 중요하다. 비즈니스 관점에서 누가 "금전 출납원"인지 확인하려면 새로 관련된 비즈니스 정책(비즈니스에서 누가 금전 출납원인지 확인하는 방법에 관한)이 필요할 뿐만 아니라 이러한 비즈니스 역할에 대한 정의가 사용자 프로비저닝의 운영 요소에 포함되어 있어야 하며 여기서 사용자 관리 컴포넌트가 해당 운영 액세스 제어 정책(즉, 금전 출납원은 금융 거래에 액세스할 수 있는 권한이 있음)을 설정한다는 점을 아키텍트는 알 수 있다. 금전 출납원 정책과 같은 운영상의 보안 정책을 설정하는 것이 유일한 것은 아니며 직원이 모든 비즈니스 자산(비즈니스 정책)에서 호스트되는 모든 유형의 데이터를 액세스하는 경우, 다양한 방식으로 이 직원을 확인하려면 비즈니스 내에 다양한 제어 모델이 필요하다.

좋은 결과를 얻기 위해서는 다양한 비즈니스 지침이 중요하며 솔루션을 완전히 구현하려면 아키텍트는 지침을 다듬을 수 있도록 비즈니스에 도움을 주어 비즈니스 프로세스의 전체 서브 도메인과 운영 프로세스의 서브 도메인(즉, 액세스 제어, 사용자 확인, 암호 관리)에 규칙과 정책의 조합에 대한 아키텍처상의 지원이 있다는 것을 보장해야 한다.

신용 점수를 제공할 수 있는 새로운 공통 아키텍처 서비스를 정의하여 아키텍처 레벨에서 다양한 대출 심사 지침을 지원할 수도 있다. 공통 실행 요소를 수집하고 재사용하는 과정을 지원하려면 BRMS 기술을 필수적으로 사용해야 한다. 세분화된 비즈니스 어휘에 따라 비즈니스 규칙에서 특정 계산을 할 수도 있으며 또는 대부를 승인하거나 거절하는 조건을 표현하거나 대부 약관을 정의할 수 있다. 아키텍처는 비즈니스 목표와 목적을 더 강화하기 때문에 이러한 특징은 아키텍처의 태스크 중 하나가 된다. 중요한 점은 이러한 아키텍처적인 선택을 하고 나서는 비즈니스 지침과 비즈니스 정책을 다시 확인해야 한다는 점이다. 아키텍트는 어떤 지표를 수집할 수 있는지 그리고 어디에 이러한 지표를 관련시킬 수 있는지 정의하여 런타임 시 운영 요소가 비즈니스 소비자에게 필요한 해당 비즈니스 데이터를 만들어 낸다는 것을 보장해야 한다.

비즈니스 프로세스를 자동화하고 최적화하기 위한 디지털 자산이나 자원의 사용과 관련하여 조직의 성숙도는 특정 비즈니스 정책이 전달되거나 시행될 수 있는 범위에 언제나 영향을 미친다. 또한, 서비스가 완전히 자동화되더라도 비즈니스 정책의 시행과 관련된 비즈니스 대상이나 행위자를 파악해야 한다. 어떤 경우에는 "비즈니스 정책"이 웹 페이지의 개인정보 면책사항과 같은 것이 될 필요가 있다. 비즈니스 정책 시행을 구현할 경우에는 기술을 선택해야 하며 동의가 필요한 비즈니스 지침은 조치로 인코드되어야 한다. (즉, 출장 신청자에게 출장 정책을 준수할 것인지 질문한다.) 또한, 조직 전체에서 보안 정책을 최적화하고 일관성을 유지하기 위해서는 미들웨어에서 보안 정책을 자동으로 시행해야 하며 이렇게 하면 일반 사용자는 시행 방법을 볼 수 없으며 필요하지도 않다. (즉, 규칙을 사용하여 모든 전송 메시지를 암호화하기 위한 보안 정책을 시행할 수 있으며 일반 사용자는 암호화를 초기화할 필요가 없다.)

옵션이 다양하다는 점은 정책과 규칙을 민첩성에 필요한 생태계의 일부로 보아야 하는 이유가 되며 이러한 생태계에서는 지침을 수집하고 추적 가능한 비즈니스 정책 시행을 제공하는 것이 매우 중요하게 요구된다. 워크플로우에서 휴먼 태스크를 조정하거나(즉, 프로세스를 정의하고 실행하기 위한 BPEL), BPM 제품에서 비즈니스 프로세스를 자동화하거나 규칙 엔진과 정책 관리를 사용하면 비즈니스 정책 시행 전략이 향상된다. 일련의 비즈니스 지침이 수집되고 민첩성을 구현하기 위한 비즈니스 요구사항이 파악되면 구현에 필요한 선택 사항을 수집하는 과정은 아키텍처 레벨에서 담당한다. 모든 경우에 다 적용되는 정답은 없으며 비즈니스 분석가와 IT 직원이 비즈니스 가치와 비용을 기반으로 집단적 의사 결정을 내려야 한다.

이러한 원칙의 실례로서 앞서 살펴본 비즈니스 지침을 생각해 볼 수 있지만, 지금은 아키텍처 계층의 관점에서 살펴보도록 하자.

자금세탁방지법(AML)과 관련된 지침에 대한 사례에서는 금융 기관은 AML에 영향을 받는 자금 지불을 용인해서는 안 되며 AML을 위반한 사람은 벌금을 지불하거나
형벌을 받을 가능성이 있다라고 말할 수 있다.

비즈니스 지침은 기업이 스스로를 보호하기 위한 것이며 따라서 기업은 비즈니스 애플리케이션을 실행하면서 부적당한 행위로 인해 고발을 받지 않게 된다. "금융 기관은 형사적 벌금을 낼 수 있는 지불 요청을 승인해서는 안 된다"와 같은 비즈니스 지침을 완수하는 데 필요한 상위 레벨 비즈니스 요구사항은 다양한 방법으로 명시될 수 있다.

과거에는 "금융 기관"의 "휴먼" 인스턴스화가 일반적이었다. 즉, 금융 기관의 직원 교육 과정에 써드파티에 지불을 하거나 지불을 승인하는 것과 관련하여 적절한 비즈니스 행위가 무엇인지에 대해 각 비즈니스 라인에 일련의 경고를 전달하는 과정이 포함되었다. 오늘날의 비즈니스에서도 직원 교육은 여전히 최고로 중요한 위치에 있다. 세 대륙에 은행원이 있는 경우, 이러한 정책을 수동으로 시행하려고 하는 것은 실용적이지 못하다. 예를 들어, 은행원이 일부 거래만 지원하도록 역할을 분할했거나 다른 은행 직원(계정 거래를 검토하는 감독관)이 계정을 볼 수 있다고 하더라도 환거래(즉, 전신환 거래 및 기타 은행간 거래)를 평가하는 자동화된 시스템을 통해 해당 지침이 준수되어야 한다.

금융 기관에서 이러한 목표를 달성하기 위한 더 효과적인 방법은 "최신 기술에 정통한" 아키텍트로 하여금 이러한 비즈니스 요구사항을 파악하게 하여 직원의 행동을 안내하고 제어하기 위한 자동화된 비즈니스 및 기술 서비스를 설계하는 것이다. 아키텍처 레벨에서는 레코드와 거래를 자동으로 분석하여 위험한 모든 범죄형 금융 거래를 평가하고 플래그를 지정하기 위한 규칙을 정한다. 새로운 아키텍처에는 비즈니스 관리 워크플로우에 포함되어 동적으로 "위험"으로 표시되는 특정 거래에서 트리거되는 새로운 관리 승인 조치가 포함된다.

아키텍트의 태스크는 매우 힘들다. 솔루션 아키텍트에게 도움을 줄 수 있는 아키텍터 구성은 어떤 것일까?

아키텍트는 비즈니스 규칙 생태계에서 정의한 분류와 하위분류를 활용하여 비즈니스 지침 세밀화 프로세스를 시작할 수 있다. 구조적 유형과 작동 또는 운영 유형, 이 두 가지 하위 유형이 일반적으로 사용된다.

여기서는 구조적 규칙 유형을 먼저 살펴보는데, 그 이유는 이러한 규칙이 비즈니스 데이터 도메인에 있는 특정 항목을 반영하기 때문이며 이러한 규칙은 비즈니스 범위를 개략적으로 반영한다. 구조적 규칙에 대한 사례로 "새 계정을 열기 위해서는 고객이 국내에 있어야 한다" 또는 "각 임대는 정확히 하나의 요청된 자동차 그룹을 갖고 있어야 한다" 또는 "하나의 은행 계정은 한 명의 고객에게만 부속된다"는 규칙을 들 수 있다. 이러한 구조적 규칙 유형은 비즈니스 프로세스나 비즈니스 모델에서 표현되는 비즈니스 자산이나 비즈니스 산물을 창출하는 데 영향을 준다.

일단 구조적 자산이 있으면, 일반적으로 작동 비즈니스 규칙 유형에 시행할 수 있는 몇 가지 조치가 반영되며 이러한 조치는 특정하게 구현된 비즈니스 프로세스나 비즈니스 모델의 특성과 관련된다. 당연한 얘기지만 여기에도 선택할 수 있는 사항이 있다. 작동 규칙(운영 규칙)은 세분화된 프로세스 구현에 따라 다양한 구현 패턴을 지원하도록 더 분석될 수 있다. 아래 그림에서는 다양한 고객과의 구현 경험을 기반으로 작동 규칙에 대한 몇 가지 사례를 확인한다.

모든 규칙 분석 작업에서는 패턴을 찾는 것이 중요하다. 이러한 패턴은 작동 비즈니스 규칙의 두 가지 공통된 특성으로 제한조건을 표현하는 패턴 또는 지침을 표현하는 패턴을 말한다.

제한조건은 필수적인 것과 수행되어야 하는 것을 말한다. 제한조건은 "있어야 한다"와 같은 단어를 명시적으로 사용할 수 있으며 또는 "필요하다"(일반적으로 "시행"될 필요를 의미함)와 같이 좀 더 묵시적일 수 있다.

지침은 바람직하지 않은 상황을 경고하며 때로는 경고 메시지로 변환된다.

프로세스 플로우 이 하위 유형은 일반적으로 해당 플로우의 매개변수나 메타데이터를 표현하는 데 사용한 하위 유형을 말한다. 라우팅 규칙은 비즈니스 프로세스에서 활동의 단계와 순서에 대한 실행을 어떻게 지시할 수 있는지 보여주는 사례가 된다. 어떤 환경에서는 프로세스 플로우를 지시하는 매개변수 값을 결정하는 비즈니스 로직 규칙과 프로세스 플로우 규칙을 구분하는 것이 유용하다.

의사결정은 수학 방정식을 기반으로 기존 데이터에서 새로운 정보가 작성되는 하위 유형이다.

ECA(Event Condition Action)는 규칙의 특정 패턴을 의미하며 이벤트가 발생하면 여기에서 해당 조건이 평가된다. 대부분의 ECA 규칙에서는 시간 연산자를 사용하여 작성이나 발생 시간 소인과 관련된 이벤트를 검색한다. "특정 기호 이름으로 된 이벤트를 마지막 x 초 내에 걸러내고 계산된 값(가격 * 볼륨 메트릭)을 수집한다"와 같은 규칙 문에는 특수한 규칙 표현이 필요하며 규칙 엔진은 런타임 시 이러한 표현을 실행되도록 하기 위해 이동 시간 창 연결지향(Statefull) 메커니즘을 필요로 한다. 분석 단계에서 시간 조건의 의미를 파악하는 것이 규칙 분석가가 수행해야 할 매우 중요한 태스크가 된다.

조치 동인은 시스템에서 다른 조치를 초기화하는 하위 유형이다. 이러한 사례로는 서비스를 비동기적으로 호출하는 비즈니스 프로세스를 트리거하는 규칙을 실행하는 것을 들 수 있다. 이러한 유형은 에스컬레이션, 감사, 평가 프로세스와 같은 비즈니스 프로세스를 트리거하는 규칙에 초점이 맞추어진 비즈니스 사용자 관점을 표현한다.

추론은 고급 민첩성 방법론을 반영하는 하위 유형이다. 작동 규칙의 내용이 규칙을 분석하는 평가 과정에 영향을 준다고 가정한다. 추론을 통해 데이터 요소를 생성하거나 갱신하며 조건이 변경되면 해당 규칙이 다시 평가될 수 있다.

ECA 규칙에서 살펴본 바와 같이 시간 연산자는 규칙의 다른 하위 유형 내에서 조건에 적용할 수 있는 더욱 일반적인 개념이라는 점을 아는 것이 중요하다. 시간 제한조건을 지원하는 규칙 유형은 없다. 예를 들어, 프로세스 플로우에서는 준비가 되면 프로세스 내에서 특정 태스크를 실행하라고 타이머 조건을 정의할 수 있다. 조건문은 다음과 같다. "주유소에서 카드 트랜잭션이 실행된 뒤 2시간 안에 같은 주유소에서 동일한 카드로 실행된 카드 트랜잭션은 사기이다". 이 조건은 사기가 일어나는 것으로 추론 규칙에서 적용하거나 트랜잭션 이벤트가 스트림의 일부인 경우에는 스트림을 처리하는 문장에서 적용할 수 있다.

이러한 절차의 대부분은 단지 아키텍처 디자인과 관련된 좋은 사례일뿐이다. 정책 및 규칙과 관련된 부분은 제어가 정적일 수 있는지, 시간이 지나면서 특성이 일부 변경되는지 또는 기타 비즈니스 변수가 있는지를 결정하는 데 있다. 예를 들면, 은행 업무에서 다양성이 중요한 부분은 지리적인 부분이다. 은행 업무에 대한 국제적 규칙 외에도 다양한 규칙과 정책이 다양한 국가에서 적용된다.

위로

운영 계층

그림 3은 비즈니스 계층과 아키텍처 계층 간에는 물론이고 아키텍처 계층과 운영 계층 간에도 수명 주기가 있다는 것을 보여준다. 운영 범위에 대한 비즈니스 지침을 개선하기 위해서는 때로는 또 다른 반복이 필요하다는 사실을 모든 당사자가 인식해야 한다. 또한, IT는 비즈니스 기능이며 운영 환경에는 표현된 자체 비즈니스 정책 제한조건이 있으며 아키텍처는 이러한 제한조건 내에서 변경되어야 한다고 주장하는 바이다. 위의 사례에서 수집된 정해진 비즈니스 지침은 LOB(Line of Business)나 집계 LOB 관점을 반영하는 것으로 보일 수 있다. CSO(Chief Security Officer)나 CIO(Chief Information Officer)가 표현하고 제어해야 하는 다른 비즈니스 지침이 있다.

예를 들면, 솔루션을 정의하는 아키텍트가 운영 정책 관리를 통해 제공되는 제어 범위에 맞는 솔루션을 디자인하려면 런타임 및 세분화나 운영 정책 결정 포인트(PDP) 또는 정책 시행 포인트(PEP)의 존재를 인식해야 한다. 아키텍트가 PAP(Policy Authoring Point)를 통해 표현한 비즈니스 정책이 현재의 운영 환경에서 시행될 수 없는 경우, 아키텍트는 IT 부서와 협력하여 이러한 새로운 지침이 운영되게 해야 한다. 때로는 일관성을 유지하고 최적화하기 위해 조직에서 크로스 LOB 정책을 운영되게 할 위치와 방법을 선택할 권한을 IT 부서에 위임한다. 일반적으로 메시지 보안 정책을 사례로 들 수 있으며 이러한 정책은 운영 인프라에 있는 특정 위치(즉, DMZ)에서 일관되게 시행되어야 한다. 때로는 운영 정책 제한조건이 정책을 시행하는 어플라이언스 유형이나 전체 네트워크 보호 지침에 영향을 받는다.

이러한 목표를 충족시키기 위해 사용되는 기술은 규칙을 사용하는 것과 같은 다양한 방식으로 달성될 수 있다고 하더라도 본래 비즈니스 정책으로 표현된 비즈니스 지침이 DMZ에서 특정 정책을 시행함으로써 시행될 것이라는 점을 IT 부서에 위임된 비즈니스 지침에서 보장할 것으로 예상할 수 있다. 따라서, 정책과 규칙을 세밀화하는 프로세스에는 기업에 운영 지표와 비즈니스 지표의 상호관계를 제공하기 위해 운영 중에 측정된 값을 "라운드 트리핑"하는 과정이 포함되어 있다는 점을 그림 3에서 알 수 있다. IT 부서에서는 규칙 기술과 LOB 애플리케이션을 사용할 수 있으며 아키텍처 및 재사용과 관련된 우수 사례가 자리를 잡게 되면 아키텍트는 이러한 두 가지 요구사항을 제공하는 공통 구조를 확립할 수 있다.

전통적으로 "운영상의 보안" 즉, 액세스 제어로 볼 수 있는 것과 관련된 비즈니스 지침과 각 추상화 레벨을 살펴보면 전체 수명 주기에서 시행되는 정책과 규칙을 세밀화하는 과정이 중요하다는 사실을 보여주는 사례를 확인할 수 있다. 상위 개념에서 보면 모든 비즈니스에는 누가 무엇을 액세스할 수 있는지를 제어하기 위한 정책이 필요하지만 직원이 10명 이상인데도 액세스할 수 있는 레코드와 개별 직원을 세분화하여 정책을 수립하려고 하는 CEO는 없다. 대부분의 LOB에는 자체적으로 보유하고 있는 자원에 대한 액세스 "정책"이 있다. 액세스 제어에 대한 관리를 최적화하기 위해 IT 조직에서 정책 시행 지점이나 일련의 시행 지점을 정할 수도 있다. 크로스 LOB 운영 정책 시행 메커니즘을 확립할 경우에는 IT 인프라를 담당하는 아키텍트가 규칙 엔진을 정책 시행 전략 내에서 사용하도록 권고하여 하나의 LOB나 전체 LOB(즉, 서비스 연합) 내에서 특정 트랜잭션에 어떤 정책을 적용할 것인지를 결정할 수도 있다. 운영 중인 런타임 환경에서 정책 "의사결정"을 구현하고 시행하기 위해 규칙 엔진을 사용하는 경우도 있다.

보안 정책을 관리하는 데 필요한 운영 정책 시행 아키텍처 양식이 아래 그림에 표시되어 있다.

두 번째 사례에서는 다수의 프로세스나 애플리케이션 전체에서 비즈니스 애플리케이션 의사결정을 재사용하거나 공유하고 관리할 수 있는 공유 아키텍처 정책 결정 위치에 대한 비즈니스 요구가 있다고 아키텍트가 결정할 수 있다. 운영 레벨에서는 이러한 정책 의사 결정 지점에 다양한 비즈니스 규칙이 포함될 수 있으며 이러한 비즈니스 규칙은 해당 비즈니스 지침을 충족시키는 데 필요한 의사결정을 구현하기 위해 작성되고 결합된다.

BMM 원칙에 대한 해석을 확장하려면 위에 있는 BMM에 따라 비즈니스 지침을 파악하는 과정에 일반적으로 아키텍처 관점에서 전략과 전술을 파악하는 것뿐만 아니라 위협과 기회를 파악하는 과정도 삽입해야 한다.

아키텍처 전략에 대한 다양한 정의를 기반으로 각 아키텍처 양식에서 정책과 규칙을 세밀하게 조정하여 비즈니스 정책, 위협 및 기회, 전략 및 전술과 같은 영역에 적용할 수 있다. 여기에는 다양한 변수가 있다는 것을 알면 특정 행동 지침을 정의하는 것을 안내하기 위한 방법론을 설정하기 위해 기업과 아키텍트, 운영 직원 간에 일어나야 하는 잘 통제된 교환(때로는 거버넌스라고 함)의 가치를 확인할 수 있다. 비즈니스 개념 모델에서 아키텍처와 운영에 대한 더욱 확고한 정의로 이동하는 방법을 비롯한 특정 비즈니스 문제에 책임성을 부여하려면 우수한 거버넌스 사례가 필요하다.

이러한 책임을 지는 아키텍트를 대상으로 하는 이유는 평가는 다양한 아키텍처 양식(즉, SOA)의 컨텍스트에서 수행될 필요가 있으며 우수 사례를 고려하여 규칙을 구현하고(즉, 서비스 디자인, 서비스 선택 및 서비스 조정 과정에서) 정책 시행 메커니즘을 적용해야 하기 때문이다. 또한, 아키텍처 양식에는 BPM(Business Process Management) 제품을 활용하여 "누가 관련되어 있나?", "그들이 언제 관련되어야 하나?", "그들이 무엇을 해야 하나?"와 같은 중요한 정보를 확인함으로써 비즈니스 프로세스의 효율성 문제를 처리하는 것과 같은 자체 우수 사례가 있다. 또한, BPM 제품은 인간 행위자와 자동화된 행위자를 지원할 수 있다. 언뜻 보면 BPM에서 구현하려는 비즈니스 로직은 태스크 내에서 처리하기 위한 데이터 및 직원, 태스크와 관련되어 있다. 어떤 직원이 어떤 태스크를 수행할 수 있는지 결정할 때 대부분의 조직에서는 기능적 역할로 사람을 그룹화한다. 따라서 아키텍트는 역할 정의를 맡고 있는 비즈니스 소유자와 사용자 프로비저닝 태스크를 맡고 있는 운영 소유자와 함께 작업해야 한다. 때로는 직원이 태스크를 수행하는 기준이 그들에게 지정된 역할과 관련되며 대부분의 조직에서는 휴가 시 개인에게 역할을 임시로 지정하는 것과 같이 이러한 것을 비즈니스 정책으로 표현하거나 한 직원이 다른 직원에게 수행할 태스크를 위임할 수 있도록 한다. BPM 태스크에 "왜 특정 방식으로 작동할까?", "왜 그러한 의사결정이 내려졌을까?"와 같은 '질문(왜)'을 추가하면 BRMS(Business Rules Management System)가 BPM을 보완할 수 있다. 아키텍트는 일련의 비즈니스 프로세스에서 간단한 전개 패턴이나 추론, 패턴 일치를 활용하기 위한 구조화된 양식에서 비즈니스 민첩성 요인을 정의하기 위해 사전 정의된 구조(즉, If then else문 이나 의사결정 테이블, 규칙 플로우, 의사결정 트리, 함수, 규칙 템플리트)를 사용함으로써 규칙의 변이성을 지원할 수 있는 BRMS를 비즈니스 분석가가 사용하도록 권고할 수 있다.

위로

결론

비즈니스 목표를 달성하고 모니터하기 위한 비즈니스 전략과 전술을 정책과 규칙을 사용하여 시행하면 비용 절감 면에서 다양한 비즈니스 개선 효과를 얻을 수 있으며 또한, 장기적인 변화뿐만 아니라 단기적 변화를 충족시킬 수 있는 능력을 개선할 수 있다. 동일한 예산으로 더 많은 일을 하는 것 그리고 더 많은 일을 하려는 비즈니스 사용자에게 더 많은 권한을 주는 것은 IT와 비즈니스를 조화롭게 하기 위한 매우 긍정적인 작업이다.

핵심 요점

• 비즈니스와 아키텍처, 운영 정책은 모두 중요하며 특히 대규모 솔루션에서 조화롭게 작업하기 위해서는 모두가 필요하다.
• 비즈니스 정책과 규칙은 대등한 엔티티이며 비즈니스 정책 지침에서 파생될 수 있으며 비즈니스 정책 지침을 구현하기 위해 함께 사용될 수 있다.
• 비즈니스 지침을 대상으로 성능을 측정하기 위해 비즈니스 팀에서 비즈니스 목표와 더욱 세부적인 비즈니스 목적을 사용하여 예상 비즈니스 결과를 정의할 수 있다.
• 하향식 접근 방식을 취하는 프로젝트에서는 정책 지침을 세부적인 정책과 규칙으로 분석한다. 이렇게 하면 조화롭게 작동해야 하는 다수의 다양한 운영 체제에서 세부적인 정책과 규칙을 어떻게 상위 레벨 비즈니스 지침 및 목표와 일치 시킬 것인지에 대한 추적성을 개선할 수 있는 혜택을 얻을 수 있다.

참고자료

교육

• 비즈니스 목적은 비즈니스 지침을 달성하기 위해 특정 체크포인트에서 성능을 세부적으로 측정하는 것으로 정의할 수 있다.
  
  
• 비즈니스 목표는 비즈니스 지침이 예상대로 효력을 발휘하는 경우에 예상되는 비즈니스의 상태나 조건을 표현하는 것으로 정의할 수 있다.
  
  
• 비즈니스 지침에 관해 자세히 배워보자.
  
  
• developerWorks의 SOA 및 웹 영역에서 기술을 향상시키는 데 필요한 참고자료를 얻을 수 있다.
  
  
• 기술 서점에서 다양한 기술 주제와 관련된 서적을 살펴보자.
  
  

제품 및 기술 얻기

• IBM 제품 평가판을 다운로드하거나 IBM SOA Sandbox의 온라인 시험판을 살펴보고 DB2®, Lotus®, Rational®, Tivoli® 및 WebSphere®의 애플리케이션 개발 도구 및 미들웨어 제품을 사용해 볼 수 있다.
  
  

토론

• developerWorks 포럼 & 블로그를 통해 developerWorks 커뮤니티에 참여하자.
  
  

필자소개

아티클 순위

의견

위로

목차

• 목표
• 개요
• 용어 정의
• 이 기사를 쓰게 된 계기
• 정책과 규칙의 추상화 레벨
• 하향식 시작 - 비즈니스 계층
• 비즈니스 목표와 결과
• 아키텍처 계층
• 운영 계층
• 결론
• 참고자료
• 필자소개
• 의견