소프트웨어 개발과 IT아키텍트의 미래 - ( 羽生田 栄一 )

번역 2009.10.11 12:22
 오랜만의 번역입니다. 자주 사서 보는 잡지중 하나인 IT 아키텍트가 이번호를 마지막으로 휴간하게 되었네요.
시중에 범람해있는 기술 테크닉서가 아닌 수준높은 내용이 담겨있어 재미있게 읽고 있었는데 아쉽게 되었습니다.

이번호 마지막 특집중 하나는 "지금부터의 IT아키텍트/개발자의 나아갈 길" 입니다.
휴간을 하는 잡지의 특집으로는 아이러니 하지만 유명한 여러 아키텍트의 견해가 담겨있어서 즐겁게 읽고있습니다.

 그 중 재미있게 읽은 하뉴다 에이이치씨(豆蔵 마메조 CTO)의 인터뷰를 번역해보았습니다.
혹 나중에 저작권에 문제가 되어 언제 삭제할지 모릅니다^^;






소프트웨어 개발의 복잡성을 4개의 부분으로 파악한다.

현대의 소프트웨어 개발은 다양한 "복잡성"을 안고있지만 , 그것을 큰 틀구조로 파악하면,
다음의 2항목을 기준선으로 4구역으로 나눌수가 있습니다.



세로축으로 소프트웨어 개발에 관한 요소를 [ 사물 , 사람]으로 표시, 가로축으로는 [소프트웨어 개발에 관한 문제가 그것의 문제인가 , 아니면 그 해결책인가]를 표시하는 문제해결의 축으로 두었습니다.

  이 두축으로부터, 4개의 구역이 만들어집니다.
첫번째 구역은 [설계/구축대상이되는 소프트웨어 시스템의 복잡성] , 
두번째 구역은 [업무영역과 문제공간의 복잡성],
세번째 구역은 [고객과 스테이크홀더, 및 개발자와의 커뮤니케이션의 복잡성] , 
네번째는 [소프트웨어 시스템을 만드는 개발팀 내부의 커뮤니케이션의 복잡성]을 표시하는 영역입니다.

 그리고 오늘날에는 이 4 영역에 잘 발란스를 주어 경영환경과 기술의 변동/진화에 더욱 기민히 대응하는 능력이 요구되기 때문에, 그것을 +1 로 그림의 중심부에 표시하고 있습니다.

 또, 소프트웨어 엔지니어링에 중요한 "4개의 P"로서 Product,Process,People,Project 를 말하고 있습니다.
그것들 각각은 위의 4 영역에 대한 것들이라고 생각할수 있습니다.

 각 영역에 요구되는 IT아키텍트의 역할

  아마도, IT아키텍트의 다수는 첫번째 구역의 [설계/구축대상이되는 소프트웨어 시스템의 복잡성] 만 주목하고 있습니다만, 앞으로는 클라우드 컴퓨팅등의 보급에 따라 , 이 영역의 중요한 부분의 다수는 캡슐화될것입니다.

 그러므로 , IT아키텍트의 역할은 , [최종적으로 세계에 몇회사 남는정도]라고도 할수있는 클라우드 인프라의 제공기업에 소속, 그 안에서 스케일아웃(scale out)하는 분산 병렬 아키텍쳐의 구조를 구측하는 [인프라 아키텍트]와 , 그것들의 환경을 제공하고 , 유저와 업무의 요구를 얼마나 적절한 서비스의 조합으로 현실화하는가를 생각하는 [서비스 아키텍트]로 2극화되지 않을까 라고 전 생각하고 있습니다.

 또, 네번째 구역의 [소프트웨어 시스템을 만드는 개발팀 내부의 커뮤니케이션의 복잡성]의 영역, 요컨데 개발프로젝트 관리의 영역에 관해서도 , 단순하게 PMBOK과 CMMI등의 지식을 베이스로 메니지먼트하면 끝날일이 아니게 됩니다. 여기서는 [고객에 있어 얼마나 가치가 있는 서비스를 기획/설계/실현/개량할것인가]라는 관점에서 PDCA사이클을 돌려 , 애자일형태의 메니지먼트를 수행할수 있는 사람이 인정받게 됩니다.

