1

도대체... SOA란 무엇인가?박현철

architect.mentor@gmail.com

SOA는 오리무중편

2architect.mentor@gmail.com Service-oriented Architecture

시작하기 전에

세미나 특징

공식적인 세미나지만, 비공식적인 강의 스타일과 이야기가 있다.

세미나 구성

Opening Session: IT에서 살아남기...

• 책 속의 이야기가 아닌, 강사가 경험한 실제 프로젝트들...

• 살아남기 위해 중요했던 것은 어떤 것들이었나?

Main Session: SOA로 살아남기...

• Part I: IT 기본을 알자. (99%)

• Part II: Service와 SOA를 알자. (1%) => 오늘의 주제

Appendix: 선택된 사람들을 위한, 좌절하기...

• 포기를 모르는 사람들을 위한 나락

• 모든 것이 쉬운 사람들을 위한 미궁

프로그래밍 언어 기본을 배우는 기간은? 1주일고급 프로그래머가 되기 위한 기간은? 5년 이상... 왜?

새로운 것이 나타났을 때는 “빙산의 일각”이 아닌“빙산의 일각으로 보이는 껍데기” 만 새로운 것일 뿐...

3architect.mentor@gmail.com Service-oriented Architecture

공식석상에서 절대 할 수 없는 이야기들...1

(나의 이야기...) 난 문제아였다. 문제는... 아무 생각이 없다는거다. 나는 이유도 잘 모른 채... 남들이 학교가면 갔고,

남들이 직장가면 갔다. 남들이 결혼해서 했고, 아이도 낳았다. 심지어, 나는 왜 먹는지, 왜 입는지, 왜 자야만 하는지, 험험... 왜싸야만 하는지, 고민한적 없다. 난 그냥 그렇게 살아왔다... 철푸덕... 혹시... 너...도...?

(어르신 왈...) 어허... 이거 문제네. 문제야. 사회생활은 그리 만만한게 아닌데. 사회생활을 뽀다구 나고, 돈 많이 벌려면 “항상

생각하면서, 자기만의 죽이는 기술”을 가지고 있어야 하는데... 어? 그런거 많다고? MMORPG(Massively Multi-

user Online Role Playing Game)할 때 주먹으로, 발로, 마법으로, 독으로, 각종 무기로, 죽이는 기술을 기똥차게 많이안다고? 니... 주글래...?

뭐... 시작 표현으로 적당한지는 모르겠지만... 암튼, 고객으로부터 “와~ 죽인다...”라는 말을 듣는게... 중요해. 그래야

보람도 있고, 돈도 벌지. 당신은 죽이는거 있나? 책...? 영어 잘해? 원서를 본다고? 우와... 음... 그래서? 그 안에는 주옥 같은

내용이 있다고? 그래...? 하지만 상황이 우리나라에 맞나? 지금 하고 있는 일에 도움되냐고. 응? 잘 모르겠다고?...

4architect.mentor@gmail.com Service-oriented Architecture

공식석상에서 절대 할 수 없는 이야기들...2

외국의 많은 책, 지식체계들을 보면 “Generally Accepted...”를 깔고 내용이 전개된다. 하지만, 우리나라에는

이게 안통한다. 생각이 다른데... 뭐? 비슷하다고? 우리나라 IT 관리자들에게 “월화수목금금금”은 양념이고, “짜면나온다.”는 주식...인데도? 우리도 마찬가지잖아. 일과 중에 메일체크, 인터넷서핑, 블로그탐색, 전화, 메신저, 커피도

먹어야지, 화장실도 가고, 증권 상황도 봐야하고, 꼼꼼히 쿠폰 챙겨야 하고, 얼마전엔 올림픽을 시도 때도 없이 봐야 하고,... 일은

그거 다 하고 남는 시간에만 하잖아... 게다가, 실제 일할 때도, 하고 싶은거만 하잖아... 시킨거는 잠시 뒀다, 대충하고...

월급이 아무리 작아도, 일하는거에 비하면 무지 많이 받는거... 우리들은... 알지...

소프트웨어 프로그래밍, 모델링, 아키텍처, 관리 분야의 영어책들? 우주... 국방... 항공... 뭐. 좋다. 나쁠 것은 없지. 그런데, 그런게... SI/SD 노가다하고 같냐고. 글고... 패키지 맹근다고? 거기에 필요한게 뭔데... 책에 있냐고... 있냐고... 미팅 때는

쓸데없는 이야기만 하다가, 끝나고 담배피면서 할 이야기 다하고... 미팅 시간보다 담대 피는 5분이 실제

브레인스토밍이잖아... 범위 짜르는 것, 팀워크 다지는 것... 이런거 하려면, 논리가 아닌, 술이 필요하다는거... 다 아는

사실인데... 책에 술 이야기 있냐고... 술 나오냐고... 술 좀 사줘봐. 듣고 싶은 이야기 술술 다 나오지...

우리나라에서는... 술과 담배만 있으면, 모든 협상은 진실된 대화와 협의로 이루어지지... “죽이지 않아?” (모 조직에 있을 때, 중요 미팅이 소집되었다... 안건은 “어디로, 어떻게 모실 것인가?”에 대한 것이었다...)

5architect.mentor@gmail.com Service-oriented Architecture

공식석상에서 절대 할 수 없는 이야기들...3

패턴? 패턴하면, 거... CNP 패턴이 쨩이잖아... 거 몰라? 쨩나네... Cut & Paste. 뭐... 물아일체...수준이지... 하루 천라인...?

거 대수도 아냐. 재사용? 나 대학교 때 리포트 낸거 다 재사용이거덩... 이미 재사용은 일상생활이지... 재사용 빼면, 시체지

뭐... 패턴과 재사용의 일상화... 이만하면 “죽이는 기술 아닌가?” 다만... 고객에게 필요한지 아닌지 생각안하고, 무조건

내가 아는 걸... 재사용한다는거지... 뭐... 다들 그래... 이런걸... 관행이라 하지.

나. 매니저거덩. 내가 얼마나 결단력이 있고 사람들을 생각하냐면... 뭐... 직원들이 아무리 객관적으로, A제품이 가장 나쁘다고리포트를 제출했어도, 기회를 줘야지. 모든 것이 처음부터 좋을 수는 없잖아. 사실... 게네들이 제품은 나빠도, 사람들은 정말

좋거덩... 밥도 잘 사주고, 싸가지가 있어. 싸가지. 싸가지가 뭔지 알아? 사람이 중요한거야... 제품은 못믿어도 사람은 믿자...

기회의 제공을 통한 사람들에 대한 끝없는 신뢰. 이게 나의 “죽이는 기술이지.”

6architect.mentor@gmail.com Service-oriented Architecture

공식석상에서 절대 할 수 없는 이야기들...4

책을 많이 읽고, 경험을 많이 하면 뭐하나... 문제의 본질 보다는 해결에만 관심이 가는데... 그러니 모든 사람들마다 생각하는게

다르지... 문제를 이해해야 필요한 역할을 알 수 있고, 문제를 이해해야 뭐가 해결인지 만들어갈 수 있지... 니 머리속에

정리된 문제 있어? 아니, 해결 말고... 숫한 스터디 속에 배운거라고는, 해결 방안뿐이지... 아. 그거 나뿌다는거 아냐. 좋지...

하지만 문제는? 모든 출발점은 문제에서부터 시작해야지... 그거 모르면 너 문제거덩? 그거 모르면 죽이는 기술

이전에 네가 먼저 죽지... 그지 같은 이 바닥에서... 뽀다구 한번 못잡고... 10000에 하나. 여태 고생해서 알아놓은 지식들이 실제사회생활에서 쓸모가 없다면? 열받지. 가다가 중지하면, 간만큼은 이익있다...? 뭐... 맞지... 하지만 우리는 금메달 못따면 당장열받는 민족인걸 어떡해. 여자 양궁 봤니? 8차전에서 열받지. 4차전에서 열받지. 결승에서 진짜 또 열받았지? 왜 8점을쏘냐고냐고냐고... 거봐... 그 드러븐 성질 못바꾸거덩... 우리에게는 결과가 중요하지. 정말 쓸모 있는 결과를 알고, 만들어가기위해서는 “문제”에 보다 더 접근해가는게 중요해... 책에는 없는... 왜 없지? 사실... 없는게 아니라... 안보는거지 뭐... 산다는거 생각해봐. 당면한 문제들이 다 다르잖아. 다 다르지... 그래서 문제에 집중하기 어렵고, 말하기 어렵고, 쓰기어려운거야. 하지만 해야지...

사실, 문제에는 “업무”와 해결을 위한 전제가 있거덩. 전제? 뭐... 업무는 당근. 돈과 시간은 말밥. 게다가 우리에게는

역할이라는게 뭔지 아는 관리자가 없거덩... 아마, 이거 맞추려면... 이미 알고 있는 대부분의 기존 해결 방안은 거의 Mission

Impossible에 가까운 것들뿐일 거야.

7architect.mentor@gmail.com Service-oriented Architecture

IT에서 살아남기... (1/2)

책 속의 이야기가 아닌, 강사가 경험한 실제 프로젝트들...

[1998, PM] 품질 이슈: 100% Round-trip(?), WAN구간 Component, Legacy와 2Phase Commit,...

[1999, Team Leader] 시장 이슈: 소련/인도/미국/캐나다/... 다국적 개발팀, No ER & EJBs... 전세계 시장 대상...

[2001, Architect] 제품 기술과 마케팅 이슈: COM/CORBA/EJB/I18N/... 등을 One Source로?

[2006, Auditor] 납기 이슈: 13만 사용자 + 2500개 유관기간 + CBD + 4개의 독립된 컨소시엄,...

[2006, Architect] 기술 난이도 이슈: 멀티코아 장착 휴대폰을 위한 소프트웨어 프레임워크 칩(Chip) 꿉기

8architect.mentor@gmail.com Service-oriented Architecture

IT에서 살아남기... (2/2)

살아남기 위해 중요했던 것은 어떤 것들이었나?

기술?: 중요한데... 노가다?

패턴?: 아... 짬밥, 짠빱? 아니... 잔반인가?

메타?: Beyond, Models of Models, MDA(Model-driven Architecture),...

규모?: 커지면, 일을 파악하기도, 나누기도, 통합하기도 점차 어려워진다...

방법론?: 최소의 Activity, 최소의 Artifact를 찾기 위한 바탕이다.

시장?: 일에 대한 보람, 어디에서 찾을 것인가...

품질?: 내 생각이 아니라, 남의 생각으로 프로젝트를 한다.

사람?: 놀라운 비밀... 소프트웨어는 사람들이 만든다...

한국?: 한국... 너 진짜 특이하다...

9architect.mentor@gmail.com Service-oriented Architecture

Main Session: SOA로 살아남기

Part I: IT 기본을 알자. (99%)

Part II: Service와 SOA를 알자. (1%) => 오늘의 주제

10architect.mentor@gmail.com Service-oriented Architecture

Part I: IT 기본을 알자.

소프트웨어, 함수, 데이터, 객체, 컴포넌트, 웹, 웹서비스, 프레임워크, 모델링 언어,방법론, 감리, SPI(Software Process Improvement), 아키텍처, etc,...

... 밑에 나열된 것들을몽땅 통틀어서,

빙산의 일각이라고 부른다.

궁금...그럼 빙산의 몸체는?

뭘까???

11architect.mentor@gmail.com Service-oriented Architecture

소프트웨어 특성

소프트웨어가 무언지 정의를 내리지 말자... 그저... 조금 알아보자.

소프트웨어는 무색 무취에, 만질 수도 없는 무형의 존재이다.

하지만, 변화에는 절대 소프트하지 않다...는 아니고... 일반적으로... 소프트하지 않게 만든다...

소프트웨어 구성 요소: Fu., Da., Cl., Co., Se., Pa., Fr., Os, Db, ... (원소기호가 아니다.)

기능/서비스 그리고 품질

12architect.mentor@gmail.com Service-oriented Architecture

소프트웨어 구성 요소

함수 ... 함수 라이브러리

데이터... 변수, 구조체, 파일, 데이터 베이스

객체/클래스... 클래스 라이브러리

컴포넌트...와 프레임워크

프로토콜/인터페이스/서비스

패키지/솔루션

서브시스템

