T T A S t a n d a r d Web viewSOA 목적을 예로 들면, 크게는 고객 만족도 제고, 비용 절감 등을 들 수 있고, 보다 구체적인 하위 목적의 예로는 기관간의

T T A S t a n d a r d

정보통신단체표준 제정일: 200x년 xx월 xx일TTAx.xx-xx.xxxx/R1 개정일: 200x년 xx월 xx일

SOA 참조 프레임워크

(SOA Reference Framework)

본 문서에 대한 저작권은 TTA에 있으며 , 이 문서의 전체 또는 일부에 대하여 상업적 이익을 목적으로 하는 무단 복제 및 배포를 금합니다 .

Copyright Telecommunications Technology Associations(2005). All Rights ⓒReserved.

정보통신단체표준(Tab|↔|) 제정일 : 200x년 xx월 xx일 TTAx.xx-xx.xxxx/R1(Tab|↔|) 개정일 : 200x년 xx월 xx일


(SOA Reference Framework)

서 문

1. 표준의 목적

본 지침의 목적은 SOA의 도입을 고려하거나 구축을 추진하고자 하는 기관의 경우 고려해야 하는 중요 요소들을 전체적인 차원에서 제시하여 SOA에 대한 이해에 도움을 주는 것이다. SOA를 체계적이고 종합적으로 이해하고 비즈니스와 IT를 연결하여 잘 활용하기 위해서는 전체적인 차원에서 SOA를 조망하고 관련 중요 요소들의 의미와 연관 관계를 이해할 필요가 있다.

2. 주요 내용 요약

본 지침은 SOA 추진에 필요한 모든 요소들을 원칙, 아키텍처, 프로세스, 거버넌스의 4 가지 부문으로 나누어 SOA 참조 프레임워크로 제시한다. 각 부문별로 이해가 필요한 중요 요소들을 부문별 주요 구성요소로 제시하고 있다.

3. 표준 적용 산업 분야 및 산업에 미치는 영향

본 지침은 SOA의 중요 요소를 참조 프레임워크로 제시하여 SOA를 적용하고자 하는 기관의 혼란을 최소화하고 나아가 SOA 시장 활성화에 기여할 것이다.

4. 참조권고 및 표준

4.1 국외표준(권고)

해당사항 없음

4.2 국내표준

해당사항 없음

4.3 기타 : 없음

5. 참조표준(권고)과의 비교

해당사항 없음

6. 지적재산권 관련사항

해당사항 없음

7. 적합인증 관련사항

해당사항 없음

8. 표준의 이력

판수 제/개정일 제․개정내역

정보통신(영문)단체표준Preface

1. The Purpose of Standard

This specification provides the guidelines about considerable items for SOA adoption, implementation and management for organizations including governments and public sectors to understand SOA wholly. It is important to understand SOA comprehensively in order to adopt SOA for the alignment between business and IT.

2. The summary of contents

This specification provides SOA reference framework that is composed with four parts, principle, architecture, process and governance. And each part has some sub elements that are considerable items for the part.

3. Applicable fields of industry and its effect

This specification contributes to minimize confusions among organizations that want to adopt, implement and manage SOA.

4. Reference Standards (Recommendations)

4.1 International Standards (Recommendations)

None

4.2 Domestic Standards

None

4.3 Other Standards : None

5. Relationship to International Standards(Recommendations)

None

6. The Statement of Intellectual Property Rights

None

7. The Statement of Conformance Testing and Certification

None

8. The History of Standard

Edition Issued date Contents 5

TTAx.xx.xxxx/R1

정보통신(영문)단체표준

6TTAx.xx.xxxx/R1


목 차

1. 개요.................................................................................................................１

2. 표준의 구성 및 범위............................................................................................１

3. SOA 참조 프레임워크.........................................................................................１

3.1 SOA 참조 프레임워크 개요...............................................................................13.2 SOA 원칙.......................................................................................................33.3 SOA 아키텍처...............................................................................................183.4 SOA 프로세스...............................................................................................293.5 SOA 거버넌스...............................................................................................37

TTAx.xx.xxxx/R1v


Contents

1. Introduction························································································1

2. Constitution and Scope······································································1

3. SOA Reference Framework·································································1

3.1 Introduction to SOA Reference Framework···································1 3.2 SOA Principle··················································································33.3 SOA Architecture··········································································183.4 SOA Process·················································································293.5 SOA Governance··········································································37

TTAx.xx.xxxx/R1vi


SOA 참조 프레임워크SOA Reference Framework

1. 개요

SOA를 체계적이고 종합적으로 이해하고 비즈니스와 IT의 연결을 위해 SOA를 잘 활용하기 위해서는 전체적인 차원에서 SOA를 조망하고 관련 중요 요소들의 의미와 연관 관계를 이해할 필요가 있다. 이를 위해 본 지침은 SOA의 도입을 고려하거나 구축을 추진하고자 하는 기관의 경우 고려해야 하는 중요 요소들을 원칙, 아키텍처, 프로세스, 거버넌스의 4 가지 부문으로 나누어 SOA 참조 프레임워크로 제시한다. 또한 각 부문별로 이해가 필요한 중요 요소들을 부문별 주요 구성요소로 제시하고 있다.

본 지침의 마련으로 정부와 공공을 포함한 기관의 정보시스템 환경 고도화 및 개선을 위하여

SOA를 적용하고자 할 때 관계자들의 SOA에 대한 이해를 돕고 전체적인 차원에서 고려 요소들을 제시하고 있어 특정 업체나 기관에 종속적인 용어, 절차, 방법론에서 벗어나 관련된 혼란을 줄일 수 있다.

2. 표준의 구성 및 범위

SOA 참조 프레임워크 파트에서는 SOA 추진에 필요한 모든 요소들을 원칙, 아키텍처, 프로세스, 거버넌스의 4 가지 관점으로 나누어 제시한다.

3. SOA 참조 프레임워크

3.1 SOA 참조 프레임워크 개요

SOA는 급변하는 비즈니스 환경에서의 비즈니스와 IT의 변화 대응력을 키울 수 있도록 지원하는 방법으로 각광받고 있다. 이러한 SOA는 비즈니스를 표현하는 새로운 방법으로 자리잡으면서 기업의 현업 혹은 IT 및 플랫폼 사업자 등 다양한 입장에서 다른 각도로 해석이 되어 다양한 분야로 영향을 미치고 있다.

이러한 SOA의 복합적 요소를 체계적이고 종합적으로 이해하고 비즈니스와 IT를 연결하기 위해 SOA를 활용하는 경우 전체적인 차원에서 SOA를 조망하고 관련 중요 요소들의 의미와 연관 관계를 이해할 필요가 있다. 본 지침상의 SOA 참조 프레임워크는 CBDi의 CBDi-SAE SOA Reference Framework를 기반으로 국내 상황에 맞게 구성한 것으로 SOA의 도입을 고려하거나 구축을 추진하고자

TTAx.xx.xxxx/R11

목적 (Goal)

정책 (Policy)

표준 (Standard)

원칙(Principle)

아키텍처(Architecture)SOA 서비스

포트폴리오

SOA 참조 아키텍처

SOA 보안 참조 아키텍처

SOA 서비스 플랫폼

프로세스(Process)계획 수립

아키텍처 & 서비스 모델링

구축

운영

거버넌스(Governance)SOA 거버넌스 조직

거버넌스 프레임워크

거버넌스 프로세스

거버넌스 플랫폼

성과지표 (KPI)

투자수익 (ROI)


비즈니스 원칙

IT 원칙

정보통신(영문)단체표준하는 기관의 경우 전체적인 차원에서의 종합적인 중요 고려요소를 체계적으로 이해하는 데

도움을 주고자 한다. 이러한 SOA 참조 프레임워크는 아래와 같이 크게 4가지 부문으로 구성된다.

첫째, SOA의 도입 동인 및 기반을 형성하게 될 비즈니스 목적/정책/표준등과 관련된 원칙(Principle) 부문둘째, SOA를 실질적으로 구현시 재사용 가능한 업무를 서비스 기반으로 표현 및 분류한 서비스 포트폴리오, 전체적인 구현의 청사진을 제공하는 참조 아키텍처, 운영을 위한 엔진인 플랫폼과 관련된 아키텍처(Architecture) 부문셋째, SOA 추진시 시간의 흐름에 따른 추진 단계를 규정한 프로세스(Process) 부문넷째, 변화 대응력을 강조하는 SOA 의 효과적인 제어 및 관리를 위한 거버넌스(Governance) 부문.

또, 원칙, 아키텍처, 프로세스, 거버넌스의 각 부문별로 이해가 필요한 중요 구성요소를 아래와 같이 도출하여, SOA 도입/구축시 전체적인 이해를 위한 시작점과 구체적인 내용 준비를 위한 기반을 형성하였다.

<그림 1> SOA 참조 프레임워크

3.2 SOA 원칙 (Principle)

TTAx.xx.xxxx/R12


3.2.1 개요 (역할)

3.2.1.1 정의

SOA의 원칙(Principle)은 SOA를 추진(도입/구축/관리)하는 데, 가장 원리가 되고, 근간이 되는 기준을 정의한 것이다. SOA를 추진할 때, 조직간이나 프로젝트간에 지속적으로 공유되어야 하고, 준수되어야 하는 기본적인 요소이다.

3.2.1.2 필요성

서비스 지향적 IT 아키텍처로 변화시키는 과정에서는 IT 기술 구조뿐 아니라 IT 업무 상의 변화가 함께 이루어 져야 한다. 이러한 변화는 SOA 도입 기획 및 구축뿐 아니라 운영 관리에 이르는 전체 IT의 생명주기 기간 동안에 계획적이고, 주도적인 변화 관리 활동에 따라 수행되어야 한다.

개발 및 운영 관련 여러 이슈와 제약 사항을 갖고 있는 현재의 IT 환경을 SOA의 모습으로 일관성 있게 변화시켜나가기 위해서는 흔들리지 않는 일관된 원칙에 따른 추진이 매우

중요하다. 이러한 근본이 되는 원칙은 SOA 참조 프레임워크의 나머지 부분을 정의하는데 필요한 원리로도 활용 된다.

3.2.1.3 구성 요소 도출 근거

SOA 원칙(Principle)의 구성 요소는 공통적으로 공유되어야 할 지배 가치로 SOA의 지향점이 되는 목적, 기술 관점의 IT 원칙, SOA 실행에 필요한 정책, 실행의 일관성과 효율성을 위한 표준 등 네 가지 요소로 도출되었다.

3.2.1.4 개념도

SOA 원칙은 범 정부 레벨에서 공유될 수 있는 원칙과 기관의 자체적인 원칙으로 나눌 수 있다. 기관별 원칙은 기관 내에서 공유 가능한 레벨과 이를 기초로 프로젝트 별 특성이 감안된 프로젝트 별 원칙으로 나눌 수 있다.

TTAx.xx.xxxx/R13


<그림 2> 영역(Domain)별 SOA 원칙간의 포함관계

4 가지 구성 요소를 보면, 가장 추상화 수준이 높은 목적에서, 구체적이고 실현관점의 표준까지를 다루게 된다.

<그림 3> SOA 원칙 구성 요소간의 관계

3.2.2 구성요소

3.2.2.1 SOA 목적 (SOA Goal)

정의

SOA의 목적이란 SOA를 통해서 기관이나 조직에서 도달하고자 하는 지향점을 말한다. SO를 계획적이고, 지속적으로 추구하기 위해 필요하며, 분명한 목적이 있어야 하며, 이것은 구체적으로 측정이 가능한 형태로 표현되는 것이 바람직하다.

TTAx.xx.xxxx/R1

A 기관 B 기관기관별 자체 원칙

기관 공통 원칙

C 기관전체 공공 기관

A ProjectB Project프로젝트별 원칙

기관 자체 원칙

C Project

개별 기관 (A기관 )

범정부 Level 공유

기관 Level 공유

가 조직 나 조직

4


필요성

SOA의 최종적인 목적은 비즈니스 프로세스와 IT를 효과적으로 연계하여, 비즈니스 목적 달성을 위해 비즈니스의 빠른 변화를 신속하고 효율적으로 지원할 수 있는 서비스 단위의

유연한 IT 아키텍처를 구축하는 것이다.

하지만, 연간 추진 계획이나 기관의 프로젝트 레벨에서는 보다 구체적이고 개별화된 목적이 필요하며, 추진 기관의 업무적 특성이나 경영 목표, 운영중인 IT 시스템이 가진 이슈에 따라 다른 SOA 추진 목적이 설정될 수 있다.

따라서, 해당 기관의 SOA 추진 목적과 개별 프로젝트의 SOA 추진 목적을 명확히 정의하고 합의하여, 해당 구성원들 간에 공유되어야 한다. SOA 추진 시에는 다양한 이해 관계가 상충할 수 있으므로(Trade off 관계), SOA의 목적은 이때의 의사 결정을 위한 판단 기준으로 활용된다.

주요 내용

SOA를 추진한다는 것은 전체 조직의 IT 아키텍처를 서비스 지향의 개념을 갖도록 하는 데 필요한 제반 활동을 수행하는 것이다. 이를 위해 IT 아키텍처를 SOA의 모습으로 일관성 있게 바꾸어 나가게 되는 데, 단계적인 단위 프로젝트 레벨의 SOA 적용의 결과가 전체 조직 레벨의 SOA로 이어 질 수 있도록 지속적인 계획 수립, 실행, 통제의 사이클을 이행해야 한다.

