Kunal Mittal, Director, Domestic TV IT, Sony Pictures Entertainment
서비스 지향 아키텍처(SOA) 프로젝트의 유스 케이스(Use Cases)와 비즈니스 요구 사항을 분석합니다. 이러한 요구 사항들을 파악하고 문서화 하는 최고의 방법도 소개합니다.
개요
Part 1에서는, SOA 프로젝트의 기술적 요구 사항에 대해 배웠다. 비즈니스 요구 사항에 앞서 기술적 요구 사항들을 검토해야 하는 이유도 설명했다. "확실한" 해답은 없었지만, 내 경험에서 볼 때, SOA 프로젝트는 정보 기술(IT) 부서가 주도하고 있고, 논의 역시 기술 쪽으로 흘러간다. 이전 글에서는 다양한 유형의 기술적 요구 사항들과, 그러한 요구 사항들을 분석할 때 주의해야 할 여러가지 함정들에 대해서도 살펴보았다.
이 글에서는, SOA 프로젝트의 비즈니스 측면에 대해 설명하고자 한다. 초기 SOA 서비스의 한 과정인, 비즈니스 요구 사항 분석의 핵심 요소들을 설명한다. 요구 사항들을 파악할 때 사용할 수 있는 기본적인 기술에 대해서도 설명한다. ("어떻게(how)" 보다는 "무엇을(what)"에 초점을 맞춰 설명할 것이다.)
SOA 프로젝트에서 몇 가지 서비스들을 규명 및 구현하는 프로세스를 설명한다. 본 시리즈의 후속 기술자료에서는 엔터프라이즈 SOA와 관련한 요구 사항을 수집, 문서화, 관리하는 방법을 설명한다.
시작하기
여러분에게 잘 정의된 SOA 이니셔티브가 있다는 전제로 시작하겠다. SOA의 기술적 요구 사항들을 규명한 상태이고, "어떤 SOA 서비스를 구현해야 할까?"라는 질문에 봉착해 있다. 기업 내 다른 IT 그룹들 마다 다른 이야기들을 할 수도 있다. 어떤 사람은 콘텐트 관리 서비스, 보안(인증/권한) 관련 서비스 같은 기술 서비스를 구현해야 한다고 말할 것이다. 어디에서 시작할지에 대한 논의는 젖혀두겠다. 여러분이 비즈니스 서비스를 시작하는 것으로 간주할 것이다. 비즈니스 서비스를 규명하는 방법을 우선 살펴보자.
서비스 규명
SOA 프로젝트에서 구현할 최초의 몇 가지 서비스들을 규명하는 방법에 대해 알아보자. 이 서비스들은 비즈니스에 미치는 영향에 따라 분리되어야 한다. 또 한편으로 그 서비스들은 당신이 추구하는 장기적 SOA 로드맵의 가치와 비전을 설명할 수 있을 만큼 충분한 가치가 있어야 한다.
Top-down 방식으로 서비스 규명하기
Top-down 방식의 경우, 기업 내 존재하는 고급 비즈니스 유스 케이스 또는 비즈니스 프로세스 플로우에서 시작한다. 또한, 비즈니스 전략 또는 IT 전략 플랜으로 시작할 수 있다. (여기에는 비즈니스 전략이 포함된다.) 이것은 프로세스들을 기능 영역 또는 서브시스템들로 나누는 시작점일 뿐이다. 이것들을 조직 전체를 대상으로 하여, 취약점, 재사용 가능한 유스 케이스, SOA 후보 서비스 명단에 넣을 수 있는 기능들을 규명하기 시작한다. 가장 복잡한 서비스나 논란의 여지가 많은 서비스들은 피하는 것이 좋다.
Top-down 방식은 비즈니스 중심적(business driven)이다. 비즈니스 문서는 SOA 서비스를 규명할 때 참조될 수 있다. 그림 1은 Top-down 방식의 단계들이다
Bottom-up 방식으로 서비스 규명하기
Bottom-up 방식에서는, 기존 시스템 또는 애플리케이션으로 시작한다. 이러한 시스템들에 있는 문서를 연구한 다음, 기능 영역, 서브시스템 지도, 고급 비즈니스 유스 케이스를 만든다. 더 어려운 것 같지만, 대부분의 기업에서는, Top-down 방식에 사용되는 고급 문서가 없거나, 있더라도 오래되었기 때문에, 불가피하게 이 방식을 선택해야 한다. Bottom-up 방식은 좀더 IT 중심적이다. 비즈니스에는 전략, 기능, 핵심 능력에 대한 문서가 부족하다.
Top-down 또는 bottom-up?
여러분은 이 두 방식 중, 특정 스타일을 더 선호할 것이다. 현실적으로, 대부분의 기업들은 이 두 가지 방식을 혼합하여 사용한다. Top-down 방식은 보다 비즈니스 중심적이지만, 이러한 방식은 거의 사용되지 않는다. SOA는 순수하게 IT 중심적이기 보다는 비즈니스 중심으로 갈 때 성공할 수 있기 때문이다.
그림 2는 서비스 규명을 위한 Bottom-up 접근 방식 샘플이다. Top-down 방식과 크게 다르지 않지만, 시작 포인트는 매우 다르다.
서비스 규명 개념에 대해서는 아래 참고자료 섹션을 참조하라.
단일 서비스에 대한 요구 사항 모으기
이 섹션에서는 단일 서비스를 대상으로 설명한다. 요구 사항들의 유형을 설명하고, SOA 서비스 요구 사항들을 수집하는 과정을 설명한다.
요구 사항 유형
이제, 첫 번째 SOA 서비스를 위한 요구 사항을 파악할 준비가 되었다. 다음 항목에 기반하여, 요구 사항들을 파악해야 한다. 이 글에서는 비즈니스 요구 사항에 초점을 맞춘다. 이전 글에서는 기술적 요구 사항에 대해 설명했다.
ㆍ접근성(Accessibility). 서비스 사용자가 이 서비스를 어떻게 찾아서, 액세스 하는가? 이러한 요구 사항은 기술적 요구 사항과 비즈니스 요구 사항이 맞물려 있다. 여러분이 구현하는 서비스를 찾아서 호출해야 하는 비즈니스 프로세스를 생각해 보면 쉽게 이해가 될 것이다.
ㆍ기능성(Functionality). 이 서비스는 어떤 비즈니스 프로세스 또는 기능을 제공할 것인가? 해결해야 할 비즈니스 문제는 무엇인가? 이것은 매우 복잡한 문제가 될 수 있다. 따라서, SOA에서 어떤 종류의 서비스를 제공할 것인지를 결정해야 한다. (참고자료)
ㆍ인터랙션(Interaction). 이 서비스를 호출하게 될 서비스나 애플리케이션이 그 서비스와 어떻게 상호 작동할 것인가? 이 서비스는 에러를 어떻게 처리하는가?
ㆍ정보(Information). 이 서비스에서 어떤 데이터를 주고 받을 것인가?
ㆍ프로세스(Process). 액션과 서비스의 이벤트 사이에는 어떤 관계가 있는가?
요구 사항 유형을 파악했다면, 이제 프로세스에 대해 생각해 보자. SOA가 아닌 경우, 서비스나 애플리케이션의 사용자들은 어떤 서비스를 원하는지를 설명해야 한다. SOA에서는, 서비스의 모든 사용자(또는 잠재적 사용자)를 알 수 없다. 서비스가 추구하는 목표에 대한 요구사항을 설명할 수 있는 서비스 공급자}(서비스를 구현하는 업무 관계자)가 필요하다. 서비스 명세에 대해서는 서비스 사용자들이 유효성 검사를 해야 한다. 하지만, 모든 잠재적 고객에게 다가갈 수도 없고, 다가가서도 안된다. 한마디로 불가능하다.
비즈니스 팀은 애플리케이션이 시간과 예산을 맞추기를 원한다. 관리 팀은 요구 사항이 오히려 더 적다. 그 무엇보다도 빠른 결과를 원한다. IT가 어떤 일을 하는지에 대해서는 신경 쓰지 않는다. 이 모두가 맞는 말이다. 이러한 현실 때문에, 많은 IT 리더들은 SOA 프로젝트에서 비즈니스 팀과 함께 일하는 것을 꺼려한다. 비즈니스 팀은 SOA의 구현 상세는 신경 쓰지 않는다. 하지만, 서비스의 근본적인 개념을 이해해야 한다. 서비스의 관점에서 비즈니스와 비즈니스 프로세스를 구상해야 하고, 비즈니스 전반에 걸쳐 재사용 할 수 있는 서비스를 규명하는 방법을 모색해야 한다.
프로젝트의 가장 큰 위험 요소들 중 하나인 비즈니스-사용자 개입에 대해 명확히 해야 한다. 관리 요소를 개입시키고, SOA의 가치와, 원하는 것을 제시간에, 빠르고, 저렴하게 제공할 수 있는 방법을 설명해야 한다.
프로세스 관점에서 볼 때, 서비스 공급자는 서비스를 기능적으로 그리고 비기능적으로 기술해야 한다. 우선 요구 사항 방법론이나 툴을 사용하여 이전 섹션에서 설명한 모든 정보 유형들을 파악해야 한다. IBM?? Rational?? Unified Process and IBM Rational RequisitePro?? 또는, 단순한 워드 프로세스 문서를 사용한다. 이 단계에서, 공식적인 절차는 필요 없다. SOA의 가치를 나타내는 몇 가지 서비스를 빠르게 선보이면 된다. 하지만, 이러한 요구 사항들은 문서화 해야 한다.
요구 사항들을 어떻게 효과적으로 문서화 할 수 있을까? 문서화 과정을 통해 비즈니스에 대한 요구 사항들을 검증할 수 있다. 요구 사항들과 기술 팀들이 협동하여 서비스를 구현하게 될 것이다.
그림 3. 유스 케이스 템플릿
SOA 프로젝트의 일부로서, 몇 가지 초기 서비스를 규명하는 방법을 이해했을 것이다. 이러한 서비스들에서 요구 사항들을 모으고, 기존 요구 사항 프로세스와 기술을 사용하여 요구 사항들을 문서화 하는 방법도 배웠다. "이상적인 SOA 팀 만들기"(참고자료)에서는, SOA 프로젝트에서, 팀과 비즈니스 분석가 역할을 보다 효과적으로 구성하는 방법을 설명하고 있다.
다음 글에서는, 엔터프라이즈 SOA 플래닝을 설명한다. 파일럿 프로젝트가 성공했고, SOA 프로그램을 시작할 준비도 되었고, 자금 지원도 받았다면, 더 크고, 복잡한 상황에서 요구 사항들을 모으고, 관리하고 문서화 하고 통신하는 방법을 모색할 때이다.