함수와 데이터를 조금 알면, 객체/클래스를 알 수 있고, 컴포넌트, 서비스 등을 알 수 있다.그리고 이들은 소프트웨어 기반 시스템 전체를 구성하는 중요한 근간이 된다.

이를, 벽돌집이라 말하는가? 벽돌은 단순한 구성 요소일 뿐인데...때로는 기본 구성요소가 전체 특성을 설명하는 가장 대표적 수단일 수도 있다.

13architect.mentor@gmail.com Service-oriented Architecture

갑자기... CPU

CPU: 0을 1로, 1을 0으로... 끝!

HW? SW?

Functions with Elements & Interactions!

14architect.mentor@gmail.com Service-oriented Architecture

함수/기능/업무/서비스

함수가 뭘까?

왜 컴퓨터 내에 CPU가 꼭 존재해야 할까?

적절한 함수의 크기를 어떻게 알 수 있을까?

함수에도 추상화가 필요할까?

In computer science, a subroutine (function, method, procedure, or subprogram) is a portion of code within a larger program, which performs a specific task and is relatively independent of the remaining code. The syntax of many programming languages includes support for creating self contained subroutines, and for calling and returning from them.

...Wikipedia

15architect.mentor@gmail.com Service-oriented Architecture

어떤 유명한 이야기

구조적 방법론 이래로 전해오는 유명한 이야기가 있다...일명 3F.

Form follows function is a principle associated with Modern architecture and industrial design in the 20th Century, which states that the shape of a building or object should be predicated on its intended purpose. - Wikipedia.

16architect.mentor@gmail.com Service-oriented Architecture

함수, 기능, 서비스

함수와 기능 그리고 서비스는 동일 선상에 있을 수 있다.

하지만, 소프트웨어에서의 기능이나 서비스는 하나의 함수가 될 수도 있지만, 일반적으로 보다 큰 포괄적 의미로 쓰인다.

즉 기능 또는 서비스는 함수보다는 포괄적 개념이며, 관심 영역에 대한 다양성/유연성/가치중심에 맞춘 개념이다.

요청자의 서비스와접수자의 서비스 간에는

많은 갭이 존재한다.

이건... 주위에서 흔히 볼수 있는 사람

들...

이건... 위기에 빠진 소프트웨어 또는

고객...

“그래... 가라앉는 사람의무게를 덜어주어야지... 난,고객이 말을 하지 않아도,

정확히 원하는 것이 무엇인지 잘 알아...”

고객에게는 관심 없고,돈에만...?

17architect.mentor@gmail.com Service-oriented Architecture

갑자기... 메모리

메모리... 뭘?

폰노이만 구조에서, CPU 자체만으로는 의미가 없다. CPU는 항상 메모리와 상호작용한다. 왜?

추억...

메모리

메모리…

18architect.mentor@gmail.com Service-oriented Architecture

데이터

데이터가 뭘까?

컴퓨터 내에 왜 메모리가 꼭 있어야 할까?

오죽하면 “정보처리 시스템”이라는 말을 할까...

Data is a synonym for information. In computer science theory there is a clear distinction between data and information, where data is a measurement that can be disorganized and when the data becomes organized it becomes information. Data can be about reality, or fiction such as a fictional movie. Data about reality consists of propositions. A large class of practically important propositions are measurements or observations of a variable. Such propositions may comprise numbers, words, or images.

...Wikipedia

19architect.mentor@gmail.com Service-oriented Architecture

데이터 세상 만사

데이터가 뭔지...

얼굴색... 사용자...

Needs와 Data 사이...

Data의 활용...

20architect.mentor@gmail.com Service-oriented Architecture

객체지향?

C언어 등을 이용한 절차적 프로그래밍 형태는 함수와는 독립된 데이터 또는 데이터 구조를 정의하고, 함수들을 통해 필요한기능을 구현하면서, 미리 정의한 데이터 또는 데이터 구조를 활용하는 형태이다.

C 프로그래밍 형태는 프로그램의 사이즈가 커질 수록 모듈화하기가 어려워, Data의 추가/변경에 따른 변화가 어떤 함수에 어떤 형태로가해질지를 파악하기 쉽지 않다. 즉 새로운 장비, 새로운 제어 프로세스가 요구될 경우 기존 프로그램에서 어떤 부분을 어떻게 바꾸고, 그에따른 파급효과가 어떻게 될지 명확하게 파악하기 쉽지 않다.

객체지향의 목적은 변화를 수용하는 프로그래밍을 하려고.

절대적인 쉬움은 존재하지 않는다. 다만 어려움에 대한 상대적인 쉬움만이 존재할 뿐이다...?

Question!

• 새로운 변화가 기존 코드에 영향을 안줄 수 있는가?

• 기존 기능의 변화가 어디에 영향을 주는지 명확히 알 수 있는가?

21architect.mentor@gmail.com Service-oriented Architecture

그럼 C++, Java, C#,...는 객체지향인가요?

C++는 “Better C”와 “Object-Oriented”가 다 된다.

기본적으로 C 언어의 특성을 살릴 수도 있다.

데이터와 함수를 하나의 타입으로 정의할 수 있으며, 타입간 상속과 포함을 통해 복합적 구조체를 효율적으로 만들 수 있으며, 컨스트럭터와디스트럭터를 통해 메모리 제어를 체계적으로 할 수 있고, 에러 처리에 대한 방식과 템플릿을 활용한 타입 차원의 재사용 코드를 생성할 수도있다. 즉 C++는 객체지향 프로그래밍 스타일을 언어 차원에서 지원한다.

그 외 Java, C#과 같은 언어는 객체지향 개념이 중시된 언어이기는 하지만, “Strong Typed Language”의 특성을 갖고있으며, 언어들마다의 부가적인 독.특.한. 특성들을 갖고 있다.

22architect.mentor@gmail.com Service-oriented Architecture

그런데... Person 클래스를 객체지향 언어들로 나타내면?

[C++]class CPerson { … };

[Java]class CPerson { … }

