서비스 지향(SO)은 IT (서비스) 딜리버리 모델의 관점에서 보았을 때 하나의 근본적으로 전환점이라고 할 수 있다. 즉, IT 딜리버리 방식을 비즈니스 프로세스에 일치시킴으로써, 비즈니스와 IT 사이의 협업관계를 크게 증진시켰다. 서비스지향아키텍쳐(SOA)로 이동 중인 애플리케이션 개발 업체들은 종종  기술에만 너무 집중하다가, 결국 SOA가 사람/프로세스/기술 삼각형의 (기술 이외의) 다른 두 부분에도 영향을 끼친다는 것을 발견하게 된다. 이러한 전환으로 인해, 각 업체의 IT 및 비즈니스 인력이 담당하고 있는 역할들은 변화를 겪게 된다. 이러한 역할 변화로 인해서 새로운 업무가 생기는 경우가 있는데 반해, 기존 직원들의 업무 범위가 단순 조정되는 경우도 있다. 서비스 개발자/디자이너/테스터 등과 같은 SOA 관련 역할들은 새로운 기술을 기존의 업무에 접목하게 된다. 비즈니스 서비스 주창자 (BSCs) 등과 같은 경우, 서비스 모델 주변의 애플리케이션 딜리버리 방식을 재조정 할 정도의 더욱 근본적인 변화, 즉 서비스지향 IT (SO-IT) 조직을 창조하게 된다.

서비스지향(SO) 시스템을 통한 비즈니스 개선

향후 수년간, SO를 지향하는 기업들은 엄청난 수익과 함께 아래와 같은 중대한 변화를 겪게 될 것이다;

• 서비스 딜리버리 기능의 중심에 IT 배치. 비즈니스 업무조직의 집합체로서, 서비스는 비즈니스의 디지털 모델을 창조하고, IT를 통해 실현 가능한 가장 중요한 아웃풋이 된다(후주 1 참조)
• 비즈니스 측과 더욱 긴밀한 결속 추진. 서비스를 제대로 디자인 하기 위해서는, IT를 기술 중심의 디자인이 아닌, 비즈니스 프로세스 중심의 디자인으로 전환할 필요가 있다. 이러한 전환을 통해, IT는 비즈니스와 더욱 밀접하게 결속될 수 있는 힘을 얻게 된다.(후주 2 참조)
• 비즈니스 측이 이해하는 수준에서의 비즈니스 딜리버리 수행. SO 모델에서, 비즈니스 유저들과 IT 측은, 새로운 시스템에 필요한 요구사항들을 개발하면서 거의 최초로 같은 수준의 입자성(granularity)을 가지며 협업을 수행하게 된다. 비즈니스 유저들은, 서비스를 비즈니스 프로세스의 각 단계에 적용하기 위해 디자인된, 상호 연관된 비즈니스 기능들의 집합체로 볼 수 있다. IT는 기획 및 수행을 같은 서비스에 결합시킨다. 이러한 공통의 언어를 통해서, IT 기술을 통한 시도가 비즈니스 프로세스로부터의 요구와 적절하게 조화되고, 결국 IT 및 비즈니스 양 측 간의  커뮤니케이션이 개선된다.
• 실질적 재활용의 증진.  다수의 애플리케이션을 계층화된 비즈니스 작업 단위로 패키지화 함으로써, 서비스의 디자인을 제대로 수행할 경우, 이전의 개발 모델들이 말로만 약속했던 비즈니스 로직의 재활용을 성공적으로 실현할 수 있다는 것을 아래의 기업들이 증명해 보였다; Allstate Insurance, Con-Way Transportation Services, Sabre, The Standard Life Assurance Group, Verizon 등 다수.
• 신규 애플리케이션의 신속한 조립 가능. 미리 제작된 기능(서비스) 풀(pool)을 활용할 경우, 뚜렷한 목적을 가진 신규 애플리케이션을 저렴하면서도 용이하게 제작할 수 있으며, 많은 경우 기존의 서비스를 새로운 액세스 채널을 통해 노출시키게 된다 (예: Allstate사의 음성 인식 포탈, Miami-Dade County의 무선 빌딩 인스펙션 애플리케이션 등) (후주 3 참조)

SO를 향한 진화의 일부분으로, 애플리케이션 딜리버리 기업들은 사업체와의 관계뿐만 아니라, 프로세스와 직위의 역할도 발전시켜야 한다. 서비스 분석에는 비즈니스 프로세스와의 강력한 연결이 요구된다.  서비스 디자인의 컨셉은 기존의 분산 및 레거시 애플리케이션이 가진 디자인 컨셉과는 상이하다. 애플리케이션 개발 기업들은, 적절한 작업 수행 뿐만 아니라, 주변에서 기대하는 양질의 서비스(QoS)를 제공할 수 있는 서비스 시스템을 구축함으로써, 적응해 나가야만 한다 (강력한 비즈니스와 SO 디자인, 그리고 신규 기술이 성공을 위한 선결조건임)

