요새 여러 고객들을 만나면서, 특히나 비즈니스 프로세스 및 룰 관련 사례들을 많이 접하면서 느끼게 되는 건,
재사용성과 유지보수성을 높이고 업무와 IT간 유연성과 간극을 메꾸기 위한 모델링 시도들이
되려 중장기적으로 보았을 땐 기업의 IT유연성을 떨어뜨리는 결과를 가져오는 경우가 많더라는 것이다.
모델 드리븐 아키텍처기반의 프로젝트에서 너무 거창하고 복잡한 모델은 오히려 나중에 전혀 새로운 변화에 적응하지 못하는 결과를 발생시킨다. 이러한 아키텍처의 경우 변화가능성이 높은 것들을 미리 빼서 그것을 속성이나 정책 혹은 프로세스와 룰등으로 유연성을 높이고자 하는데, 문제는 변화의 대상이 이러한 속성들이 아니라 모델 자체인 경우 유연성이 극도로 나빠진다는 것이다.
과거, 기업들의 업무가 크게 변하지 않았을 때에는 이러한 모델기반이 유연성을 보장할 수 있을지 모르겠으나 이기종간 융,결합이 극심한 지금에서는 업무의 모델이 정적이지 않다. 막대한 자금을 들여 구축한 프로젝트가 막 종료 일보직전인데 기업 합병으로 갑자기 초반에 설계한 모델에 많은 부분 수정이 가해져야한다면?
재사용성과 유지보수성을 높이고 업무와 IT간 유연성과 간극을 메꾸기 위한 모델링 시도들이
되려 중장기적으로 보았을 땐 기업의 IT유연성을 떨어뜨리는 결과를 가져오는 경우가 많더라는 것이다.
모델 드리븐 아키텍처기반의 프로젝트에서 너무 거창하고 복잡한 모델은 오히려 나중에 전혀 새로운 변화에 적응하지 못하는 결과를 발생시킨다. 이러한 아키텍처의 경우 변화가능성이 높은 것들을 미리 빼서 그것을 속성이나 정책 혹은 프로세스와 룰등으로 유연성을 높이고자 하는데, 문제는 변화의 대상이 이러한 속성들이 아니라 모델 자체인 경우 유연성이 극도로 나빠진다는 것이다.
과거, 기업들의 업무가 크게 변하지 않았을 때에는 이러한 모델기반이 유연성을 보장할 수 있을지 모르겠으나 이기종간 융,결합이 극심한 지금에서는 업무의 모델이 정적이지 않다. 막대한 자금을 들여 구축한 프로젝트가 막 종료 일보직전인데 기업 합병으로 갑자기 초반에 설계한 모델에 많은 부분 수정이 가해져야한다면?
공유하기 버튼
|
|
덧글