두번째 구역의 [업무영역과 문제공간의 복잡성]에 관해서도 , 클라우드 컴퓨팅과 연계, 모바일과 유비쿼터스의 기술과 조합된 업무와 밀착된 리치한 인터페이스, 문제영역의 의미를 적확히 모바일화하는 위에 온톨로지등의 룰를 베이스로 세련되게 서비스를 제공하는등 , 클라이언트 측의 정보를 잘 관리할수 있게 됩니다. 여기에서 활약하는 IT아키텍트는 , 현장과 업무의 니즈를 필드워크로 파악해 적확한 모델로의 형태를 내는 "필드 IT 아키텍트"로로도 불려질 존재일지도 모릅니다.

세번째 구역의 [고객과 스테이크홀더, 및 개발자와의 커뮤니케이션의 복잡성]에 대해서는 , 앞으로 여러 조직과 커뮤니티의 속한 다양한 클라이언트/스테이크홀더가 횡단적으로 관계하는 일이 늘어날것이라 생각됩니다. 따라서, 출신지와 이력, 인종등이 혼재한 멤버의 이해와 관심사를 잘 조정해 적확한 골을 설정해, 프로젝트로서 정리해가는 코라보레이션 형의 워크 스타일과 , 그 퍼실리테이션을 행하는 인재가 중요하게 될것입니다. 이것을 행할 IT아키텍트는 "프로듀서형의 IT아키텍트"로 불려질지도 모릅니다.

 4개의 영역의 무엇에 강한지에 따라  IT아키텍트의 개성이 나온다.

그리고 앞으로, 이 4개의 영역은 IT의 공공 인프라화의 진전에 따라서 점점 융합이 진행. 그러는와중 상황의 변화에 신속한 대응이라는 요구에 응하는 한편, 전체의 발란스를 생각해 [사물/사람],[문제/해결]의 사이를 브릿지해,IT의 유효성을 최대한으로 발휘할수있도록 일을 나누는 인재,즉 IT아키텍트의 필요성이 늘어날것입니다.

  아마도 , 이런 환경에서는 업무와 기술은 거의 모르는 관리 중심의 타입인 프로젝트 메니져가 활동하는 여지는 적어지게 됩니다. IT 아키텍트는 1,2구역을 중심으로 제품의 품질에 최종책임을 갖는 인재, 프로젝트 메니져는 3,4영역을 중심으로 프로젝트의 납기/코스트에 최종책임을 갖는 인재로 대략적인 구분을 남겨두고, 서로 경쟁하며 절차탁마해 나가게 됩니다. 그리고 각각의 IT아키텍트의 개성은, 4구역 안에서도 어느 영역의 스킬/경험이 보다 강하느냐에 따라 다양해지게됩니다.

 클라우드시대에 따른 IT인재의 활동영역

 클라우드 시대에있어, IT인재가 활약하는 장소는 , [클라우드의 이용국면] , [클라우드의 제공국면] , [현재시스템과 클라우드의 결합국면]이라고 하는 3개의 영역으로 나눠져 갈것입니다.
 언제가 되든 , [저코스트로 신속히 아이디어를 형태로 만드는 수단]으로서 사용되는 것이 클라우드의 유효성을 가장 살리는 활용법으로 존재, 이것은 클라우드와 애자일한 경영/애자일 개발의 친화성이 높음을 의미합니다.

 앞으로는 경영자도 프로젝트 메니져도 ,[업무와 IT],[아이디어와 실현수단]의 양방에 관해, PDCA사이클을 돌리며 가설검증형으로 스피디하게 기획/실시해 가는 것 뿐의 기량이 요구됩니다. 그리고 , 그활동을 지지하는 IT아키텍트,IT인재는 다음의 세가지 영역에 따른 활동의 중심이 되어, 유저와 경영자에게 비지니스 가치를 가져오지않으면 안됩니다.

-언제라도/어디서라도 , 현장에서 쾌적한 환경을 제공한다.
-"비지니스상의 효과의 애자일한 검증"이라고 하는 PDCA사이클을 돌리며, 서비스의 기획/설계/개발을 행함.
-효율성/신뢰성/스케일아웃의 요건을 만족,SLA를 담보가능한 인프라 아키텍쳐를 제공한다

반대로, 이런 것이 가능하지 않으면, IT아키텍트라고 해도 단순한 코스트경쟁으로부터 벗어나는것은 어려워 IT프로페셔널로서 살아가는 길은 닫혀져 버릴 가능성이 있습니다.
 지금의 IT는 "경영의 무기"로 존재합니다.
IT아키텍트를 시작하는 IT인재는, 지금보다도 , 더욱 경영과 업무에 함께해 활동하는 스탠스로 바꾸어 나가지 않으면 안됩니다.



Trackbacks 0 : Comments 2