비즈니스 측과의 관계 강화를 통한 새로운 역할

서비스 지향 접근방법을 통한 개발은 새로운 행태를 낳는다 ? IT와 비즈니스 측 인력들의 전통적인 역할에 변화 발생. Forrester는 오늘날 많은 기업에서 이러한 변화의 초기 징후를 발견하고 있다. 즉, 서비스 지향 시스템 도입의 초기단계에 있는 기업은, 새로운 SO 역할을 기존의 역할에 접목시키면서 일종의 ‘하이브리드’를 창조하고 있다. 이 하이브리드 역할은, 회사의 SO-IT 시스템이 더욱 성숙하게 되면, 점점 사라지게 되고, 대신 새롭고 공식화된 직위 및 그에 부합되는 업무내용(Job Description)이 나오게 된다. 새로운 직종의 출현 여부 및 시기는 조직의 규모에 따라 달라진다. 전문화된 역할과 자리를 새로이 만들 수 있는 충분한 자원을 가진 대기업은, 개인이 그 직위에서 수행하게 될 전문화된 업무의 양 때문에, 신속하게 실행에 옮기게 된다. 반면, 소규모의 회사들은 새로운 자리를 만드는 데 다소 시간이 걸린다. 그 대신, 다수의 역할을 하나의 자리로 통합하게 되며, 따라서 (전문적이기 보다는) 다소 일반적인 성격의 자리를 만들게 된다. 

다음 챕터들에서는, 서비스 지향 생명주기에서 나타나는 핵심 역할들과 이들의 예상 업무를 설명토록 하겠다. (그림 1 참조)

그림 1 SOA Roles Within The Service Delivery Life Cycle 

비즈니스 - IT 간 만남을 주도하는 비즈니스 서비스 주창자들(BSCs)

BSC(비즈니스 서비스 주창자)는 서비스지향IT(SO-IT)를 향한 변환에서 핵심적을 역할을 담당한다. 비즈니스 프로세스와 IT 기술에 모두 능숙하여, 비즈니스와 IT 양측 모두로부터 신뢰를 받고 있는 BSC들은, 비즈니스와 IT 양 측이 비즈니스 프로세스 문제에 함께 주력하여, 문제 해결을 위한 서비스 및 솔루션을 도출할 수 있는 환경을 조성한다. 예를 들어, Wachovia의 IT 그룹에는, 사업체와의 IT 협력 관계를, 협업 비즈니스 디자인으로 발전시킬 정도의 모기지론 가입 프로세스에 관한 상당한 지식을 갖춘 설계자가 있다. 이 IT 설계자는 비즈니스 프로세스 상의 문제점을 인식하고, 이 문제점을 해결하는데 필요한 IT 및 비즈니스 시스템 상의 변화를 기획하여, 주도할 만한 신뢰성을 확보하고 있다. BSC들에게는, 탁월한 커뮤니케이션 능력과 비즈니스 프로세스에 관한 이해, 개념적인 사고 방식, 신속한 학습 능력, 다양한 그룹의 사람들과의 네트워킹 능력, 그리고 자신의 기회를 스스로 개척할 수 있는 능력이 요구된다.

유력한 BSC 후보자들은 주로 다음의 세가지 유형이다. IT를 잘 아는 사업부서 부서장들, 기능적 지식이 풍부한 IT 부서 장기 근무자, 그리고 외부 컨설턴트 등 이다. 이들은 자신들의 광범위한 경험을 활용하여, 서비스 딜리버리 팀의 기능적, 기술적 측면에 관한 아이디어들을 연구한다. BSC의 핵심 업무는 아래와 같다;