SOA는 적용 대상을 업무 범위와 기간에 따라 단계적으로 나누어 프로젝트 형태로 진행하게 된다.

업무적인 범위에 따라 전체 조직 레벨의 적용과 단위업무 레벨의 적용으로 나눌 수 있다. 여기서, 전체 조직은 단일 기관이 될 수도 있으나, 보다 넓은 범위로 비즈니스 파트너 관계를 갖는 여러 기관간의 연합체나 비즈니스 생태계가 될 수도 있다.

기간에 따라서는 장기/중기/단기 기간별로 계획을 설정하여, 단계적으로 추진하게 되는 데, SOA 목적(Goal)은 이러한 각 기간별 단계별로 설정되어야 한다. 단기적인 목적은 개별 SOA 구축 프로젝트의 목적이 되며, 중기/장기 목적은 SOA 구축 프로젝트들의 전체 목적이 된다.

이러한 목적은 그 추상화 수준에 따라 상위 수준의 목적과 다수의 보다 구체적인 하위 수준의

목적의 계층 구조로 나뉠 수 있으며, 상위 수준의 목적은 최종적인 Business의 목적으로 정의되고, 하위 수준은 보다 IT 실행 관점의 목적으로 가깝게 정의되며, 정량적 측정이 가능한 형태로 정의될 수 있다.

개념도

TTAx.xx.xxxx/R15

정보통신(영문)단체표준목적은 상위 수준의 목적과 하위 수준의 목적으로 분류할 수 있으며, 본 지침에서 다루고 있는 SOA 거버넌스에서 다루는 있는 성과지표(KPI) 및 측정 지표(Metric)와도 연계된다.

<그림 4> SOA 목적과 SOA 거버넌스의 관계

예시

가. 공공 기관의 SOA 목적 계층도 SOA 목적을 예로 들면, 크게는 고객 만족도 제고, 비용 절감 등을 들 수 있고, 보다 구체적인 하위 목적의 예로는 기관간의 협력 증진, 새로운 부가가치의 발현, 시스템간 연계-통합의 유연성 개선, IT 소유 비용의 절감 등이 있다. 목적의 정량적 표현을 예로 들면, 기관간 연계를 통한 서비스 매출액, 신규 부가 서비스 매출액, 연동 시간 및 비용의 5% 감소, 시스템 운영 비용의 10%절감 등이 있다.

<그림 5> 목적 계층도(Goal Tree) 예시

그림에서는 공공 기관 입장에서 본 상위 수준의 목표는 최종적인 예상 비즈니스

성과를 목표로 기술하고, 하위 수준의 목표는 좀 더 구체적인 업무 및 IT 관점의 예상 성과를 기술하였다.

나. 렌터카 회사의 SOA 목적 예시

TTAx.xx.xxxx/R1

목적 (Goal

)KPIMet-ric

기관간 협력 제고 신규부가가치창출

유연성 개선 업무 중복 제거

대국민 고객 만족도 제고

비용 절감

TCO 절감민원 처리 기간 감소

6


다음 그림은 일반 기업 입장에서 본 상위 수준의 목적을 보여 주고 있다.

<그림 6> 목적(Goal) 예시

위의 목적에 대한 하위 목적을 렌터카 회사의 사례를 들어 나타내면 다음과 같다. 목적(Goal) 하위 목적 (Sub Goal) 예시

고객 만족도 제고 우수 고객에게는 호텔 예약이나 여행지 선정 등 다양한 Special Offer 를 할 수 있어야 한다.고객의 취향과 선호도 이력을 분석하여, 개인화된 추천 예약 환경을 갖추어야 한다.

파트너 통합 제고 고객이 요구하는 차량을 제공할 수 없을 때, 차량 중개인으로부터 해당 차량의 재고 정보를 제공받아야 한다.

적응성 증대 예측 가능한 비즈니스적인 변화를 지원해야 한다. -빈번한 조직 재편이나 인수 합병을 지원할 수 있어야 한다.-비즈니스 규칙의 변화에 쉽게 적응 할 수 있어야 한다. (단체 예약에 따른 요금 체계의 변화가 용이해야 한다).

멀티채널

역량 제고

전화 이외에 인터넷, TV, Digital Kisk 등에서의 예약이 가능해야 한다.

프로세스

최적화

거의 실시간으로 차량 사고나 절도 등의 차량 사고를 통보 받을 수

있어야 한다. 원스탑

서비스

웹사이트 하나에서 여행 관련 전체적인 필요서비스를 일괄 패키지로

예약 할 수 있어야 한다. (호텔, 페리, 식당, 공연장 등)

다. IBM의 SOA 목적 예시

1. 비즈니스전략에 연계된 비즈니스 요구사항에 대응한다.2. 이사회의 방침에 따른 거버넌스 요구사항에 대응한다.3. 서비스 제공에 따른 최종 사용자의 만족 시켜야 한다.4. 정보 사용의 최적화를 달성한다.5. IT 유연성(Agility)을 제고한다.6. 업무요구사항과 통제요구사항이 어떻게 변환되어야 하는 지를 정의한다. 7. 통합되고 표준화된 어플리케이션들을 획득하고 유지한다.8. 통합되고 표준화된 IT Infrastructure를 획득하고 유지한다.9. IT 전략에 따라 필요한 IT 기술을 획득하고 유지한다.

TTAx.xx.xxxx/R1

투명성 고객 만족 파트너 통합

적응성 Multi-Channel 역량

최적화One Stop 서비스

7

정보통신(영문)단체표준10. IT 비용과 효과에 대한 투명성과 이해도를 높인다.11. 모든 IT 자산을 최대한 보호하고, 재활용한다.12. IT Infrastructure, 자원, 역량을 최적화한다.

3.2.2.2 SOA의 IT 원칙 (SOA IT Principle)

정의

SOA IT 원칙(IT Principle)은 앞에서 정의된 목적을 실제 달성하기 위해 필요한 원리 중에서, IT 관점에서 가장 근본적이고, 일반적인 SOA 의 기본 규칙 (Base Rule)을 정의한 것이다.

필요성

SOA의 IT 원칙은 IT 자원을 활용하여 SOA를 추진하는 데 있어, 기준이 되는 규칙으로 IT 기술 관련 의사 결정시에 기준이 될 수 있는 보편 타당한 지침이 된다. 이것은 SOA 관점의 아키텍처를 결정하는 IT 요소 기술 (데이터, 플랫폼, 어플리케이션, 보안, 네트워크, 사용자 인터페이스 등)의 채택 및 설계 적용에 대한 기준을 제공한다.

주요 내용

SOA의 IT 원칙은 서비스 지향 관점에서 본 보편적인 IT 규칙이지만, 추진 기관별로 특성을 감안한, 선별적인 재정의 작업이 필요하다. 이러한 IT 원칙은 뒤의 SOA 정책 및 SOA 표준 (Standard) 수립에서 참조 된다.

주요 내용으로는 서비스 제공자와 소비자 간의 역할 분담, 서비스 중계 계층의 역할, 서비스의 특성, SOA의 필수 구성요소 항목 등을 정의하게 된다.

개념도

OASIS의 SOA 참조 모델에서 정의한 서비스 참여자 모델은 아래와 같이 서비스 사용자(Consumer), 서비스 제공자(Provider), 서비스 중계자(Mediator)로 나뉘어 지고, 각각 서비스(Service)를 사용하고, 연계하고, 제공하는 역할을 수행한다.

TTAx.xx.xxxx/R18


<그림 7> 서비스 가시성 모델

예시

가. CBDI Forum의 IT 원칙 [CBDI SOA Core Principles]서비스 지향 아키텍처에서 가장 근본이 되는 특징은 미리 잘 정의된 서비스 계약에

따라 IT 시스템을 구성하는 역할을 서비스 제공자 (Provider) 역할과, 서비스 소비자(Consumer) 역할로 나누어 구축하고 운영하는 모델에 입각한 IT 아키텍처라는 점이다.

그림에서처럼, 서비스 계약을 통해 제공되는 서비스가 소비자 역할을 담당하는 어플리케이션에 전달되어 쉽게 활용 가능해야 한다. 이를 위해 소비자는 어떤 서비스가 제공되며, 어떻게 업무에 적용할 수 있는지를 알아야 하고, 제공자는 제공되기로 계약된 서비스가 무엇인지를 알아야 한다. 하지만, 서비스 소비자는 서비스 공급자가 어떻게 서비스를 생성하여 조달하는 지의 구체적인 방식에

대해서까지 알 필요는 없다.

소비자의 요구 수준 변동과 제공자의 서비스 제공 역량 사이의 차이를 최소화하여

조정하고, 항상 일정하게 합의된 품질에 따르는 서비스를 제공 할 수 있어야 한다.

TTAx.xx.xxxx/R19


<그림 8> 서비스 소비자와 제공자의 역할 및 서비스의 원칙

SOA는 서비스 공급자의 역할과 서비스 소비자의 역할이 서비스 계약에 근거해서 명시적으로 분리된 형태의 아키텍처이다. 이 때, 서비스 계약의 서비스를 정의하는 기준과 원칙이 필요하며, SOA 서비스의 원칙은 서비스 개발 프로세스와 거버넌스(Governance) 요구 사항 기준에 대한 기준점을 제공하게 된다.

아래에 기술된 SOA 서비스의 원칙에서 가장 많이 준수되는 원칙은 가)항의 느슨한 결합의 원칙이다. 이것은 IT 관점의 유연성을 추구하기 위해서 가장 먼저 필요한 것이기 때문이다. 각각의 원칙이 준수되어야 하는 정도와 어느 원칙이 우선 적용되어야 하는지는 기관이나 프로젝트의 목적과 투자 비용에 따라 달라지게 된다.

1) 느슨한 결합 (Loosely Coupled) - 계약 기반의 서비스 명세화를 통해 서비스 내부를 은폐하고, 기술적인 유연성을 제고한다. 공급자와 소비자간의 명시적 분리 및 이들간의 관계 변경에 따른 영향도를 최소화한다.

- 일반적으로 가장 우선 적용되는 원칙이며, IT 유연성을 제고하는 데 가장 필요하다.

2) 표준화 (Standardized) - 단일 Instance 형태로 서비스를 일원화하여, 기관 전체차원에서 일관성 있는 업무 처리 방식의 재사용을 가능하게 한다.

- 일관성 있는 프로세스 행위, 유틸리티, 정보, 규칙을 제공한다.- 서비스의 재사용과 가장 관련이 많으며, 기술적인 재사용 뿐 아니라, 업무적인 관점에서 프로세스, 데이터, 어플리케이션이 일관성 있게 관리될 수 있는 지의

TTAx.xx.xxxx/R1

제공자(Provider)

소비자(Consumer)

Service

Loosely Coupled

Standardized

Abstracted

Composable

Modular

Virtualized

역할

역할

계약

10

정보통신(영문)단체표준관점이 강조된다.

3) 추상화 (Abstracted) - 서비스의 일반화를 통해 다양한 업무적인 상황(Context) 및 시간에 따른 변화에 대한 업무적인 유연성을 제공한다.

- 서비스의 일반화(generalization)란 예를 들면 다른 상품, 마케팅 채널, 지리(지역)적인 차이, 업무 규칙의 차이, 미래의 업무 변화에 대해서도 비슷하고 일관성 있는 방식으로 동일한 서비스를 활용할 수 있도록 서비스의 명세

(Specification)정의를 일반화 시키는 노력을 말한다.

4) 조합성 (Composable) - 다른 대체 서비스의 활용이나 복합 서비스를 쉽게 만들어 낼 수 있게 하기

위해, 프로세스 계층과 어플리케이션 계층을 분리하게 된다. 이를 통해 표준화와 다양성을 동시에 실현할 수 있게 된다.

- 하위 계층에는 공통적이고 표준화된 서비스를 두고, 상위 계층에는 이를 상세화하여 조립하는 계층을 두게 된다.

5) 모듈화 (Modular) - 서비스간의 의존성을 최소화하고, 이를 컴포넌트화하게 한다. 이를 통해 서비스가 독자성 (Autonomous)을 갖고, 일정한 모듈 영역에 대한 책임을 가지게 된다.

- 서비스의 개발, 테스트, 배포 및 운영, 향후 개선에 적합한 최소한의 서비스 크기(Granularity)를 기준으로 모듈화해야 한다.

6) 가상화 (Virtualized) - 업무 중심의 IT 자원 캡슐화(Encapsulation)를 통해, 서비스 소비자와 독립적인 서비스 제공, 서비스 제공자와 독립적인 IT 자원 조달을 용이하게 한다.

- 가상화는 공급자와 소비자간에 서로 독립적인 소프트웨어 라이프 사이클 및

업그레이드 주기를 갖고, 관리될 수 있게 하며, 이를 통해 유연성을 높일 수 있도록 한다.

[CBDI Forum, SOA Core Principles]

나. IBM의 SOA IT 원칙

1) 서비스 재사용- 비즈니스 서비스는 반드시 다른 여러 서비스나 어플리케이션들로부터

사용되거나 소비될 수 있도록 설계/구축/문서/실행 되어야 한다.

TTAx.xx.xxxx/R111

정보통신(영문)단체표준2) 서비스 포트폴리오

- 모든 서비스들은 엔터프라이즈 서비스 포트폴리오의 한 부분이어야 한다.

