패턴을 사용하여 다양한 통합 문제를 해결하는 방법 1부 - 통합의 필요성

패턴을 사용하여 다양한 통합 문제를 해결하는 방법을 설명합니다

 

통합의 필요성

기업은 일반적으로 수천 개는 아니더라도 수백 개의 애플리케이션으로 구성되어 있으며, 이 애플리케이션은 맞춤형으로 구축되었거나 타사, 레거시 시스템의 일부 또는 이들의 조합으로 여러 계층의 다양한 운영 체제 플랫폼에서 운영됩니다. 30개의 서로 다른 웹사이트, 3개의 SAP 인스턴스, 수많은 부서별 솔루션을 보유한 기업을 어렵지 않게 찾아볼 수 있습니다.

 

꽃 - 디자인 패턴

 

어떻게 기업이 이런 엉망진창이 되도록 방치할 수 있냐고 묻고 싶을 수도 있습니다. 이런 엔터프라이즈 스파게티 아키텍처의 CIO는 해고되어야 하지 않을까요? 글쎄요, 대부분의 경우와 마찬가지로 모든 일에는 이유가 있습니다.

우선, 비즈니스 애플리케이션을 작성하는 것은 어렵습니다. 완전한 비즈니스를 운영하기 위한 하나의 큰 애플리케이션을 만드는 것은 거의 불가능에 가깝습니다. ERP 공급업체들은 그 어느 때보다 큰 규모의 비즈니스 애플리케이션을 만드는 데 어느 정도 성공을 거두었습니다. 하지만 현실은 SAP, 오라클, 피플소프트와 같은 거물급 업체들도 일반적인 기업에서 필요한 비즈니스 기능의 일부만 수행한다는 것입니다. ERP 시스템이 오늘날 기업에서 가장 많이 사용되는 통합 포인트 중 하나라는 사실만 봐도 이를 쉽게 알 수 있습니다.

 

둘째, 비즈니스 기능을 여러 애플리케이션에 분산하면 비즈니스에 가장 적합한 '최고의' 회계 패키지, '최고의' 고객 관계 관리 또는 주문 처리 시스템을 유연하게 선택할 수 있습니다. 엔터프라이즈 애플리케이션에 대한 원스톱 쇼핑은 일반적으로 IT 조직이 원하는 것이 아니며, 수많은 개별 비즈니스 요구 사항을 고려할 때 불가능합니다.

공급업체들은 이러한 선호에 부응하여 특정 핵심 기능에 집중된 애플리케이션을 제공하는 방법을 배웠습니다. 하지만 기존 소프트웨어 패키지에 새로운 기능을 추가하려는 욕구가 끊임없이 발생하면서 패키지형 비즈니스 애플리케이션 간에 일부 기능이 유출되는 문제가 발생했습니다. 예를 들어, 많은 청구 시스템이 고객 관리 및 회계 기능을 통합하기 시작했습니다. 마찬가지로 고객 관리 소프트웨어 제조업체는 분쟁이나 조정과 같은 간단한 청구 기능을 구현하는 데 주력하고 있습니다. 고객이 청구서에 대해 이의를 제기하는 것을 고객 관리 기능으로 볼 것인가, 아니면 청구 기능으로 볼 것인가 등 시스템 간의 기능적 구분을 명확하게 정의하는 것은 어렵습니다.

 

고객, 비즈니스 파트너, 내부 사용자와 같은 사용자는 일반적으로 비즈니스와 상호 작용할 때 시스템 경계를 생각하지 않습니다. 이들은 비즈니스 기능이 얼마나 많은 내부 시스템을 가로지르는지에 상관없이 비즈니스 기능을 실행합니다. 예를 들어, 고객이 전화를 걸어 주소를 변경하고 마지막 대금이 입금되었는지 확인할 수 있습니다. 많은 기업에서 이러한 간단한 요청은 고객 관리 및 청구 시스템 전반에 걸쳐 이루어질 수 있습니다. 마찬가지로 고객이 새로운 주문을 하는 경우에도 여러 시스템의 조율이 필요할 수 있습니다. 기업에서는 고객 ID를 확인하고, 고객의 정상 여부를 확인하고, 재고를 확인하고, 주문을 처리하고, 배송 견적을 받고, 판매세를 계산하고, 청구서를 보내는 등의 작업을 수행해야 합니다. 이 프로세스는 5~6개의 서로 다른 시스템에 걸쳐 쉽게 이루어질 수 있습니다. 고객 입장에서는 하나의 비즈니스 거래에 불과합니다.

 

애플리케이션 간에 공통된 비즈니스 프로세스와 데이터 공유를 지원하려면 이러한 애플리케이션을 통합해야 합니다. 애플리케이션 통합은 여러 엔터프라이즈 애플리케이션 간에 효율적이고 안정적이며 안전한 데이터 교환을 제공해야 합니다.