[C#]class CPerson{ … }

[C++]class CPerson {private:

String socialSecurityNumber;String name;String companyName;String department;float salary;

public:CPerson(String&, String&);void print();

};

[Java]class CPerson {

private String socialSecurityNumber;private String name;private String companyName;private String department;private float salary;

public CPerson(String s1, String s2) {}public void print() {}

}

[C#]Public/protected/private class CPerson {

private string socialSecurityNumber;private string name;private string companyName;private string department;private float salary;

public CPerson(string s1, string s2) {}public void print() {}

}

23architect.mentor@gmail.com Service-oriented Architecture

그 밖의 객체지향적 특성들...

Message, Encapsulation, Inheritance, Composition, Polymorphism, Abstraction,...객체지향 개념은 적절한 모델링(Function, Data, Class, Component, Service)을 하기 위해

반드시 이해해야 할 사항이다.

객체지향을 소개하는 자리라면 매우 중

요하게 다루어질개념들...

하지만, 여기서는 그림으로만, 대신한다.

24architect.mentor@gmail.com Service-oriented Architecture

컴포넌트 특성 (1/2)

컴포넌트는 다음과 같은 특성을 갖는다.

컴포넌트는 캡슐화된 블랙박스(black box) 패키지 형태로 제공되며 인터페이스와 구현이 분리되어 있다. 따라서 개발과 적용/사용을 분리할수 있다.

컴포넌트는 별도의 변형이나 가공없이 그 자체로써 수행(Executable) 및 배포(deployable)가 가능하여야한다. 이러한 특성으로 인해객체(Object)보다 독립적이며 재사용성(Reusability) 대체성(Replaceability), 플러그 가능성(Pluggability)을 가진다.

class

class

class인터페이스

하드웨어 컴포넌트

소프트웨어 컴포넌트

USB2.0: Printer, Mouse, NWCard, Hard/Memory, Speaker, …

주위의 많은 것들이, 기능은 통합되면서도... 특정 영역들은 컴포넌

트로 분할 특화된다.Ex, 휴대폰 & Bluetooth

이때 좋은 것들도 많지만, 귀찮은것들도 많이 생겨난다. 모든 것들에 대해 별도 전원 관리가 필요하며, 각각의 특수성을 이해하고, 호환성에 많은 문제점들이 나타난다.

25architect.mentor@gmail.com Service-oriented Architecture

컴포넌트 특성 (2/2)

컴포넌트는 재사용성(Reusability)이 있는 소프트웨어모듈이다.

컴포넌트가 가지고 있는 가장 큰 장점 중에 하나가재사용성이다. 한번 개발된 컴포넌트는 하드웨어와 같은 독립된모듈로 여러 소프트웨어에서 재사용하여 사용된다.

재사용을 위해서는 재사용하기 적절한 수준의 업무 기능을구현해야한다.

컴포넌트는 대치성(Replaceability)이 있는 소프트웨어모듈이다.

컴포넌트의 대체성은 기존 시스템에서 기능이 변경되거나 추가되었을 때에, 전체의 시스템을 변경하는 것이 아니라 변경된기능에 해당하는 컴포넌트를 새로운 컴포넌트로 대체할 수있다.

대치성을 위해서는 Architecture, Interface 정의가중요하다.

예약Component

고객Component

진료Component

환자Component

예약Component

의사Component

A 병원 System B 병원 System

진료Component

재사용

예약Component

고객Component

진료 1Component

병원 System

진료 2Component

진료 1Component

진료1 Component에서진료 2 Component로 대치

사업자에게 중요한 특성

-만든 것은또 써먹어야...

고객사에게 중요한 특성

-급변하는 업무에변화를 적용

26architect.mentor@gmail.com Service-oriented Architecture

웹(Web)

웹: ARPANET, TCP/IP, Email, USENET, FTP, Telnet 등의 다양한 기술 요소들을 바탕으로 WWW(World Wide Web)이 등장함.

Standard information service through Internet

Hypertext Markup Language (HTML)

Uniform Resource Locator (URL)

Web Browser, Web Server, HTTP

27architect.mentor@gmail.com Service-oriented Architecture

웹서비스(Web Services)

웹서비스: 표준 프로토콜을 기반으로, 큰 수준(coarse-grained)에서 상호작용을 하며, 비동기적 특성을 포함하고 있음.

XML

UDDI – Universal Description Discovery & Integration

WSDL – Web Service Description Language

SOAP – Simple Object Access Protocol

Publis

hFind

Web Service RequestorWeb Service Provider

UDDI Registry

(Web Service Agency)

Interact

Internet

Service

Description

Service

Description

Service Client

Publis

hFind

Web Service RequestorWeb Service Provider

UDDI Registry

(Web Service Agency)

Interact

Internet

Service

Description

Service

Description

Service Client

28architect.mentor@gmail.com Service-oriented Architecture

프레임워크(Framework)

프레임워크 - 자주 등장하거나 재활용할 수 있는 기능과 아키텍처 스타일을 미리 구현해놓은 재사용 가능한 소프트웨어자산/반제품

A set of cooperating classes that make up a reusable design for a specific class of software (<= Class Library 특성)

A set of components working together so they address a number of problems in one or more domains (<= Package특성)

Commonality VariabilityVariability Commonality VariabilityVariability

29architect.mentor@gmail.com Service-oriented Architecture

잠깐! 언어-Language

Language Features

그림 vs. 음성 vs. 문자

• 재미있는 규칙: 동물+소리=소리, 비동물+소리=쏘리 (개소리, 바람쏘리)

• 언어 체계에는 대단히 많은 규칙이 있다.

언어가 실체를 의미하지는 않는다. “빵”도 그렇고...,

이것 만은 알고 넘어가자. => 모델링에서 주의할 사항!

• 1. 언어의 중의성 - 꽝, Wax, Unisex, ...

• 2. Langue & Parole - “국민의 뜻”, “어머! 옷 이쁘다.”, ...

Languages in SW Development

Programming Language

Structured Query Language

Modeling Language! – 모델링 언어?

30architect.mentor@gmail.com Service-oriented Architecture

모델링 언어(Modeling Language)

모델이란?

모델링의 결과로, 현실이나 시스템을 단순화/가시화 시킨 것

현실을 필요한 형태로 가시화한 것

시스템 구조와 행동을 명세화한 것

시스템 분석/설계 문서화한 것

모델링 언어란?

모델링을 하기 위한 언어

가시화 - 눈으로 보는 것이 중요한가? 당근.

31architect.mentor@gmail.com Service-oriented Architecture

다양한 방법론들

방법론들은 소프트웨어 패러다임을 주도하거나, 특정 소프트웨어 아키텍처 스타일을 강조한다.

구조적, 정보공학적, 객체지향적, 컴포넌트적, 서비스적

클라이언트/서버, 웹기반, 패키지통합, SOA

최근의 방법론들은 기존 방법론의 주요 특성들을 재구성한 것이다. 따라서 그 내부를 보면 이전의 방법론적 특성(패러다임, 기술)들을 대부분 포함하고 있다.

서브루틴 개념의 활용

구조적 프로그래밍(Structural Programming) – 업무 기능 구조

정보공학(Information Engineering) – ISP, 업무와 DB 통합관리

케이스(CASE: Computer Aided Software Engineering) 도구

클라이언트/서버, 웹 기반 아키텍처, EA(Enterprise Architecture)

OMG의 객체기술관련 활동과 UML(Unified Modeling Language)의 대중화

J2EE, .NET, CCM 등 컴포넌트를 위한 환경/표준의 발전

SPICE, CMMi 등 프로세스 성숙도 반영

COTS, Product Line, Web Services, MDA

[퀴즈 #1] 당신이 속한 조직의 방법론 활용 수준이 “1”에 머무르고 있을 확률은?

[퀴즈 #2] 당신이 알고 있는SI 조직들의 방법론 활용 수준이 “1”에 머무르고 있

을 확율은?

SOA 방법론

1

2

3

4

32architect.mentor@gmail.com Service-oriented Architecture

소프트웨어 개발 방법론들의 대상 및 재사용 단위들

개발 방법론들의 대상

UI

DB

Programming Language

Library, Framework, Dev. Environment

OS

NW

HW

& Business/Domain

재사용 단위들

Code

Document

Class Library

Component

Architecture/Framework

System

Software Process

Guide & Check List, Principles

Best Practice

Knowledge/Experience

33architect.mentor@gmail.com Service-oriented Architecture

산출물들과 모델

산출물들은 일반적으로, 모델들을 포함한다. 모델들은 서로 관련을 갖고 있으며, 추상화 수준 및 입출력 관계를 통해 상호 보완적관련성을 갖는다.

물리적(Efficiency & Suitability) 모델– PSM(Platform Specific Model)

개념적(Domain, Essentials) 모델

논리적(Business Completeness) 모델– PIM(Platform Independent Model)

[모델링 과정]모델링 요소 찾기, 관련 짓기, 세부표현하기, 정제하기

템플릿 적용

[모델 체계]

RFP제안서계약서

프로젝트수행계획서

34architect.mentor@gmail.com Service-oriented Architecture

Agile Method

Agility, Agile이란?

급변하는 비즈니스 환경에서 보다 많은 이익을 얻기 위해 스스로 변화하고 또 주위의 변화에 대응하는 능력을 Agility라 한다. Agility를 갖춘조직은 변화에 주눅들어 피하려 하기 보다는 적극적으로 수용하고 대응함으로써 경쟁자들보다 앞서 나갈 수 있다. 소프트웨어 개발분야에서도 마찬가지로 다양한 변화를 수용하고 대응할 수 있어야 프로젝트를 성공시킬 수 있다. 이에 따라 최근 여러 방법론들이 각광 받고있고 이들을 Agile method라 부른다.

The Manifesto for Agile Software Development

2001년 2월 11일에서 13일까지 3일간 유타의 워새치 산에 위치한 스노버드 스키 리조트에 17명의 사람들이 모여 서로의 공동 관심사에대해서 이야기를 나누었다. agile이란 단어가 공식적으로 세상에 모습을 드러내는 순간이다. 여기에는 Extreme Programming(XP), Scrum, the Dynamic Systems Development Method(DSDM), Adaptive Software Development(ASD), Crystal Methods, Feature-Driven Development(FDD), Pragmatic Programming 등의 대표자들이 참석하였다. 이들은 여러 토의와 의논 끝에 하나의선언문을 만들게 된다. 이것이 소프트웨어 개발에 대한 선언문(The Manifesto for Agile Software Development)이다.

35architect.mentor@gmail.com Service-oriented Architecture

Agile Method의 대표주자 XP

36architect.mentor@gmail.com Service-oriented Architecture

객관적 품질관리를 위한 감리(Audit)

감리대상으로부터 독립된 감리인이 정보시스템의 안전성, 효율성 및 효과성 향상을 위하여 정보시스템의 구축, 운영에 관한 사항을 종합적으로 점검, 평가하고 감리의뢰인 및 피감리인에게 개선이 필요한 사항을 권고하는 것

감리

구 분 권리와 의무 비고

발주기관

- 과업범위에 대한 변경관리 및 기성확인 요청- 상시적인 사업관리 대행 및 지원 요구- 정기적인 회의 참석 및 의견 개진- 감리의 독립성을 최대한 보장

개발업체

- 산출물 및 관련자료 제출 의무- 감리결과 지적 사항에 대한 시정조치 활동- 수시 의사결정 사안에 대한 신속 검토 요구- 감리결과에 대한 이의제기 및 조정 요구

감리업체

- 감리의 독립성과 전문성 확보- 감리관련 자료요구 및 면담 요청- 감리과정에서 득한 사항 및 감리결과의 보안 유지- 수시 검토 요구사항에 대한 상시적인 지원 및 조정- 감리 지적 사항에 대한 조치 여부 확인

감리 주체 별 권리와 의무

정보시스템의 효율적 도입 및 운영 등에 관한 법률” 제12조 - “공공기관 대상”- 2007년 2월 점검해설서V2.0 공지

감리 해설서

왠 감리? – 요즘 프로젝트의 감초

37architect.mentor@gmail.com Service-oriented Architecture

SPI...

SPI(Software Process Improvement)의 핵심 분야는 무엇일까?

“소프트웨어 중심의 프로젝트” 관리를 체계적으로 하기 위한, 단 하나를 꼽으라면, 코딩이다.

무엇을 어떻게 잘... 코딩할 것인가?

• 요구사항 정의

코딩이 제대로 되었다는 것을 어떻게 검증할 것인가?

• 테스트

개발 과정 전체 내용의 일관성을 어떻게 맞출 것인가?

• 동료검토(사람), 형상관리(도구), 변경관리(정책)

coding

RequirementDefine

Testing

Configuration & Change ManagementPeer Review

coding

CMMi, SPICELevel 2/3/4/5

소프트웨어 아키텍트는 커뮤니케이션을 모니터링/통제할 수 있어야 한

다.

CMMi나 SPICE를(Software Process Best Practices &

Standards) 활용해 SPI(소프트웨어프로세스를 개선)하는 것은 큰 프로젝트를 체계적으로 이끌 수 있는 가

장 좋은 방법 중 하나이다.

38architect.mentor@gmail.com Service-oriented Architecture

프로세스를 중시하는 CMMi

1980년대 초 미 국방성은 많은 업체로부터 소프트웨어를 납품 받고 있었지만, 각 업체별로 품질수준이 상이하고, 일정이나 비용을 초과하는 경우가 자주 발생하였다. 그래서 소프트웨어 조직의 수준을 평가하기 위한 모델을 카네기멜론대학과 공동으로 개발하였는데, 이것이CMM(Capability Maturity Model)이 등장하게 된 배경이다. 그 후 P-CMM, SA-CMM,SE-CMM등 5종류의 CMM이 추가로 발표가 되었고, 이들를 통합하여 CMMi(Integrated) 정의하였다.CMMi는 IT 조직의 능력을 가장 낮은 레벨 1 부터 레벨 5까지 5단계로 나눠 조직의 소프트웨어 개발 관리 및 운영프로세스 수준을 평가하고 개선하는 국제 표준 모델이다.

CMMi 역사 및 배경

회사의 목적에 부합하는 프로세스 수립 및 실행

조직을 효율적으로 운영하기 위한 표준 모델 제공

개발 및 운영환경 효율화 및 고객만족도 증대

IT 표준화 및 프로세스개선 모델 제공

CMMi 도입 효과

CMMi를 효과적으로 인증 받기 위해 품질, 소프트웨어 공학, 방법론, 프로젝트 관리 모두가 중요하며, 이들에 대한 조직의 경험 및 실제 활용 능력이 필요하다.

CMMi 인증 요건

39architect.mentor@gmail.com Service-oriented Architecture

아키텍처

중요한 것, 관심사 품질

40architect.mentor@gmail.com Service-oriented Architecture

아키텍처의 정의

System: A collection of components organized to accomplish a specific function or set of functions.

Architecture: The fundamental organization of a system embodied in its components, their relationships to each other, and to the environment, and the principles guiding its design and evolution.

41architect.mentor@gmail.com Service-oriented Architecture

아키텍처의 이해

Mission

System

Viewpoint View

Stakeholder Architecture

Description

Architecture

Environment

Library

Viewpoint

Concern

Model

Rationale

fulfills 1..*

influences

inhabits

has an

has 1..*

is addressed to

1..*

has 1..*

is important to 1..*

selects

1..*

conforms to participates in

1..*

consists of 1..* 1..* aggregates

described by

provides

participates in

organized by1..*

has source

0..*

1..*

identifies

1..*

identifies

1

establishes methods for

1..*

used to cover 1..*

아키텍처를 이해하는 것은절대로 쉬운 일이 아니다.

사람들마다진짜... 다른생각을 한다.예) 돈질, 노

가다,...

결론의 합리성이 매우중요하다.

목적은하나인데...예를 들어,

성능 개선...

42architect.mentor@gmail.com Service-oriented Architecture

잠깐. 소프트웨어(제품 빼고)를 알아봤다. 그 것 말고... 뭐가 더?

43architect.mentor@gmail.com Service-oriented Architecture

Part II: Service와 SOA를 알자.

Service

SOA

그럼... Service와 SOA는빙산의 일각도 아닌...

겉에 보이는 눈과 얼음... 정도?

44architect.mentor@gmail.com Service-oriented Architecture

Informal Session – 지극히 간단한 정의

서비스: 비즈니스 기능

따라서 비즈니스적 특성에 따라 서비스를 정의해야 함

SOA: 서비스를 효율적으로 제공하기 위한 IT 관련 아키텍처

따라서 IT 특성에 따라 SOA를 정의해야 함

“으아... 넘 재미없어... 너무 딱딱하잖아...”라고 할까봐…조금은 비공식적인 정의로부터 시작합니다.

45architect.mentor@gmail.com Service-oriented Architecture

Informal Session – Service & SOA Background (1/2)

새로운 소프트웨어 단위 – 거대 모듈 필요? 조직/시스템 영역을 넘나드는 소프트웨어 모듈이 점차 증대됨

함수... 클래스... 컴포넌트... 도 양에 안차... 도메인에 걸친 업무 영역을 시스템으로 연계하기 위한 체계도 필요...

업무와 소프트웨어와 데이터의 상호 연동 관계 및 변화 적응성이 중요해짐

신규 Network, HW Resource 수요 창출이 수반될 것이며, 보안, 업무 표준화 관련 시장 규모가 확대될 것임

협업체계 중심의 조직 구조 변화 및 업무 형태 변화 필요

ex, 방카, 자통법 등 기업간 상호연동체계 및 내부간 상호작용의 객관화 필요...

FTA, Global 등 기업 경쟁력 필요성 증대...

제휴(적과의 동침...), 채널 확대, 연계, M&A, 지주사 설립 등 변화에 강한 “Collaboration” 체계 구축이 중요해짐.

46architect.mentor@gmail.com Service-oriented Architecture

Informal Session – Service & SOA Background(2/2)

SOA는 BPM, Web2.0, RFID, NextGen Mobile 등 다양한 기술체계와 함께 활용될 것이며, 어느 시점부터는 “쏘~아…쏴…” 물결을 타기 시작할 것임… 2015년? 2020년?... 2030년!

SOA를 지배하기 위해서는 “신기술”기반의 “새로운 시장”을 이해해야 하며, “잘”하기 위해서는 표준화, IT 벤더들의정책 등을 모니터링 하고 “고객을 위한” 것과 “IT 관련 벤더들”의 배를 채우기 위한 것들을 구별할 수 있는 지혜가 필요할것임.

SOA가 지향하는 것을 달성하기는 쉽지 않음. (SOA 이전의 경험과 조직의 성숙도에 가장 큰 영향 받음, 여태의 모든 기술이그랬음) “Business System의 Automation”은 기업들간 경쟁적 상황때문이라도 일부%에 국한될 수 밖에 없고, 결국SOA를 기반으로 한 상대적 Business Agility를 가능하게 하는, 크게는 IT Gov., 작게는 Software Architecture가 중요할것임.

SOA를 통한 시장은 매우 큰 규모로 커질 것임. 하지만 경쟁력의 핵심은 SOA를 이루는 “IT 체계의 효율적 개발/운영을 통한Business Agility” 임. (SOA는 “시장에서 유행할”갑옷이며, 방패는 효율적 IT 개발/운영 체계이고, 칼은 Business Agility임.)

47architect.mentor@gmail.com Service-oriented Architecture

Informal Session – SOA 관련 국내 현실 (1/3)

SOA 가능한가?

예...

기업에서 IT를 비즈니스에 활용한지도 오래되었고, 사용자들의 IT 친숙도가 높아짐에 따라, 기존의 단순 업무 기능처리를 조금 더 복합/통합된상위 업무 기능처리로 발전(프로세스 개념 적용)함.

현재는 여러 업무간, 여러 시스템간 특히, 이기종 플랫폼간을 관통하는 프로세스를 포함하는 서비스 수준으로 발전 함.

IT가 Biz의 필수 요건이 되면서, 경영전략에서 IT의 중요도가 점차 증가되고 예산 규모도 커짐. 더구나 IT가 발전함에 따라 동일 비용 대비HW 성능이 좋아지고 있기 때문에, 강력한 HW를 필요로 하는 유연한 플랫폼 활용이 용이해졌고, Loosely Couple 방식으로 인한 성능 저하및 VM(Virtual Machine)이나 Container 등의 부담이 그리 크지 않음.

48architect.mentor@gmail.com Service-oriented Architecture

Informal Session – SOA 관련 국내 현실 (2/3)

SOA 잘 할 수 있나?

아니오...

표준도 없고(하다 못해 서비스를 표현하는 표준 Notation 조차도 없음), 서비스 모델링을 하기 위한 전제, 모델링 방법 및 구현 방법이 거의모든 벤더마다 다름. 수십가지 이상의 객체지향 방법론이 등장했던 것처럼, SOA 방법론은 벤더 수보다 많이 등장하고 있는 상황이다보니SOA 방법의 최적화가 이루어지지 못하고, 프로젝트 특성에 따른 다양한 전략도 적용하기 어려운 상황임. (제한된 Global Company는체계적 SOA를 갖고 있지만, 국내 여건에 충분하지 않고, 국내는 영업 인력 중심이기 때문에 정작 Know-how가 있어도, Local에는 지식전수가 되지 못함.)

특히, 국내의 SI는 모델링 인력이 DB 분야외에는 매우 부족한 상황이기 때문에 UI, Class, Component, Workflow 등을 적절히 포함한Service Modeling에 대한 인력이 별로 없다고 봐야함. 당연히 SOA 특성을 반영한 QA, Architect 특히 PM이 없는 상황임.

따라서 국내의 어떤 프로젝트도 SOA를 잘 할 수 있는 상황이 아님. 다음 페이지에 개략적인 SOA의 문제점을 적어놓았음.

Mission Impossible? 그럼, 왜 그렇게많은 조직들이… SOA를 부르짖을까?

1. SW 재개발 예산 빌미 (가장 컸던 것이C/S, 다음 WEB, 그 다음 CBD, 지금은 SOA) 예전에 잘 못한 거 하려고...

2. SOA로 기존성능 내려면 훨씬 많은 장비를 팔아먹을 수 있다.^^ (벤더들의막강한 영업력에... 국내의 CxO들이어찌할 방법은 없다.)

49architect.mentor@gmail.com Service-oriented Architecture

Informal Session – SOA 관련 국내 현실 (3/3)

• 해본 Customer가 별로 없음. (원시인에 주어진 노트북) ex, Service User? (

누구이고, 준비되나?), SCM/DCM…Value-Driven – Difficult!

• 찾고, 정의하는 형식이 (Official or De facto)표준화된 바 없음.

• 어떻게 구현될 것인지 표준화된 바 없음. 표준 표기(Notation)조차 없음.모델링? – BAD!

• 표준화된 Environment 없고, 매우 어려움. (WSDL, UDDI, Descriptor 등

작성…) SOA라는 공통 대상하에 모든 벤더들이 동상이몽(침 줄줄)하고 있음...개발? – Difficult!

• 효율적 테스트 방법/환경 없음. 애당초 목적이 효율적 테스트에 있지 않음.테스트? – In-efficient!

• (특정 플랫폼이 아닌)Internet, XML 기반이기 때문에 최적화시킬 수 없음. 언

어(C, C++, Java,…) 수준 이상의 성능 저하.성능? – BAD! (Time & Resource)

Service Learning Curve (Web Services,

SOA,…) – Huge!

• 현재 대부분의 고객/벤더에 없음. 일부 Biz Framework(Expensive!)과 Biz

와 무관한 App. Framework(Heavy!)만이 존해할 뿐.

“Reusable IT/SW Asset 기반”이 전제임

– Almost Nothing!

• 적절 Risk 대응이나 관리... 어려움. 사람이 없는데... 뭘 할 수 있을까?관리자 및 SOA 관련 전문가 부재 – Difficult!

Transaction & Security에 대한 방안 필요!

• BearingPoint: SOA Can Be Costly, Hard To Maintain…

• SAP: SOA는 고가인데다 구현하는데 오랜 시간이 걸리기…

“고가”, “구축 기간 오래 걸림”, “유지보

수 어려움”

•Tx와 Security는 기업 애플리케이션의 기본임.

• 기존 체계에 대한 경험이 많을 수록 러닝커브는 더욱 커짐. (아이러니...)

50architect.mentor@gmail.com Service-oriented Architecture

Service가 뭘까?

Vision, Mission, Goal

[여의도 최고 미용실, Luxury Service 제공, 최고의 Cutting Service, Pama.. Service]

Biz Strategy

[주기적 길거리 홍보(도우미), 최고/최신 기자재/약품 사용, Tea lounge 마련]

Major Portfolio

[파마, 염색, 커팅, …]

Organization

• [마케팅, 회계, 구매, Main 미용사들, 보조 미용사들]

Constraints, Compliance

• [여의도, 200~300평, 위생법(?),…]

Service (주로 대외 고객 중심의 서비스)

[커팅 서비스]

Brief Description

• [머리카락 자르기]

Brief Process (Component Integration)

• [희망 스타일 묻기, 스타일 권고하기, 자르기, 머리감기기, 드라이 및 스타일링]

Constraints, Compliance

• [상품권 안됨, 가발 커팅 안됨]

• [타 서비스 연계: 염색 서비스 전의 서비스로(변화는,…), 파마 서비스 전의 서비스로(변화는,…)

Cf. 컴포넌트: [파마], [염색], [커팅], [머리세척], [드라이], [장비관리 – 파마말이기계, 머리세척기, 거울, 의자, 가위, 톱(?),…], [돈관리 –금전등록기, 현금,…], [고객]

51architect.mentor@gmail.com Service-oriented Architecture

모델링 관점에서 보면 Service가 뭘까?

Business& Integration

Changeability& Usability

Quality& Productivity

Enterprise-wide Agility

가장 중요한 것은 Function과 Data이다.이것만 있으면 다 할 수 있다. 또한 Function과Data가 없다면, 아무 것도 할 수 없다. Function과Data 없는 Object? Component? Service?흥. 핏. 쳇...다른 것들은 조금 더 잘해보기 위한 수단일 뿐이다.

52architect.mentor@gmail.com Service-oriented Architecture

SOA의 기원(Origin)

Publication Date: 12 April 1996

"Service Oriented" Architectures, Part 1

Roy W. Schulte, Yefim V. Natis

A service-oriented architecture is a style of multi-tier computing that helps organizations share logic and dataamong multiple applications and usage modes.

53architect.mentor@gmail.com Service-oriented Architecture

SOA – 패러다임의 진화

54architect.mentor@gmail.com Service-oriented Architecture

SOA Maturity Model

SOA에 대한 이해는 다양한 모습과 수준의 SOA Maturity Model을 통해 이해해볼 수 있다.

또한 SOA 도입에 있어서 SOA maturity Model 은 현재 수준과목표 수준을 결정하고 해당 수준의 성취를 위한 다양한 활동과 적용방안등을 결정하는데 매우 중요한 역할을 한다.

SOA Maturity Model이란?

SOA의 도입목표와 목표달성을 위한 요건을 단계별로 정의하여 구성한모델

SOA 인증을 위한 모델은 아니며 다양한 관점에서 SOA의 특성과 관련내용을 포함하여 구성된 모델

프로젝트의 범위와 목표에 따라 다른 성숙도 Level을 가질 수 있으며, 무조건 높은 성숙도를 가져야 하는 것은 아님

55architect.mentor@gmail.com Service-oriented Architecture

다양한 SOA Maturity Model

SOA MM은 크게 Governance 측면과 Technology 측면 그리고 Process 측면으로 나누어 유형을 분류 할 수 있으며다양한 단체 및 솔루션 제공사 들이 각각의 특성을 지닌 모델을 제시 하고 있음.

SOA 성숙도 모델 설명

IBM SIMM•� 시스템 관점에서 통합의 단계별 성숙도로 구분하고 있음•각 단계별 개발 방법론, 아키텍처 스타일, 하드웨어 시스템 구성 형태 등을 제시 하고 있음

HP SOAMM•� Business, 아키텍처, People, Technology 등 Governance등 관점에서 역량 모델 제공•SOA Domain 과 Sub Domain 에 대한 세부 항목과 각각의 수준별 필수 요건에 대한 항목을 제공

MS SOAMM•타 벤더와는 다른 형태의 접근을 취하고 있음•성숙도 수준별 기업의 비즈니스가 요구 하는 내용을 IT 에서 필요한 형태의 역량으로 구분후 해당 수준에 매핑 하여 제공

BEA •SOA 구현프로젝트 위주로 성숙도 수준이 정리 되어 있음

Oracle/Accenture•SOA 를 이용하는 수준으로 SOA 성숙도 수준을 정리 하고 있음•각 단계별 SOA 를 활용하는 특정 업무의 예를 들어 주고 있음

Sonic/Amberpoint/Bearing Point

•CMMI 를 인용 한 것이 특징임•각 단계별 도입 효과(비즈니스 적인)를 제시 하고 있으며 CSF 를 제시함•필요 주요 표준기술과 목표,조직의 특성 등 상세한 부분을 제시하고 있음•각 단계별 하드웨어 구성과 중요 변화에 대한 언급이 상세함

LG CNS•EA 연장선상에서 SOA 를 바라보고 있음•성숙도 모델과 로드맵을 분리 하여 제공

CBDi•기존 방법론의 문제를 해결한다는 취지를 가지고 있으며 비즈니스 효과를 중심으로 성숙도 모델을 제시•SOA 의 거버넌스 관점에서 성숙도 모델을 제시하고 있음(인력, 스킬, 역할 등)

BPTrends•CMMI 를 인용 한 것이 특징임각 단계별 필요 역량으로 비즈니스 프로세스의 성숙도와 함께 표현 되어 있는 것이 특징임

56architect.mentor@gmail.com Service-oriented Architecture

Ex) IBM Service Integration Maturity Model(SIMM)

Silo ServicesComposite Services

VirtualizedServices

DynamicallyRe-ConfigurableServicesComponentizedIntegrated

Level 1 Level 4 Level 5 Level 6 Level 7Level 3Level 2

Applications

Methods

Organization

Infrastructure

Architecture

Business

View

Modules ServicesProcess Integration

via Services

Dynamic

Application

Assembly

ComponentsObjects

Structured Analysis

&

Design

Service

Oriented

Modeling

Service

Oriented

Modeling

Grammar

Oriented

Modeling

Component Based

Development

Object

Oriented

Modeling

Ad hoc IT

Governance

Emerging SOA

Governance

SOA and IT

Governance

Alignment

SOA and IT

Governance

Alignment

Ad hoc IT

Governance

Ad hoc IT

Governance

SOA and IT

Governance

Alignment

Service

Oriented

Modeling

Process Integration

via Services

Platform

Specific

Platform

Specific

Platform

Neutral

Dynamic

Sense &

Respond

Platform

Specific

Platform

Specific

Monolithic

Architecture

Emerging

SOAGrid Enabled SOA

Dynamically Re-

Configurable

Architecture

Component

Architecture

Layered

ArchitectureSOA

Platform

Specific

Function

Oriented

Service

Oriented

Service

Oriented

Service

Oriented

Function

Oriented

Function

Oriented

Service

Oriented

SOA maturity Model 을 시스템 통합 관점과 어플리케이션 구현 방법 관점에서 SOA 성숙도를 정리해 놓은 점이 특징

57architect.mentor@gmail.com Service-oriented Architecture

Simple SOA Requirement

Quality?

품질(Quality)이란? 명시적 또는 묵시적으로 기대했던 바를 만족시킬수 있는 제품 또는 서비스가 갖는 특성들을 총칭하는 말이다.품질속성(Quality Attribute)이란? 양이나 질로 관찰하여 수치로 측정할 수 있는 시스템의 특성이다.품질요구사항(Quality Requirement)이란? 시스템이 제공해야 할 품질속성의 수준을 말한다. 품질속성은 관찰할 수 있고 측정할 수 있어야하기 때문에 품질요구사항도 가능하면 정확한 수치로 제시되어야 한다.품질속성시나리오(Quality Attribute Scenario)란? 품질속성과 관련된 상황을 기술한 것으로 Source of Stimulus, Stimulus, Environment, Artifact, Response, Response Measure 등을 포함한다.품질모델(Quality Model)이란? 품질속성을 분류하고 정의하여 누구나인정할 수 있는 품질 측정 기준을 정의한 것이다. (예, ISO 9126의Quality Model, SW Arch. in Practice 2Ed.의 Quality Model 등)

품질 관련 용어들

품질 요구사항

1. 변경용이성(Changeability): 업무적 변경 효율성2. Time to market: 비즈니스 서비스의 적시성 서비스통합: 데이터 통합이 아닌, 서비스 수준의 통합 기존자산 재사용: 기존 서비스 재사용3. 사용성(Usability): 편리한 User Interface & Interaction

품질 요구사항 관련 품질 달성 방안

1. Layered: 소프트웨어 모듈별 역할 정의 및 변화 추적성 확보2. Rule: 변화 로직의 Localization, 업무 변화에 대한 유연성 확보3. MVC: UI, Control, Data간 유연한 상호작용 체계 확보4. Service Hierarchy: Domain Area, Node Area, Composite Service, Atomic Service, Domain Component Loosely Coupled with SCA5. Component: Interface & Implementation Class, reference, property => Interaction with Black Boxes6. Class: Constructor & Annotation => Self-Contained & Configuration7. Function: Abstracted API => Change Tolarence8. Data: Abstracted Data Structure (VO, DTO) => Abstracted Data Structure with SDO9. Reuse: IT Asset의 적극적 활용 Legacy Wrapping Framework for Development & Operation Solution – ESB(MCA, EAI), RBMS10. Rich Client: Powerful User Interaction & Accessibility

The totality of features and characteristics of a product or a service that bear on its ability to satisfy stated or implied needs. - ISO/IEC 9000

58architect.mentor@gmail.com Service-oriented Architecture

Software Architecture Overview

UILayer

Biz LogicLayer

Resource

UserInterface

FrontController

Database RBMS BPM EAI

<<SCA>>

Composite Service{Impl=BPEL}

<<SCA>>

Composite Service{Impl=JAVA}Composite

Service

AtomicService

DomainComponent

DomainComponent

AtomicService

DomainComponent

Workflow Component

EAI 연동Component

타 시스템

Application 연동

CompositeService

Component Framework(Optional)

Authentication/Authority

1. Layered: 소프트웨어 모듈별 역할 정의 및 변화 추적성 확보2. Rule: 변화 로직의 Localization, 업무 변화에 대한 유연성 확보3. MCV: UI, Control, Data간 유연한 상호작용 체계 확보4. Service Hierarchy: Domain Area, Node Area, Composite Service, Atomic Service, Domain Component => Loosely Coupled with SCA5. Component: Interface & Implementation Class, reference, property => Interaction with Black Boxes6. Class: Constructor & Annotation => Self-Contained & Configuration7. Function: Abstracted API => Change Tolerance8. Data: Abstracted Data Structure (VO, DTO) => Abstracted Data Structure with SDO9. Reuse: IT Asset의 적극적 활용 Legacy Wrapping Framework for Development & Operation Solution – ESB(MCA, EAI), RBMS10. Rich Client: Powerful User Interaction & Accessibility1

2

3

4

5

6

7 8

9

9

9

10

9

Enterprise Service Bus (Max)

Enterprise Service Bus (Min)

1

1

59architect.mentor@gmail.com Service-oriented Architecture

고객관리Component

고객관리Component

증권고객평가Service

고객평가Service

Service-Oriented Architecture

CompositeService

AtomicService

DomainComponent

(외부)Service

고객등록Service

고객

SingleView 고객평가 ……

고객Component

보험고객확인Service

증권고객확인Service

기존 시스템기존 시스템고객

Component

보험고객평가Service

기존 시스템기존 시스템

(외부)고객평가Service

Domain

Node

OrchestrationChoreography

기존 시스템ERP,...

기존 시스템ERP,...

channelESB

통합Service

증권Service

보험Service

Service & Component

Node 군

External Node

Domain: Logical AreaNode: Physical Area(노드 내는 프로세스 내 통신노드간 통신은 프로세스간 통신)

4

Service Hierarchy에 업무와 물리적 상황을 반영

5 6

60architect.mentor@gmail.com Service-oriented Architecture

SOA라도, 기존의 모든 개발 이슈들을 피해갈 수 없다.

큰 프로젝트라면, (SOA 프로젝트라도) 다음 중 어느 것 하나 피해갈 수 없다...

개발 가이드 반영 -> 개발자 Skill Set 분석 -> 교육 자료 작성 & 교육 실시 & 평가

General Issues

Demon, Log, Debug/Release, Message, Naming, Coding, Batch, Error/Exception, Validation, Reporting, Packaging, SQL, Stored Procedure & Trigger, Localization(Korean) & Internationalization, Test Automation, Build, Deployment, Scripting, File Upload/Download, En/Decription, Session Management, Pooling, Threading, Asynchronous, Caching, Messaging, Env. Configuration, Transaction, Security Policy, Stateful/Stateless, Dynamic Injection, DTO/VO/SDO, Memory Handling or Garbage Collection, ACL, OR-Mapping/DAO, Transaction, ...

이들은 아키텍처 관련 사항들 뿐만 아니라, 이슈들끼리 서로 관련성을 갖는다.

Middleware/Solution[ESB/MCA/EAI, EAM] Interaction

Development/Test/BackUp/Operation Environment[Framework, CASE, Analyzing&Testing Tool]

개발은 노가다! 체력이 제일 중요하다!

61architect.mentor@gmail.com Service-oriented Architecture

SOA 환경/표준 (Simple… 예시)

[Java & Web Services]

Java(J2SE) 1.5, 1.6 (Generic, Annotation, ...)

Java EE 5 (Java EE 6 - Dynamic WS Endpoint,...): JAX-WS(JAX-RPC)2.0, JAXB2.0, WS-Metadata2.0, WSEE1.2, EJB3.0...

AJax (Asynchronous JavaScript & XML, XMLHttpRequest & HTML DOM, ear, war)

EJB(Enterprise JavaBeans) vs. POJO(Plain Old Java Object)

WSDL 1.1/2.0

SOAP 1.1/1.2

UDDI 1.0/2.0/3.0

Web Services vs. REST

JAX-WS 2.0 (Resource Injection)

JAXB 2.0 (SAX, DOM, XPath,...)

Servlet, JSP, JSTL, XSLT, XML Schema, ...

HTTP, JMS, XML, JNDI, Dispatching, Serializing, Deployment, Build(Ant, Maven)

Type Mapping(Standard Binding, Source Code Annotation, Algorithmic, Rule Based)

Marshalling/Unmarshalling

Validation, Marshal Event Callback, Mapping Annotation, ...

Static/Dynamic

XML Catalogue(OASIS XML Catalogs 1.1)/ServiceProvider/...

[Web Services Standards]

XML/ebXML: eXtensible Markup Language

SOAP: Simple Object Access Protocol

WSDL: Web Services Definition Language

UDDI: Universal Description, Discovery and Integration)

WSCI: Web Services Choreography Interface

WSFL: Web Services Flow Language

DSML: Directory Services Markup Language

XLang

BTP: Business Transaction Protocol

XML ENC: XML Encription

XKMS: MXL Key Management System

XML DSIG: MXL Signature

XACML: eXtensible Access Control Markup Language

SAML: Security Assertions Markup Language

62architect.mentor@gmail.com Service-oriented Architecture

마무리 - 서비스의 특징

서비스에 대한 정의

서비스의 특징

Coarse grained : 서비스는 fine-grained 구성요소를 포함(cf. 추상화 & 캡슐화)

Well-defined contract : 서비스 사용과 기능에 대한 정보(cf. WSDL)

Loosely coupled : 변화에 영향을 받지 않는 재사용 촉진(cf. Async.)

Discoverable : 의도한 소비자에 대한 “광고” (cf. service directory)

Durable : 지속 가능하면서 탄력적이어야 함 (cf. 비즈니스 주제는 영속)

Composable : 조립 가능 + 유연한 기능추가 (cf. orchestration)

Business aligned : 서비스의 식별과 분석은 비즈니스로 부터…

Reusable : 재사용 관점을 비즈니스로 가져온 것임

Interoperable : 모든 서비스가 상호운용 가능하지는 않음

SOA에서 서비스란… 지속적이고 개별적인 업무/기술적 기능들의 집합

In the context of Enterprise architecture, Service-orientation, and Service-oriented architecture, the term ‘service’ refers to a discretely defined set of contiguous and autonomous business or technical functionality.

?

63architect.mentor@gmail.com Service-oriented Architecture

프로그램 로직을 직접적으로 담고 있는 단위서비스(Atomic Service)와

단위서비스들의 조합 로직을 담고 있는 복합서비스(Composite Service)가 가장 기본임

마무리 - 서비스 분류

Intra-EnterpriseOrchestration

Composition

External-EnterpriseOrchestration

Composition

Inter-EnterpriseOrchestration

서비스를 포함하는 프로세스의 흐름을 정의

큰 규모의 기능을 수행하도록서비스들을 결합

엔터프라이즈 간 상호작용서비스 인터페이스

Composite Service

Atomic Service

Transaction

Program

Function

Data

Transaction

Program

Function

Data

64architect.mentor@gmail.com Service-oriented Architecture

마무리 - 서비스의 크기

PC 판매

서비스의 granularity 결정은 제조사(IT)가 아닌, 판매원(현업)이 결정해야 함

기업의 전략 및 역량, 경쟁환경에 따라서비스는 변한다.따라서, 획일적인 기준은 의미가 없고,경쟁업체와 차별화된 서비스를정의해 나갈 수 있어야 한다.

전자상가

단위 서비스의 기준이 다르다 !

동일 할 수가 없다 !!!서로 다른 조직간의 연계가 활성화됨에 따라 점차 서비스 기준이 복잡해진다.

Atomic 서비스는 절대 기준이 아닌조직 & 비즈니즈 구조에 따라상대적 개념으로 변화해야 한다.엔터프라이즈

AtomicService

CompositeService

전자대리점

홈쇼핑

Supply Chain

Orc

hestra

tion

단, 프로젝트 추진 시에는절대적 개념으로 정의해야 한다.변화에 대한 베이스라인이 확정되면절대적인 개념이 필요하다.

65architect.mentor@gmail.com Service-oriented Architecture

마무리: SOA = 서비스 제공을 위한 소프트웨어 아키텍처

소프트웨어 구조 관계

분할

사용

레이어

클래스

클라이언트-서버

프로세스

동시성

공유 데이터

배치

구현

작업 배정

~의 하위모듈인, ~와 비밀을 공유하는

~의 정확한 존재를 요구하는

~ 정확한 존재를 요구하는,

~의 서비스를 사용하는,

~에 대한 추상화를 제공하는

~의 인스턴스인,

~의 접근 메쏘드를 공유하는

~와 통신하는, ~에 의존하는

~와 동시에 실행되는

~와 동시에 실행될 수도 있는

~을 배제 또는 선행하는

동일한 논리 쓰레드에서 실행되는

데이터를 생산하는, 데이터를 소비하는

~에 할당하는, ~로 이전하는

~에 저장되는

~에 작업을 배정하는

도움이 되는 영역

자원 할당과 프로젝트 구조화 및 계획, 정보 은폐, 캡슐화, 형상 통제

엔지니어링 하위집합, 엔지니어링 확장

“가상 기계” 이식성 위에 점증적인 개발을 통해 시스템 구현

공통 템플릿으로부터 신속하게 구현하는 객체지향 설계 시스템

분산 운영, 관심사의 분리, 수행성능 분석, 부하 균형

스케줄링 분석, 수행성능 분석

자원 다툼이 있는 곳, 쓰레드가 분기, 병합, 생성, 삭제 되는 곳을 식별

수행성능; 데이터 통합; 변경용이성

수행성능, 가용성, 보안 분석

형상 통제, 통합, 테스트 활동

프로젝트 관리, 전문 기술 사용, 공통성 관리

뷰타입

모듈

C&C

할당

요놈만이라도예를 들자.

66architect.mentor@gmail.com Service-oriented Architecture

Ex) 레이어 (Layers)