3) 서비스 디커플링 (Decoupling)- 서비스 제공자와 소비자 사이의 관계에서 통신 규약(Protocol), 기술, 플랫폼, 서비스 위치에 대한 의존성을 완전히 분리해야 한다.

4) 서비스 라이프사이클 (Life Cycle)- 서비스의 라이프사이클은 확립된 개발 프로세스에 따라 통제되어야 하며, 개발 프로세스는 서비스 식별, Funding, 개발, 테스팅 등을 모두 포함한다.

5) 서비스 테스트- 서비스 소비자 어플리케이션은 거버넌스 조직이 정의하는 표준에 따른 표준

테스트 환경을 사용하여 서비스를 테스트할 수 있어야만 한다.

3.2.2.3 SOA 정책 (Policies)

정의

SOA 정책은 SOA 원칙에 따라 전략을 수립하여, 아키텍처를 정의하고, 실행을 강제하는(Enforcing) 메커니즘으로, IT 원칙보다 구체적인 SOA 관점의 기술적 방침이다. 이것은 구체적으로 시스템의 동작 방식을 결정하는 기술적인 의사결정의 기준이 되며, 서비스 품질이나 설계/개발 및 서비스 사용과 관련된 내용을 다루게 된다.

필요성

정책은 원칙을 실현하기 위한 관점에서, 좀 더 구체성을 가지고, SOA의 비기능적인 품질 요구 사항과 이를 위한 작동 방식(메커니즘)을 정의하는 역할을 수행한다.

주요 내용

기존 IT의 접근 방식이 업무 기능과 업무에서 다루는 정보의 관리에 중점을 두었다면, SOA에서는 그것뿐 아니라, 정책(Policy)도 매우 중요하게 강조된다. 정책의 예로는 아키텍처 설계 가이드 라인이나 보안 정책, 서비스 구축 정책 등을 들 수 있다.

정책은 서비스 계약과도 밀접하게 관련된다. 서비스의 사용 및 제공이라는 관점에서 서비스 계약의 이행 규칙을 명시적으로 규정하므로, 정책은 측정 가능한 실행 지표를 가질 수 있으며, SOA 거버넌스의 자동화된 통제 및 관리 메커니즘과도 연결되게 된다.

개념도

TTAx.xx.xxxx/R112

정보통신(영문)단체표준OASIS 에서 정의하는 정책(Policy)과 서비스 계약(Contract)간의 관계에 따르면, 정책과 서비스 계약은 서로 참조하는 관계이며, 서비스 계약 수행을 위해 필요한 아키텍처 품질 관점의 요건을 정의한다.

<그림 9> 정책(Policy)와 서비스 계약간의 관계

예시

가. CBDI 의 SOA 정책1

SOA의 정책은 서비스 품질(QoS) 정책, 설계 정책, 서비스 조달(Sourcing) 및 사용 정책, 기술정책의 4 가지 유형으로 분리 해 볼 수 있다.

- 서비스 품질(QoS)는 서비스에 대한 품질 요구수준으로 서비스 품질의 Type은 유연성(Agility), 용량(Capacity), 가용성(Availability), 보안성(Security)로 나눌 수 있다. 이중 유연성은 서비스 설계와 관련되고, 나머지는 비기능적인 요구사항으로 서비스 품질(QoS) 인프라스트럭처 설계와 주로 관련된다. 이러한 서비스 품질(QoS) 정책은 실행시간(Runtime) 거버넌스와 밀접한 관련을 갖는다.

- 설계 정책은 SOA의 QoS 요구사항에 맞도록 일관성 있는 준수해야 하는 설계 접근 방식을 말한다. 여기에는 설계 규칙, 설계 패턴, 설계 가이드가 있으며, 설계 정책은 다른 SOA 정책 요소의 영향을 받는다. 이러한 설계 정책은 설계 시점(Design-time) 거버넌스와 밀접한 관련을 갖는다.

설계 규칙의 예로 모든 서비스는 UI 및 장치 독립적이어야 한다는 던지, 재사용의 관점에서 모든 서비스는 계층(Layer)를 이루어야 한다는 점 등을

1 Service Orientation: Winning Strategies and Best Practices by Paul AllenTTAx.xx.xxxx/R113

정보통신(영문)단체표준들 수 있다.

SOA 설계 패턴의 예로는 계층(Layer) 아키텍처, 싱글톤(Singleton), 팩토리(Factory), 프락시(Proxy), 어댑터(Adapter) 패턴 등을 들 수 있다.

SOA 설계 가이드로는 낮은 결합도(Coupling)과 높은 응집도(Cohesion)을 달성하기 위한 서비스 간의 의존 관계, 서비스의 오퍼레이션 호출에 필요한 통신 방식(동기, 비동기, 배치전송) 등을 예로 들 수 있다.

- 서비스 조달(Sourcing) 정책 및 사용 정책. 서비스 조달정책은 내부조달(insourcing)과 외부조달(outsourcing)으로 나눌 수 있으며, 핵심 경쟁력으로 차별화와 부가가치의 원천이 되는 서비스는 내부조달(insourcing)을 통해 자체적으로 운영해야 하며, 운영 효율화와 가격 경쟁력을 핵심으로 가져가야 하는 부분에 대해서는, 외부조달(아웃소싱)을 하는 것이 바람직하다. 물론, 서비스의 조달(Sourcing)정책은 자유로운 서비스의 선택적 조달 환경이 갖추어져 있을 때에 한하여 적용된다. 서비스 사용 정책은 기관 내부 사용, 비즈니스 파트너간 사용, 오픈 마켓에서의 사용으로 나뉘어 진다.

- 기술 정책

기술 정책은 정해진 기술 환경 제약 상황(하드웨어, 네트워크, 개발 언어, 모델링 언어, 소프트웨어 플랫폼 등)에서 서비스를 제공하는 기술 컴포넌트를 어떻게 개발하고 통제할 것인지의 구체적인 규칙을 정의하는 것이다. 예로 들면 기술 표준, 통신 방식(동기/비동기), 서비스의 정의/발견/운영/배포기준, 용량, 가용성, 보안성에 대한 개발 및 운영 규칙 등이 있다.

나. IBM의 SOA 정책

- 정책 1 – 반드시 서비스 재사용 정책이 있어야 한다. 서비스는 필요할 때마다 만들어지는 것이 아니라, 재사용 되어야 한다. 서비스 재사용의 비즈니스 적인 관점과 기술적인 관점이 모두 고려 되야 한다.

- 새로운 서비스가 개발되기 전에 항상, 기존의 서비스가 사용 될 수 있는지를 확인하는 검토 프로세스를 정의한다. - WSDL 디자인 규칙이나, 상호 운영성을 위한 WS-I 준수 여부 등이 설정된다.

- 정책 2 – IT 준수(Compliance) 정책을 정의해야 한다. 모든 서비스는 현재의 IT 참조 아키텍처(Reference Architecture)를 준수해야 한다. 이를 위해 모든 서비스가 구체적으로 어떤 표준을 지켜야 하는 지 정의한다. 서비스 품질 정책도 한가지 예가 될 수 있다.

- 정책 3 – 보안 정책이 수립되어야 한다. 서비스를 사용(Consumption)하는 과정에서 어떤 보안 표준이나 인증 프로세스가

TTAx.xx.xxxx/R114

정보통신(영문)단체표준필요한지 정의되어야 한다.

3.2.2.4 SOA 표준 (SOA Standard)

정의

SOA 표준(Standard)은 기 수립된 SOA 정책을 갖고 SOA를 추진하기 위하여 다수의 이해 관계자들간의 일관성 있는 수행을 위하여, 구체화된 준수(Compliance) 요건들을 채택하거나 재정의하여 실제 실행에 필요한 기준을 정립한 것이다.

이러한 표준 수립은 국내외의 SOA 관련 표준화 기구에서 정의한 각종 기술 표준에 대한 수용뿐 아니라, 산업별 또는 기관별로 정의한 비즈니스 규칙 및 용어 표준, 아키텍처 정의 표준, 기술 표준 등을 정의하는 활동이 모두 포함된다.

필요성

SOA 표준은 SOA 참조 프레임워크에서 아키텍처와 거버넌스, 프로세스와 연관되어, 공통적으로 필요한 정의 및 요소 기술들이 해당 기관내의 기준으로 활용되어야 한다.

여러 이해 관계자들간의 합의와 공유가 필요한 필수적인 공통 업무 규칙과 상호 호환을 위한

기술 요소를 명확히 정의함으로써, SOA 구현 과정에서 발생되는 다양한 이해도 및 상호 호환성의 불일치 문제를 최소화하는 것을 목표로 한다.

주요 내용

SOA 표준은 기관 전체 조직(Corporate)의 관점에서, 기술과 독립적인 업무 관점과 개방성, 상호 호환과 운영을 고려한 기술 관점의 모두가 수용되어야 한다.

업무적인 관점에서는 해당 조직이 속한 산업 또는 범 정부적인 표준을 참고하여 비즈니스

표준을 작성하는 것이 필요하고, 기술 관점에서는 다양한 기술간의 상호 호환성을 보장하기 위한 국제 기술 표준을 선택하여 적용하는 것이 필요하다.

SOA 기술 표준을 수립하기 위해서는 먼저, 기관내의 현재의 SW플랫폼과 어플리케이션이 수용하는 기술 표준을 상호운용성 관점에서 분석한다.

TTAx.xx.xxxx/R115

정보통신(영문)단체표준개념도

<그림 10> SOA 표준 개념도

예시

가. 기술 표준

산업 기술 표준은 해당 표준 별로 얼마나 많은 SW 벤더에서 지원되고 있는지, 해당 산업계에서 얼마나 많이 사용되고 있는 지, 충분히 성숙된 기술인지, 서로간의 상호 호환성에서 문제는 없는 지 등을 검토하여 기관에 맞게 선택적으로 채택되어야 한다.

SOA를 위한 기술 표준은 공개 표준 연계 기술인 XML과 웹 서비스를 기반으로 하고 있다. 따라서, 웹 서비스 기술 표준화 활동을 주도적으로 수행해 왔던 비영리 단체인 WS-I, OASIS를 중심으로 이루어져 왔다.

웹 서비스 국제 표준화 기구인 WS-I에서는 WS-I Basic Profile을 통해서 SOA의 핵심적인 상호 운용성의 기본 표준인 Web Service 기술 표준을 규정하고 있으며, WSDL, SOAP, UDDI, XML, XML Schema로 이루어져 있다.

OASIS는 e-비즈니스에서 이용되는 표준을 개발하는 비영리 단체이다. WS-I에서 웹 서비스의 SOAP과 WSDL과 같은 핵심 표준을 개발하고 있다면, OASIS에서는 비즈니스 도메인에 특화하여 각종 응용 표준을 개발하고 있다. 대표적으로 WS-BPEL, WS-Addressing, WS-Reliable Messaging, WS-Policy, WS-Metadata Exchange, WS-Security, SAML등이 있다. 또한, OASIS에서는 SOA를 위한 레퍼런스 모델과 레퍼런스 아키텍처를 정의하고 있다. OASIS SOA 레퍼런스 모델은 SOA의 핵심 개념을 정의하고 있어, SOA 개념의 이해와 공유에 도움을 주고 있다. OASIS SOA 레퍼런스 아키텍처는 여러 가지 관점(View)에서 본 SOA의 다양한 모델에 대해서 정의하고 있다.

본 SOA 지침의 아키텍처 부분에서 정의하고 있는 SOA 참조 아키텍처 계층 예시를 기준으로 한 SOA 표준의 예는 아래와 같다. 기관의 성격에 맞게 정의된 SOA 아키텍처 모델을 기준으로, 아키텍처 Layer 별로 표준 메시지 및 프로토콜 기술을 정의하고 있다.

레가시나 컴포넌트를 서비스화하여 제공하는 서비스 계층의 기술 표준은 XML 기반의

TTAx.xx.xxxx/R1

기관 표준

SOA 표준산업 표준

적용 대상

업무 표준

기술 표준관점

16

정보통신(영문)단체표준SOAP, WSDL, UDDI, XML Schema, XPath, XQuery 등을 표준으로 하고 있지만, ESB 등으로 구현되는 공통적 계층인 통합 계층은 XML 기반 표준뿐 만 아니라, 기타 Non XML 기반의 기술 표준도 허용하고 있다.

<그림 11> 계층(LAYER)별 기술 표준 예시

나. 업무 표준

SOA를 추진하는 데 필요한 업무적인 기준으로, SOA 관련 용어표준, 서비스 분류 체계 표준, 관리 표준 등을 예로 들 수 있다.

다. 산업 표준

UDDI 저장소는 웹 서비스에 대한 정보뿐 아니라, 웹 서비스 제공자에 대한 정보도 가지고 있다. UDDI 저장소의 화이트 페이지(White Page)는 웹서비스 제공자의 이름, 주소, 전화번호 등의 정보로 구성되고, 옐로우 페이지(Yellow Page)는 UNSPSC, NAICS, ISO3166과 같은 표준 산업 분류를 통해, 웹서비스 제공자의 서비스를 분류하고, 그린 페이지(Green Page)에서는 웹서비스 활용에 필요한 기술적인 사항(WSDL)을 제공한다.

그 외 업종별 산업 표준으로 GCI (Global Commerce Initiative), OTA (Open Travel Alliance), 전자 부품 제조 기업들의 RosettaNet, 헬스케어 분야의 HIPAA, 보험업계의 ACORD, AIAG (Automotive Industry Action Group) 같은 산업별 표준과 좀 더 범용적인 전자 XML 기반 전자상거래 표준인 eBXML 같은 국제 표준이 존재한다.

