1001엔젤

출 처 : http://blog.naver.com/amuck?Redirect=Log&logNo=80002465378]

1. CBD? 지금이 적기인가?
 
만약 여러분이 CBD(Component Based Development)에 대해 아직 들어보지 못했다면 곧 알게 되겠지만, CBD는 개발 지연과 믿을 수 없는 품질 등 사시사철 지속되는 문제들을 돌파할 수 있는 최신의 개발방법으로서 최근에 관심을 끌고 있다.관계형 데이터베이스, 4GL, CASE와 같은 기술 파도를 연속해서 뚫고 나온 많은 IT 관리자들은 CBD에 대해 회의를 품고 있지만 나름대로 일리도 있다.그들은 이미 생산성이 대폭 증가를 이룰 수 있다는 열광적인 예측들로부터, 적은 투자만으로도 큰 효과를 얻어낼 수 있다는 것 까지 포함해서, 그 동안의 기술 결과들을 익히 보아 왔기 때문이다.
그렇다면 CBD는 지금까지 것과는 다른 것인가? 그것은 CIO들이 무시해도 될 만한 일시적인 기술 유행에 그칠 것인가? 아니면 IT분야에서 포용하고 인정해야 할 새로운 패러다임인가? 비용은 실제로 얼마나 들 것이며 거기서 얻는 이익은 무엇인가?

이 글에서는 CBD전망과 문제들에 대해서 조사하고자 한다. 여러분은 왜 CBD가 IT를 위한 진정한 주요 패러다임 변동인지, 그리고 왜 그것이 결국 널리 적용되어야 하는지 알게 될 것이다. 주요 회사들은 이미 CBD로 이동중이다. 그것이 새로운 개념이기 때문이 아니라 전략적 규범이 될 것이기 때문이다. 가트너 그룹은 2004년 까지 CBD 와 비즈니스 컴포넌트의 대규모 상품을 소유한 IS 조직들은 그렇지 않은 조직들보다, 5배에서 10배 까지 더 많은 생산성과 대응력을 가질 것으로 보고 있다.

많은 회사들은 그들이 계속 전통적인 방법으로 일하는 한, 경쟁자들의 앞서가는 생산성을 도저히 따라잡을 수 없게 될 것이다. 새로운 인터넷 경제에서, IT 솔루션과 비즈니스 성공 사이에 연관이 매우 밀접해 지면서, 많은 CIO들은 시스템 평가 방법을 재정립하고 있다. 기업의 어플리케이션 개발 능력을 향상시키는 일은 단지 효율성 개선 수준이 아닌 훨씬 더 큰 의미를 가지는 것으로 - 전략적 필요성으로 인식되고 있다.

CBD가 가져올 효과는, 열심히 뛰어서 회사의 응용프로그램을 인도해 주는 수준으로부터 더 나아가서, 그 자체가 경쟁력 있는 무기가 되는 것이다. CBD를 사용한 회사들이 새로 정교하게 만든 e비즈니스 어플리케이션을 배치하고 주도해 나가고 있을 때, 다른 회사들은 설계, 개발, 테스트, 디버깅 하느라 고생하게 될 것이다.

만약 CBD의 이점들이 그렇게도 극적인 것이라면, 왜 더 널리 보급되지 않았을까? 거기에는 산업 표준 미성숙, 기술 장벽, CBD기반 도구 부족, 좋은 조언자 부족, 실용 방법론 부족과 같은 몇가지 요인들이 있다. CBD의 전략적인 이점을 정확히 알고 있는 일부 기업들은 야심적인 CBD 프로젝트를 곧 진수할 차비를 차리고 있다. 위에 열거한 요인들 때문에 그 동안의 노력들은 실패를 거듭하였고, 그런 실패들은 IT조직들이 CBD에 대한 편견을 갖는데 기여했다. 그러나 지난 몇 년 동안의 기술 진보에 힘입어 위의 실패 요인들을 해결하게 되었고, CBD를 이용하여 성공을 경험하고 있는 조직들도 이제는 나타나고 있다. 이런 성공들은 CBD의 근본 전망을 확인시켜 주었다. 이렇게 중요한 추세인 CBD를 CIO들이 주시해야 되는 이유는 그에 내포된 전략성 때문이다.

 2. CBD? 진정 새로운 것인가?

 모듈화modular 프로그래밍에 관해 들어본 사람이라면 컴포넌트의 기본적인 가치 명제도 이와 같다고 보면 된다.