복잡한 소프트웨어 시스템을 분리할 때 가장 많이 사용하는 기본 기술이다.

상위레이어는 하위레이어를 호출... 끝.

전체를 이해하지 못해도, 하위레이어만을 하나의 상호작용하는 대상으로 인식할 수 있다.

상호작용, 의존성 제한/최소화, 관심사/변화의 추적성

시스템, 프로젝트, 부서, 팀, 팀원, 등등 전체 표준화, 일관성을 유지하기 위해 좋은 수단이다.

하지만, 한 변화가 레이어들간 연쇄 반응을 일으킬 수 있으며, 수행 성능상 문제점이 나타날 수 있다.

가장 어려운 점은 얼마나 많은 레이어를 정의하고, 어떤 역할을 할당할 것인가에 있다.

클라이언트[UI/logic/lib, Event] & 서버[로직 & StoredProcedure/Trigger/데이터]

종속성, 유연성 문제로 2Tier -> 3Tier -> Multi-Tier 체계로 변화하는 가운데, 다양한 Middleware, Library, Framework, Platform, Standard들이 등장함. 이들 중 가장 영향력 있었던 것은 Web!

Web과 함께 등장한 많은 개발 환경들은 SQL을 별도로 독립시킨 3Tier 체계를 갖추고 있다.