라. 기관별 표준

TTAx.xx.xxxx/R117

정보통신(영문)단체표준업계 공통의 표준 기술을 활용하여, IT 아키텍처의 유연성을 제고해야 하지만, 개별 기관에서 현실적으로 수용할 수 있는 기술 표준을 선별해서 채택해야만 표준의 준수가

원활히 이루어 진다. 기관이 보유하고 있는 기존의 레가시(Legacy) 시스템들의 기술 구조에 따른 제약사항, 기관의 기술 역량, 향후의 기술 전략 등을 고려해서 여러가지 기술/산업 표준들 중에 기관별 표준이 선정되어야 한다.

3.3. 아키텍처

3.3.1. 개요

3.3.1.1 정의

SOA 아키텍처는 서비스 지향의 SOA 환경을 실체화 하기 위한 참조 구조도이며, 서비스, 아키텍처, 플랫폼 관점으로 SOA 서비스 포트폴리오, SOA 참조 아키텍처, SOA 보안 참조 아키텍처, SOA 서비스 플랫폼으로 구성한다.

3.3.1.2 필요성

SOA를 실현하기 위해서는 비즈니스 및 기술과 관련된 다양하고 단계적인 절차와 관점이 요구되므로 이해관계자들간의 공통적인 언어가 요구되며, 이러한 공통적인 언어로서 각 단계별로 서비스포트폴리오, 아키텍처, 플랫폼을 활용한다.

1) 이해 공유SOA 도입/개발/관리/운영/활용 시에 SOA 환경에 대한 비즈니스적/기술적 관점에서 구조적 이해를 공유함으로써 일관성 있고 효과적인 업무 수행을 위함

2) 합의도출각 이해관계자간(현업, IT부서, SOA 추진부서 등) 협의를 통해 도출된 결과물로서 전사차원에서 SOA를 추진하고 서비스 활용성을 극대화하기 위함

3) 커뮤니케이션 도구비즈니스 담당자와 기술 담당자간의 커뮤니케이션을 하기 위한 기준 도구로서 활용

3.3.1.3 구성요소 도출근거

SOA 서비스 실현을 위해서는 비즈니스 측면과 기술적 측면을 동시에 고려해야 한다. SOA 아키텍처의 네 가지 구성요소인 SOA 서비스 포트폴리오, SOA 참조 아키텍처, SOA 보안

TTAx.xx.xxxx/R118

정보통신(영문)단체표준참조 아키텍처, SOA 서비스 플랫폼은 CBDI의 SOA 프로세스의 주요 입출력 항목들 중에서 국내 현황 및 수행 경험을 기반으로 재해석하여 도출하였다.

SOA 실현의 비즈니스 측면에서 서비스 도출 및 명세를 위한 기준으로서 서비스 포트폴리오를 수립하며, SOA 실현의 기술적 측면에서 정의된 서비스를 실제 구현하기 위하여 SOA 참조 아키텍처, SOA 보안 참조 아키텍처를 정의하고 도입될 솔루션의 구체적인 검토 SOA 서비스 플랫폼을 도출한다 SOA 보안 참조 아키텍처는 보안 부분이 상대적으로 중요도가 높고 표준화에 따른 영향도가 크기 때문에 별도로 제시한다

3.3.1.4 개념도

<그림 12> SOA 아키텍처 개념도

3.3.2. 구성요소

3.3.2.1 SOA 서비스 포트폴리오 (SOA Service Portfolio)

정의

서비스 포트폴리오는 비즈니스 관점의 논리적 커뮤니케이션 도구이며, 서비스 기준/크기와 서비스 카탈로그로 구성된다.

필요성

TTAx.xx.xxxx/R119

정보통신(영문)단체표준SOA의 서비스를 식별하고 명세하기 위한 기준과 업무별/시스템 별로 SOA를 적용함에 있어서 고려되어야 할 항목이 무엇인지 제시할 필요가 있다.

1) 전략적 특성의 손쉬운 반영기업, 산업, 비즈니스, 정보기술 부분별로 전략적 분류와 선택에 따른 서비스 및 목록의 기준이 수립되어야 함

기업, 산업, 비즈니스, 정보기술 SOA 실현을 위한 목적 중에 하나인 효과적이며 효율적인 서비스의 재사용 및 재활용을 위해서는 SOA를 적용함에 있어 서비스 도출의 일관성을 제공하기 위해서 서비스화에 대한 기준 및 크기에 대한 가이드 수립이 요구됨

2) 서비스 재사용 및 공유의 기준서비스 재사용 및 공유를 위하여 중요도, 활용도, 산업화에 따른 서비스 목록 및 분류체계 수립이 요구됨

효율적인 활용을 위하여 서비스에 대한 목록 및 메타정보 등을 조회할 수 있는 카탈로그의

필요함

서비스 분류체계는 조직 내에서 활용되고 운영되는 기존 서비스 목록을 파악하고 신규 조합

(Composite) 서비스를 생성하고자 할 때 참조하기 위한 기준으로 필요로 한다.

3) 서비스 활용의 극대화 요구업무요구사항에 따라 전략적 분류기준을 수립하고 필요한 SOA의 논리적 서비스들의 목록화 하기 위함

구축된 또는 구축하고자 하는 서비스들에 대한 목록을 이해하기 쉽도록 분류하여 서비스

참조에 도움을 주고 서비스 보완에 대한 계획을 수립하는 서비스 전략으로 활용하기 위함

기업 관점에서 전략적 분류기준에 의하여 서비스를 체계적으로 목록화 하기 위함

주요내용

서비스포트폴리오는 1) 서비스 기준 및 크기, 2) 서비스 분류체계 3) 서비스 관리체계로 구성된다.

1) 서비스 기준 및 크기

TTAx.xx.xxxx/R120

정보통신(영문)단체표준산업분야별로 서비스 기준/크기(Granularity)를 손쉽게 참조하여 구현할 수 있도록 지원함

2) 서비스 분류체계서비스 식별 및 명세를 통해 얻어진 서비스 참조 목록과 목록간의 연계관계이며, 이는 조직 내외에서 참조 및 공유하는데 활용함

3) 서비스 관리체계서비스 속성관리, 변화관리, 권한관리 등의 관리 부분은 SOA 거버넌스 영역과 관계됨

서비스 기준 및 크기는 조직내의 표준 업무 참조 모델, 업무분석, 기능분석, 시스템분석 등을 기준으로 서비스를 식별하고 도출할 수 있도록 해주며, 서비스 도출 기준과 서비스의 크기(granularity)는 각 업무분야 및 상황마다 다르기 때문에 절차적 방법이나 기준적 방법에 의해서 서비스 기준과 크기에 대한 가이드를 제시해야 한다.

서비스 분류체계는 서비스 목록 또는 서비스들의 계층적 구조이며, 이들 서비스는 구현되어 사용중인 서비스뿐만 아니라 아직 구현되지는 않았지만 비즈니스 분석에서 도출된 서비스를

포함한다.

서비스 관리체계는 서비스의 등록/수정/삭제, 서비스의 속성관리, 서비스에 대한 권한별 관리 등을 포함한다.

예시

가. 서비스 분류체계 수립 방안 및 예시 (출처 : 삼성SDS, 2007)서비스 분류체계 수립 프로세스는 표준 프로세스 모델과 기술참조 모델에 기반하여

비즈니스와 기술 관점을 동시에 반영한다. 3단계에 걸친 Top-down방식의 서비스 분류체계 수립 프로세스를 수행한다.

<그림 13> 서비스 분류체계 수립 단계

서비스 분류체계 프레임워크는 업무 기준의 비즈니스 서비스, 비즈니스 서비스를 지원하는 관련 시스템들의 인터페이스와 흐름을 고려한 소프트웨어 서비스, 각 시스템의 아키텍처와 구성을 고려한 테크니컬 서비스를 식별하면서 비즈니스와 IT간

TTAx.xx.xxxx/R121

정보통신(영문)단체표준밀접한 융합이 가능한 서비스 분류체계를 수립을 제공한다.

나. 공공부문 서비스 분류체계 수립 (출처 : 삼성SDS, 2007.09)본 예시에서는 연계 요구사항을 분석하여 연계 기능을 확장하고 다양한 연계 대상

시스템 및 연계 조건을 고려한 표준화된 서비스 분류체계를 수립한다. 연계 서비스의 이해 증진 및 이용 활성화를 위하여 효과적인 서비스 분류체계를 만들어야 했으며, 연계 기능의 변경에 따른 영향도, 비즈니스 프로세스의 가변성 및 복합성, 적용 범위에 따라 핵심비즈니스 서비스, 프로세스 서비스, 유틸리티 서비스를 도출하도록 했다. 연계 서비스는 업무 도메인에 대한 서비스, 비즈니스 프로세스에 대한 프로세스 서비스, 핵심 비즈니스 서비스, 유틸리티 서비스 및 대상 시스템에 따른 시스템 별 서비스로 분류한다. 이 외에도 서비스에 대한 등록 및 검색을 위한 서비스 비즈니스 속성 및 기술 속성에 대하여 정의 및 관리해야 한다.

<그림 14> 서비스 분류체계 적용 방안

3.3.2.2 SOA 참조 아키텍처 (SOA Reference Architecture)

정의

SOA 참조 아키텍처는 SOA 기술적 환경에 대한 논리적 구조도이며, SOA 실현 요소에 대한 점검 및 서비스 플랫폼을 위한 모델로도 활용한다. SOA 개념과 경험이 내재된 참조 아키텍처를 참고하여 조기에 특정 프로젝트에 적합한 아키텍처를 활용 할 수 있다.

필요성

SOA를 실현함에 있어서 가시화, 단순화, 최적화 할 수 있는 기준이 되는 논리적 구조도로서 참조아키텍처는 다음과 같은 필요성이 있다.1) SOA실현(분석/설계/개발) 기간을 단축시키기 위하여 아키텍처 및 시스템의 기준을 조기에 확보할 필요가 있다.

TTAx.xx.xxxx/R122

정보통신(영문)단체표준2) 설계/개발 또는 솔루션을 적용함에 있어 개발 위험을 감소시키기 위하여 조직 및 프로젝트 내의 SOA 전문가에 의해 완성된 참조 아키텍처를 기반으로 한다.

3) SOA 개념과 경험이 내재된 참조 아키텍처를 참고하여 조기에 특정 프로젝트에 적합한 아키텍처를 생성한다

주요내용

SOA 참조 아키텍처가 일반적인 주요 계층은 3개의 계층을 포함하며, 이는 다양한 비즈니스적, 기술적 환경 및 요건에 의하여 확장되어 적용된다.

<그림 15> SOA 참조 아키텍처 개념도 예시

1) 비즈니스 프로세스 서비스 레이어2) 통합 서비스 레이어3) 기본 서비스 레이어

SOA를 실현하기 위하여 필요한 특정 기술이나 솔루션에 독립적인 기능적 구성요소이며, 이는 SOA 솔루션과 맵핑 가능하며, 이와 관련된 내용은 서비스플랫폼에서 설명한다.

예시

가. SOA Reference Architecture – Solution stack view (출처 : IBM, 2006)SOA 참조 아키텍처는 서비스 사용자(Consumer)와 서비스 제공자(Provider) 관점에서 수직적으로 5개 영역과 수평적으로 4개영역으로 구성된다.

TTAx.xx.xxxx/R123


<그림 16> SOA 참조 아키텍처 예시

나. SOA Layers (출처 : The Keys to Successful SOAs2, 2005)SOA 참조 아키텍처는 운영시스템 계층, 컴포넌트 계층, 서비스 계층, 프로세스 계층, 화면 계층, 통합 계층, 품질 계층의 7계층으로 구성한다.

계층 내용 예시

Layer1운영시스템 계층

Operational system layer레거시 시스템, 패키지 솔루션자체개발 애플리케이션

CRM, ERP

Layer2컴포넌트 계층

Enterprise components layer컴포넌트 기능 구현 WAS

Layer3서비스 계층

Service layer서비스 명세되는 계층, 조합서비스도 포함됨

WSDL

Layer4프로세스 계층

Business process composition or choreography layer

서비스 조합 및 프로세스 BPM

Layer5화면 계층

Access or presentation layer서비스 사용/활용 WSRP

Layer6통합 계층

Integration, ESB라우팅, 프로토콜 중계/변환 등 ESB

Layer7품질 계층

Quality of Service보안, 성능, 가용성 등의 품질

모니터링, 관리, 유지보수WSM

3.3.2.3 SOA 보안 참조 아키텍처 (SOA Security Reference Architecture)

정의

2 SOA world Magazine, http://webservices.sys-con.com/read/90109.htmTTAx.xx.xxxx/R124

정보통신(영문)단체표준SOA 보안 참조 아키텍처는 SOA 참조 아키텍처의 부분집합으로서 서비스 보안 부분을 강조하여 SOA 보안 서비스 계층(기능군)으로 이루어진 논리적 보안 구조도이며, SOA 보안 부분 적용 시 참조 모델로 활용한다.

필요성

SOA의 특징적 요소들을 지원하기 위한 보안 요소들을 고려해야 하며, 객체식별(사용자와 서비스), 조직과 기업 경계의 확장에 따른 신뢰 관계 형성 및 상호운용성 제공, 분산 서비스를 조합한 안정적이고 신뢰성 있는 신규 서비스 제공, 거버넌스를 위한 식별 등을 위해 SOA 보안이 더욱 요구된다.