큰 시스템을 관리하기 편한 조각으로 나누고, 식별되는 명세서 별로 인터페이스를 명확히 갖는 모듈로 구현하고, 문서로 정확히 나타낸 후, 소프트웨어 빌딩블록의 집합을 만들 수 있다. 개발자들은 빌딩 블록을 조립하여 어플리케이션을 마무리 짓는다.

오늘날까지 경험으로 증명된 바에 따르면, 개발자들이 외부 파라미터 위주로 컴포넌트를 호출하면, 컴포넌트의 내부 코드를 조사하여 그것을 프로그램과 연동시키는 것 보다, 작업을 완료하고 시험하는데 있어, 수십, 수백 배 더 빠르게 일을 마칠 수 있다.

적절히 구현된 모듈화의 주요 이점중의 하나는, 개발자들이 결과를 내는 방법에 관해서는 신경 쓸 필요가 없다는 것이다. 단지 주어진 기능을 사용하면 되는 것이다. 예를 들면, 고정금리 대출이자 계산 모듈이 있다면 새로운 대출금 지불 시스템을 개발할 때 “재사용”할 수 있다. IT조직은 “바퀴를 재 발명” 하는 일과 같은 경우를 피할 수 있을 뿐만 아니라, 전체 개발 스텝에서 널리 사용될 수 있는 복잡한 로직을 가진 모듈을 미리 만들고 테스트하는 등 모자라는 IT 기술자들을 지렛대 효과로 활용할 수 있다.

모듈화 개념은 오랫동안 IT 조직에서 이용되어 왔다. 만약 그것이 컴포넌트 중심 개발의 전부라면 왜 CBD를 IT의 새로운 파도라고 귀찮게 권유하는가?

CBD가 힘을 얻고 있는 이유는 모듈화 이점을 대규모로 확장할 수 있게 되었기 때문이다. e비즈니스 세계는 궁극적으로 이기종 분산 컴퓨팅 환경이다. 미들웨어 수준에서 컴포넌트들은 이기종 플랫폼 마다 서로 다른 아키텍처와 언어, 표준화 장벽들을 극복할 수 있는 접착제 역할을 흘륭히 증명했다. CBD는 전자 상거래와 같은 다방면의 e비즈니스 어플리케이션 개발에서 선진적 방법을 지렛대로 쓸 수 있다.

다시 대출금 계산 루틴 예제로 돌아가서, 만약 이 모듈이 20년 전에 개발되었다면 그것은 관계형 DB가 출현하기 이전 환경인 메인 프레임에 배치되었을 것이다. 그 후에 조직이 클라이언트-서버 시스템으로 전환될 때 이 모듈은 호환성이 없었기 때문에 재사용할 수 없었고 따라서 재작성할 수 밖에 없었다. 더욱이 데스크 탑과, 브라우저 중심 어플리케이션 환경으로 구현되면서 호환성은 더욱 멀어졌고 당연히 재사용은 되지 않았다.

새로운 운영 시스템으로 진화되고 난 후, 새로운 플랫폼, 새로운 DBMS, 새로운 네트워킹 프로토콜, 새로운 프로그래밍 언어들도 진화되면서, 이때 호환성 문제들이 얼마나 복합적으로 얽히는지 우리는 알고 있다. 이것이 바로 관리를 잘하는 IT 조직들이 "모듈화 프로그래밍”을 오랫동안 가장 좋은 규칙으로 선택한 이유이다. 그러나 그들은 지속적으로 진화된 기술 아키텍처들을 지렛대로 이용하여 대규모 개발 방법론으로 발전시키지 못한 아쉬움이 있다.

그러나 이제, 모든 것이 변했다.

오늘날 모든 타입의 컴퓨팅 플랫폼들은 인터넷을 통해 상호 연동된다. 표준들이 등장하여 이기종 시스템들 사이의 비 호환성을 중화 시키고 있다. 사용자 인터페이스용 공통 프로토콜들도 태어났다. 벽이 허물어진 것이다.

오늘날 SQL을 사용하는 관계형 모델은 기업 데이터 관리 분야에서 사실상de facto 표준으로 부상하고 있다. 또한 이기종 분산 어플리케이션 미들웨어 표준으로서 COM+, CORBA, EJB(Enterprise Java Beans) 가 빠르게 성숙되는 것을 볼 수 있고, Java, Visual Basic과 같은 컴포넌트 기반 언어들이 e비즈니스 개발 표준이 되어가는 것도 볼 수 있다.

