SOA 프로젝트 플랜 향상

문서 옵션 JavaScript가 필요한 문서 옵션은 디스플레이되지 않습니다.

난이도 : 중급

Yvonne Balzer, Senior IT Management Consultant, IBM Global Services ITMC

2004 년 7 월 16 일

서비스 지향 아키텍쳐 (SOA)는 IT 효율성을 증대 시킬 수 있는 잠재력을 갖고 있다. 하지만 한 조직에서 이를 구현하려면 기술적 노하우 그 이상이 필요하다. 관리 측면에 있어서도 훈련을 받아야 한다. 이 글에서 모든 SOA를 성공적으로 이끌 수 있는 관리 원리를 제시한다.

비즈니스와 IT 가치 체인은 오늘날 산업으로 함께 합병되기 시작했다. 이제 우리는 IT 구현과는 독립된 enterprise architecture와 Service-Oriented Architecture (SOA)를 이야기하고 있다. 이러한 변화와 함께, 우리는 비즈니스와 IT를 구현하고, SOA 같은 아키텍쳐를 정의 및 개발하며 엔터프라이즈 중심의 클라이언트를 실행하는 방식을 채택해야 한다.

이러한 모든 이유들로 인해서 관리는 오늘날 IT 분야에서 그 어느 때보다도 중요한 역할을 하고 있다. 이 글에서, IBM IT Management Consulting (ITMC) 팀의 관리 방식을 나누고자 한다. 이들은 여러 클라이언트 Engagement를 개발 및 구현했다. 입증된 IT 관리 구조 및 방법에서 시작하여 SOA 요구사항을 만족시키는 관리 모델을 향상시켰다.

동기와 목적

산업계의 도전과 이슈로 인해서 현재 조직에서의 IT의 역할은 급격히 변했다. 오늘날 IT는 거의 실시간 비즈니스를 수행하도록 빠르고 유연하게 대처해야 한다. IT는 통합되고 복잡한 엔터프라이즈 아키텍쳐의 일부를 설계 및 관리해야 한다. 비즈니스와 IT 컴포넌트간 경계도 흐려지고 있다. 이 글에서는 이러한 목표를 달성하고 성공적인 SOA Engagement를 구현하는데 도움이 될 주요 관리 기능을 제안한다.

관리는 전략 레벨, 기능 레벨, 작동 레벨에 대한 고객의 비즈니스 목표를 지원하기 위한 중심적 구조를 제공한다. 규칙, 프로세스, 메트릭스, 효과적인 계획수립에 필요한 조직적 구조체, 결정 수립, 조정, 고객의 비즈니스 필요와 도전적인 목표를 달성하기 위한 SOA Engagement의 제어 등을 정의한다. 마지막으로 관리 모델은 다음을 정의한다:

• 무엇을 할 것인가?
• 어떻게 할 것인가?
• 누가 할 것인가?
• 어떻게 평가를 받을 것인가?

이 모델은 규칙, 프로세스, 메트릭스, 효과적인 계획수립에 필요한 조직적 구조체, 결정 수립, 조정, 고객의 비즈니스 필요와 도전적 목표를 달성하기 위한 SOA Engagement의 제어 등을 정의한다.

다음은 SOA Engagement 내에서 적절한 관리 구조를 정의하기 위해 필요한 핵심 질문들이다:

• 이 Engagement에서 고객이 얻을 수 있는 혜택은 무엇인가? 고객의 목적과 기대는 무엇인가?
• IT 플래닝을 위해 고객의 사이트에 이미 존재하고 있는 역할, 책임, 구조, 절차는 무엇인가?
• 기술과 리더쉽 능력이 어떻게 개발될 수 있는가?
• 비즈니스와 IT의 배열을 최적화하기 위해 어떤 원리와 가이드라인이 필요한가?
• 새로운 변화를 빠르게 받아들이기 위해 영속성과 유연성을 유지하기 위해 비즈니스와 IT가 인터랙팅하는 방식을 구성하는 적절한 방법은 무엇인가?
• 적절한 서비스 표준화, 서비스 정의, 서비스 디스크립션이란 무엇인가?
• 서비스와 서비스 제공자들은 어떻게 제어 및 평가될 수 있는가? 기존 서비스의 변경을 감시, 정의, 권한부여 할 사람은 누구인가?
• 서비스의 소싱 전략에 대해 어떻게 결정할 것인가?
• 어떤 문제들이 존재하며 이 Engagement가 이러한 문제를 풀기위해 고객을 어떻게 도울 수 있는가?