주요내용

SOA를 실현함에 있어서 서비스 관련 보안 기준을 제시하기 위하여 보안 정책 및 체계, 전송보안, 메시지 보안, 식별/인증/접근통제, 보안 인프라 등으로 구성된다.

1) 서비스 인증 (SSO)- 비즈니스 프로세스 - 조합(Composite) 서비스

2) 메시지 부분 보안3) 보안 정책/표준/프로토콜4) 보안 솔루션간의 맵핑 및 연계

예시

가. SOA 보안 참조 모델 (출처 : IBM & STSC3)

3 http://gupea.ub.gu.se/bitstream/2077/20518/1/gupea_2077_20518_1.pdfTTAx.xx.xxxx/R125

정보통신(영문)단체표준<그림 17> SOA 보안 참조 모델

1) 거버넌스 및 위험관리 (Governance and Risk Management)- 거버넌스 : 조직 역할과 책임 정의- 프로세스와 권한- 위험 : 보안 비용과 가치 창출을 결정하기 위한 관리 프로세스- 컴플라이언스 : 평가와 보고2) 비즈니스 보안 서비스 (Business Security Service)- 비즈니스 보안 서비스를 구현하기 위한 IT 보안 서비스와 IT 보안 정책 지원- 계정과 접근관리 : 신용정보와 접근 통제의 라이프사이클- 데이터 보호와 노출 통제- 안전한 시스템과 네트워크3) 보안 및 정책 인프라(Security Policy Service)- 보안 정책 라이프사이클 관리- 정책 분배와 변경- 정책 결정과 강제화- 모니터링과 보고4) IT 보안 서비스 (IT Security Services)- 서비스로서 보안 기능을 제공하기 위한 블록 구현- 식별(Identity) 서비스- 인증(Authentication) 서비스- 접근통제(Authorization)와 프라이버시 서비스- 비밀과 무결성 서비스- 감사 서비스- 부인 방지 서비스5) 보안 실현

3.3.2.4 SOA 서비스 플랫폼 (SOA Service Platform)

정의

서비스 플랫폼은 참조 아키텍처를 기반으로 SOA를 실현하는데 필요로 하는 SOA 관련 솔루션들의 물리적 구조도이며, SOA 관련 주요 솔루션들 기능으로 구성된다.

필요성

SOA 모델링과 아키텍처를 수행한 후에는 이를 실제 구현하기 위하여 필요한 솔루션에 대한 구체적인 구조도가 존재해야 한다. 이를 위하여 앞서 수립된 논리적 구조도인 SOA 참조

TTAx.xx.xxxx/R126

정보통신(영문)단체표준아키텍처와 SOA 보안 참조 아키텍처를 실질적으로 구현할 수 있는 물리적 구조도인 SOA 서비스 플랫폼의 수립이 필요하다.

주요내용

서비스의 실현을 위해서 필요로 하는 서비스 프로세스, 서비스 통합, 서비스 보안, 서비스 관리/모니터링, 서비스 레지스트리 및 레포지토리 등의 다양한 요건을 수행하기 위해서 필요한 물리적 솔루션과의 연관관계를 맺기 위한 수단이며 이는 다양한 표준 기술 등과도

연결시킬 수 있다. 다음은 국내외 SOA 주요 솔루션으로 구성된 SOA 서비스 플랫폼 구성도이며, 크게 5가지 제품군으로 이루어진다.

<그림 18> SOA 서비스 플랫폼 구조도 예시

1) 비즈니스프로세스관리 (BPM, Business Process Management)2) SOA 미들웨어 (ESB, Enterprise Service Bus)3) 보안 (Security)4) 서비스관리 (WSM, Webservices Management)5) 서비스 레지스트리 및 레포지토리 (Registry & Repository)

예시

가. 공공부문 서비스 공유 플랫폼 구성방안 (출처 : 삼성SDS, 2007.09)서비스 공유 플랫폼은 서비스 기반 아키텍처의 핵심역할을 수행하며, 서비스의 메시지 전송관리, 서비스 모니터링, 서비스 보안/인증관리를 수행하는 서비스 오케스트레이션 서버와 서비스 등록/버전/이력관리의 레지스트리 서버로 구성된다.

TTAx.xx.xxxx/R127


서비스 공유 플랫폼의 기능을 부문별로 살펴보면 다음과 같다.

1) 서비스 모니터링 운영중인 서비스의 기동현황 및 성능관리(SLA Service Level Agreement 등)를 수행하며 이를 위한 보고서를 지원함

2) 메시지 전송관리 서비스 Deploy관리, 메시지 변환처리, 서비스 라우팅, 서비스 브로커링 및 서비스 처리과정의 로그관리와 오류처리를 수행하는 것으로 SOA미들웨어(ESB, Enterprise Service Bus) 기반임

3) 서비스 보안/인증 관리 서비스 인증, 메시지 보안처리 및 서비스 보안지원을 처리하는 것으로 GPKI, 공인보안모듈이 적용되어야 함

4) 서비스 레지스트리 개발된 서비스 등록, 서비스 운영환경 검증 및 반영을 위한 버전관리, 이력관리를 수행함

5) 서비스 운영체계 서비스 개발에서 검증, 운영, 관리, 폐기까지 전과정의 생명주기(Lifecycle)을 관리하는 운영체계를 의미함

나. 서비스 플랫폼 (출처 : Gartner, 2006)

TTAx.xx.xxxx/R128

Application Server, TPM

Portal,Intelligent Client

Application Integration,Adapters

Management,Security

Design,Development

Tools

ESB

Middleware:Request/reply InteractionMessaging InteractionInternet/Web Standards Basic Integration (Transformation and routing)Basic Quality of ServiceExtensibility (for adapters and other plug-ins)

Metadata:Service InterfacesService Properties

RulesPolicies

Network TopologyData Models, Schemas

Maps of Assemblies and Flows

BPM,Workflow

MDB

ESB: enterprise service busMDB: meta database


<그림 19> 서비스 플랫폼

미들웨어 역할을 수행하는 SOA 미들웨어(ESB)와 메타데이터 역할을 수행하는 메타데이터베이스(MDB, Meta database)를 중심으로 통합/어댑터, 어플리케이션서버, 포탈, 설계/개발도구, 관리/보안, 프로세스관리(BPM) 으로 구성된다.

3.4 프로세스

3.4.1 개요

3.4.1.1 정의

프로세스란 SOA를 추진(도입, 구축, 관리)하기 위한 절차와 그 사이의 관계를 정의하고, 정의된 절차에서 수행되어야 할 작업 및 작업을 위한 입력물과 작업에서 도출되어야 하는

출력물을 프로젝트 추진 단계 별로 규정해 놓은 것이다.

3.4.1.2 필요성

프로세스를 살펴봄으로써 SOA를 추진하는 과정에서 수행되어야 할 일과 도출되어야 하는 출력물을 추진 단계에 따라 이해할 수 있게 된다. 이를 통해서 SOA 추진을 위해서 투입되어야 할 인적 물적 자원에 대한 계획을 수립할 수 있게 된다. 또한 각 단계의 출력물을 통하여 각 업무의 수행 완료 여부 및 평가가 가능하다.

TTAx.xx.xxxx/R129

계획 (Plan) 아키텍트 (Architect) 명세화 (Specify)

설계 (Design)조립 (Assemble)실행 (Execute)

계획 수립 아키텍처 및 서비스 모델링

구축운영

계획 수립아키텍처 및 서비스 모델링

구 축 운 영



SOA 참조 프레임워크 내의 프로세스는 ‘계획 수립’, ‘아키텍처 및 서비스 모델링’, ‘구축’, ‘운영’의 네 단계로 정의하였다. 이는CBDI의 서비스 지향(SO) 프로세스와 서비스 지향(SO) 프로세스의 CBDI의 순차적인 수행 단계를 기반으로 하여 각 단계의 의미와 표현을 국내 실정에 맞도록 수정하였다. 또한 전체 단계를 4 단계로 단순화하여 복잡도를 줄이고자 했다.

위와 같은 기준을 갖고 SOA 추진 단계를 기준 SOA를 계획(Plan)하는 ‘계획 수립’ 단계, 서비스와 서비스를 위한 플랫폼을 위한 구조를 잡는 ‘아키텍처 및 서비스 모델링’ 단계, 서비스의 구현과 이를 이용하여 비즈니스 서비스를 조립하는 ‘구축’ 단계 그리고 구축 되어진

SOA 환경을 관리하고 감시하는 ‘운영’의 네 단계로 나누어 정의하였다.

<그림 20> CBDI의 SO 프로세스의 순차적 진행 단계4

3.4.1.4 개념도

아래의 <그림 21>은 본 문서에서 정의한 프로세스의 네 가지 구성 요소(계획 수립, 아키텍처 및 서비스 모델링, 구축, 운영)를 도식화한 것이다.

<그림 21> 프로세스의 구성 요소 간의 관계

3.4.2 구성 요소

4 CBDI Journal (February 2007)TTAx.xx.xxxx/R130


3.4.2.1 계획 수립

정의

계획 수립은 전략적으로 결정된 SOA를 추진함에 있어서 가장 먼저 선행이 되어야 할 절차로 조직에서 추구하는 전략적인 목표를 달성하기 위한 SOA 추진을 기획하는 단계이다. 즉, SOA를 추진함으로써 이루고자 하는 조직의 목표를 이루기 위해서 기존 조직 내의 업무와 IT 환경을 분석하고 이를 바탕으로 추진하는 SOA에서 갖추어야 할 요구 사항 들을 정의함으로써 IT 환경의 발전 방향을 정의하는 단계이다.

필요성

계획 수립의 절차에서는 전략적으로 SOA 추진 목표를 이루기 위한 요구 사항 들이 도출 된다. 이 단계에서 도출된 ‘비즈니스 요구 사항 정의서’는 다음 단계인 아키텍처 및 서비스 모델링 작업의 기반이 된다.즉, 이 단계에서 이루어지는 작업은 SOA 추진의 큰 그림을 그리는 작업이 되며, 이어지는 다른 작업 들의 방향성을 제시하게 된다.

주요 내용

SOA 추진에 있어서 ‘계획 수립’의 단계는 SOA에서 제공되는 서비스에 대한 사용자의 요구 사항이 구체화되는 단계로, ‘서비스 지향 비즈니스 요구 사항 정의’ 절차를 포함한다. 이 단계에서 이루어져야 할 작업은 아래 <표 4-4-2-1>과 같다. 업무 내용을 살펴 보면, 설정된 SOA의 전략적인 목표를 바탕으로 SOA 업무 기준을 정립하고, 이를 바탕으로 업무에 대한 설계 문서, 그리고 비즈니스 요구 사항 정의서를 만드는 작업 등이 포함된다.

절차 세부 절차 입력물 출력물

서비스 지향

비즈니스 요구

사항 정의

서비스 지향

비즈니스 모델

작성

설정된 전략적인

비즈니스 목표와

아키텍처

서비스 지향 비즈니스 모델

서비스 지향

비즈니스 설계

서비스 지향비즈니스

모델

서비스 지향 비즈니스 설계

문서

비즈니스

요구사항 정의

서비스 지향비즈니스

모델

비즈니스 요구 사항 정의서

<표 1> 계획수립 단계의 작업 내용

위의 ‘계획 수립’ 단계의 세부 업무간의 관계는 <그림 22>에서 도식화하였다.

TTAx.xx.xxxx/R131


<그림 22> 계획수립 단계의 작업의 개념도

3.4.2.2 아키텍처 및 서비스 모델링

정의

‘아키텍처 및 서비스 모델링’은 거버넌스 프로세스에서의 결정과 앞의 계획 수립 단계에서의 출력물을 바탕으로 SOA를 위한 아키텍처와 필요로 하는 서비스, 그리고 서비스를 운영하기 위한 플랫폼을 설계하는 단계이다.

필요성

아키텍처 및 서비스 모델링 단계는 앞의 계획 수립의 단계에서 도출된 SOA에 대한 요구 사항을 보다 구체화시켜서 다음의 ‘구현’ 단계에서 바로 사용할 수 있는 구체적인 SOA 플랫폼과 서비스 들의 사양을 도출하게 된다.이 단계에서 작성되는 자료는 SOA 추진에 참여하는 각 팀 간의 원활한 의사 소통과 협업을 위한 바탕이 되며 추진하는 SOA의 구성 요소(서비스와 플랫폼)의 기능에 대한 설명과 구현 방안 및 SOA 운영 관리를 위한 입력물이 된다.

주요 내용

‘아키텍처 및 서비스 모델링’ 단계는 ‘아키텍처 설계’, ‘서비스 모델링’, ‘서비스 명세 작성’, ‘서비스 플랫폼 설계 및 검증’ 절차를 포함한다. 이 단계에서 이루어져야 할 작업은 아래 <표4-2>와 같다.

TTAx.xx.xxxx/R132

정보통신(영문)단체표준전체적으로 보면 이 단계에서는 SOA를 위한 아키텍처 정의와 제공되어질 SOA 서비스 들에 대한 설계 그리고 이 서비스 들을 제공하는 바탕이 되는 서비스 플랫폼에 대한 설계가 여기에

포함된다.


아키텍처 설계 SOA 참조 아키텍처 설계

및 개선