혹자는 각각의 기술 간에 상대적인 장점들을 논하려 들지도 모른다. 그러나 언제나 얻을 수 있는 이점으로는 어플리케이션과 애플릿, 컴포넌트들이 개발되면 이기종 플랫폼에도 보급되어 수행될 수 있다. 이와 같은 상호연동은 CBD 패러다임으로 이동되면 나타날 수 있는 현실이다. 그렇게 되면 한 환경에서 개발된 소프트웨어 모듈은 다른 환경에서도 실행될 수 있게 된다.

패러다임이 이동되고 있는 증거로는 기술 컴포넌트들이 시장에서 번성하는 것을 보면 알 수 있다. 웹을 통해 컴포넌트들을 이용할 수 있을 뿐 아니라, 어떤 종류의 컴포넌트들이든지 다운로드할 수 있고 구매도 할 수 있다. 때때로 규격품widget이라 불리는 기술 컴포넌트들은 공통 기능들을 자동화하여 GUI 디스플레이 관리나 grid 컨트롤, 프린트 유틸리티 형태로 나오고 있다.

컴포넌트 시장은 더 높은 수준의 기능 분야로 확장되기 시작하였다. e비즈니스 어플리케이션 구축자들은 쇼핑 cart나 주문 관리와 같은 공통 웹사이트 작업을 다룰 수 있는 컴포넌트들을 획득해서 사용할 수 있다.

요약하면, 모듈화 개념은 새로운 것은 분명 아니지만, 이기종 환경에서 구현할 수 있는 능력은 새로운 것이다. CBD는 중요한 개발의 새로운 파도로서, 그것이 아주 새로운 아이디어라서 가 아니라, 품질과 생산성을 함께 이루고자 했던 이전의 생각들을 최근까지는 이루지 못하다가, 이제서야 실현할 수 있는 수단이 되었기 때문이다.
 

3. 컴포넌트?

 컴포넌트 : 특정한 기능을  수행하기 위해  독립적으로 개발되고,  잘 정의된  인터페이스를 가지며, 다른  부품과  조립되어  응용 시스템을  구축하기 위해 사용되는 소프트웨어 부품(단위).   

  A Component  is a software building block,  used to  construct large component or  application for end- users.    -John Dodd(Computer Associates) -    

위에서 말했던 것처럼, 컴포넌트는 그 본질이 개별 특성을 가진 소프트웨어 모듈이다. 그것은 패키지로서, 사용자에게 서비스를 제공할 수 있도록 잘 정의되어야 한다. 컴포넌트는 객체지향 기술 분야의 용어를 자주 빌려 쓰지만, 컴포넌트와 객체지향이 결코 같은 것은 아니다. 메인 프레임에 있는 COBOL 루틴도 자바 프로시저 만큼 쉽게 컴포넌트로 쓸 수 있다.

컴포넌트는 각각 명세서를 한 개씩 동반하면서 거기서 자신이 제공하는 서비스를 식별하도록 돕는다. 서비스는 기능을 구체화시켜 이를 통해 밖으로부터 접근할 수 있게 한다. 서비스에는 이름과 파라미터 목록이 있다. 캡슐화encapsulation 개념은 CBD에서 근본을 이루고 있다. 컴포넌트에는 데이터와 그들이 제공할 필요가 있는 프로세스들을 포함시킨다. 그리고 컴포넌트에 접근하여 기능을 수정할 수 있는 방법은 정의된 인터페이스를 통하는 길 뿐이다. 이 “폐쇄 경계”closed boundary 개념은 CBD가 객체지향 기술과는 다른 길을 가도록 한다.

객체지향기술에서, 상속은 한 객체가 다른 객체를 효과적으로 수정할 수 있는 강력한 원리이다. 객체 특성이 변경되면, 해당 하위 객체는 모두 자동으로 변경을 상속 받는다. 상속은 강력하기는 하지만 기술을 습득하기가 매우 어렵고, 시스템 개발에서 큰 도전 정신이 필요하다. 왜냐하면, 설계가 바뀌면 파급효과는 객체 경계를 넘나들어 통제하기가 힘든 때문이다.

