EA & ISP 그리고 아키텍처

EA와 ISP를 통해 아키텍처를 고민한다면 개발부분까지도 고려해야 한다.
근 1년간 프로젝트를 하면서 항상 고민하는 부분이다.
플레닝 단계에서 레벨을 낮게 잡은 부분에 대해 개발업체는 항상 고민을 할 수 밖에 없다.
때문에 컨설팅을 하고 나면 개발업체/개발팀등등....는 무얼 해야 하는지 모르는 경우 태반....
그러다 보면 EA한 결과를 받아 들이고 싶지 않기에 또다른 플레닝을 하는 그런 모습들이 보인다.

이 갭을 채우려면 EA 컨설턴트는 낮은 단계까지 플레닝을 해야 하며 개발영역과 컨설팅 영역을 채우워야 하는 필요성이 생긴다. 그런데 상위레벨의 아키텍처와 구현레벨의 아키텍처의 갭을 메우기란 쉽지 않다.
EA는 Owner단계와 Planner단계에 집중을 하는 경우가 많고 Designer단계로 내려오면 설계부분에 대한 압박이 있기 때문이다. 디자인 단계까지 내려간다 하더라도 구현의 레벨로 들어서면 또 갭이 생긴다. 그러다 보면 의사결정을 위한 도구라는 냄새는 점점 사라지게 되는 것이다....이러한 이유로 EA는 실체가 없다는 말을 하는 사람들도 있었다.
그렇지만 상위단계의 플레닝이나 구도를 잡아주는 모습을 보여주는 역활로 본다면 아주 중요한 작업이지 않을 수 없다.

비지니스와 기술을 연결해주는게 아키텍트라면 이러한 단계를 연결해줘야 하는 사람은 누구인가? 아무도 없다???? T.T 결국은 아키텍트나 아키텍트 그룹이 이갭을 채워줘야 하는데
지금 내가 이 갭을 채우는 작업을 하고 있다. 서로 안하려고 발버둥 치는 경우도 있었다.

EA를 알아야 하며 이것을 분석하고 이것을 구현레벨까지 끌어내리는것이 나의 회사에서의 존재 목적인 것이다....
일을 하다 보면 상위레벨과 구현레벨의 차가 작지 않아 이러한 영역을 채우려면 많은 것을 알아야 한다. .....기술 , 디자인 말고도 알아야 할게 태반이다. 더군다나 아키텍트라면 코드레벨까지 알아야 한다. 이러한 경우라면 더더욱..... 뿐만아니라 EA의 상위레벨도 알아야 한다.
코딩을 직접 하지는 않더라도 상위레벨과 하위레벨을 연결하고 그들의 뷰로 설명을 할수 있는 문서와...언어등이 필요한것이다. 그냥 박스나 몇개 그리고 말꺼라면 또다시 그자리인것이다... 안하느니 못한 아키텍처정립인 것이다. 쯪....

게다가 상위레벨의 개념적인 생각들이 개발 영역으로 들어오면서 퇴색하는 경우도 있고 변경되는 경우도 있고..... 아키텍처에 대한 통합 관리가 필요한데 이러한것을 개발조직들은(현업은 다르다고 할수 있겠지만 전문지식성이 없기에 별 이견없음 ) 더군다나 알고 싶지 않아 한다. 이러한 것은 기업의 자산이 되는 경우가 많지만.... 별로 중요시 여기지 않는 경우가 태반.....

조직의 리더들이 생각하는 바가 많이 달라지는 경우도 있고....
심지어는 그들이 변절 ( ? ) 하는 경우도 있다. 그들의 생각이 서로 상충하여 조직에 분열이 생기는 경우도 있다.
어떻게 보면 기술때문에 생기는 문제도 문제이지만 사람때문에 생기는 문제가 더 많은 듯하기도 하고..... 거버넌스라는 말을 해야 하는 경우도 생기는 것이다.....

이러한 것이 내가 가지고 가야할 숙제... 인지도 모르지.... 음냐...뭐해먹고 살지 ??