SOA 도입 계획서 SOA 참조 아키텍처

SOA 보안 참조 아키텍처 설계

및 개선

계획 수립 단계의 3가지 출력물, 기존 IT 전략 및 아키텍처, SOA 참조 아키텍처

SOA 보안 참조 아키텍처

서비스 모델링 서비스

포트폴리오 정의

계획 수립 단계의 3가지 출력물, 기존 IT 전략 및 아키텍처

서비스 포트폴리오 정의서

서비스 식별/정의

서비스 포트폴리오

정의서, 기존 IT 서비스 후보 목록

(갱신된) 서비스 목록

서비스 명세

작성

서비스 명세

설계

서비스 설명(서비스 포트폴리오 정의서의

일부)

서비스 명세서

서비스 검증 및

공지

서비스 명세서 (확인된)서비스 명세서, (갱신된) 서비스 목록

서비스 플랫폼

설계 및 검증

서비스 플랫폼

설계

기존 IT 전략 및

아키텍처, 서비스 포트폴리오 정의서, SOA 참조 아키텍처, SOA 보안 참조

아키텍처

서비스 플랫폼 설계 명세서

서비스 플랫폼

검증

서비스 플랫폼 설계

명세서

검증된 서비스 플랫폼

<표 2> 아키텍처 및 서비스 모델링 단계의 작업 내용

위의 ‘아키텍처 및 서비스 모델링’ 단계의 세부 업무간의 관계는 <그림 23>에서 도식화하였다.

TTAx.xx.xxxx/R133


<그림 23> 아키텍처 및 서비스 모델링 단계의 작업 개념도

3.4.2.3 구축

정의

‘구축’은 아키텍처 및 모델링의 출력물인 서비스 및 서비스 플랫폼에 대한 설계 명세서를 바탕으로 SOA 서비스와 플랫폼을 구현하는 작업이다. 즉, 앞의 ‘아키텍처 및 서비스 모델링’ 단계의 출력물인 서비스 플랫폼 명세서, 서비스 목록, 서비스 상세 설계서 등의 구체적인 설계 문서를 참조하여 이를 구현한 SOA 환경을 완성하는 단계이다.

운영자 입장에서는 서비스를 운영하기 위한 플랫폼을 설치하고 구성하는 작업이 이루어지고, 서비스를 제공하는 제공자 입장에서는 서비스를 구현하는 작업을 해야 하며, 서비스를 사용하는 사용자 입장에서는 서비스 지향(SO)적으로 업무의 개선 및 제공자에 의해서 제공된 서비스를 조립하여 개선된 업무를 구현하기 위한 애플리케이션을 만드는 작업이 이루어진다.

필요성

‘구축’ 단계는 앞서 ‘아키텍처 및 서비스 모델링’ 단계에서 문서화된 SOA 서비스와 서비스가 수행될 플랫폼의 소프트웨어 및 하드웨어 시스템을 구현하는 단계로서 이 단계에서 실제

TTAx.xx.xxxx/R134

정보통신(영문)단체표준운영할 SOA 환경이 구축되게 된다. 이 단계에서 구축되는 SOA 환경 및 결과 자료는 뒤의 ‘운영’ 단계에서 SOA를 위한 서비스를 배치하고 플랫폼을 관리하는 지침이 된다.

주요 내용

‘구축’ 단계는 ‘비즈니스 개선’, ‘서비스 조립’, ‘서비스 구현’, ‘서비스 플랫폼 설치’ 절차를 포함한다. 이 단계에서 이루어져야 할 작업은 아래 <표 4-4-2-3>과 같다.이 단계에서는 SOA 플랫폼에 대한 설치, 설계에 따른 서비스 작성 및 테스트, SOA를 바탕으로 개선된 업무 절차 정의 및 작성된 서비스를 조립하여 개선된 업무를 위한

애플리케이션 구축이 이루어지게 된다.


비즈니스 개선 서비스 지향

비즈니스

개선사항 정의

비즈니스 요구 사항

정의서

서비스 지향 비즈니스 개선

사항 정의서

서비스 지향

비즈니스 개선

서비스 지향 비즈니스

개선 사항 정의서

개선된 비즈니스 시스템

정의서, 개선된 비즈니스 프로세스

서비스 조립 서비스 조립

설계

개선된 비즈니스

시스템 정의서, 공지된 서비스 목록 및 명세

서비스 조립 명세서

서비스 조립 서비스 조립 명세서 구현 및 테스트된 서비스

조립물(애플리케이션)서비스 구현 서비스 설계 및

코딩

서비스 명세서 서비스 구현물

서비스 테스트 서비스 구현물 검증된 서비스 구현물

서비스 배치 절차서

서비스 플랫폼

설치

서비스 플랫폼

설치

서비스 플랫폼 설계

명세서, 검증된 서비스 플랫폼

설치된 서비스 플랫폼

<표 3> 구축 단계의 작업 내용

위의 ‘구축’ 단계의 세부 업무간의 관계는 <그림 24>에서 도식화하였다.

TTAx.xx.xxxx/R135


<그림 24> 구축 단계의 작업 개념도

3.4.2.4 운영

정의

‘운영’ 단계는 앞서 구현된 서비스 들을 사용할 수 있도록 배치하고 관리하며, 서비스 들의 운영 상태 및 이를 제공하는 전체 시스템의 동작 상태를 감시하여 상태에 대한 정기적인

보고를 하는 단계이다. 즉, 이 단계에서는 서비스 및 시스템을 운영하는 운영자의 입장에서 전체적인 시스템 운영 관리를 하는 작업을 하게 된다.

필요성

운영 단계는 구축된 SOA 환경을 원활하게 사용 가능하도록 서비스들에 대한 감시와 관리를 하는 단계로서, 이 단계에서 얻어지는 자료는 시스템에 새로운 서비스를 추가하거나 혹은 이전에 구현된 SOA 서비스 혹은 플랫폼에 대한 수정과 보완 작업을 위한 참고 자료로 사용된다.

TTAx.xx.xxxx/R136


주요 내용

‘운영’ 단계는 ‘서비스 운영 및 관리’ 절차를 포함한다. 이 단계에서 이루어져야 할 작업은 아래 <표 4>와 같다.

이 단계의 주요 작업을 살펴보면, 앞의 ‘구축’ 단계에서 만들어진 서비스들을 SOA 플랫폼 상에 배치를 하고, 그 서비스 들의 수행 결과를 측정하여 운영 지침에 맞는 관리 보고서를 만드는 작업이 포함된다. .


서비스 운영 및

관리

서비스 배치 서비스 배치 절차서, 검증된 서비스 구현물

배치된 서비스들

서비스 운영 배치된 서비스들 서비스 수행 측정치

(metrics)서비스 관리 서비스 수행 측정치,

서비스 운영 가이드

서비스 관리 보고서

<표 4> 운영 단계의 작업 내용

위의 ‘운영’ 단계의 세부 업무간의 관계는 <그림 25>에서 도식화하였다.

.

<그림 25> 구축 단계의 작업 개념도

3.5. 거버넌스

3.5.1 개요(역할) 3.5.1.1 정의

TTAx.xx.xxxx/R137

정보통신(영문)단체표준기업 거버넌스(Corporate Governance)는 기업이나 기관 내에서의 조직의 책임과 역할의 정의, 이에 따른 의사결정권의 부여, 의사결정시 준수할 정책(Policy) 및 평가지표와 같은 기업을 통제하기 위한 메커니즘이다. IT 거버넌스는 기업 목표 달성을 위하여, IT 및 관련 프로세스에 대한 위험요소에 대한 투자 효과성 판단 하에 기업을 통제/관리하는 조직 관계 및 프로세스 구조를 말한다.

SOA 거버넌스는 이러한 IT 거버넌스가 서비스 지향 개념과 관련 원칙 및 분산 아키텍처측면에서 적절히 관리되도록, SOA 프로세스를 중심으로 하여 확장된 것이다.

전체적인 거버넌스간 상관관계는 <그림 26>과 같이 표현된다.

<그림 26> 거버넌스 관계도

3.5.1.2 필요성

SOA는 서로 다른 조직(기획 조직, 현업 조직, IT 조직 혹은 관련된 협력회사나 기관)이 연관되는 범 부서적인 성격을 가진다. 즉, 서비스 사용자, 서비스 제공자, 서비스 관리자가 각각 다른 조직/회사에 속할 수 있다. 그러므로, 비즈니스와 IT 조직 전반에 걸친 범 부서적인 성격이 강조되는 SOA의 성공적인 적용을 위해서는, 이를 효과적으로 통제할 수 있는 SOA 거버넌스가 필수적이다.


TTAx.xx.xxxx/R138

정보통신(영문)단체표준SOA거버넌스의 전체적인 측면의 이해를 위하여, 본 지침에서는 CBDiForum의 SOA 선순환 모델(Excellence model)5을 구성요소 도출을 위한 기반으로 하여 국내 상황에

맞도록 일반화 하였다.

SOA 선순환 모델은 SOA 프로세스의 관리/통제를 위한 프로세스 부문, 이를 지원하는 거버넌스 지원 부문(enabler), 그리고 거버넌스 프로세스에 의해 제공되는 결과 부문, 성공적인 결과에 의한 지원부문에 대한 투자 정당화로서 이루어 진다. 이러한 SOA 선순환 모델을 근간으로 하여 다음과 같은 구성요소를 도출하였다.

거버넌스 지원 부문 (enabler) : 조직, 거버넌스 플랫폼 거버넌스 프로세스 부문 : 거버넌스 프로세스, 거버넌스 프레임워크, 거버넌스 결과 부문 : 성과지표와 투자수익(ROI)

<그림 27> CBDi Forum의 SOA 선순환 모델과 SOA 거버넌스 구성 요소

3.5.1.4 주요 내용 및 개념도

SOA 거버넌스는 SOA를 구축하기 위하여 누가 무엇을 어떻게 해야 하고, 성과 측정은 어떻게 하는 지를 제시한다. 즉, 비즈니스 요구와 목표를 달성하기 위해 SOA이행을 효율적으로 기획, 결정, 운용, 통제하기 위해 필요한 규칙, 프로세스, 측정 기준, 조직 구성들을 정의한다.

SOA 거버넌스는 서비스 개발 및 운영 측면과 서비스를 IT 자산으로서 관리하는 측면으로서 일반적으로 다음과 같은 활동을 수행하게 된다.

5 CBDiForum의 SOA 선순환 모델(Excellence model) : CBDiForum의 SOA 선순환 모델은 경영과 업무, 직장환경, 조직 구성원의 자질까지도 품질개념에 넣어 관리하는 전사적 품질 관리(TQM, Total Quality Management) 개념을 기반으로 구성되었다.

TTAx.xx.xxxx/R139

정보통신(영문)단체표준 서비스 식별, 설계, 명세 뿐만 아니라, 서비스 펀딩, 서비스 재사용을 위한 공유 및 이에 대한 보상이 포함되도록 IT 프로세스를 개선

보안, 모니터링, 성능, 버전 관리 및 공동 사용을 위한 IT 플랫폼 개선 레지스트리/리포지터리와 서비스 개발/배포/관리를 위한 도구 사용을 위한 규정된 수행 절차 구축

역할과 책임의 재정의와 이와 관련된 IT와 비즈니스 역할에 대한 교육 및 훈련 SOA 거버넌스의 성공적인 적용을 위한 IT 조직 재구축

전체적인 SOA 참조 프레임워크상에서 SOA 거버넌스의 각 구성 요소는 원칙, 아키텍처, 프로세스들을 종합적으로 연계하게 되며, 다음과 같이 표현될 수 있다.

<그림 28> SOA 거버넌스 개념도

3.5.2 주요 구성요소

3.5.2.1 SOA 거버넌스 조직

정의

SOA 거버넌스 조직은 SOA 목적 달성을 위한 IT 투자, 설계에 대한 의사결정과 구축을 가이드하는 범 부서적인 팀이다.

TTAx.xx.xxxx/R140

정보통신(영문)단체표준필요성

SOA 거버넌스는 기술적인 측면과 함께 조직적인 측면도 강조된다. 의사 결정 수행시 관계되는 표준(Standard) 및 정책(Policies)을 준수하도록 하기 위하여, 적절한 조직의 관여와 해당 조직이 해야 할 일이 무엇인지 규정하는 것이 중요하다. SOA 거버넌스 조직은 기존 조직과 효과적인 연계를 위하여 필요하며, 전사차원의 SOA 적용을 원할히 하고 필요한 모든 역할과 책임을 확인하기 위하여 필요하다.

주요 내용 및 개념도

SOA 거버넌스 조직은 각 비즈니스 라인의 역할과 경계를 파악하여 범 부서적인 조직 구조로서 모든 관점을 조정할 필요가 있다. 이 때, 각 기관의 문화, 조직 집중 및 분산의 정도, 비즈니스 조직과 IT 조직간의 상호 의사소통 수준을 고려한 역할과 책임의 부여를 통하여, 올바른 결정을 수행할 수 있는 SOA 거버넌스 조직을 구성한다. .

SOA 거버넌스 조직을 형성하는 일반적인 두가지 접근 방법은 다음과 같다.

중앙 SOA 거버넌스 조직전사에 최적화되어 있다. 중앙 거버넌스 협의회는 각 비즈니스 도메인과 기술 문제 전문가가 대표로 구성한다. 중앙 거버넌스 협의회는 새로운 서비스의 구현을 승인하기 전에 기존 서비스의 변경뿐 아니라 서비스의 추가 및 제거를 검토한다.