결국, 기업시스템에서 가장 기본적인 레이어는 UI, BizLogic, Resource

Layered & Variability, 예외) Game - Data/DirectX

Enterprise - App/Batch

• 분산환경에서 Vendor들은 각 레이어들을 통합할 수 있는 인프라, 솔루션, 프레임워크들을 출시.

• Rule, Workflow, Common Utility, XML, Security, MCI, EAI, Clustering, Data Access, Messaging, Deployment, Error, Log, I18n, Encription/Decription, ...

타 Layer에 복잡성/변화를 숨기기 위한 고수준(High-level) 인터페이스 정의가 중요함.

67architect.mentor@gmail.com Service-oriented Architecture

Ex) 레이어 - UI

클라이언트의 변화

Thin, Fat, Rich,...

Cmd, Windows(GUI, Mouse, GraphicLib), Browser(Accessability, Network), (ActiveX)Control, Scripting(Static, Dynamic)

Web Brower - HTTP 1.1 - Web Server

Event-driven Environment

Mouse, Keyboard, Actor, Time/Schedule, Error/Exception, ...

Web Server 프로그램 구성

Server Page (Static Page, Dynamic Page), CGI, Servlet, ...

Dynamic HTML 생성 - Front Controller(전체), Page Controller(Object 별)

Web 2.0, RIA, X-internet, Flex, ...