• 비즈니스와 IT 양측간 협업 강화. BSC들은 IT 인력들이 프로젝트의 사업적 의미와 전략을 이해하고, 동시에 비즈니스 인력들이 서비스 지향아키텍쳐(SOA)의 핵심컨셉과 전략을 이해하도록 해야 한다. BSC들은 신규 사업 아이디어를 도입하고 주창할 정도의 깊은 사업적 지식과, 디자인, 테스팅 및 재활용의 기획업무를 지원할 정도의 기술적 역량을 보유하고 있다. Wachovia의 설계자 처럼, BSC들은 전문가로서의 자신의 역량을 활용함으로써, 문제에 대한 해결책을 개발하고, 이를 비즈니스 및 IT 양측 모두에 설득해야 한다. BSC들은 장기적인 전략적 변화의 관점 속에서 단기적인 비즈니스 개선을 주도해 나가야 한다.
• 비즈니스적 시각과 IT 아키텍쳐 시각을 연동. 프로젝트에서, BSC는 비즈니스와 IT 각각의 관점을 함께 묶어주는 접착제의 역할을 한다. 비즈니스측과 IT 측의 목표가 상호 충돌할 때, BSC들은 비즈니스 및 IT 양측 모두에 걸쳐 있는 요구사항과 문제점들을 번역하여, 사업상의 이점을 그대로 유지하면서도, 여전히 SOA로의 변환을 추진할 수 있는 해결책을 개발할 수 있도록 주도한다.(후주 4 참조)
• 서비스 인터페이스의 디자인, 설치 및 관리를 촉진. 서비스 인터페이스 디자인은 서비스 딜리버리에 있어서 가장 중요한 부분이다. 따라서, BSC들은 디자인 작업이 제대로 수행될 수 있도록 하기 위해 기능 및 기술 팀 인력들과의 협력을 통해 업무를 수행한다. 서비스 인터페이스 디자인은 기능적 요구사항 및 인터페이스 시맨틱스(symantics) 외에도, 보안, 가용성, 응답시간 등의 서비스품질(QoS) 관련 요구사항도 함께 다루고, 기록해야 한다. BSC는, 다수의 프로젝트 및 비즈니스 단위들에 걸쳐 있는 서비스 인터페이스 디자인을 검토 및 네고하는 서비스 관리 프로세스에도 관여한다.

비즈니스의 요구사항들이 충분히 만족될 수 있도록 확인하는 비즈니스 서비스 애널리스트

BSA 업무는 시스템 애널리스트가 수행하는 업무와 유사하다고 할 수 있다. BSA는 서비스에 요구되는 사항들을 파악하기 위해, 비즈니스 프로세스 및 관련 문제들을 명확히 이해해야 한다. BSA는 탁월한 커뮤니케이션 능력과 함께, 비즈니스 프로세스에 관한 명확한 이해 및 신속한 학습능력을 보유하고 있어야 한다. BSA는 일반적으로 비즈니스 인력으로부터 충원되지만, 비즈니스를 잘 아는 기술직 인력도, 업무 수행이 가능하다.

사업단(business unit) 근무자, 충분한 기능적 지식을 갖춘 오랜 경력의 IT 인력, 또는 외부 컨설턴트가 BSA 후보자가 될 수 있다. 입사 후 배치된 부서에서 충분한 경험을 배양한 장기 근속 사원들도 좋은 후보자들이다. 회사내 여러 사업단을 경험했다면, 넓은 시각을 통해 BSA 업무를 더욱 효과적으로 수행할 수 있을 것이다. 현재 근무중인 회사에서 배양한 깊은 업무지식과 타사에서의 경험을 함께 지닌 BSA는 훨씬 폭 넓은 경험을 제공할 수 있다. 여러 회사를 경험하는 것이 필수사항은 아니지만, 이를 통해 한 회사 내에서 생길 수 있는 근시안적인 시각과 이에 따른 단순한 서비스 디자인을 미연에 방지할 수 있다. BSA의 핵심업무는 아래와 같다.