CBD 캡슐화로 시스템 설계에서 관리 체계를 세울 수 있게 되었다. 그것은 변경이 일어나도 컴포넌트 내로 국한시킬 수 있고, 캡슐 밖으로는 어떤 영향도 주지 않기 때문이다. 상속기능을 모두 사용하여 객체지향 언어를 쓰면 컴포넌트에서 지렛대로 사용될 수 있으나, CBD 기술로 안정된 어플리케이션 빌딩 블록을 인도할 수 있도록 컴포넌트 경계이내로 캡슐화 사용을 제한했다.

컴포넌트를 구현할 때는 서비스가 어떻게 실행되는지를 정의한다. 구현된 결과로 나오는 것은 소스 코드가 한 부분이고, 다른 한 부분은 설계 모델 자체이다. 고급 툴 집합들 중에는 소스 코드를 모델에 연관시켜, 본래의 비즈니스 요구사항과 프로세스들 까지 역 추적 할 수 있는 것도 있다. 이렇게 연결하면 전통적인 방법과 툴을 사용하였을 때 보다 컴포넌트의 설계 의도를 더욱 깊이 이해 할 수 있게 된다. 컴포넌트 명세서는 서로 다른 몇 개 환경으로 구현될 수 있다. 예를 들면, 어떤 컴포넌트를 COM+ 나 CORBA 두 가지로 구현할 수 있다.

컴포넌트 실행물executable(즉, 오브젝트 코드)은 구현으로부터 나온다. Princeton Softech 제품인 Select Component ManagerTM 와 같은 몇몇 CBD 지원 툴들은 실행물들을 저장할 때 컴포넌트의 구현물implementation과 명세서들도 함께 붙여 놓을 수 있다. 그리고 사이트 관리자가 지정하는 대로 분산시킬 수도 있다.

대체로, 컴포넌트들은 테스팅과 QA 프로세스들을 강도 높게 거쳤기 때문에, 품질이 높은 소프트웨어 모듈들이다. 다시 말하면 미리 시험한 단단한 소프트웨어 루틴들이므로 새로운 어플리케이션에 신뢰를 가지고 포함(재사용) 시킬 수 있다는 것이다. 이렇게 일할 때, 전체적인 어플리케이션의 인도 시기는 더 앞당길 수 있다. CBD 환경을 사용하지 않는 것보다 미리 시험된 컴포넌트는 테스팅과 디버깅 중 많은 부분을 생략할 수 있기 때문이다.

최근에, 표준 인터페이스 정의 언어들이 부상하고 있다 (CORBA에서 IDL, COM에서 ODL 등). 이제는 개발자들이 목표로 하는 미들웨어 환경에서 사용할 최종 상품에 상호연동해서 쓸 수 있도록 컴포넌트를 생산할 수 있게 되었다.

오늘날 컴포넌트는 기술 컴포넌트와 비즈니스 컴포넌트 두 종류로 나누는 것이 보편적이다. 기술 컴포넌트는 위에서 말했던 “규격품”widgets처럼 어플리케이션의 기술적 경향에 초점을 맞추고 다양한 비즈니스에서 재사용 할 수 있다. 왜냐하면, 그것들은 GUI 행동처럼 계통generic 기능들을 가지고 있기 때문이다.

비즈니스 컴포넌트는 초점이 고 수준이다. 그것은 해당 어플리케이션의 요구사항에 제한되어 설계하는 경향을 항상 띠기 때문에 만들기가 더욱 어렵다. 그러나 조그만 더 앞서 생각하면 다른 어플리케이션에서도 재사용 될 수 있는 비즈니스 컴포넌트들을 설계할 수 있다.

예를 들면, 새로운 e비즈니스 어플리케이션에서 화면에 카탈로그 품목들을 표시하고, 선택품목을 쇼핑 바구니에 추가 하는 기능이 필요할 수도 있다. 쇼핑 바구니 관리자를 일반화로 설계하여 여러 서비스를 제공할 수 있는 컴포넌트로 만들면, 현재 개발중인 어플리케이션에서 가치 있게 쓸 뿐만 아니라, 아직 밑그림 단계에 있는 미래의 e비즈니스 어플리케이션에서도 쓸 수 있는 것이다. (이 예는 비즈니스 컴포넌트라기보다는 기술 컴포넌트를 범용으로 만든 정도라고 주장할 수도 있겠는데, 여기서는 단지 컴포넌트 설계 방법을 설명하려는 취지이다.)

