개발팀 내부에서 사용하는 범용적인 Framework를 만든다면, 생산성 향상 / 중복 개발의 제거등으로 초점이 맞추어 질수 있습니다.

하지만 비지니스를 수반하는 시스템은, 시장의 변화가 어떻게 될지 모르고, 국가마다 워낙 다양한 문화와 법들에 영향을 받기 때문에 Framework 형태로 제공할 수 밖에 없습니다. 미래를 예측할수 없으니 완제품이 아닌 반제품(Semi-Complete Product) 을 선택할 수 밖에 없는 상황이지요.

그리고 비지니스를 수반하는 Framework 는 이해당사자의 역학 관계에  따라 크게 영향을 받습니다.  그래서 이 Framework를 사용할  잠재적인 고객은 누구이며, 이 고객들에게 어떠한 Benefit들을 줄수 있는지를 정하는 것이 가장 우선일듯 합니다.

고객 역시 무엇이 필요한지 알수 없는 상황이라면, 그 길을 제시하면서 서서히 표준화하는 것이 중요합니다.

표준화에서는 일반적으로 Spec을 협의하고  그 기능을 서로 구현하자고 이야기 하는 것보다 먼저 돌아가는 구현체를 가진 회사(조직)가 우리가 이러 이러한 기능을 가진 실사례가 있으니 이것을 기반으로 하자 라고 하는 사례가 많습니다.

(WS – *이 대표적인 예이며, 결국 Sun과 Microsoft의 협작으로 WS-*에 많은 부분이 이 두 회사가 원하는대로 된 사례입니다. )

결국 고객들에게 어떠한 Benefit들을 제공하느냐가 시장에 살아남을수 있고,  Benefit을 제공하기 위한 전략들을 이해하고 이해당사자들을 모아 Architecting해야 하기 때문에 도메인 특화된 지식과 그 업계의 흐름을 잘 알아야만 됩니다.

도메인 특화된 지식과  시장의 흐름을 읽어, 정말 구미에 당기는 기능들을 넣지 않으면, 안될거 같습니다.   너무나 큰 숙제를 가진 덕에 정말 힘드네요🙂