비즈니스 애플리케이션 프레임워크 & 컴포넌트

* 인터넷에서 비즈니스 애플리케이션 프레임워크 & 컴포넌트(이하 BAFC)에 대한 자료는 간단한 소개 이상은 찾기가 어렵습니다. 디자인이나 구현과 관련된 내용은 Martin Fowler의 Anaylsis Patterns(http://www.martinfowler.com/articles.html#N1003F) 외에는 없습니다. 그 이유를 나름대로 추론하자면 첫째는 BAFC에 대한 관심의 부족을, 두번째는 BAFC에 대해서 내세울만한 성과의 부족을, 세번째는 (업체들의) 그런 자료를 공개할 동기 부족을 들 수 있을 것 같습니다.



비즈니스 애플리케이션

ERP(Enterprise Resource Planning), CRM(Customer Relationship Management), SCM(Supply Chain Management), HRM(Human Resource Management) 등으로 대표되는 (영리 혹은 비영리) 비즈니스 업무 자동화와 정보 제공 및 분석을 위한 애플리케이션을 비즈니스 애플리케이션이라고 한다. 비즈니스 애플리케이션은 앞의 예처럼 패키지 형태의 솔루션일 수도 있고, 독자적으로 개발한 Custom-built 애플리케이션 형태일 수도 있다. 비즈니스 애플리케이션의 자세한 분류 체계는 PeopleSoft(http://www.peoplesoft.com/corp/en/products/ent/index.jsp) 혹은 SAP(http://www.oracle.com/solutions/index.html)을 참조한다.


Product Line

다양한 형태의 비즈니스 애플리케이션들은 공통점을 보유하고 있다.

첫 번째는 기술 플랫폼을 공유한다. J2EE(Java 2 Platform, Enterprise Edition)나 .NET과 같은 기술 플랫폼이 이에 해당한다. 물론 SAP 처럼 독자적인 기술 플랫폼을 보유하고 있는 업체도 있고, PeopleSoft 처럼 J2EE와 같은 표준 기술 플랫폼을 차용한 업체도 있을 것이다. 광의로 해석하면 운영 체제나 하드웨어까지도 이에 포함된다.

두 번째는 기술 프레임워크이다. 기술 프레임워크는 기술 플랫폼에 특화된 개발 표준으로 이해하면 된다. 물론 SAP 처럼 독자적인 기술 플랫폼을 지닌 업체에게는 기술 플랫폼과 기술 프레임워크의 구분이 불필요할 수 있다. 그러나 외부 표준 기술 플랫폼을 차용한 경우에는 이를 자신들에게 적합한 방식으로 가공한 기술 프레임워크가 있을 것이다. 예를 들어 Struts는 오픈 소스 진영의 J2EE에 대한 개발 표준(기술 프레임워크)이 된다.

세번째는 비즈니스 프레임워크이다. 애플리케이션의 유형과 독립적으로 존재 가능한 비즈니스 대상 혹은 프로세스의 설계 및 구현이 이에 해당한다. 예를 들면 화폐, 주문, 제품, 고객, 공급사, 직원, 결제 등이 이에 해당된다. 자세한 항목은 다음을 참조한다. (ftp://ftp.software.ibm.com/software/websphere/awdtools/businesscomponents/bcgtm.pdf) 이런 비즈니스적인 공통 요소에 대한 개발 표준을 BAFC로 이해하자.

수평적 통합에 기반한 솔루션 포트폴리오를 가지고 있는 업체들은 경쟁력 향상을 위해서 이 공통적인 요소들을 중복없이 공통적으로 관리하는데 관심을 갖게 된다. 이를 Product Line이라고 지칭할 수 있을 것이다.


비즈니스 애플리케이션 프레임워크 & 컴포넌트

현 시점에서 기술 플랫폼과 기술 프레임워크에 대한 성숙도는 상대적으로 높은 편이며 이제 관심의 초점은 BAFC로 넘어가고 있다. 이는 기술 플랫폼부터 애플리케이션까지 수직접 통합을 시도하는 IBM, MS, Oracle 등의 업체와 비즈니스 애플리케이션 개발 및 컨설팅에 집중하는 SAP, PeopleSoft, Siebel, webMethods 등의 업체들이 주도하고 있다.

(1) Microsoft Business Framework(이하 MBF)

MS 는 ERP, CRM 등의 제품 개발을 위한 Project Green(http://www.informationweek.com/story /showArticle.jhtml?articleID=15200123)을 진행하고 있다. MS가 이미 다양한 비즈니스 애플리케이션(http://www.microsoft.com/BusinessSolutions)을 보유하고 있기는 하지만 대부분이 M&A를 통해서 확보한 관계로 애플리케이션 사이에는 기술 플랫폼과 기술 프레임워크에서의 이질성이 존재한다. 이 이질성을 해소하기 위한 작업이 Project Green이다.

Project Green은 기술 플랫폼은 .NET, 기술 프레임워크는 Enterprise Library에 기반하고 있다. 그리고 동시에 애플리케이션 사이에서 공통적인 비즈니스 요소들을 MBF(http://www.gotdotnet.com/team/PDC/4121/DAT340.ppt)로 개발하고 있다. 따라서 Project Green을 통해서 개발될 애플리케이션은 MBF를 사용하여 구현될 것이다.

그러나 MBF는 WinFS나 Longhorn 등의 출시와 맞물리면서 그 진척이 주춤하고 있는 상태이다.(http://www.infoworld.com/article/04/09/01/HMlonghornmbf_1.html)

(2) IBM Business Components for WebSphere™ Application Server(이하 BC)

IBM은 ERP나 CRM 등의 솔루션을 직접 제공하고 있지는 않으며, 기술 플랫폼과 기술 프레임워크, 비즈니스 프레임워크 등을 제공한다.

기술 플랫폼은 J2EE(WebSphere), 기술 프레임워크는 Struts이다. 그리고 BC는 SanFrancisco 프로젝트와 연결되어 있다.

기 본적으로 Entity Bean을 포함한 EJB(Enterprise JavaBeans)를 중심으로 설계/개발되어 있는 BC는 비즈니스 영역에 구애받지 않고 공통적으로 사용할 수 있는 컴포넌트와 특정 영역에서만 사용 가능한 컴포넌트로 구분되어 있다. 전자는 Cross Domain Component(CDC)라고 하며 화폐, 달력, 계정, 고객, 파트너 등이 포함된다. 후자는 Business Domain Component(BDC)라고 하며 현재는 일반 회계, 주문 관리(Order Management), 창고 관리(Warehouse Management) 등의 영역에 해당하는 컴포넌트를 제공한다. 자세한 컴포넌트 목록은 다음을 참조한다.(ftp://ftp.software.ibm.com/software/websphere/awdtools /businesscomponents/basecomponentoverview.pdf)

(3) Oracle Application Development Framework(이하 ADF)

Oracle 의 ADF는 기술 프레임워크를 중심으로 비즈니스 프레임워크가 포함되어 있다. 그런데 ADF는 BC 혹은 MBF와는 상이하다. ADF는 라이브러리 혹은 컴포넌트 형태의 비즈니스 컴포넌트를 제공하는 것이 아니라 신속한 비즈니스 컴포넌트(BC4J)의 개발을 돕는 마법사 도구를 제공한다.


그 외에도 webMethods Composite Application Framework, SAP Composite Application Framework 등의 BAFC가 있다.


비즈니스 애플리케이션 프레임워크 & 컴포넌트의 특징

BAFC 는 일정한 Best Practices 및 디자인 패턴에 기반하여 설계되어 있다. 실질적으로 BAFC가 제공하는 재사용 가능한 컴포넌트 못지 않게 견고한 설계 기법 등이 더 중요한 역할을 할 수 있다. SanFrancisco 디자인 패턴이 대표적인 예이다.

Oracle의 JDeveloper, MS의 Visual Studio.NET 등 BAFC는 IDE(+ 모델링) 도구와 밀접하게 통합되어 있으며 일정 부분은 MDA(Model-Driven Architecture)를 지향하고 있다.

BAFC 는 다양한 트랜드와 연결되어 있다. SOA(Service Oriented Architecture), 웹 서비스, BPM(Business Process Management), BPEL(Business Process Execution Language), 포탈 등이 이에 해당한다.


시사점

성질 급한 A라는 고객을 가정하자. 어느날 A가 통상적으로는 6개월이 걸리는 B라는 애플리케이션을 4개월 안에 개발해 줄 것을 요청한다. 혹은 2개월일 수도 있다. 물론 A가 합리적이라면 그 댓가는 만족할 만한 수준일 것이다. 이는 A의 성질로 인한 것이 아니라 A가 속해있는 시장의 상황과 그 시장에서 경쟁적 우위를 확보하기 위한 불가피한 선택으로 받아들여야 한다.

우리는 A의 요구 사항을 총족 시킬 수 있는 역량을 갖추고 있는가? 혹은 그 역량을 확보하기 위해서는 어떤 부분에 투자하여야 하는가? 아마도 BAFC가 여러 많은 안 중의 하나임에는 분명해 보인다.

여기서 BAFC가 가치가 있는가에 대해서 논의하는 것은 무의미해보인다. 앞으로의 논의는 어떻게 BAFC를 우리의 것으로 만들 수 있는가가 초점이 되어야 한다.

How? Buy or Build?