보다 적극적인, 비동기 상호작용(Asynchronous Interaction)

68architect.mentor@gmail.com Service-oriented Architecture

Ex) 레이어 - Business Logic (1/2)

Process vs. Thread

Context: Request(외부로부터의 단일 호출) & Session(C/S간 오랜 기간 상호작용)

Stateless Session

Pool이 가능하고, 적은 Resource로 많은 요청 처리... 기업 App 처리의 기본!

Stateless Server Component는 다른 세션으로부터 다른 요청을 처리할 수 있다.

[Context까지 한꺼번에 받아오던가, DB 등에 저장했다가 불러오던가..., SOA 정책도 필요]

클라이언트 저장: 데이터 암호화, 쿠키, 웹폼에 숨겨진 필드 데이터 직렬화, 리치 클라이언트 객체에 데이터 저장 => 모든 데이터를 항상전송해야. 양이 많으면 부담..., 암호화 문제!

IP 인식? Proxy서버 사용시... Client IP 모두 동일...

서버 저장: 파일, 테이블(소매 시스템의 경우, 클라이언트들 보통 놀고 있음... 적절 & 장애 처리 및 클러스터링이 필요한 경우, 적절)

...도저히 Stateless로 가능한 상황이 아니라면, Stateful...

BizProcess/Workflow, Calculation, Rule

69architect.mentor@gmail.com Service-oriented Architecture

Ex) 레이어 - Business Logic (2/2)

리모트(Remote, Inter-process) 환경 사이를 넘나드는 데이터 구성 - Serialize? XML?

Transaction

UoW(Unit of Work) 처리는?

단순 Transaction Script 수준: 본질적으로 Procedure -> 작은 프로젝트에 적합

lost Update, Inconsistent read, Deadlock

Locking, Isolation, Immutability, ACID => 대부분, 성능과 Trade-off 관계에 있음

기업 애플리케이션에서 동시성을 제어하는 가장 중요한 수단은 Transaction이다.

Transaction은 기술적 문제가 아닌, 비즈니스 전략적 문제이다. (쉽지 않다. 술과 안주를 하나의 Tx로 볼 것인가?)

타당성 검토, 계산 처리, 데이터 저장, 타시스템 호출, 데이터와 함께 UI에 응답

대부분 개발자가 이해하는 간단한 절차 모델이 필요하며, 설정방법이 명확한 지침으로 나타나야 함.

Service Layer와 Domain Model Layer의 이원화 (Optional => Mandatory)

Service Layer는 UI 레이어를 위한 API 역할 뿐만 아니라, 기존 Legacy에 대한 래퍼(Wrapper) 역할을 수행하고, Transaction Control, Security와 관련된 로직을 포함할 수 있으며, Use Case Controller라고 할 수도 있다.

Domain Model 내부에는 데이터 매핑을 위한 모델도 필요하며, 큰 규모 프로젝트인 경우 OR 매핑 또는 데이터 사용 방식은 복잡하다.

70architect.mentor@gmail.com Service-oriented Architecture

Ex) 레이어 - Resource

일반적으로 R-DBMS를 활용한다.

File System을 활용하는 조직/업무도 아직 많다. 하지만, 이에 대한 전략은 비교적 단순하다.

Cache, Entity Bean, XML Description, DBIO, ...

DTO(Data Transfer Object), VO(Value Object), RecordSet, Record, Table-Row, Class/Container/Iterator, SDO(Service Data Object)

OR: M:N, N:1, 1:N, 1:1

SQL은 널리 사용된다. 하지만 성능상 이슈 해결과 효율적 Join, Index 활용은 쉽지 않다.

강력한 SQL vs. 개별 모듈/클래스별로 분할된 SQL(추세)

일반적으로 Table : Class = 1:1 (+ Aggregation + Inheritance + Interface 고려)

Join의 활용 범위..., 뷰..., 인덱싱...

데이터 래퍼는 Database와 Logic을 분리시킴 (분산 환경에서의 변화 용이)

표준화가 가장 안된 분야이며, 툴, 프레임워크 등 다양한 솔루션들과 방식이 혼재됨

그 외 다양한 Resource Access Pattern들이 있다.

Decoupling Patterns

Resource Patterns

Input and Output Patterns

Cache Patterns

Concurrency Patterns

71architect.mentor@gmail.com Service-oriented Architecture

Ex) 레이어 - 분산 (1/2)

Biz Module/Component/Service/System을 잘 정의했어도, 분산 정책은 생각보다 간단하지 않다.

꼭 분산해야 할 경우!

클라이언트 - 서버 사이

큰 시스템의 경우, 애플리케이션 서버 - 데이터베이스 서버 사이

큰 시스템의 경우, 웹서버 - 애플리케이션서버 사이

제품(독립 서버, 독립 SW 솔루션)/Legacy/외부시스템 연계가 필요한 경우 (eDW, ERP)

업무적 안정성, 성능, 보안 등을 고려한 시스템 분리가 필요한 경우 (주문)

모든 분산 환경 앞(Layer, Component, ...)에는 Facade를 둔다.

직접적인 접근이 불가능하거나, 비동기가 필요한 경우?

AJax, RSS, Web Services를 고려하자!

72architect.mentor@gmail.com Service-oriented Architecture

Ex) 레이어 - 분산 (2/2)

배포

서로 다른 서버에 컴포넌트 분리 배포 (소프트웨어 아키텍트 입장에서 볼 때... SI에서는 최악의 형태...)

큰 서버에 몽땅 몰아넣음 (소형 시스템에만 가능한 형태)

서로 다른 서버에 컴포넌트 몰아넣고, 클러스터링함 (일반적 방식)

앞에 답이 하나도 없다. + 모두 답이다... 적절한 수준과 복합적 상황

빈도(동시처리 수, 총 처리수)와 로직 규모, 지역적 특성, 보안, 성능 요구 등 고려해야!

컴포넌트 크기를 서브시스템(ex, Billing System) 수준으로 ~ 컴포넌트 크기를 테이블 수준으로

크기는? 무지 크면... 요청 하나에 엄청난 것이 떠야함.[업무적 포괄성, 비효율성] 작으면, 작은 것만 뜨면됨[관리적 어려움]

시스템에 [하나 ~ 테이블 수] 사이에 정답이 있음, 적정 모듈 수 곡선 중요!

리모트콜은 호출 수를 줄여야한다. 호출 수 줄이면... 일반적으로 컴포넌트 크기는 커진다.

그래도, 객체는 분산하면 절대 안된다... (모든 객체를 단일 컴포넌트에 & 분산)

73architect.mentor@gmail.com Service-oriented Architecture

마지막 - 결론

Service... SOA... 결국은 100%를 결정하는 것이 아닌... 1%의 기존과 유사한 새로운 역할일 뿐이다.

서비스는 변화에 살아남기 위한 형태의 비즈니스 표현일 뿐이며,

SOA는 변화에 살아남기 위한 소프트웨어 아키텍처의 한 형태일 뿐이다.

??? 1%??? 조직의 크기와 특성에 따라, 1%도 안될 수 있다...

다만, 1%라해서 새로운 역할을 쉽게 이해하거나 수행할 수 있다는 것은 아니다.

예를 들면, CEO, CFO, CIO, CTO, CSO, CKO,... 당신은 이런 역할을 쉽게 이해하고 수행할 수 있는가?

당신은 비즈니스를 모두 이해하고 있는가? 당신은 소프트웨어 아키텍처를 이해하고 있는가? 그리고... 당신은 사람과 조직을

이해하고 있는가?

자연... 인간... 문명... 이런 것들이 빙산의 실체를 구성하고 있는 것들이다.

(세상에... 그럼... 1%도 안되는, SOA를 제대로 알려면? SOA 프로젝트를 하면서 최소한 5년 이상은 시행착오를 해봐야... 그때부터

이해하는 수준으로 접어들 수 있다... 통달? 최소 30년!)

(이럴 수가... 그럼... 나의... 진짜... 결론은 IT 탈출?...^^)

수고하셨습니다.

74architect.mentor@gmail.com Service-oriented Architecture

Appendix: 선택된 사람들을 위한...좌절하기 코너...

포기를 모르는 사람들을 위한 나락 - Service

모든 것이 쉬운 사람들을 위한 미궁 - SOA

[경고 땡.땡.땡.]Appendix의 내용은

“노약자. 임산부. 미성년자. 그리고,세상을 편하게 살아가려는 사람들은

절.대. 보면 안.된.다.

75architect.mentor@gmail.com Service-oriented Architecture

여태까지의 내용은 단지 하나의 기본... 출발 점에 불과했다...

정말일까? 여태까지의 내용은... 단지 출발에 불과 했을까? 예를 들어 다음과 같은 사항을 생각해보자...