기술 컴포넌트들은 개발 작업 속도를 획기적으로 높였다. 그러나 CBD가 IT 조직에 - 수십, 수백 배 생산성 향상으로 실질적으로 기여하려면 - 중요 비즈니스 컴포넌트 라이브러리를 개발하고 활발히 재사용해야 한다.

4. 컴포넌트에도 전략이 필요하다

 CBD로 소프트웨어를 개발할 때 전통적 개발 방법도 함께 써서 혼성 조립 프로세스가 되고 이것은 “소프트웨어 개발의 산업 혁명”으로 부르고 있다. CBD에 내재된 개념들은 다른 산업에서 성공한 품질 개선, 예측 가능한 생산들과 일맥 상통한 것이기 때문이다.
즉, 미리 생산한 표준 컴포넌트들을 획득하고 포함시켜 최종 제품을 구축하는 것이다

컴포넌트를 이용해 조립한 어플리케이션 부분이 “재사용” 성취 비율이다. 재사용이 많을 수록 생산성은 커지기 마련이다. 경쟁력이 높으므로 어플리케이션은 더 빨리 인도되고, 전통적 시스템에 비해 품질은 돋보이게 높아진다.

몇 년이 지나면, IT 조직들은 경제적 필요성 때문에라도 CBD로 넘어갈 수 밖에 없다. CBD가 비즈니스 컴포넌트 라이브러리를 이용하면서 충분한 시간을 두고 개발될 때, 큰 생산성 이득을 가져올 수 있다. 그에 더해, 실용 방법론을 채용하여 CBD를 구현한다면, IT는 “대규모 병렬 개발”을 이루어, 주요 어플리케이션의 큰 부분들이 순차로 생산되는 대신에, 동시에 생산할 수 있게 된다. 효과가 전체에 파급되어 생산성이 더욱 증가되면 가트너 그룹이 예측한 대로 다섯 배에서 열 배까지 제품 인도가 빨라질 것이다.

내부 IT 요원을 유지하면서, 고객 요구에 맞추어, 경쟁력 있게 솔루션을 생산하고자 하는 회사들은, 외주 개발비 이하로 생산하면서 경쟁사 보다 신속히 어플리케이션을 인도하려면 CBD가 필요할 것이다. 서비스 제공자들은 경쟁사보다 싸게 입찰에 응하기 위해 CBD가 필요할 것이고, CBD를 사용하지 않는 내부 요원들에게 더 저렴한 비용을 요구하는 목적으로도 CBD가 필요하다. 이런 시나리오로 나가면, 비즈니스 컴포넌트 라이브러리가 있는 서비스 회사는 전투 초기에 어플리케이션 완료 비율이 어느 정도 있으므로, 그 컴포넌트들을 지렛대로 요긴하게 이용할 수 있다. 즉, 출시는 더 신속히, 제품 품질은 더 높게, 비용은 더 낮게 제안 할 수 있게 된다. CBD 구현에 실패한 IT 조직들로서는 작업을 직접하지 못하고 다른 곳에 양도하지 않을 수 없게 될 것이다.

CBD는 또한 부족한 IT 기술자들을 지렛대로 이용할 수 있는 수단이기도 하다. 특별히 전문적 기술을 가지고 있거나 해박한 비즈니스 분야 지식을 가진 최고의 개발자들은 재사용이 가능한 컴포넌트들을 만들고, 다른 많은 개발자들은 그들의 작업 결과를 이용한다. 회사는 이런 재능 있는 사람들로부터 이익 최대화를 실현할 수 있다.

미들웨어 표준 출현과 함께, 컴포넌트 기반 언어와 기술이 도처에 증가하고 있고, 컴포넌트 산업은 초기 상태에 있으며, ERP 벤더와 선진 IT 회사들의 CBD 포용 움직임들 ? 이들 징후들을 볼 때 지나가는 유행으로서가 아닌, CBD에 대한 진지한 장기 투자가 필요하다. CIO들은 CBD의 본질에 친숙해질 필요가 있다. 첨단 회사들로서는 “미래는 바로 지금”the future is now” 이기 때문에 CBD기술의 파도를 결코 놓쳐서는 안 될 것이기 때문이다.