우리의 경험에 비추어 볼 때, 우리가 받아들여 정형화된 관리 모델은 비즈니스 목적을 성공적으로 달성하는데 있어 핵심 요소인 것이 분명하다. 따라서 SOA Engagement에 관리 기능을 확립할 것을 제안하는 바이다. 관리 모델은 각 단계에서 배운 경험을 토대로 다음 단계를 정의 및 실행하는데 포커스를 맞추며 나중에 채택된 것들의 근본적인 요구사항을 다루어야 한다. SOA의 채택과 구현을 위한 관리 기구의 생성은 관리 모델의 핵심 요구사항이다. 빠른 채택성을 위해서는 클라이언트의 기존 조직을 사용하고 서로 협업하여 이를 SOA Engagement에 적응시키는 것을 권장하고 있다.

위로

관리 모델: SOA Engagement의 올바른 모습

IT 관리에 대한 다양한 정의가 존재한다. 한 IT Governance Institute (참고자료)는 다음과 같이 IT 관리에 대한 개요를 제공한다:

IT 관리는 이사화와 실무 관리팀의 책임이다. 이것은 엔터프라이즈 관리의 일부이며 리더쉽과 조직적 구조로 구성되어 있으며 조직의 IT가 이것의 전략과 목적을 지탱하고 확장한다는 것을 보장하며 처리한다.

IT 관리의 목적은 IT 노력들이 IT의 퍼포먼스가 비즈니스 목표에 부합하도록 하여:

* 엔터프라이즈와 함께 결합된 IT가 기대하던 이득을 볼 수 있도록 한다.
* IT가 엔터프라이즈를 움직여 기획들이 활용되고 이익이 극대와 될 수 있도록 한다.
* IT 리소스들이 신뢰성 있게 사용되도록 한다.
* IT 관련 위험 부담들이 적절하게 관리되도록 한다.

그림 1에 설명된 관리 모델은 조직적 구조, 합동 프로세스, 전략적 방향과 관리 원리(governance principles)라고 하는 기본 규칙에 근거한 관계의 조합이다. 이러한 방식은 크고 복잡한 Engagement의 경험을 토대로 개발되었다. 이곳에서 우리는 이러한 요소들이 어떤 종류의 프로젝트들이든 간에 핵심적이라는 것을 깨달았다.

전략적 방향과 가이드 원리

클라이언트의 전략적 방향의 정의는 적절한 SOA를 개발하고 비즈니스 필요에 대한 초점을 유지하는데 필요한 성공의 핵심요소이다. 비즈니스 전략과 목적에 대한 일반적인 이해는 비즈니스 단위와 IT 모두에 있어서 기본이 된다.

관리 원리(governance approach)와 가이드라인은 모든 결정에 있어서 근본적인 토대이다. 이것으로 솔루션 영역을 구상하고 협업이 발생하는 방식을 정의한다. 따라서 이들은 잘 이해되어야 하며 실무 관리 팀들의 동의도 필요하다. 하나의 주요한 가이드라인은 관리 접근 방식이다. 두 가지로 구분할 수 있다:

• 중앙 관리: 엔터프라이즈에 알맞다. 관리 위원회는 각 서비스 도메인과 subject matter 전문가들을 대표를 두고있다. 이들은 솔루션의 핵심적인 기술 컴포넌트를 구현하는 사람들에게 말할 수 있다. 중앙 관리 위원회는 변경의 구현에 권한을 부여하기 전에 서비스 리스트에 대한 추가나 삭제 뿐만 아니라 기존 서비스의 변경까지 심사한다.
  
  
• 분산 관리: 분산 팀들에게 알맞다. 각 비즈니스 단위는 조직 내에 서비스를 제공하는 방법에 대한 제어권을 갖고 있다. 여기에는 기능적 서비스 도메인 접근 방식이 필요하다. 중앙 위원회는 다른 팀들에게 가이드라인과 표준을 제공할 수 있다.