분산 SOA 거버넌스 조직분산 거버넌스 조직은 분산된 부서들에 최적화되어 있다. 비즈니스 부서 각각이 각 조직내에 서비스를 제공하는 방법을 통제한다. 이 방법은 기능적 서비스 도메인 접근 방법이 필요하다. 중앙 위원회는 지침과 표준을 제공한다.

<그림 29> SOA 거버넌스 조직 개념도

TTAx.xx.xxxx/R141

정보통신(영문)단체표준일반적으로, SOA 로드맵을 통제하고 프로젝트를 지원하기 위하여, 기존 조직내 SOA거버넌스 조직이 완전히 내재화되기 전까지, SOA 추진단(CoE, Center of Excellence)를 설립한다. 이러한 SOA 추진단내 존재하는 내부 상세 조직 구성원은 전사 차원의 SOA 전환 및 적용을 위한 중심점 및 촉매제 역할을 수행하며, 다음과 같은 책임을 부여하는 것이 일반적이다.

전략, 전술, 운영 레벨에서 비즈니스 요구 사항에 부합된 SOA 참조 프레임워크의 구현 및 유지

아키텍처 청사진, 기업 템플릿, 설계 자산과 같은 기술 결과물에 대한 권한 및 자산 재활용 리더십(thought leadership) 상담 및 조언

교육

베스트 프랙티스, 정책(Policies) 및 수행 절차의 적절한 의사소통 프로젝트 팀에게 방향을 제시할 수 있는 SOA 전문가 파견 프로젝트 예산 결정의 적절한 통제

예시

다음은 전사차원에서의 SOA 거버넌스 조직을 전략/관리/실행과 같은 통제 수준 측면과 현업/IT/임원(CIO/CTO등)와 같은 역할 측면에서 구성한 사례이다. ( Source : IBM )

<그림 30> SOA 거버넌스 조직 예시 – IBM

TTAx.xx.xxxx/R142

정보통신(영문)단체표준 통제 수준 측면 - 전략부문, 관리 부분, 실행 부문의 세가지 수준에서의 고려 : 이러한 관점은 거버넌스 프로세스에 의해 구현되는 의사결정 통제 수준 및 결재 라인과

관계된다.

현업/IT/임원(CTO/CIO) 역할 측면- 현업, IT, 임원(CTO/CIO등)와 같이, 수행 책임과 역할이 존재하는 조직으로 구분한 것으로 SOA 추진팀은 이 중 일부와 연계되어 구성된다.

다음은 SOA 거버넌스 조직의 또 다른 구성으로 SOA 추진단을 구성 예이다. 이 예에서는 (1) 전략 통제 부문에 해당하는 임원, (2) 관리 통제 부문에 해당하는 아키텍처 검토 위원회와 아키텍처 오피스, (3) 실행 통제 부문에 해당하는 SOA 전문 조직과 실제 프로젝트를 수행하는 프로젝트 이니셔티브팀으로 구성하였다. SOA추진단 관리 통제를 위한 전담 조직과, 실행 통제를 위한 필요시 지원팀으로 구성하였다.

<그림 31> SOA 추진단(CoE, Center of Excellence) 예시 – IBM

3.5.2.2 거버넌스 프레임워크

정의

거버넌스 프레임워크는 조직에서 SOA가 필요한 수준으로 적용되고 일관성을 제공할 수 있도록 확인하는데 필요한 전체 거버넌스 대상 분야를 정의한 것이다.

필요성

TTAx.xx.xxxx/R143

정보통신(영문)단체표준SOA 거버넌스의 구현을 위하여, SOA 목적/원칙에 기반한 거버넌스 대상 분야의 선정이 필요하다. 거버넌스 프레임워크는 거버넌스의 관심 적용 범위/수준을 전체적인 차원에서 판단할 수 있는 대상 분야를 제공하며, 해당 대상 분야에 대해 최종적으로 거버넌스 프로세스로 구현하도록 하여, SOA 프로세스가 전체적으로 통제/관리되는 기반을 제공한다.


SOA 거버넌스는 성공적인 SOA 적용을 위해 기업의 비즈니스 목표들에 우선 순위를 부여하고, 목표 달성을 지원하기 위한 전략적, 기능적, 운영적인 수준의 관리 구조를 제공할 필요가 있다. 이러한 관리 대상 분야는 거버넌스 프레임워크에서 선택된다. 거버넌스 프레임워크에 의해 제공되는 거버넌스 대상 분야는 거버넌스 프로세스로서 거버넌스 대상

프로세스와 연계(Joint-process)되어 실행된다.

<그림 32> 거버넌스 프레임워크 및 구성 요소(거버넌스 대상 분야)의 개념도

예시

CBDIForum에서는 거버넌스 프레임워크 및 구성 요소를 이루는 거버넌스 대상 분야로서 포트폴리오 거버넌스, 아키텍처 거버넌스, 프로비저닝 거버넌스, 사용 거버넌스, 운영 거버넌스, 조직 거버넌스, 비즈니스 거버넌스를 제시하고 있다. 각 거버넌스 프레임워크의 대상 분야는 다음 내용을 중심으로 한다.

- 포트폴리오(Portfolio) 거버넌스 - 서비스 포트폴리오 관리를 위한 관점

TTAx.xx.xxxx/R144

정보통신(영문)단체표준 전사 혹은 프로젝트 수준의 서비스 분리

비즈니스 도메인 별 서비스 규명 및 관리

서비스와 다른 자산들과의 연관 메타 데이터 유지

- 아키텍처(Architectural) 거버넌스 – SOA지향적 아키텍처 일관성 유지를 위한 관점 서비스 구축 라이프사이클 전반에 걸쳐, SOA 대원칙(Principles) 준수를 위한 정책

(Policy) 적용 서비스 구축 라이프사이클 전반에 대하여, 아키텍처 리뷰 기술 뿐 아니라, 대원칙 및 아키텍처에 대해서도 일관된 SOA 교육 수행 전사 공통 SOA Reference model과 아키텍처 수립 계층 기반 비즈니스 서비스 아키텍처

- 프로비저닝(Provisioning) 거버넌스 - 서비스 소싱 결정을 위한 점검을 위한 관점 서비스 프로비저닝을 위한 비즈니스 전략

애플리케이션 조립과 서비스 프로비저닝의 별도 액티비티 분리

애플리케이션 조립과 서비스 프로비저닝간 공식적인 서비스 명세(rich service specification)에 의한 계약 형태로, 서비스 공급망 구성

- 사용(Usage) 거버넌스 – 서비스 사용 제어를 위한 점검을 위한 관점 레지스트리를 사용하여, 허용된 외부 서비스 및 내부 서비스 리스트 제공 런타임시 비인가 받은 사용 거부 – 런타임 엔진에 의한 정책 적용

일관성을 위해 특정 도메인의 필수 서비스 사용 강제화 – 고객 관리 서비스, 정책 및 규제준수 서비스

전사 서비스의 필수 사용

- 운영(Operational) 거버넌스 – QoS 유지를 위한 점검을 위한 관점 정책에 기반한 SOA 인프라스트럭처의 선택 ( 제품 및 기술 선택시 정책이 주요 결정 기준 )

정책(Policy)를 별도의 자산으로 관리 서비스 소비자에 대한 SLA와 같은 정책/계약의 적용 메시지 수준의 정책 적용을 위한 비즈니스 룰 엔진의 사용

- 조직(Organizational) 거버넌스 – SOA를 위한 조직의 역할 및 책임 점검 서비스 제공자/소비자 액티비티의 조직적 분리

TTAx.xx.xxxx/R145

정보통신(영문)단체표준 공통 서비스 제공 부문의 분리

공통 서비스에 대한 공통 혹은 전사 펀딩 체계

공통 서비스 펀딩 투자에 대해, 사용 기반 과금 조직의 자원 할당에 대한 프로비저닝(Provisioning) 전략 적용 조직간 서비스 명세에 기반한 계약

- 비즈니스 거버넌스 – 비즈니스 목표 지원 관점 비즈니스와 IT간 SOA 공동 Ownership SOA 사용에 대해 관련 현업의 이해 비즈니스 부문이 이해할 수 있는 단위로 SOA가 매핑 일관된 비즈니스 정책 적용을 위해 서비스가 단위로 사용

비즈니스 정책 준수 여부가 실시간으로 제공되는, 비즈니스적으로 의미 있는 서비스의 운영현황 사용

다음은 IBM에서 제시하는 거버넌스 대상 분야인 규제 준수, 예외 처리 및 이의 신청, 지속성, 커뮤니케이션, 각 대상 분야별로 거버넌스 프로세스가 추가될 수 있다.

- 규제 준수(Compliance) 기존 SOA의 변화를 검토하고 승인하며 거버넌스의 지침에 따라 결정하는 구조회된 접근 방법 정의

공식화된 설계와 서비스 평가 검토 수행

- 예외 처리 및 이의 신청(Exception & appeal) SOA 이의 신청을 위한 수단 제공 독특한 비즈니스 요구사항을 충족하기 위한 SOA 원칙/아키텍처/프로세스 등에 예외를 허용

- 지속성(Vitality) 새로운 서비스가 통합됨에 따라 SOA의 유지 보수 및 커뮤니케이션 보증 변화가 문서화 되고 커뮤니케이션됨

- 커뮤니케이션(Communication) 액세스를 필요로 하는 모든 사람들에게 SOA를 이용 가능하게 함 SOA의 중요성을 잘 이해할 수 있도록 홍보

3.5.2.3 거버넌스 프로세스

TTAx.xx.xxxx/R146

정보통신(영문)단체표준정의

거버넌스 대상 프로세스(예, SOA 구축 및 운용 프로세스) 에 대해, 주요 관심 대상 분야별로 추가된 관리 및 점검을 위한 프로세스이다.

필요성

성공적인 SOA 적용을 위하여, 모든 IT 조직은 통제 프로세스를 필요로 한다. 이 프로세스들은 조직의 규모에 따라 적절한 수준에서 실행될 필요가 있다. 즉, 전략 개발, IT 기술 기획, 포트폴리오 관리, 소싱, 혁신 관리, 아키텍처 관리 등 관심 대상 분야별로 필요한 점검 및 관리 프로세스가 기존 거버넌스 대상 프로세스에 추가되어, 유기적인 통제 메커니즘을 형성할 필요가 있다.


거버넌스 프로세스는 거버넌스 대상 분야별로 필요한 점검 프로세스가 된 것이다. 즉, 거버넌스 프레임워크의 필요 거버넌스 대상 분야 별로, SOA 구축 및 운용 프로세스에 점검 및 관리 프로세스를 추가하여, 거버넌스 미적용 상태인 SOA 구축 및 운용 프로세스를 거버넌스 적용 프로세스로 변환하게 된다.다음은 SOA 프로젝트시의 거버넌스 대상 프로세스(예, SOA 구축 및 운영 프로세스)에 거버넌스 프로세스가 어떻게 추가되어 연계되는지의 관계를 보여준다.

<그림 33> SOA 구축 및 운영 프로세스에 관련된 거버넌스 프로세스 개념도

예시

다음은 IBM의 거버넌스 대상 분야인 지속성(Vitality), 규제 준수(Compliance),

TTAx.xx.xxxx/R147

정보통신(영문)단체표준커뮤니케이션(Communication), 예외 및 이의 신청(Exception & appeal)을 “서비스 식별(identify services) 프로세스에 적용하여, 거버넌스 미적용 프로세스(non-governed process)를 거버넌스 적용 프로세스(well-governed process)로 전환한 예이다.

<그림 34> 거버넌스 프로세스 및 관련 신규 역할 추가 예시 – Source : IBM

TTAx.xx.xxxx/R148

정보통신(영문)단체표준3.5.2.4 거버넌스 플랫폼

정의

거버넌스 플랫폼은 효과적인 거버넌스의 구현을 위한 IT 지원 도구를 전체적으로 통칭한다.

필요성

효과적인 거버넌스 수행을 위해서는, 특정 조직에 의해 강요된 규칙의 준수라는 차원보다는 좀더 자연스럽게 내재화되어, 사람들이 올바른 결정을 적시에 내릴 수 있도록, 관련 정책 시행(Policy enforcement) 및 라이프사이클 관리와 같은 거버넌스 구성 요소가 생성 및 자동화될 수 있는 플랫폼이 필수적이다.

주요 내용

SOA 거버넌스의 기업내 성공적인 적용을 위해서는 단순한 기술적인 역량뿐 아니라 조직 관리적 기술 역량도 필요하다. 대개의 경우, 엔터프라이즈 서비스 버스(ESB, Enterprise Service Bus)와 서비스 리포지토리(repository)만으로 협의의 SOA 거버넌스를 구현하는 경우가 많다. 그러나 실제로, SOA 거버넌스는 SOA 라이프사이클의 일부인 개발, 배포(deployment) 및 서비스 관리의 다양한 부문들에 대해, 여러가지 다양한 조직 관리적인 부문을 기술적으로 내재화하는 부문도 필요하며, 이러한 부문도 거버넌스 플래폼의 요소로서 고려하여야 한다. 그러므로, 효과적인 거버넌스 플랫폼의 적용을 위해서는 우선 조직측면의 거버넌스 모델을 정의한 후, 관련 기술 플랫폼 적용 방안을 검토하는 것이 필요하다.

예시