5. CBD는 장애를 극복해야 한다

 어떤 이들은 인센티브 프로그램 필요성에 대해 이의를 제기하기도 하는데, CBD 채널이 성공하려면 주요 요인을 식별할 수 있어야 한다.

컴포넌트 명세서를 문서화하고 회람하는 절차가 있어야 한다. 컴포넌트 개발자들은 무엇을 만들어야 좋은지 알 필요가 있고, 컴포넌트 관리자들로서는 어떤 컴포넌트가 현재 있는지 알 수 있어야만 그들이 이용 방법을 생각할 수 있다
 
 IT 조직은 리파지토리를 만들어 놓고 컴포넌트가 완료될 때마다 그 곳에 저장해야 한다. 컴포넌트는 키워드로 설명해 놓아야만 정교한 검색 방법을 쓸 수 있다. 문화 장벽과 비용 장벽이 극복된다 하더라도, 개발자들로서 필요로 하는 컴포넌트를 찾을 방법이 없다면, 그들은 계속 바퀴를 재 발명할 것이고, 중요한 재사용은 결코 이루어지지 않을 것이다. IT 조직이 라이브러리에 컴포넌트들을 많이 축적해 갈수록, 버전 관리 설비 못 지 않게 연구를 잘 하는 것도 매우 긴요해진다. 원격 개발 팀들이 협의할 수 있는 설비들도, 웹을 통해 원격 리파지터리에 질의할 수 있는 기능과 함께 중요하다.
 
컴포넌트들이 파생된 설계 모델들을 통합하는 방법을 강구해야 한다. 점점 더 가치 있는 자산은 코드가 아니라 설계임을 알게 되는데 이것은 자동화 대상인 비즈니스 프로세스와 역으로 맵핑이 가능하기 때문이다. 컴포넌트 명세서와 설계 모델을 통합시킬 수 있는 컴포넌트 도구들이 있다면 가치를 매우 높여주고, 시간 절감도 가져온다. 왜냐하면 기술 구현을 획득하는 것은 물론 그 뒤에 가려서 안 보이는 기업 비즈니스로 연결된 지적 자산도 획득할 수 있기 때문이다.
 
공지 시스템을 자동화할 필요가 있다 - 개발자들은 컴포넌트에 관한 관심사를 등록할 수 있고 새로운 버전이 이용 가능하게 될 때 이메일을 통해 즉시 알릴 수 있다
 
컴포넌트 관리 소프트웨어는 기술 지원을 독립적으로 해야 한다. CORBA, COM+, EJB와 같은 컴포넌트들은 모두 단일 컴포넌트 리파지토리 안에서 문서화나 관리할 수 있다.
 
많은 조직들은 이미 컴포넌트로 만든 프로그램들을 많이 가지고 있다. COM 기반의 Visual Basic 프로그램도 그 예다. 컴포넌트 리파지토리는 “끌어 놓기drag and drop” 를 지원해야 한다. 거기서 이들 컴포넌트들을 분석하고, 카탈로그 만들고, 라이브러리에 넣어, CBD 가 진행될 수 있도록 한다.
 
IT 조직들은 방법론과 조언자들 도움이 필요하다. 그들은 어떻게 컴포넌트 유산을 찾고, 어떻게 올바른 컴포넌트 설계를 하고, 어떻게 전체 어플리케이션 개발 공정에 CBD를 삽입할지 알 필요가 있다. 개발도구만 가지고는 이런 지식들을 전달할 수 없다. 그것은 사람만이 할 수 있는 일이다.
위의 열거한 리스트가 다는 아니다.
예를 들면, CBD 환경을 확장할 수 있어야만 매우 큰 모델과 큰 개발팀을 지원할 수 있다.
IT 조직들은 다양한 도구와 서비스로 이루어진 채널을 구축할 수 있게 되어서, 사용자들에게 CBD공정을 보여 주면서 접근할 수 있도록 해야한다.
 

6. CBD방법론? 실용적인 경로 채택으로 생존력을 길러야 한다

 인터넷 세상은 이미 컴포넌트 세상이다. IT 조직이 공식적인 CBD 프로그램을 가지고 있든 아니든 상관없이 명백히 소프트웨어 컴포넌트를 이용하여 일하고 있다. 자바나 비쥬얼베이직 언어들과, COM+와 EJB 표준들은 모두 컴포넌트 기반이다. 그러므로 컴포넌트는 더 이상 새로운 이론이 아니다. 이미 널리 보급되어 많은 곳에서 활발히 사용되고 있기 때문이다.

