EAI 프로젝트를 해보지 않은 나는 그 어려움을 잘 모른다.- 일부분 예상되는 부분도 있지만....
현재 SOA Based Project (이름하여, Fundamental SOA )를 진행 중이다..
진행의 ownership은 나에게 있지 않다. 단지, Solution based support다.
정책의 핵심은 아니라는 소리다. 단지 플랫폼을 제공해주고, 거기서 일어나는 이슈나 가이드를 제공해주는 역할이다. 따라서, 욕심이 나던 일도 내일이 아니니 접근하기가 애매하다.
현재 ESB 개발이 1차 릴리즈 되고, 이젠 연계에 관한 테스트를 진행 할 수 있도록 지원한다.
어제는 consumer(서비스 소비자) , 오늘은 Provider( 서비스 제공자)를 만났다.
공통적인 모습은 양쪽다 별다른 관심이 없다는 거다. 단지 자신이 하던 개발에 추가적인(?) 개발이라고 생각할 뿐......
마치 난... consumer에게는 기술지원을 해주는 사람처럼... 상세하게 메시지 구조나 ESB의 역할... 어떻게 연동해야 하는지에대해 친절(?)하게 설명해줬다.
반면, Provider쪽에 가서는... Fixed 된 인터페이스 설계문서를 달라고 졸라댄다...
예를 들면..." 과장님이 설계서 완료를 못하면...consumer쪽에서 개발을 못해요... 개발 지연이 예상되구여..어쩌구 저쩌구... 제발 빨리 해주세요...ㅡ.ㅡ"
흠... 중간에서 난 ESB 처럼 행동해야한다. 메시지 라우팅도 했다가... 서비스 콜아웃도하고....
SLA를 조절 하듯 일정에 대한 협의안을 찾아내야하고... 이슈 발생시 Alert 기능을 사용해야 할것이다.
최근에 본....기업혁신을 위한 서비스 지향 아키텍처( IBM SOA SIG 역)
이책에서 SOA Office 라는용어라는 것이 나와서... 머... 이렇게 거창해야하나? 라는 의구심도 들었는데.. SOA는 협의의 산물이라는 관점에서는 당연히 필요한 조직인것 같다.
또 한가지, SOA 프로젝트를 진행할때... 필요한 부분은 SOA 목적 및 목표에 대한 강렬한 전파이다.
가끔 Consumer쪽에서 Provider를 걱정한다.
왜 일까.... 이유는 자신이 원하는 결과를 돌려 줄 수 있는지 에 대한 의구 심이다...
한예로... Provider쪽에서 DBLink 나 이런거 제공하는지... --;
사실 그건 걱정할께 아닌데.... Consumer의 눈앞에 보이는 것은 ESB다! 하지만, 그들의 눈엔 보이지 않는다.
이 프로젝트가 SOA Based라는 것을 모르는 것일까?
보다 비즈니스 민첩성을 확보한 시스템이 되기 위해서는 그 시스템을 구축/ 개발하는 사람들에게...
이 프로젝트 또는 자신이 해야할 역할에 대해서 명확히 의미전달을 해주는 것이 중요하다.
가끔 개발하다 보면.... 설계서가 자신이 구현할 최종 목표라고 생각하고 개발하는 경우가 있다.
더 큰 목표가 있음에도 말이다....
잊지말자! 커뮤니케이션! 점검하자! 커뮤니케이션!