소프트웨어 품질 요건을 맞추기 위한, SOA가 되어야 한다.

EA(Enterprise Architecture)와 Service는 따로 노는 것이 아니다.

SOA를 활용한, MDM(Master Data Management) 체계가 필요하다.

ITIL V3는 서비스 중심의 체계로 변환되었다. Service Strategy, Service Design, Service Transition, Service Operation,

Continuous Service Improvement

CMMi – Service 프로세스의 성숙도 수준을 향상시켜야 한다.

SOA는 Corporate Governance에 근간을 둔 IT Governance 체제와 통합되어야 한다. 즉 SOA는 Enterprise Survival을 위한

하나의 방안에 불과하다.

위에 나열된 말들은 결코 단편적으로 해결할 수 없는 것들이며, 상호 관련성이 존재할 수 밖에 없다. 이들에 대해 어떤 길을 누가제시할 것인가? 모든 사람들이 “문제 해결”을 위해 협력하지 않는다면, 어떻게 “실제적인 효과”를 얻을 수 있겠는가...여기에서 모든 것을 볼 수는 없다...

역설적으로 들리겠지만, 여기서의 내용을 이해하기 위해서는, 철저한 긍정적 생각이 필요하다. Be Positive!

76architect.mentor@gmail.com Service-oriented Architecture

서비스가 무엇인가?

인간에게 의미, 행복, 가치를 던져주는 모든 것들...

77architect.mentor@gmail.com Service-oriented Architecture

서비스는 정말 필요한 것인가?

IT 관련 여러 분야에서 Service Convergence가 일어나고 있음.

아키텍처 (SOA에 많은 벤더들이 집중하고 있다.)

1996년 4월 Gartner Report – 증가하는 IT 환경의 복잡성 해결을 위해, SOA 필요성 제시한 이후...

구조적, 정보공학적, 객체지향적, 컴포넌트 기반 이후 “IT 변화 관리의 핵심 패러다임”으로 진화하였으나...

아직 충분히 시장에서 성숙되지 못했다.

SOA는 변화하는 환경에 적응하기 위해, 대두된 하나의 중요한 패러다임일 뿐이며...

모든 것을 해결하는 “Silver Bullet”이라는 것은 없다... SOA도 모든 것을 해결하는 것은 아니다...

프로세스 (CMMi 1.2)

2006년 CMMi - Development & CMMi - Acquisition 제정

2007년 CMMi - Services 제정

IT 서비스 관리 (IT Service Management)

ISO 20000, Sarbanes Oxley 등 IT 시장의 컴플라이언스 및 IT 거버넌스에 더 부합되는 서비스 관리 요소들과, 비즈니스 연계 강화를 위한서비스 관리 요소들을 포함하는, 시장의 변화 요구를 잘 수용할 수 있는 Best Practice가 필요함.

2007년 IT 서비스 관리의 Best Practice로 ITIL(IT Infrastructure Library) V3가 제시됨.

• Service Strategy

• Service Design

• Service Transition

• Service Operation

• Service Continuous Improvement

Architecture, Process,Management 영역에서도Service는 강조되고 있다.

78architect.mentor@gmail.com Service-oriented Architecture

EA & ITIL V3 & IT Governance

지속적 프로세스 평가 및 개선

변화의 축 - Service Strategy in ITIL V3

Service Design in ITIL V3

Service Transition in ITIL V3

Service Operation in ITIL V3

변화에 관한 추진력 - Continual Service Improvement in ITIL V3

Biz ArchitectureInfo. ArchitectureApp. ArchitectureTech. Architecture

Management ProcessEngineering ProcessSupport ProcessOrg. Process

PrinciplesArchitecturesInfrastructuresBusiness needsInvestment

Architecture CentricPlanning *

Process CentricBirth...

Service Centric ->Business for Money!!!

Organization CentricProsperity ^^

EA 중심 ISP 컨설팅ITIL 중심

ITSM 체계 구축IT Governance 구축

IT 통합 관리 체계 구축

ITIL이 뭐여?IT Gov.은 또 뭐여?

SPI 중심 SI

서비스 관리를 잘 하려면...

ITIL V3에서 뽄딸 것이 많습니다.

79architect.mentor@gmail.com Service-oriented Architecture

ITIL V3 이야기를 조금 합시다.

ITIL is a “Good Practice”.

ITIL의 가장 큰 단점은 – 내 것이 아닌, 남의 것(Know-How)이라는 점이다. 나에게 맞추어야 한다.

특히 CMMi, ITIL 등의 선진 Practice 내용에 포함된 “Generally Accepted Culture”가 전혀 다르다.

A Service is about “Creating VALUE for the Customer”.

A Service is a Means of delivering value to customers by facilitating outcomes the customers want to achieve without the ownership of specific costs or risks.

Value is the core of the service concepts.

업무 서비스(Business Service), 지원 서비스(Support/IT Service)로 나누어 생각할 수 있다. 핵심은 “노동 가치"

Service Management is a set of specialized organizational Capabilities for providing value to customers in the form of services.

A System is a Group of interacting, interrelating, or interdependent components that form a unified whole, operating together for a common purpose.

시스템은 주어진 환경을 바탕으로, 특정 목적을 위한 HW, NW, SW 구성과 상호연동을 포함한다.

A function is a Subdivision of an organization that is specialized in fulfilling a specified type of work, and is responsible for specific end results.

ITIL에서 Function이란 조직/팀을 의미한다.

A process is a structured set of Activities designed to accomplish a defined objective.

Measurable, specific results to customers or stakeholders, respond to a specific event

정해진 목적 달성을 위한 상호 관련 행위들의 모임이 프로세스다.

일단. 첫 걸음은용어부터…

용어 용어 용어 용어 용어 용어 용어 용어 용어 용어 용어 용어 용어 용어

ITIL V3를 조금만이라도이해하기 시작합시다.

80architect.mentor@gmail.com Service-oriented Architecture

ITIL V3 Service Lifecycle (1/2)

ITIL V3 focuses on the Service Lifecycle and the way service management components are linked.

ITIL V3에서는 Service의 기획, 생성과 개선에 대한 전체 생명주기를 다룬다.

Service Lifecycle consists of five phases.

Service Strategy – the phase of designing, developing and implementing service management as a strategic resource.

• Service Strategy is the axis of the Service Lifecycle.

Service Design – the design phase of developing appropriate IT services, including architecture, processes, policy and documents; the design goal is to meet the current and future business requirements.

Service Transition – the phase of developing and improving capabilities for the transition of new and modified services to production.

Service Operation – the phase of achieving effectiveness and efficiency in providing and supporting services in order to ensure value for the customer and the service provider.

• 기존의 ITSM은 주로 운영관점에서 모든 것들을 생각해왔다. ITIL V3는 Strategy, Design, Transition, Operation, Improvement 모두와 그들간의 관련성을 포함한다.

Continual Service Improvement – CSI phase stands for learning and improving, and embraces all cycle phase.

• SPI(Software Process Improvement) 관점과 매우 유사하다. 다만 범위가 더욱 포괄적이고 목적이 ITSM에 전문화되어 있다.

Service Life CycleStrategy – Design – Transition– Operation – Improvement

81architect.mentor@gmail.com Service-oriented Architecture

ITIL V3 Service Lifecycle (2/2)

Service Strategy

Financial Management

Service Portfolio Management

Demand Management

Service Design

Service Catalogue Management

Service Level Management

Capacity Management

Availability Management

IT Service Continuity Management

Information Security Management

Supplier Management

Service Transition

Transition Planning and Support

Change Management

Service Asset and Configuration Management

Release and Deployment Management

Service Validation and Testing

Evaluation

Knowledge Management

Service Operation

Event Management

Incident Management

Request Fulfillment

Problem Management

Access Management

Monitoring and Control

IT Operations

Service Desk

Continual Service Improvement

CSI Improvement Process

Service Reporting

목적과 기준

목적 달성 방안

목적 실현

서비스 제공

프로세스 개선 기준이 된 책: VHP, “Foundations of IT Service Management Based on ITIL V3”, 2007* 이 이후 내용의 대부분은, 이 책을 근간으로 정말 성의 없이... 대충 간추린 것이다. (그림 빼고...)

CMMi를 보면 PA라는 게 있죠...왼쪽에 나열된 것은 그런 놈들과

비슷한 놈들입니다. 음... 갑자기 두통...

82architect.mentor@gmail.com Service-oriented Architecture

Service Strategy

Service? Strategy?

Business eco systems

From value chains to value nets

Linking to external practices and standards

Adaptive processes for customers, services and strategies

Managing uncertainty and complexity

Increasing the economic life of services

Selecting, adapting and tuning the best IT service strategies

Service Strategies – Covers Practical decision making

우리가 Google과 같이잘 나가는

회사가 되지 말란 법이 있는가?

83architect.mentor@gmail.com Service-oriented Architecture

Service Design

Service? Design?

Policies, architecture, portfolios, service models

Effective technology, process and measurement design

Outsource, shared services, co-source models?

How to decide & how to do it

The service package of utility, warranty, capability, metrics tree

Triggers for re-design

Service Design –A Pragmatic service blueprint

Director Service Management

Service Level

Manager

Problem Manager

Security Manager

Procurement Manager

Activity 1 AR C I I C

Activity 2 A R C C C

Activity 3 I A R I C

Activity 4 I A R I

Activity 5 I I A C I

RACI: A Model used to help define Roles and Responsibilities. RACI stands for Responsible, Accountable, Consulted and Informed.

회사가 가려는 방향을 구체적 전략으로실체화하는 관리 역량이 필요하다.

84architect.mentor@gmail.com Service-oriented Architecture

Service Transition

Service? Transition?

Newly designed change, release & configuration processes

Risk and quality assurance of design

Managing organization & cultural change during transition

Service management knowledge system

Integrating projects into transition

Creating & selecting transition models

Service Transition –Managing change, risk & QA

만들자. 어떻게?잘!

85architect.mentor@gmail.com Service-oriented Architecture

Service Operation

Service? Operation?

Robust end-to-end operations practices

Redesigned, incident and problem processes

New functions and processes

Event, technology and request management

Supporting strategy, design, transition and improvement

SOA, virtualization, adaptive, agile service operation models

Service Operation –Having Responsive, stable services

재주는 곰이 다 부렸다.이제는 돈을 벌 차례다.

86architect.mentor@gmail.com Service-oriented Architecture

Continual Service Improvement

Service? Improvement?

The business case for ROI

Getting past just talking about it

Overall health of ITSM

Portfolio alignment in real-time with business needs

Growth and maturity of SM practice

How to measure, interpret and execute results

Continual Service Improvement –Measures & improvements that work

학습 조직... 지속적 개선...이런건... 태고적부터 중요했던 것이다.

87architect.mentor@gmail.com Service-oriented Architecture

ITIL V3 Processes across the Service L/C

여기 있는 것들을 하나씩 이야기할려구?차라리... 주겨라 주겨...

음... 그럼 딱 하나만 예를 들자구요.

88architect.mentor@gmail.com Service-oriented Architecture

Availability Management

Availability Management

Determining the availability requirement of the business

Determining the VBF(Vital Business Functions)

Determining the impact of failing components

Defining the pre-requirements for availability, reliability and service life of the IT components

Monitoring and analyzing IT components

Investigating availability, reliability and service life and reporting on them from the perspective of the business, the user and the IT organization

Availability management monitors, measures, analyzes and reports on the following aspects: availability, reliability, maintainability, serviceability

Measuring is extremely important. It can be done from three perspectives: business perspective, user perspective, the IT service provider’s perspective

오호... 어베일러빌러티...조금 들어본 것 같기도 하고...

가용성이잖아...그거 뻔한거 아닌가?

But...

89architect.mentor@gmail.com Service-oriented Architecture

잠깐!

왜... 잠깐?

전 세계적으로도 프로세스에 대한 표준이라는 것은 거의 존재하지 않는다. 다만 (Best) Practice를 제시하고, 각 조직에 맞는 프로세스를정의하여 활용하도록 권고할 뿐이다.