각 원리는 그 원리의 목적과 내용을 설명하는 정당한 근거로 정의되어야 한다. 가이드 원리는 SOA의 개발, 관리, 사용법에 대한 기본 규칙을 정의한다. 특정 원리들은 아키텍쳐 디자인 또는 서비스 정의의 경우-가이드 원리에서 파생되어 특정 주제에 포커스를 맞추게 된다. 이러한 원리들은 디자인의 스타일에 대한 고유의 작동을 제공하는 특징이고 프로젝트의 다음 측면들을 다루어야 한다:

• 가이드 원리:
  • 재사용, 세분성, 모듈성, 구성가능성, 컴포넌트화
  • 표준에의 순응(일반 스팩과 산업 스팩)
  • 서비스 구분과 범주화, 준비와 전달, 모니터링과 트래킹
• 특정 아키텍쳐 원리:
  • 캡슐화
  • 비즈니스 로직과 기반 기술의 분리
  • 단일 구현과 엔터프라이즈 관점의 컴포넌트
  • 기회가 있는 곳에서 기존 자산 활용
  • 수명 주기 관리
  • 시스템 리소스들의 효율적인 사용
  • 서비스 완성과 퍼포먼스

SOA 스타일의 아키텍쳐와 디자인 원리, 그리고 이러한 원리들이 비즈니스와 IT 커뮤니티에 주는 혜택을 이해함으로서 솔루션을 설계할 때 SOA를 어떻게 적용할지를 결정할 수 있다. 이러한 원리들은 서비스의 디자인에 필수적인 특정 성질들을 드러나게 한다.

관리 프로세스

관리 프로세스는 전략적 IT 플래닝과 조정에 필요한 프로세스이다:

• 전략 개발
• IT 플래닝
• 포트폴리오 관리
• 소싱(Sourcing)
• 혁신 관리
• 아키텍쳐 관리

SOA Engagement 내에서 Engagement 초반에 Architecture Management Process (AMP)를 확립해야 한다. AMP의 일차적인 목적은 일관성 있고 효율적인 개발과 정의된 SOA의 지속성을 보장하는 것이다.