• 비즈니스 문제에 관한 전문가, 그리고 변화의 주창자가 되라. BSA는 비즈니스 프로세스를 항상 심도 깊게 이해하고 있어야 한다. BSA들은 변화의 동인을 이해하고, 해결책을 시각화하며, 제기된 변화의 효율성을 증명(또는 부인) 할 수 있는 핵심 메트릭스를 찾아 낼 수 있어야 한다. BSA는 IT 관련 아웃풋을, 고객, 공급자, 파트너, 규정자, 심지어 투자자를 포함한 가치사슬(value chain)의 시각에서 볼 수 있어야 한다. 단기적인 관점에서의 비즈니스 개선도 중요하지만, BSA는 단기적 개선사항들을 장기적인 전략적 변화에 맞춰 나갈 수 있는 비전도 함께 보유하고 있어야 한다.
• IT에 대한 비즈니스 측의 요구사항을 대변. 비즈니스 개선을 위한 아이디어가 생산되어, 하나의 프로젝트가 되면, BSA들은 비즈니스 측의 시각을 지속적으로 대변한다. BSA들은 기능적 요구사항들을 수집, 분석 그리고 문서화하는 작업을 주도한다. 이들은, IT 측이 제안된 변화가 비즈니스에서 갖는 의미를 이해할 수 있도록 지원한다. BSA들은, 비즈니스 측이 프로세스 변화를 적절하게 기획하고, 변화가 비즈니스에 끼치는 영향을 모니터 할 수 있도록 한다. BSA들은 비즈니스 측의 이해관계를 대변하는 권한을 부여받았다고 할 수 있으나, 중요한 결정은 프로젝트 스폰서에게 맡기는 것이 일반적이다. Agile 개발 서클에서, BSA는 Agile 개발팀에 대해 고객의 대변자 역할을 수행한다.
• 서비스 요구사항들의 이행 상황을 감독. BSA들은 프로젝트 매니저들과의 협력을 통해서, 프로세스 디자인에서 테스팅에 이르는 기능적 요구사항들이 지속적으로 다뤄질 수 있도록 한다. 이것은 애플리케이션 생명주기 관리(ALM) 솔루션 벤더들이 공언하는 지속성과 유사한 것이다. 프로세스 모델과 사용 케이스를 통해, 서비스 인터페이스 디자인을 위한 배경을 구성되는데, 이 때문에 이들은 BSA들이 관심을 가지는 두가지 핵심 아웃풋이다.
• 애플리케이션간 서비스 디자인, 검토, 그리고 재활용의 지원. BSA들은, 일련의 서비스들이 프로젝트에 독립적으로 사용될 수 있도록 하기 위해, 애플리케이션간 모델링 및 디자인 검토 미팅에 다른 BSA들과 함께 참석한다. 예를 들어 Verizon은, 자사가 향후 사용할 서비스들을 디자인 하는 경우, 사업 부문 및 직종 간에 서비스 디자인 관련 미팅을 다수 시행함으로써, 서비스 인터페이스 및 양질의 서비스(QoS) 이행에 관한 의견을 조율한다. Sabre는 모든 신규 서비스 인터페이스 디자인을 검토하는 “아키텍쳐 검토 위원회”를 운영하고 있다.  

서비스를 현실화 시키는 서비스 디자이너/개발자

서비스 디자이너/개발자들은, 기능적 디자인과 기술적 작업을 완결함으로써, 서비스들이 현실세계에서 요구되는 양질의 서비스를 제공할 수 있도록 한다. 이 업무를 각각 분리하여 수행하는 회사들이 있을 수는 있다. 하지만, 서비스 디자이너/개발자들은 서비스의 기능적 디자인을 조율하여, 업무수행, 가용성, 확장성, 회복성 등의 각종 기술적 요구사항들을 만족시킬 수 있어야 하기 때문에, 반드시 경험이 풍부한 인물이어야 한다. 서비스 디자이너/개발자들은, 완성된 버전의 서비스 인터페이스 디자인이, 같은 기능을 불러올 필요가 모든 애플리케이션들에서 유용하게 사용될 수 있도록 해야 한다. 핵심 업무는 아래와 같다;