그러나 CBD 개념을 단순히 이해하는 것만으로는 IT 회사들로서 CBD 프로그램 구현에 성공할 수 없다. CBD의 성공 스토리는 아직 찾기 어려우므로 필요한 것은 점차 CBD로 안전하게 이동할 수 있는 방법이다.

CBD는 RAD, 객체지향 개발, 구조적 개발 등, 초기 기술들을 대체하는 것이 아니라, 이런 기술들의 장점을 이용하고 확장 시킨다. 조직들은 그들이 알고 있는 원칙들은 그대로 쓰면서, RAD에서 부족했던 엄격함과 CASE에서 성취할 수 없었던 신속히 돌아 오기(turnaround)와, OO와 UML 이론 중에서 실용적인 것들을 추가하면 된다.

프로젝트에 따라 일부만 CBD로 이동해 갈 수는 있다. 그러는 동안 컴포넌트 구조를 설계하는 일과 CBD 공정에서 개발하는 일들에 관한 본질 원리들을 배우고 또 가치를 평가할 수 있을 때, 그 다음 단계에서 본격적인 “도구 개조”에 착수하면 된다.

개발 공정은 세 가지 주 요소로 구성된다.

정렬 (Align)
설계 (Architect)
조립 (Assemble)

정렬 단계는 “올바른” 시스템이 보장되도록 IT 와 비즈니스를 동기 시켜 개발한다.
설계 활동의 최종 결과는 비즈니스 요구를 반영 해야 한다. 단지 방법론자들만 즐겁게 해 주는 예쁜 그림이어서는 안 된다.

설계 단계에서는 알맞게 세그먼트로 나누어 설계와 개발이 CBD로 잘 진행될 수 있게 한다.
미래 재사용에 쓰려고 핵심 씨앗을 생산적으로 뿌리는 시기는 바로 이 단계다.  이 단계에서 시간과 비용을 획기적으로 절약한다.

조립 단계에서는 UML, 다른 모델링 규율, 코드 생성, CBD 관리 기술을 적용하여 어플리케이션 증분을 최종 완료 시킨다.
요점은 실질 결과를 인도하여 비즈니스에 실질 가치를 더해주는 것이다. 기업 수준의 CBD라면, 조립 공정은 “공급”과 ”관리” 기능을 통합한다. 즉, 도구들을 이용하여 가용 컴포넌트를 찾고 통합하여 최종 비즈니스 솔루션을 만들어간다.
 

컴포넌트 기반 개발 방법은 이제 전성기에 접어들었다고 해도 과언은 아니다.
미들웨어 표준(CORBA, COM+, EJB) 는 이미 쓰이고 있고, CBD에 적합한 객체 지향 언어들은(Java, Visual Basic) 지금 첨단 e비즈니스 어플리케이션 개발에 널리 이용되는 도구이다. 기술 수준에서 본다면 컴포넌트를 사용하는 일은 표준 실무가 되었다.

조직 문화와 비용 문제들은 현실적인 것들이지만, 그것들은 또한 예상 할 수 있는 수준이다. CBD로 이동은 현재 진행중이다. CBD 적응에 실패한 회사들은 경쟁에서 치명적인 손실을 감수해야 될 것이다.

전성기에 접어들었다고는 하나 이는 어디까지나 이론상의 전성기일뿐 실제 프로젝트에 CBD개발방법론에 기초하여 완벽하게 진행되는 경우는 아주 드물다고 할 수 있다. (이는 여타의 다른 개발프로젝트에서도 마찬가지결과를 보인다)

CBD개발방법론 자체로서는 이론에 지나지 않는다.
이론을 구체화 하고, 실제 업무와 프로젝트에 손쉽고 빠르게 적용할 수 있는 도구를 사용하는 것이 좋다.

컴포넌트 기반 개발방법론은 몇 명의 프로젝트 책임자나 설계자에게만 필요한 것이 아니다.  전체 프로젝트에 참가하는 모든 개발자와 프로그래머가 참여할 수 있어야 하며 CBD개발방법론의 분석 및 설계단계 그리고 조립단계를 통털어 관리할 수 있는 특별히 개발된 별도의 도구가 필요하다.