메모 : soa governance 작업 결산..

고객은 관리/통제 체계구축하는 프로젝트란 점에서
세밀하고 엄격한 통제 프레임워크를 통해 방대한 데이터 축적과 정교한 제어를 기대한다.

바람직한 관리체계에 대한 고객이 갖는 오해의 시발점은
영업이 고객을 설득시키는 논리에서 찾아볼 수 있다.
영업측면에서는 방대한 도메인과 3~4레벨에 해당하는 산출물과 프로세스가
'체계적이다. 상세한 수준에서도  Best practice가 준비되어 있다'는 논리가 설득에 편하다.

단기적으로는 영업에 성공되어 나이스지만
고객이 '정교한 관리가 최선'이란 관점에 빠져들게 될 경우
돌아가지 않는 관리체계를 강력하게 요구하게 되고 결국 구축결과는 '실패'로 빠져든다.
그리고 투자에 대한 성과없음은 고객과 수행사 모두에게 타격으로 돌아가게 된다.

많은 수행사례들 중에서 
초기에 구축된 많은 도메인과 정교한 관리체계를 까내지 않은 사례는 없었다.
추기 구축된 내용을 쳐내고 2차 3차 또는 고도화란 이름으로 SDLC일부에 집중하는게 대부분..
고객, 컨설턴트, 영업 모두 이러한 사례를 인지해서 잡질하지 않게 유의..


governance framework은 고객사에 맞추어 전반적으로 재검토 구축될 대상.
고객도 프로젝트에 참여해서 구축, 모니터링, 개선을 반복해야 하는데 기피하는 고객이 많다.

이러한 이유로
고객은 '보유한 framework로 단기간에 커스터마이즈..'란 요구를 할 텐데..
반드시 고객참여와 고객위주/주도가 되도록 하고
커스터마이즈로 갈 수 밖에 없는 경우 적어도 3~4사이클이 돌 때까지 
만들어 가는 경우 framework 구축 후 1~2사이클이 돌 때까지 모니터링 가능하도록 기간을 잡는다.

soa governance에 앞서 고객사 나름대로
architecture나 개발방법론이 어느정도 정리가 되어 이에 대해 주관이 서 있는 상태가 되어야 한다..
architecture governance가 선행되는 나름의 이유가 있는 것..

정책은 올바른 방향으로 '유도하기 위한 수단'으로 쓰여야 하고
프로세스는 정책이 '효율적으로 이행되도록 수행이전 또는 수행중' 단계로 끌어올 수 있도록 구성하고
조직은 팀단위 단계별 승인식 구성 대신 '일을 기준으로 협업 및 구성원 배정과 가이드가 이루어지는' 구성.
인프라는 PEM(Policy Enforcement Model)을 기준으로 구성(솔루션 및 자동화는 선택요소중 하나).
프로세스뷰를 정의/가시화하는 이유는 이를 기준으로 측정,모니터링을 통해 병목지점을 찾아 개선하기 위해..

고객과 소통가능한 목표이미지를 수립하고 시나리오를 흘려봄으로써
프로세스나 요건이 적절한지 확인하고 누락된 프로세스나 정책을 찾아볼 수 있다.
(도메인별 라이프사이클이 아닌 전체 흐름이란 관점하에 효율성,비용 체크하기
도메인 및 정책들간 연계필요성은 도메인에 빠져들 경우 쉬이 보이지 않기 마련임을 염두..

..(작성중)