• 비즈니스 프로세스를 운용가능한 서비스 디자인으로 변환. 디자이너/ 개발자들은 비즈니스 프로세스를 해석하고, 이에 따른 기능적 요구사항을 이해하기 위해, BSA들과 협력한다. 서비스 디자이너/ 개발자들은 서비스 스펙의 분석, 모델링, 디자인 작업을 수행하고, 이후 반복적인 다듬기에 들어간다. 기존의 애플리케이션들이 비즈니스 트랜젝션의 소스가 되는 경우, 윗 작업을 수행하기 위해서는 이들 애플리케이션들을 먼저 이해할 필요가 있다. 레거시 트랜젝션이 서비스가 되는 것이 좋은 예라 할 수 있는데, 이러한 작업에는, 관련 애플리케이션 플랫폼과 통합 플랫폼, 그리고 커뮤니케이션 프로토콜의 역량과 한계를 기술적으로 이해하는 것이 필요하다.
• 서비스 개발 및 유닛 테스트. 정해진 개발 프로세스 이후, 디자이너/개발자들은 디자인 스펙에 맞는 소스코드를 작성한다. 소스코드에는 프로그래밍 언어코드(Java C#(C Sharp)), VB.NET), XML 스키마 정의, WSDL, 및 기타 언어들이 포함된다. 서비스 디자이너/개발자들은 비즈니스 프로세스 통합 플로우, 설치 디스크립터, 보안정책, 관리정책 등을 두루 잘 알고 있다. 디자이너/개발자들은 레거시 트랜젝션을 개발하거나, 이들을 개발하기 위한 툴을 가지고 작업한다. 디자이너/개발자들은 인터페이스에 대한 서비스의 무결성을 확인하고, 작업단위별 기능을 점검하며, 기술문서 표준에 따라 문서작업을 수행한다. 테스트 위주의 개발이 도래함에 따라, Agile 개발자들과 서비스 개발자들은 기존의 생명주기보다 훨씬 빠르고, 반복적으로 테스트를 수행하게 되었다.
• 디자인 패턴을 개선하기 위해 서비스 설계자들과 협력. 디자이너/ 개발자들은 서비스 품질(QoS) 기준을 제정함으로써, 각각의 서비스들이 QoS 기준에 부합되는 지를 증명하고, 서비스 설계자들이 정의한 패턴을 활용하며(서비스 설계자 편 참조), 그리고 내부적 재활용을 위해 요구되는 반복가능한 프로세스 및 베스트 프랙티스를 확보하기 위해 협력한다.

기존 서비스들로부터 다채널 애플리케이션을 구축하는 서비스 어셈블러들

서비스지향IT(SO-IT) 시스템에서, 서비스는 비즈니스 트랜젝션이 수행 되었음을, 그리고 채널은 이 트랜젝션들의 전달 방식(예: 웹 애플리케이션, 무선 장치, 대화신 음성 응답 시스템, 판매시점 시스템 등)을 나타낸다. 2005년 경, SO-IT 시스템을 지향하는 대부분의 기업들은, 애플리케이션들이 기존의 서비스들로부터 전체 또는 일부분 조립될 수 있을 정도의 인벤토리를 개발하게 될 것이다. 현재에는, 얼리 어답터들이 이러한 경향을 실재로 보여주고 있다 ? Miami-Dade County의 경우, 자사의 기존 서비스를 재활용 하는 비율이 20%에 달하고 있다. Standard Life는 자사의 신규 프로젝트가 필요로 하는 서비스들 중, 약 75%를 이미 자사가 보유하고 있는 상황에 빈번하게 맞닥뜨리고 있다. 이러한 경향으로 인해 “서비스 어셈블러”라는 신종 업무가 태어났다.

서비스 어셈블러들은 서비스를 재활용한다 ? 서비스 어셈블러들은 서비스들을 정의하거나 구축하지 않는다. 서비스 어셈블러들은 기 구축된 서비스 라이브러리로부터 서비스를 끌어내어, 필요한 유저 인터페이스와 통합 포인트를 구축함으로써, 물리적 세계의 비즈니스 프로세스를 요구하는 서비스로 연결시켜 준다.  직업적 경력의 관점에서 보았을 때, 서비스 어셈블러는 신참 개발자나 신입 프로그래머들, 즉, 서비스 디자이너/개발자 보다는 기술적 경험이 일천한 개발자 들이다. 이들은 SOAP와 기타 메세징 프로토콜들, 뿐만 아니라 스크립팅 언어와 다중 접근 채널을 위한 기타 툴들도 능숙하게 다룰 수 있다. 서비스 어셈블러의 업무는 레거시 프로그래머가 되기 위한 경로일 수도 있다. 즉 서비스 어셈블러들은 이 업무를 통해 분산시스템 세계나 서비스지향 개발 모델로 천천히 이동해갈 수 있다. 핵심 업무내용은 아래와 같다;

• 서비스들을 물리적 비즈니스 프로세스로 연결. 서비스 어셈블러들은, 여러 형태의 유저 인터페이스와 채널로부터 서비스를 불러오는데 필요한 스크립팅 언어와 전통적인 프로그래밍 언어를 채용한다. 서비스 디자이너/개발자들이 비즈니스 규칙을 파악하여, 이들을 서비스로 묶어 내는 작업에 주력하는데 반해, 서비스 어셈블러들은 서비스 요청에 필요한 데이터를 수집하여, 요청을 접수하고, 그 결과를 사용자들에게 보여주는데 주력한다.
• 인터페이스가 비즈니스 프로세스의 요구사항을 충분히 만족시킬 수 있도록 확인. 비즈니스 프로세스가 고려될 때, 최적의 서비스가 디자인 될 수 있다는 사실은, 서비스에 대한 액세스 채널에도 그대로 적용된다. 서비스 어셈블러들은, 인터페이스 또는 액세스 채널의 디자인이, 사용자들의 요구사항을 충분히 반영할 수 있도록 하기 위해서, BSCs와 BSAs로부터 지시를 받는다. 여기에는, 인터페이스 프로토타이핑, 사용성 테스팅, 그리고 사용자 선호도 테스팅 등이 포함된다.

서비스 어셈블러들은, 현장학습(OJT)의 일환으로 더 높은 단계의 업무를 맡을 수도 있다. 예를 들어, 어셈블러들은 다수의 플랫폼에 기반한 서비스들을 하나의 스크린으로 통합해야 하는 복잡한 인콰이어리(문의) 애플리케이션을 구축할 수도 있다. 서비스 어셈블러들은 복잡한 DB의 체크포인트 이벤트나 리커버리 작업을, 서비스 디자이너/개발자의 감독 아래 수행할 수도 있다. 서비스 어셈블러들은 디자이너/개발자들이 구축한 서비스들을 유닛 테스트 하기 위해 서비스-인터페이스 테스트 장치를 구축할 수 있다. 사용자 인터페이스가 복잡해지면서, 대화형 플랫폼 기능이 요구됨에 따라, 서비스 어셈블러의 업무내에서도 경력 개발을 할 수 있는 좋은 기회가 점점 증가하고 있다. (후주 5 참조)

서비스 기능이 적절한가 그리고 그 이상인가를 증명하는 서비스 테스트

테스트 역할은 SO-IT에서 부수적인 조직 변화를 보게 되게 될 것이다.  서비스는 서비스 인터페이스 레벨로 테스트되어야만 하는데, 즉 최소한 접근 채널 당 하나씩의 서비스 인터페이스 테스트 장비 시리즈 개발을 요구한다.  뿐만 아니라, 서비스테스트는 공유 자원으로써의 서비스 테스트가 갖는 난제를 설명할 수 있어야 한다.  SO 개발에 특수한 책임을 갖는 핵심 테스트는 다음을 수행해야 한다.

• 정확한 서비스 기능 운영을 보장해야 한다.  애플리케이션이 사양에 따라 기능하는 전체로써 중요성을 갖는 반면, SO-IT의 재사용이 함축될 때 각각의 개발적 서비스가 정확하게 실행되는 것은 훨씬 더 중요하게 된다.  서비스 테스트는, 유저가 서비스 데이터를 포맷하는 방식과, 서비스가 어떤 것이든 조절할 수 있도록 보장될 것을 요구하는 방식을 여러가지로 복제할 수 있을만큼 창의적이어야 한다.
• 서비스에 관해 적절한 QoS를 보장해야 한다.  각각의 서비스는 QoS에 관해 정의된 매개변수 내에서 운영되어야 하며, 서비스 테스트는 서비스가 적절한 반응 시간을 제공하며 그 외 QoS 요구조건을 만족시킨다는 것을 증명하는 테스트로 사용하여 기능적인 테스팅 계획을 보조해야만 한다.
• 복잡하고 공유된 테스트 환경을 관할 하라.  재사용이 가능한 서비스는, 개별 비즈니스 기능에 대한 요구 위에서 테스트 환경을 재창조고자 하는 테스터의 니즈를 창출하게 된다.  테스트 행정가의 역할이 형식화되지않으면, 자동화 부족에 따라 테스트 진행에 심각한 방해를 받게 될 것이다.  즉, 테스터는 깨끗한 테스트환경을 만들고, 조직 내에서 다른 플랫폼 위에서 가능한 서비스 환경을 복제하거나 혹은 emulating하기 위해 테스터는 엄청난 시간을 소비해야 할 것이다.  외부 사용을 위해 서비스가 노출될 때, 테스트실행자 역할의 복잡함은 엄청난 양의 지시에 의해서 잠재적으로 가중되는데 특히 외부 비즈니스 파트너를 위한 테스트 환경을 지원하고자하는 니즈를 고려할 경우 더욱 심해 질 것이다.

SO-IT 테스트는 인프라스트럭춰, 네트워크, 데이터베이스 및 다양한 서비스에 대한 다중 채널 접근을 충분히 테스트할 그 외 IT 그룹에 대한 구성화 노력을 하도록 할 것이다.

서비스 라이브러리안이란 서비스 저장소를 유지하는 사람들을 말한다

서비스 라이브러리안이란, 조직의 서비스 메타데이타를 지키는 사람으로서, 재사용 저장소(컴포넌트 자산 저장소와 같은)을 활용하며, 서비스 적절한 메타데이타를 이용하여 서비스 메타데이타를 확장시키고 이러한 능력을 조사하는 이들이다.  이들은 인프라스트럭춰를 사용하고, 서비스를 트랙킹하는데 필요한 툴 및 서비스와 연계된 메타데이타를 관리한다.  사서는 저장소를 대중화하는데 필요한 조직 훈련을 개발하고 대규모로 강제화할 수 있도록 지원해야 한다.  이 프로세스는 반드시 재사용을 독려하는 것이어야 하며, 새로운 서비스에 설계 혹은 개발 노력을 들이기 전에 프로젝트 팀이 저장소 스캔을 용이하게 함으로써, 과잉되는 서비스 창출을 막아야 한다.(후주6 참조)  앞서 목표지향(Object-Oriented, OO)에서 증명되었듯이, 만일 저장소가 어설프게 기능한다면, 좋은 의도를 가진 개발자를 좌절시킬 것이고, 이 결과 과도하게 범람하는 서비스 라이브러리를 만들어 낼 것이다(후주7참조)  서비스 라이브러리안의 핵심 임무는 다음과 같다.

• 서비스 레퍼지토리 툴과 접근 인터페이스를 충족시키고 유지하기
• 기업의 정책과 표준을 제정할 수 있도록 서비스관련 출판에 관해 컨센서스를 구축하기
• 저장소에 서비스 관련 출판에 관해 기존 정책과 표준을 강행하기
• 서비스 생산자와 소비자 간에 커뮤니케이션을 지지하기
• 서비스 사용 및 재사용을 모니터링할 수 있는 메커니즘을 개발하기.  자동화된 툴은 메트릭스 상에서 효과적인 분석과 보고취합을 제공할 것이지만, 이보다는 수동의 메커니즘과 프로세스가 ROI에 대한 평가를 개발할 것이다(후주8참조)

서비스 아키텍춰는 기술 기반을 제공한다

포레스터의 SOA 정의에 의하면, 애플리케이션 설계와 소프트웨어 인프라스트럭춰 설계 양쪽을 다 포함한다(미주 9).  하지만 이 둘 중에서 애플리케이션 설계에 주로 주력하는 반면, 서비스 설계사는 SOA와 SOA 플랫폼에 대한 미래 전략을 관리하고 소프트웨어와 하드웨어 인프라스트럭춰 설계 전체로부터 출발한다.   SOA플랫폼을 최상으로 사용할 수 있도록 서비스 설계-개발자를 가이드하기위해, 서비스 설계사는 정교한 서비스 디자인 플랫폼을 개발하게 된다.  BSCs와 협력하여, 서비스에 관한 비젼과 전략을 세우며, SOA 활용을 강화할 수 있도록 앞장선다.  핵심 임무는 다음을 포함한다.

• SOA와 SOA플랫폼에 관한 목표 비젼을 개발하고 유지하기
• 현재의 애플리케이션 플랫폼에서 미래 SOA플랫폼으로 이동할 수 있도록 진화적 계획을 수립하기
• 그리고 SOA플랫폼 속으로 통합될 것을 결정하는 서비스 디자이너-개발자와 새로운 SOA플랫폼, 기술 파트너쉽 형성 등에 관해 학습하기
• 서비스에 관한 인프라스트럭춰와 아키텍춰로 모든 기술적 이슈들을 이해하고 해결하기
• 비즈니스 서비스를 지원하는 인프라스트럭춰 서비스를 정의하기
• 지원되는 애플리케이션 기술 환경에 대응하는 서비스 수행 패턴을 정의하기
• 서비스처럼 레가시 처리를 커버할 전략과 수용가능한 기술을 설계하기 그리고 포장이 적절한 솔루션인 때와 더 강력한 기술이 보장되는 때에 관한 역치를 설정하기
• 전략적 취지로서 SOA 수행을 용이하게 하기
• 서비스를 수행하는 로컬 프로젝트 팀에게 기술적, 설계관련 조언하기
• 산업계 및 학계로부터 SOA 전략을 주기적으로 업데이트하기

새로운 역할은 조직 위계에 영향을 준다

어떤 역할들은 전통적인 조직 위계 내에 남아있는 반면, 다른 역할들은 새롭고 독립적 그룹을 생성하고 전통적인 보고구조를 변화시키는 기회를 갖게 된다. BSA그룹이 그 예이다.  기초 지식에 기반한 IT 부서 혹은 영역에 BSA를 배당함에 따른 유익이 있지만, BSA가 협력이 더욱 어렵게 하고 현지화된 사고를 조장할 수도 있다.  대안으로, BSA는 보다 새로운 전략적 시각을 가지고 관련 그룹 안에 보고할 수 있다.  말하자면, 프로젝트 관리 오피스 혹은 그 외 엔터프라이즈규모의 통제 메커니즘이 그것이다.

또 다른 예는 데이터베이스 조직이다.  자체 관리, 경력 경로 및 목적을 구비한 별도의 데이터베이스 관리자(DBA) 조직을 생성하여, 데이터베이스 자산관리에 충분한 관심이 보장되도록 하고, 애플리케이션 프로젝트목표에 부수적인 것이 되지 않도록 보장하게 된다.  그러나 가장 성공적인 DBAs는, 프로젝트 기간동안 점선으로 할당된 개발팀원처럼 작업하는 이들이라고 할 수 있다.  BSA에 대해 사용되었던 유사한 접근이 좋은 모델이다.

RECOMMENDATIONS

SO가 요구하는 변화에 대비하라

장기적인 SO 성공없이도 초기 서비스제공노력은 성공적일 수 있지만, 장기적인 SO가 성공하기 위해서는 재사고하는 역할, 임무 및 조직적 구조가 필요하다.  대부분의 조직은 성장의 아픔, 붕괴를 피하고 적극적인 변화를 위한 선택을 해야만 한다.  SO-IT에 대한 역할 변화라는 면에서, 조직은 SO의 임팩트를 분석해야 하며, 조직적 변화의 시기를 결정해야 하며, 성공적인 SO프로젝트를 통해 새로운 역할과 프로세스를 용이하게 해야한다.  조직이 반드시 해야하는 것은 다음과 같다.

• 서비스 제공 라이프싸이클을 우선 이해하라.  SO는 개발에 있어 새로운 업무를 도입하는데, 이 중 첫번째가 비즈니스 프로세스 설계 맥락 내에서의 서비스 설계이다.  새로운 활동에 필요한 역할을 이해하라
• 현행 역할, 포지션 및 기술 수준을 정의하라.  진부한 조언으로 보이지만, 의미있는 출발점이 될 수 있도록 현행 조직 구조에 현행 역할을 도식화 하라.  기존 직원의 타고난 기술의 인벤토리를 구축하라.  요구되는 SO-IT에 대한 이해의 결과와 그 차이를 정의하는 기술을  비교하라
• 조직의 성향을 추가하라.  IT 직원 규모에 의존하기 때문에, 예를 들면, 서비스 설계-개발자와 서비스 어셈블러의 역할을 구분할 수도 구분하지않을 수도 있다.   그러나, 이들 역할을 구분하는 것은, 기존 개발자 일부가 그 역할을 수행하기 위해 필요한 기술을 구비하고 있는지 융통성있게 고려해 보도록 하는 것이다.  이러한 관찰을 위해 기술 부족을 보완할 수 있도록 훈련 과정을 이끌어 낼 수 있고 또한 조언하는 과제를 위해 비숙련자와 숙련자를 파트너로 작업시킬 수 있다.
• 지금 바로 시작하라. 타이밍이 모든 것을 결정한다. SO 변화는 실제적으로 모든 IT조직에게 현실이 되고 있다.  보다 현명한 조직의 선택은 오늘 그 변화를 적극적으로 대처하기 시작할 것이다.

ENDNOTES

1. 서비스로 이뤄진 비즈니스의 디지털 모델이 가중되는 비즈니스 변화에 보다 잘 순응할 수 있기 때문에, 지속적인 비즈니스 최적화를 지원할 수 있도록 IT 능력을 구조개편하는 것이 SO의 목표이다.

2. 핵심 서비스 설계 원칙 중 하나는 비즈니스 프로세스 맥락에서 설계하는 것이다.

3. Allstate 보험사는 3년 전 보험설계사를 위한 포털을 가동했다.  올해는 음성에 의해 가동되는 전화 인터페이스를 추가하여 포탈내 서비스를 재사용하고 새롭게 패키지했다.   플로리다의 마이아미 데이드카운티는 기존 60개 레가시 트랜젝션 서비스보다 더 성공적으로 렙하였다.  그 한 예는, 휴대용 노트북에 실시간으로 빌딩 건축 허용 검사와 승인을 할 수 있는 빌딩 검사 애플리케이션을 포함시켰다.

4. SOA에 이르는 방법은 다양하며, 각각 특성과 아키텍춰상 우선순위가 있다.

5. 기업의 상호작용 채널(웹, 소매샵, 연락본부, ATM/kiosks, 모바일장치, 보이스 시스템등) 전체에 경험 조정을 지원할 수 있도록 공통 서비스(협업, 워크플로우, 콘텐트 배송 등) 세트에 상호작용 플랫폼을 번들로 제공한다.  왜냐하면 상호작용 플랫폼은 어떠한 채널에서도 사용될 수 있는 서비스를 제공하기 때문에, 다중 채널 통합 플라그에 호환되지않는 서비스 문제를 피할 수 있다.

6. 컴포넌트 자산 저장소는 개발자들이 또다시 새로 구축하기 전에 기존 서비스를 찾아볼 수 있도록 해주는 편의 기능을 추가한다.

7. 레퍼지토리 수행에 중요한 성공요소는 레지스트리에 어떻게 그리고 언제 서비스를 카탈로그화하기, QoS와 서비스의 기타 특징을 명쾌하게 정의하기 그리고 다양한 비즈니스 영역전반에 걸쳐 서비스를 구분해 낼 수 있는 공통 용어를 구축하는 등 공통 프랙티스를 개발하는데 집중한다.

8. 재사용, 모니터링 ROI와 그 외 메트릭스를 측정을 촉진하는데 사용되는 현재의 툴은 적절하지않는데, 특히 SO-IT 채택에서 그러하다.

9. SOA는 점점 애플리케이션에서 보안, reliable 배송, 프로세스 플로우, 작동등 인프라스트럭쳐 표준 기능으로 이동하고 있다.  따라서, SOA는 애플리케이션 설계만큼이나 인프라스트럭쳐 설계에 해당한다.