많은 Engagement에서의 경험을 바탕으로 우리는 클라이언트 Engagement에 빠르고 쉽게 사용 및 채택할 수 있는 표준 AMP를 개발했다. 이 프로세스는 네 개의 하위 프로세스로 구성되어 있다. (그림 2) 이는 IBM LOVEM 노테이션을 사용하는 자산으로서 사용할 수 있다. (LOVEM은 line of visibility engineering methodology의 약자이다.( 참고자료)

그림을 자세히 분석해보자:

• Architecture review and approval process:
  • 기존 SOA에 대한 변경을 확인하고 승인하는 구조화된 방식을 정의한다. SOA 로드맵에 따라 결정한다.
  • 공식적인 디자인과 서비스 평가 리뷰가 핵심 제어 포인트이다.
• Architecture exceptions and escalation process:
  • 아키텍쳐 결정에 영향을 끼치는 방법을 제공한다.
  • 독특한 비즈니스 필요에 부합하기 위해 SOA 아키텍쳐에 대한 예외를 인정한다.
• Architecture maintenance process:
  • SOA가 관리되고 있으며 새로운 서비스가 이 아키텍쳐에 통합될 때 그 변화가 주주들에게 알려진다는 것을 확인한다.
  • 아키텍쳐에 대한 변화가 문서화되고 알려진다.
• Architecture communication process:
  • SOA가 액세스를 필요로 하는 누구나 SOA를 사용할 수 있음을 확인한다.
  • SOA의 중요성에 대한 인식을 증대시킨다.

조직적 구조

아키텍쳐 관리를 제공하기 위해 몇몇 구조는 한 조직 내에서 확립되어져야 하며 모든 필요한 역할들과 책임들 뿐만 아니라 적절한 결정 수립 구조를 정의해야 한다. 현장에서의 경험을 통해 크고 복잡한 Engagement에 아키텍쳐 오피스를 설립하는 것이 매우 유용했다. 아키텍쳐 오피스는 전략 레벨, 방법 레벨, 작동 레벨에 대한 비즈니스 요구와 SOA를 연관 지어 관리하는 책임이 있다. 여기에는 아키텍쳐 디자인 권한이 필요한데 이것은 아키텍쳐 관리 프로세스의 주인이다. 또한 각 레벨마다 역할과 책임이 정의되어 있다.

클라이언트 사이트에서 작업한 결과를 토대로 그와 같은 아키텍쳐 오피스를 확립 및 실행하는 두 가지 효과적인 방법을 깨달았다:

• 클라이언트 조직은 이미 아키텍쳐 오피스와 같은 기능을 갖춘 기구들이 있다. 우리는 이 기존 구조에 투입해야 한다. 모든 기능들과 책임들이 아키텍쳐 레벨의 결정을 이루는데 참여해야 한다. SOA Engagement의 경우 위원회 멤버들은 SOA 결정에 개입하여야 하며 과정을 보고 받아야 한다.
• 클라이언트 사이트에 어떤 관리 위원회가 없다면 SOA Engagement의 콘텍스트 안에 아키텍쳐 오피스를 만들고 핵심 프로젝트에 대한 결정을 할 것을 권한다. 클라이언트와 SOA Engagement에 개입된 프로젝트 담당자와 임시적으로 아키텍쳐 오피스를 구성하라. 멤버들은 정책 결정자가 되어야 하며 스폰서로서 CIO를 포함시켜야 한다. Engagement가 끝나면, 아키텍쳐 오피스는 클라이언트 조직에 통합될 수 있다.

그림 3 오피스와 각 레벨을 채우고 있는 역할과 책임을 보여주고 있다. 전략 레벨의 경우 아키텍쳐 위원회가 있는데 이것은 표준과 원칙을 제출하고 비즈니스와 IT 전략에 따른 서비스들을 구분하는 책임이 있다. 전술 레벨에서 아키텍쳐 그룹은 아키텍쳐 관리 프로세스를 정의하는 책임이 있는 아키텍쳐 디자인 권력기구로서 작동한다. 서비스의 변경, 제거, 추가와 도메인 관리에 대한 결정 기준도 함께 관리한다. 작동 레벨에서 프로젝트 팀은 서비스를 개발 및 구현한다.

각 팀은 태스크와 책임, 그리고 작동 모드를 정의하는 역할 디스크립션이 필요하다.

SOA 관리는 도메인 소유권(domain ownership)이라는 개념을 도입했다. 일반적인 비즈니스 관련물들을 공유하는 도메인이 관리 되는 곳에 있다. 많은 경우 고객 정보, 케이스 정보, 상업 통계 등의 비즈니스 서비스의 세부사항들이다. 뿐만 아니라 상업 위험 비율, 제품 분석, 플래닝 서비스 같은 논쟁 레퍼런스도 있다. 각 도메인은 각자의 비즈니스 객체를 관리하고 인터페이스들을 다른 도메인에 퍼블리시하는 책임이 있다. 이 도메인은 비즈니스 객체에 대한 검색과 관리 서비스를 제공하면서 비즈니스 로직, 위치, 객체와 서비스와 관련한 포맷을 캡슐화한다. 제품 또는 제품 분야를 담당하고 있는 사람들은 도메인으로부터의 서비스를 원할 때 요청을 만들고 이 두 그룹은 관계를 결정하고 서비스 레벨 계약을 만든다. 이러한 관계와 계약은 도메인들간 존재한다.

도메인 소유권이라는 개념을 사용하여 SOA Engagement의 개발 수명주기에 제공되어야 하는 새로운 역할과 책임이 있다. (표 1)

표 1. SOA Engagement의 역할과 책임

주어진 서비스 도메인 내에서 작업하는 사람들은 비즈니스와 기술 통합을 개발하여 비즈니스 서비스를 만드는 책임이 있다. 비즈니스 서비스들은 비즈니스 라인을 통해 공유되어 구성원들과 지역에 혜택을 준다. 이것은 애플리케이션 개발에 대한 조직적 구조(역할과 책임)에 변화를 도입했다. 한 애플리케이션 내의 기능을 개발하는 것이서 한 서비스 도메인 내에서 기능을 개발하는 것으로 변했다.

위로

관리 모델 시작하기

관리 모델을 개발할 때 사용하는 이 프로세스는 세 단계 방식에 기반을 두고 있다. 이 방식은 시간 제한이 있는 클라이언트 Engagement에 근거하여 개발되었다. 성공 열쇠는 Engagement 기능의 확립이다.

• Step 1: 작동화
  • 핵심 관리 기능을 적소에 설정하고 클라이언트의 비즈니스 작동을 지원한다.
  • 수행하면서 배운다. 빠른 수행이 관건이다.
  • 잘 훈련된 실무진을 사용하여 상위 관리 레벨에서 활동하도록 한다.
• Step 2: 전문화
  • 필요한 구조, 프로세스 메소드, 툴을 구현한다.
  • Step 1의 경험을 수용한다.
  • 숙련된 아키텍트와 메소드 실무진을 사용한다.
• Step 3: 안정화
  • 클라이언트 직원을 교육 및 훈련하여 작동을 실행한다.
  • 작동 모드에서 코칭 모드로 변경한다.
  • 코칭 전문가와 컨설턴트 및 전문가를 사용한다.

그림 4는 이 단계를 보다 자세히 그려놓았다.

위로

힌트 & 팁

다음은 실제 Engagement를 통해 우리가 배운 교훈들이다:

• 액세스가 필요한 모든 사람들과 주기적으로 통신한다. (프로젝트 뉴스레터, 미팅 등을 이용). SOA는 문화적인 변화 뿐만 아니라 기술적 변화를 가져온다. 이는 경계를 만들 수 있다. 따라서 상호 통신이 필수적이다.
• 결정, 제한, 가정 등을 문서화하여 정책 결정의 투명성을 보장한다.
• 즉시 수행할 핵심적인 사항과 툴 세트와 템플릿 등을 정의한다.
• 수명 주기 관리와 버저닝에 필요한 실제 툴을 설정한다.
• 규칙에 맞춰 결정을 내리고 그러한 결정들을 문서화하고 통신한다.
• 모든 주주들로부터 지속적으로 스폰서를 받도록 하고 정책 결정자들을 영입한다.

위로

결론

이 글에서 SOA Engagement에서 관리가 중요한 이유와 무엇이 필요한지를 설명했다. SOA 관리 모델의 핵심 요소들에 대한 개요를 제공했다. 가이드 방향으로서 SOA 원리에서 시작하여 하나의 주요 프로세스로서 아키텍쳐 관리 프로세스가 서비스 지향 아키텍쳐로의 일관성과 순응성을 유지하도록 한다. 적절한 결정 수립과 개발에 필요한 역할과 책임으로 조직 구조를 확립하는 방법도 설명했다. 마지막으로 관리 모델을 시작하는 방법을 설명했고 과거 경험에서 배운 교훈들도 나눴다.

위로

참고자료

• "Service-Oriented Architecture: Implementation challenges" (MSDN, April 2004)
  
  
• "Business process reengineering and beyond"
  
  
• "Ten emerging best practices for building SOAs" (SearchWebServices, February 2003)
  
  
• IT Governance Institute
  

위로

필자소개

	Yvonne Balzer는 IBM Global Services의 IT 관리 컨설턴트이다. 이곳에서 IT 관리와 전략에 대한 컨설팅을 하고 있다.

위로

기사에 대한 평가

매우 불만족 (1) 불만족 (2) 보통 (3) 만족 (4) 매우 만족 (5)

위로