실제의 모든 프로세스는 매우 어렵다. 그들 프로세스들이 갖는 이론적 배경들이 심오(?)하지는 않으나, 이론理論 자체는 (이론異論은 있을 수있다...) 더럽게(!) 따분하고 재미없고, 게다가 경험이 없으면 이해하기도 어렵다. 또한 경험이라는 것이, 각 조직의 상황이 동일할 수 없기때문에 경험을 통한 프로세스 공유가 쉽지 않다. 프로세스는 쉽게 이해할 수 있는 것이 아니다. (SPI, CMMi, SPICE 등에 관련된 일을 조금해봤으면 안다...) 가끔은... (정말 가끔은...) 이론적 근간을 알아보거나, 최소한 그들(!)의 존재성을 인식 할 필요가 있다. 프로세스를 더 잘 알고활용하기 위해서...

Availability Management를 통해 그 기반에 깔린 이론적 배경을 살펴보고, 프로세스와 관련된 난이도를 조금이나마 이해해본다.

Availability란 언제 어디서나 서비스나 자원을 제공해 줄 수 있는 시스템의 능력을 말한다.

오류(fault)가 발생해서 시스템이 더 이상 서비스나 자원을 제공하지 못하는 장애(failure) 상태에 빠지면 가용성이 낮아진다.

(놀라운 일... 가용성을 수식으로... 수식의 놀라운 힘... 시각적 효과로 두통을 발생시킴...)

• A: Availability

• MTBF : 장애와 장애 사이 평균 시간(Mean Time Between Failures). 장애 없이 시스템을 가동하는 평균시간

• MTTR : 복구에 걸리는 평균 시간(Mean Time To Recover). 장애 때문에 생기는 평균 다운 시간

MTTRMTBF

MTBFA

90architect.mentor@gmail.com Service-oriented Architecture

잠깐!

가용성: 가동시간과 다운시간

... 감 잡자... (가용성을 한마디로... 가용성은 돈 먹는 하마다!)

가용성(Availability)같은 것을 아키텍처 관점에서는 품질 속성(Quality Attributes)이라 한다. 이런 품질 속성들을 만족시키기위한 다양한 방법들이 존재하며, 그 중 하나가 다음과 같은 것(품질 속성 시나리오라고 함)을 파악해보는 것이다.

Source: 시스템 내부, 시스템 외부

Stimulus: 누락(omission), 폭주(crash), 틀린 타이밍(timing), 틀린 응답(Response)

Artifact: 프로세스, 프로세서, 통신 채널, 저장 장치,...

Environment: 정상 운영 환경, 조절 운영 환경(일부 가동, 대체 시스템 가동)

Response: 오류나 장애 기록, 관계자에게 통보, 운영 환경 교체, 시스템 운영 중단,...

Response Measure: 가동률, 가동 시간, 복구시간

가동시간 비율 다운시간 비율 연간 장애 시간 주간 장애 시간

98% 2% 7.3일 3시간22분

99% 1% 3.65일 1시간41분

99.8% 0.2% 17시간30분 20분10초

99.9% 0.1% 8시간45분 10분5초

99.99% 0.01% 52분30초 1분

99.999% 0.001% 5분25초 6초

비용

가용성100%98% 99%

여기서부터는뭔... 소린지 전혀 몰라야 지극히 정상임

91architect.mentor@gmail.com Service-oriented Architecture

잠깐!

가용성 달성 방안

어떻게 하면 가용성을 확보할 수 있을까?

좋은 방법이 있나?

• 방법이야... 많다.

Availability

Fault Detection

Fault

Recovery

Fault Prevention

Preparation &

Repair

Reintroduction

Ping & Echo

Heartbeat

Exception

Voting

Active Redundancy

Passive Redundancy

Spare

Shadow

State Resynchronization

Checkpoint/Rollback

Removal from Service

Transactions

Process Minitor

구성요소 A 구성요소 B

2. 제한시간 안에

응답을 보낸다. (echo)

1. 구성요소 B에게

신호를 보낸다. (ping)

구성요소 A 구성요소 B

1. 일정한 시간 간격을

두고 신호(heatbeat)를

내보낸다.

2. 구성요소 A의

신호를 받으면 A가

정상이라고 판단한다.

정상상태

구성요소 A 구성요소 B

1. 신호(heatbeat)를

내보내지 못한다.

2. 구성요소 A에

오류가 생긴 것으로

판단하고 오류 복구

작업을 시작한다.

오류상태

X

1. 호출

2. 처리

4. 예외 던짐

3.

오류발생

5. 예외처리

워메...갑자기 이게 뭣이여...

92architect.mentor@gmail.com Service-oriented Architecture

잠깐!

Availability

Fault Detection

Fault

Recovery

Fault Prevention

Preparation &

Repair

Reintroduction

Ping & Echo

Heartbeat

Exception

Voting

Active Redundancy

Passive Redundancy

Spare

Shadow

State Resynchronization

Checkpoint/Rollback

Removal from Service

Transactions

Process Minitor

Vo

ter1. 같은 입력을 서로

다른 프로세스들이

동시에 처리한다.

오류!

2. 각 프로세스는

입력을 처리한

결과를 Voter에게

투표한다.

3. Voter는 투표

결과로부터

오류를 감지한다.

프로세스 B

프로세스 C

프로세스 D

프로세스 A

구성요소 B

구성요소 A

구성요소 B1. 같은 입력을 똑같은

구성요소들이

처리한다.

구성요소 C

구성요소들을 오류가

생기지 않으면 항상

같은 상태를 유지한다.

1. 같은 입력을 똑같은

구성요소들이

처리한다.

만약 구성요소 B에서 오류가 발생해서 입력을

처리하지 못하더라도 항상 같이 동작하는 다른

구성요소들이 있기 때문에 장애가 발생하지

않는다.

X

정상 상태

오류 발생구성요소 A

구성요소 C

Active 구성요소

Standby 구성요소

1. Active 구성요소가

입력을 받는다.

2. Active 구성요소는

입력을 처리한다.3. Active 구성요소는

처리결과를 반환한다.

3. Active 구성요소는

Standby 구성요소에게

처리결과를 통보한다.

4. Standby 구성요소는 자신의 상태를

Active 구성요소와 일치시킨다.

Active 구성요소

Standby 구성요소

3. Standby 구성요소가

입력을 받아서

처리한다.

1. Active 구성요소에

오류가 발생한다.

4. Standby 구성요소는

처리결과를 반환한다.

2. Standby 구성요소는 상태를 복구하여

운영을 시작한다.

X

정상 상태

오류 발생

워메...2이건 또 뭐여...

93architect.mentor@gmail.com Service-oriented Architecture

잠깐!

Availability

Fault Detection

Fault

Recovery

Fault Prevention

Preparation &

Repair

Reintroduction

Ping & Echo

Heartbeat

Exception

Voting

Active Redundancy

Passive Redundancy

Spare

Shadow

State Resynchronization

Checkpoint/Rollback

Removal from Service

Transactions

Process Minitor

운영 구성요소

예비 프로세스

1. 운영구성요소는

입력을 받아 처리한다.

2.처리결과를 반환한다.

3. 최종 상태를 로그

파일이나 데이터베이스에

기록한다.

4. 일정한 간격으로 예비 구성요소와

운영 구성요소의 상태를 맞춰준다.

운영 구성요소

예비 구성요소

3. 예비 구성요소가

입력을 받아서

처리한다.

1. 운영 구성요소에

오류가 발생한다.

4. 결과를 반환한다.

2.예비 구성요소는

기록으로부터

상태를 복구하여

운영을 시작한다.X

정상 상태

오류 발생

정상 동작하는

구성요소

오류가 있어서

정정한 구성요소그림자 모드

1. 정정한 구성요소는 그림자

모드에 배치한다.

정상 동작하는

구성요소

오류가 있어서

정정한 구성요소

2. 정정한 구성요소는 정상

구성요소의 행동을 따라 하면서

제대로 정정되었는지 검증받는다.

정상 동작하는

구성요소

오류가 있어서

정정한 구성요소3. 검증이 끝난 구성요소는 그림자

모드에서 빠져 나온다.

시스템

시스템

2004/01/01

정기 체크포인트

2004/02/08

비정기 체크포인트

(OS 갱신)

일정한 시간 간격을 두거나

특별한 이벤트가 발생했을 때

정상 상태인 시스템의

체크포인트를 저장해 둔다.

2004/02/01

정기 체크포인트

만약, 갑자기 시스템이 비정상

상태가 되었고 그 원인이 OS

갱신 때문이라는 것이

밝혀졌다면 OS를 갱신하기 전에

마지막으로 저장해 놓은

체크포인트를 읽어서 그 상태로

롤백한다.

시스템

2004/02/01 상태로 롤백

여기서부터는욕이 나오는 것이 정상이다...

94architect.mentor@gmail.com Service-oriented Architecture

잠깐!

Availability Management?

거. 참... 어렵네...

문제는... 여기까지가 Availability의 단 1%였다면?

• 허걱...

하드웨어들에 대한 물리적인 고장 (그나마 소프트웨어는 닳아 없어지지는 않는다...)

• 애플리케이션 서버, 파일 서버, 프린트 서버, 메일 서버, ...

네트워크 문제들

데이터베이스 시스템의 문제

웹서버/웹애플리케이션 서버 고장

SCSI, 파이버 채널, 멀티 호스팅, 다중 경로, 디스크 어레이, JBOD, 핫/웜 플러깅 디스크, 핫 스페어, Write 개시, SAN, 레이드, LUN,...

다양한 플랫폼,...

가상화,…

이런데... 비용 고려하고, 조직(내부, 외부) 역할/책임 고려하고, 다른 쪽(보안, 성능, 유지보수성, ...)과 Trade-off 생각하고,

Risk/Issue 생각하고,... 게다가...

게다가… 계속 바뀐다...

제1 상책: 안한다... (이건... 안된다.)

제2 상책: 남에게 미룬다... (이건... 될 것 같다.)

• 그래서 Out-sourcing이 필요하고, Supplier Management가 필요하고, Service Level Management가 필요하고, Financial Management가 필요하고, Service Measurement가 필요하고,...

• 이게... ITSM의 본질이다. 남에게 미루는 것. 하지만, 원하는 바는 챙겨야 하는 것!

– + 보험(Insurance)까지!

– + 내부통제, ... (내부 통제의 본질은... 경영상황에 맞게... 조직에서 “Control”하는 것을 Management하는 것이다.)

요약하면

95architect.mentor@gmail.com Service-oriented Architecture

여기까지 보았는가?

IT 관련된 내용 뿐만 아니라, 어떤 것이라도, 그 내면의 세계에 집중하기 시작하면, 그 어려움은 갑자기 증폭된다. 내부적으로다른 것들과 연결되어있다는 것을 알기 시작하기 때문이다. 마치... 사전을 찾아보면, 그들 단어들이 모두 얽혀있다는 것을 알 수있듯이... 어렵다. 복잡하다. 제대로 된 출발은 이것을 인식하는 순간부터 가능하다.

SOA? 혼자 하면, 답이 없다. T-Network. 모든 사람이 T. 본인의 기술 분야를 깊게, 다른 사람과의 의사소통 영역은 넓게.

진짜 중요한 것은 기술보다 사람! 사람들간 네트워크이다. 문제를 이해하고, 요건에 맞는 올바른 결과를 만들어내는 것이 중요

하고, 실제의 일은 혼자서 할 수 있는 것보다 함께 할 때 더 좋은 결과를 만들어갈 수 있다. 돈? 영업? 장사? 이런 것들을 뛰어

넘어선, 협력체계, 의사소통 체계, 함께하는 문화가 가장 중요하다.

모든 기술을 알려고 애쓸 필요 없으며(불가능하다), 혼자 일을 다 하려고 애쓰지 마라. 그 것보다는 본인의 전문성을 확보하고, 협

력을 통한, 기술 인적 네트워크를 만드는 것이 더 중요하다. 그리고 더 큰 모습, 다양한 것들을 봐야한다. 그리고 문제, 고객에 더 집중하라. 비용, 시간, 자원 등이 고려된 "요구"에 맞게 만든 것이 올바른 해결이지, 상황과 직접 관련 없는 외국의 방

법론이나 해결을 빌려오거나 강요하는 것은 바람직하지 않다.

또한... 일에 대한 열정과 Fun & Professional이 필요하다.

그리고 하나 더 추가한다면 독특한 헤어 스타일… 정도^^ 즉, 여러분들의 개성도 중요하다.

모든 것이 엉망이 되었지만, 어려움이 존재하는 것을 알았다면, 다시 출발할 수 있다.

승부는 지금부터...^^

SOA... 오리무중... 끝...