다음은 IBM의 SOA거버넌스 플랫폼의 전체 분류와 관련된 제품의 사례를 보여준다.

TTAx.xx.xxxx/R149


3.5.2.5 성과지표(KPI)

정의

성과지표는 SOA 목적에 따라 서비스를 운영하는 과정에서 수집되어 시스템/사용자 및 관련 그룹의 성과를 확인할 수 있는 지표이다. 성과지표는 플랫폼으로부터 자동적으로 수집된 성과기준(metrics)을 구성요소로 하여 최종적인 비즈니스 목적과 결부된 성과 지표형태로 자동화 된다.

필요성

SOA 생명주기 전체에 걸쳐서 해당 서비스의 결과가 비즈니스의 목적에 맞는 지를 지속적으로 평가할 수 있는 체계가 필요하다. SOA의 목적과 연계된 성과지표(KPI)의 상태를 모니터링 하기 위해서는 관련 구성 요소를 이루는 성과 기준(metrics)에 대한 수집 및 평가가 우선적으로 필요하다.. 성과기준은 SOA 플랫폼으로부터, 서비스 운영 중에 수집되며, SOA의 가시성 부여를 위해 SOA 목적과 관계된 성과지표(KPI)의 형태로 종합되어, 비즈니스 대쉬보드 형태로 사용자에게 제공될 수 있다. 이렇게 성과지표는 비즈니스 평가의 기준 자료로서 비즈니스의 목적을 달성하기 위한 프로세스의 진단 및 지속적인 개선에 지속적으로

활용될 필요가 있다.


SOA 선순환 모델(Excellence Framework)6의 지원 부문(Enabler)을 기준으로 비즈니스 목적(Goal)을 분석하고 이를 위한 성과지표(KPI)를 정의한다.

6 Source : CBDiJournal Feb, 2006TTAx.xx.xxxx/R150

정보통신(영문)단체표준이러한 성과지표(KPI)를 구성하기 위한 구성 요소인 성과 기준(metrics)은 SOA 플랫폼에 의해서 자동화되어 수집된다.

<그림 35> SOA 가치 모델링에 기반한 성과지표(KPI) 개념도

예시

다음은 CBDiForum의 SOA 선순환 모델의 지원 부문(enabler) 역량 영역을 기준으로 SOA 비즈니스 가치를 성과지표(KPI)와 연결한 예이다.

TTAx.xx.xxxx/R151

정보통신(영문)단체표준다음 예시에서는 비즈니스 목적 달성을 위한 KPI 구성을 위해, 다양한 성과 기준(metrics)와 성과 기준의 형태(평균, 합 등)가 조합된 것을 보여 주고 있다.

평가 영역 고객 만족

전략적 목적(Goal) 고객 만족도 15% 개선비즈니스 시나리오 계좌 검증 프로세스의 수행시간을 단축하여, 고객의 계좌 개설

요청에 대한 승인/거절을 통보하는 시간을 축소. 또, 신용 평가, 정보 수집 등을 자동화한다.

KPI “계좌 개설 프로세스” 평균 프로세스 수행시간KPI 정의 신규 상용 고객의 계좌의 승인/거절 통보를 위해 소요되는

수행시간의 평균값 (즉 주어진 시간동안의 모든 완료된 “계좌 검증 프로세스 수행시간”의 “총합”을 같은 시간 동안의 계좌

검증 “프로세스 수행 갯수”로 “나눈 것” )목표 허용 범위 목표 = 14 비즈니스 시간성과기준(metrics) “계좌 검증 프로세스 수행 시간”, “프로세스 수행 갯수”

3.5.2.6 투자수익(ROI)

정의

투자수익(ROI)는 가장 널리 사용되는 경영성과 측정기준 중의 하나로, 투자 대비 이익 혹은 비즈니스 가치 등이 제공된 비율을 의미한다. 투자 수익(ROI)는 정성적인 측면과 정량적인 측면에 대한 고려가 모두 포함되어야 한다.

필요성

프로젝트에 대한 투자 결정은 항상 어려운 분야 중 하나이다. 특히, SOA 프로젝트의 경우 장기적인 관점에서의 장점이 제시되는 경우가 많고, 이를 수치화하여 제공하는 표준 모델이 일반화 되어 있지 않다. 그러나 예산 집행 부서에서는 투자 결정 범위를 좁히고 위험요소를 최소화하기 위해 관련 프로젝트에 대한 투자수익(ROI)이 제시되지 않는 경우, 프로젝트를 승인하지 않으며, 그러한 프로젝트의 경우 임원진의 후원을 받기 힘들다. 그러므로 SOA 프로젝트를 위해서도, 관련 투자수익(ROI)부문에 대한 효율적인 접근 방안을 이해할 필요가 있다.


투자수익(ROI) 부문은 정성적 투자수익(ROI)와 정량적 투자수익(ROI) 부문을 동시에 고려할 필요가 있다. 특히, SOA 프로젝트의 경우, SOA의 특징인 비즈니스 측면에서의 재사용성 등 장기적 관점에서의 접근이 필요한 관계로, 정량적 투자수익(ROI) 부문에 대한 고려시 시간에 따른 투자 수익의 증가 부문에 대한 고려가 필요하다.

< 정성적 투자수익(ROI) >

TTAx.xx.xxxx/R152

정보통신(영문)단체표준SOA에 의한 정성적 투자 수익(ROI)은 다음과 같은 분야가 일반적으로 제시된다. - 유연성 증가- 비용 감소- 위험 감소- 매출 증대- 신규 제품 제공- 규제 준수정성적 투자 수익의 경우는 수치화해서 제공되지 않은 관계로, 일반적으로 업계의 구축 사례 및 이에 따른 효과를 제시함으로써 비즈니스 팀이나 임원진에게 제시된다.

< 정량적 투자수익(ROI) >SOA에 대한 정량적 투자 수익(ROI)를 명확히 하기 위해서는, 부분적인 투자수익 (ROI)가 아닌 전체적인 관점에서 접근이 필요하다. 즉, 자동차를 구성하는 하나하나의 부품적인 관점이 아닌 자동차 전체를 보는 입장에서의 접근이 필요하다. 정량적 투자 수익 계산을 위하여, SOA 투자수익(ROI)7은 제공 비즈니스 가치를 해당 구축

비용(소프트웨어, 하드웨어, 인건비)으로 나눈 것으로 일반적으로 계산될 수 있다. SOA ROI 분석을 위한 세가지 주요 요소는 다음과 같다.

SOA 고유의 비즈니스 가치 프레임워크 비용 프레임워크

SOA의 지속적 구축 횟수특징적인 것은 지속적 구축 횟수와 관련된 시간적인 개념이다. SOA의 경우, 투자 수익(ROI)에 있어서 핵심적인 고려 사항은 비용/이점에 대한 시간에 따른 가치 변화이다. 이러한 시간적인 요소에 대한 고려는 SOA의 재사용에 대한 부분을 충분히 반영하여, SOA의 기본 개념이 가지고 있는 가치 실현의 속도가 초기 투자시 반영이 적게 되는 단점을 보완할 수

있다.

SOA 투자수익(ROI) 분석을 위한 기본적인 ROI 기본 개념은 <그림 36>을 통해 이해할 수 있다. 시간적인 측면을 고려한 투자수익(ROI)산정의 개념은 <그림 36>에 나타난다.

7 Source : IBM Global Business Services – SOA , A Practical Guide to measuring return on that investment

TTAx.xx.xxxx/R153


<그림 36> SOA 투자수익(ROI)의 계산

아래 그림의 경우, Example 1과 Example 2의 두 가지 프로젝트 사례를 보여준다. 초기 투자 이후, SOA의 지속적인 적용에 의한 재사용의 효과를 적용하면, 두번째 구축부터는 구축 비용 감소에 의하여, 점진적인 SOA의 투자수익(ROI) 증가를 확인할 수 있다. 즉, (그림 x-x)와 같이 Example 1 프로젝트의 초기 구축시의 투자수익(ROI)이 두번째, 세번째 구축 프로젝트시 점진적으로 증가하는 것을 확인할 수 있다.

<그림 37> SOA 투자수익(ROI)의 시간에 따른 증가 개념도

예시

< 정성적 투자 수익 >CBDIForum에서 제시하는 다음의 SOA 비용 대비 이점의 예에서는 SOA로 인해 발생되는 추가 비용과 SOA에 의해 제공되는 일반화인 장점/비즈니스 가치를 보여준다.

TTAx.xx.xxxx/R154


다음 예시는, 전세계 11개 산업의 35개의 SOA 구축 프로젝트에 대한 결과를 분석하여 도출한, SOA 도입시의 주요 비즈니스 이점을 보여준다.

<그림 38> SOA 프로젝트의 가치 연구 – Source : IBM Global Business Services

< 정량적 투자 수익 >

TTAx.xx.xxxx/R155

정보통신(영문)단체표준다음 예시에서는, IBM Global Business Services의 SOA 투자수익(ROI) 계산을 위한 절차를 (1), (2), (3), (4)의 순서로 적용한, 정량적 계산 방법 및 관련 설명을 제시한다.

가. 전체 절차 예시(1). SOA 비즈니스 가치 프레임워크에서 관련 기대 효과 선택(2). 비용 적용 시나리오중 적용 가능한 부문 선택

– 전체 구축 시나리오(서비스 사용자 부문 및 서비스 제공자 부문 전체)- 서비스 사용자 시나리오 - 서비스 제공자 시나리오

(3). 초기의 간단한 ROI 계산(4). 2번째 혹은 그 이후의 구축시의 ROI 계산

나. 접근 절차 상세 설명 및 개념도 (1) 단계 - SOA 비즈니스 가치 프레임워크에서의 비즈니스 가치 즉 관련 기대 효과 선택 및 계산

SOA 비즈니스 가치 프레임워크에서 보는 바와 같이, SOA의 가치 중 “유연성 증가”는 “매출 증가” 및 “비용 감소”를 통해 “수익 증가”로 연결된다. 게다가 두가지 중요한 질적 요소, 즉 “운영 위험 감소”와 “규제 준수 능력 개선”은, 최종적으로는 “수익 증가”에 기여하는 두가지 질적 요소이다. SOA 가치의 특정 부문을 선택후 이와 연결되는 다양한 가치를 분리하여 생각하면 이 가치를 계량화할 수 있다. 즉, “재사용성 증가” “유지관리 비용 감소” “비용 감소”로 연결, 혹은 또 다른 경로로서, “재사용성 증가” “통합 시간 감소” “통합 비용 감소” 와 “비용 감소”로 연결된다. 어떤 경우든, 적용 가능한 가치의 재정적인 총합이 전체적인 가치가 된다. 물론 이러한 가치중 일부분(예, 변화 대응력 개선)은 계산이 힘들 수는 있으나, 현실적으로 중요할 수 있다. 만약 특정 SOA 가치가 숫자로 증명하기 힘들다면, 정성적 가치로 사용 가능하다.

(2) (3) 단계 - 비용 적용 시나리오 중 적용 가능한 부문 선택 및 초기 투자 수익(ROI)의 계산

초기 프로젝트의 비용 적용 시나리오 즉 구축 범위가 전체 구축 부문(범위 C)인지, 서비스 사용자 시나리오 부문(범위 A)인지, 아니면 서비스 제공자 시나리오 부문(범위 B)의 구축 부문인지를 선택 후 관련 비용을 소프트웨어, 하드웨어, 구축 인건비 측면의 비용의 합으로 총비용을 계산한다.

(4) 단계 - 투자 효과 분석을 위해 SOA의 지속적 구축 횟수를 반영. 즉, 첫번째 프로젝트 투자 이후, 시간의 경과에 따라 기존 프로젝트 투자를 SOA의 재사용 측면에서 활용함에 의한 비용 절감 효과를 두번째, 세번째 프로젝트를 통해 확인할 수 있도록 시간에 따른 비용의 감소를 확인한다.

TTAx.xx.xxxx/R156


<그림 39> 지속적인 SOA 구현에 의한 시간에 따른 투자수익(ROI)의 증가

TTAx.xx.xxxx/R157


표준작성 공헌자

표준 번호 : TTAx.xx-xx.xxxx/R1

이 표준의 제․개정 및 발간을 위해 아래와 같이 여러분들이 공헌하였습니다.

구분 성명 위원회 및 직위연락처

(Tel, e-mail)소속사

과제 제안한국정보화진흥원,

PG418

표준 초안 제출

강승우

김효정

문병선

최정준

윤정희

한국오라클 상무

한국 IBM 상무삼성 SDS 수석SK C&C 부장

한국정보화진흥원 책임

[email protected]@[email protected]

[email protected]

[email protected]

표준 초안 검토

및 작성

김은주 SOA 프로젝트그룹 의장02-2131-0447

[email protected]

외 프로젝트그룹 위원

표준안 심의

사무국 담당

TTAx.xx.xxxx/R158

mailto:[email protected]






(뒷 표지)

정보통신단체표준

SOA 참조 프레임워크(SOA Reference Framework)

발행인 : 김홍구발행처 : 한국정보통신기술협회

463-824, 경기도 성남시 분당구 서현동 267-2Tel : 031-724-0114, Fax : 031-724-0019

발행일 : 200x.xx

Documents

T T A S t a n d a r d Web viewSOA 목적을 예로 들면, 크게는 고객 만족도 제고, 비용 절감 등을 들 수 있고, 보다 구체적인 하위 목적의 예로는 기관간의