[아키텍쳐] 보유하고 있는 책

Posted at 2010.09.06 08:52 // in Principle // by MOOVA 무바㏇
2010:09:05 22:38:26
2010:09:05 22:39:40

보유하고 있는 아키텍쳐 책이다.
이 중에서, 소프트웨어 아키텍쳐 이론과 실제는 독학 후 교육을 받은 예외 케이스이다.
처음엔 이 영역에 대해서 이해도가 낮아서 고생을 했는데, 그 후 주기적인 관심을 둔 탓인지 아키텍처 영역도 중복되는 부분이 많다는 것을 깨닫는다. 아직 멀고도 험난한 이 길 선상에서 그래도 잠시나마 위안을 주는 그런 종류의 책이다.

소프트웨어아키텍처이론과실제
카테고리 컴퓨터/IT > 컴퓨터공학 > 소프트웨어공학
지은이 렌 베스 (에이콘출판, 2007년)
상세보기
제9회 JOLT상 수상작

실무 사례를 통해 익히는 소프트웨어 아키텍처 지침서. 이 책은 소프트웨어 아키텍처의 개념 설명에서부터 저자들의 실무 경험을 통한 소프트웨어 시스템의 설계, 명세, 확인 작업의 핵심 기술들을 소개한다.

또한 실무에서의 아키텍처 사례 연구를 통해 소프트웨어 시스템을 설계하는 방법과 시스템 구성요소들의 상호작용과 역할, 실제 환경에서 구현할 수 있는 법에 이르기까지의 내용을 제시한다.

<소프트웨어 아키텍처>는 아키텍처 개요와 수립, 아키텍처 분석과 확산으로 구성했다.

☞ Jolt 상 - 해마다 가장 뛰어난 소프트웨어 개발 서적을 선정하는 Software Development 잡지의 상




소프트웨어아키텍처2.0성공하는솔루션을위한비즈니스와아키텍처의만
카테고리 컴퓨터/IT > 컴퓨터공학 > 소프트웨어공학
지은이 루크 호만 (에이콘출판, 2009년)
상세보기
성공하는 솔루션을 위한 비즈니스와 아키텍쳐의 만남

『소프트웨어 아키텍처 2.0』는 현실에서 성공할 수 있는 아키텍처와 마케팅 정보를 어떻게 통합해야 하는지, 기술과 비즈니스 관점에서 날카롭게 지적하고 상세히 설명한다. 소프트웨어 전문가인 저자는 아키텍처에 관한 결정을 내릴 수 있도록 중요한 방향을 일러준다. 이 책은 실제로 도움이 되는 가이드라인을 제공한다.


데이터아키텍처전문가가이드(2010)
카테고리 컴퓨터/IT > 컴퓨터공학 > 데이타통신
지은이 편집부 (한국데이터베이스진흥원, 2010년)
상세보기

 

데이터아키텍처 전문자격(DAP, Data Architecture Professional) 대비 수험서. 이 책에서는 산업 현장에서 데이터 아키텍처 전문가에게 요구되는 세부 업무와 자격 검정안내 등에 대하여 상세히 설명하고 있다. 효과적인 데이터베이스 구축을 위한 전사 아키텍처를 비롯 데이터 품질 관리, 데이터 요건 분석, 데이터 표준화, 데이터 모델링, 데이터베이스 설계와 이용 등의 실무 가이드로 구성됐다.

전 세계가 놀랄만한 IT 역사를 창조한 IT강국 우리 대한민국은 짧은 시기에 정보시스템 구축과 확산의 시대를 넘어서 이제 정보서비스품질(Information Service Quality)에 대한 관심과 평가가 요구되고 있으며 정보품질을 위한 투자와 노력을 필요로 하고 있다. 정보서비스품질 고도화를 위한 핵심 요소는 바로 정보의 원천이 되는 데이터 분야이며 이를 위한 데이터아키텍처 전문가 육성이 절실한 시점에 본 자격검정의 탄생을 기쁘게 생각하며 본 검정이 데이터 강국 코리아 건설을 위한 서막의 디딤돌이 되어 우수한 데이터 전문가가 배출되기를 간절히 바란다.
조광원│비투엔컨설팅 대표이사

정보화가 어느 정도 이루어진 기업의 경우 매일 엄청난 규모의 데이터가 쌓이고 있고 연간 수십억원의 비용이 지출되고 있지만 정작 데이터의 활용은 만족스럽지 못한 것이 현실이다. 이는 진주를 돼지우리에 버려두고 있는 것과 마찬가지라고 할 수 있다. 좋은 데이터를 확보하여 바른 의사결정으로 연결시키기 위해서는 데이터확보, 축적, 흐름, 활용 등을 체계적으로 관리해야 한다. 본 자격검정은 "데이터에 의한 경영"의 세계로 가는 좋은 나침반이 될 것이다.
김인현│투이컨설팅 대표이사

데이터는 시스템의 골격이다. 데이터가 바로 서지 않고서는 시스템이 결코 온전할 수 없다. 그럼에도 불구하고 데이터의 진정한 전문가는 찾아보기 어려운 것이 작금의 현실이다. 거의 모든 개발요원들이 애플리케이션만 중시하고 데이터는 프로세싱을 위해 잠시 보관해 두는 창고쯤으로 여기고 있다. 이러한 접근방법은 시스템을 복잡하게 하고 유지보수에 너무 많은 자원을 투입하게 만들었다. 늦은 감이 없진 않지만 이제라도 데이터를 바로 세울 수 있는 전문가들을 양성할 수 있는 자격검정이 탄생된 것을 정말 다행으로 생각한다. 자격검정은 이제 진정한 데이터 전문가를 육성하는 횃불이 될 것이라 믿어 의심치 않는다.
이화식│엔코아컨설팅 대표이사



뷰티풀아키텍처19인의아키텍트가들려주는아름다운이야기
카테고리 컴퓨터/IT > 컴퓨터공학 > 소프트웨어공학
지은이 디오미디스 스피넬리스 (지앤선, 2010년)
상세보기

소프트웨어 설계에 숨어져있는 아름다움을 살펴보는 아키텍처 이야기!

소프트웨어 설계와 아키텍처를 이끌고 있는 19인의 아키텍트가 들려주는 아름다운 이야기 『뷰티풀 아키텍처』. 소프트웨어 회사에서 아키텍처를 결정하는 아키텍트의 역할은 매우 중요하다. 이 책은 우리 주변에서 건축물을 보듯이 다른 훌륭한 아키텍트가 만든 아키텍처가 어떤 모습인지 살펴 볼 수 있게 하였다. 일류 소프트웨어 디자이너들과 아키텍트들이 선호하는 소프트웨어 아키텍처에 대해 기술하고, 개발 뒤에 숨은 이야기를 총 5가지 테마 영역으로 풀어내고 있다.


 

저작자 표시 비영리 변경 금지
신고
크리에이티브 커먼즈 라이선스
Creative Commons License
블로그코리아에 블UP하기

댓글을 남겨주세요.

[Workflow] 왜 이제와서 BPM인가?

Posted at 2010.08.30 09:02 // in Bender // by MOOVA 무바㏇
인원들이 정리 안 된 어떤 한 프로젝트에서 한 부서의 일을 본의아니게 몽땅 떠 넘겨받아서 처리했을 때의 일이다.
 이 업무는 해당 시스템의 청사진으로 모든 업무와 연계된 모듈이 예상되었다. 해당 정직(을)과 담당자들은 이미 이 업무를 맡기 싫어, 책임을 회피하고 요리조리 빠져나가려는 궁리만 하고 앉아 있었다. 해당 PM도 본인 회사의 시스템 담당자들에 대한 회의가 들어서인지 전적으로 프리랜서들에게만 의지를 하고 있던 상황이었다. 

인계받을 모듈의 규모도 작은 규모가 아니어서 싸인을 하는데만 여러 기업의 입심이 참 대단했었다. 보통 이런 상황에서 기업과 기업의 입장차이때문에 싸인을 마지못해 하는 경우가 많은데, 본인은 그런 상황에서 공식적으로 제대로 일을 한번 해 볼 수 있다는 기쁨 때문에 흥쾌히 그 종이에 싸인을 했다. (정말 돌이킬 수 없엇던 실수를 한 것이다.!)
- 아마 이 싸인으로 중간업체는 많은 돈을 챙겼다고 알고 있다. 본인에게는 콩고물 하나 돌아오는게 없었다.

2010:08:30 08:43:36

"전체적인 그림만 완성하면 난 만족할 뿐..."


이 때 맡아서 진행하려했던 모듈을 살펴보니, 코드와 프로세스는 전혀 정립되어 있지 못한 상황이었다. 이 모듈을 모두가 회피했었던 이유를 난 바보같이 늦게나마 깨달은것이다.
개발자들은 개발자 나름대로의 신공을 부려 각 기능을 제대로 개발했을지 모르겠지만, 큰 그림을 돌봐주는 사람이 없어 각 모듈을 조립했을 때 나왔던 큰 그림은 마치 중요한 부분들이 빠진 찢어진 지도와도 같았다. 현 시점에서 가장 중요한것은 이렇게 흩어져 있고 정리 안 된 것들을 "어떻게 보기좋게 정리를 해고 진행해야 하는가?"에 대한 고민이었다. 이 프로젝트를 실천하기 전 솔루션 엔지이너로 활동한 탓인지 프로세스 정비를 하는것이 유일한 첫째 대안이었다.
아무리 복잡한 업무라도 프로세스만 제대로 정립을 해 준다면, 나머지 구차한 작업들은 모두 한결같이 진행되리라!

해당 프로젝트에선 공식적으로 BPMS를 도입하고 있었지만 해당 업체의 컨설턴트들을 좀처럼 만나볼 수 없었다. 아마도 프로젝트 초반 시안만 작성해주고 떠났다고 본다. BPMS를 쓰지 못한다고 해서 아쉬워할껀 없었고 개인적으로 프로세스 정립하는 툴을 이용해서 5일동안 해당 업무의 프로세스를 정리하고자 했다. 시간도 너무 촉박했고 옆에서 닦달하는 PM은 항상 언제 끝나냐는 강압적인 압박만 지속한 상태다. 자신들이 직원들이 미적지근하게 처리 못 한 것들을 이제와서 정리를 해 주겠다는데 일정만 그렇게 외쳐대니 참으로 안타깝기 그지없었다.
이미 엎지러진 물이니 개인적인 시간을 내어서라도 전체적인 데이터가 흘러갈 수 있는 그림만 완성한다면 난 만족할 뿐이었다.

"개발자도 비즈니스 프로세스를 알아야한다"

그렇다면 프로세스의 정립이 첫 우선순위가 된 이유는 무엇인가?

일반적으로 프로세스라는 것을 생소하게 여기는 개발자가 많다. (TDD나 짝프로그램은 다른 범주이다. 개발자들에게 하려는 목표와 방향을 제시해주고, 실제로 그들이 해야 할 일에 대해서 정립을 했을 때 TDD나 짝 프로그래밍도 가능한 일일것이다. TDD와 BP는 범주가 달라서 따로 설명하지 않겠지만 둘 다 중요한 원리와 사상이 있다.)

프로세스란 결과를 발생시키기 위해 어떤 이벤트에 반응하는 한정된 활동들의 집합이다. 프로세스는 아주 단순한 것에서부터 복잡한 것에 이르기까지 다양하지만, 일반적으로 가치 사슬(value chain)이 가장 상위의 프로세스로 한정짓고 있다. 가치 사슬은 여러개의 비즈니스 프로세스로 구성되어 있고 비즈니스 프로세스는 또 각각의 프로세스로 분류된다. 프로세스는 서브 프로세스를 여러 레벨에 걸쳐 하위에 지니고 있을 때도 많다. 반대로 개별의 프로세스를 정립하면 상위의 프로세스로 그룹핑하고, 더 나아가서 최종적으로 가치 사슬을 나타내는 그룹으로 표현될 수 있다. 이때 주의해야할 것은, 상위 개념의 프로세스가 잘못 재정되면 가치 사슬로 묶여 있는 서브 프로세스들은 한꺼번에 무너지기 쉽상이다.

2010:08:29 19:03:52
가치 사슬

아쉽게도 주먹구구식의 프로젝트에선 위와 같이 비즈니스 프로세스의 정립을 할 시간 조차 없을 때가 많다. 만약 운이좋아 문서에 전체적인 윤곽을 그려낼 수 있으면 그나마 다행이다. 하지만, 항상 시간이 없고 일정은 촉박하다. 이런 일들은 BPMS벤더회사의 컨설턴트들이 해 주어야 하는데 그들은 개발자들이 구현할 때 즈음되면 다들 사라지고 없다. 또한 개발자들은 정리 안 된 거미줄위에 항상 반복되는 코드를 그려댈 뿐이다. 부서전체의 업무가 막장으로 가기전에 어서 빨리 프로세스를 재정립해야만 한다.!
 
"BP를 위한 좋은 도구"

이런 상황에서 도입할 수 있는 것 중에 하나는 간단한 WorkFlow시스템이나 프로세스를 그려줄 수 있는 간단한 도구를 사용하는 일이다. 적절한 BP도구를 사용하면 문서도 알아서 작성해주며, 최종적으로는 코드까지 산출해 준다. (물론 나머지는 개발자의 몫이다.) 필자가 주로 애용하는 BP도구는 Visual Paradigm이나 IBM의 RSA, 또는 Windchill의 Workflow엔진등이다. 물론 이것들은 비싼 라이센스를 지불해야 하기 때문에 정 여력이 없을 때는 OSWorkFlow같은 오픈소스를 사용할때도 있다. (벤더나 엔진은 다르더라도 BPML이라는 표기법은 모든 Workflow엔진에 비슷하게 사용된다. 필자가 항상 강조하는 원리와 기초가 중요하다고 하는 게 바로 이런 부분들 때문이다. 원리와 사상을 알면 어떤 도구나 언어를 사용하더라도 문제될게 없다.)

2010:08:29 19:17:27
OSworkflow의 프로세스 편집기

이 도구들은 복잡한 프로세스를 그림으로 표현할 수 있다는 장점이 있고, 또한 호환 가능한 규격이 이미 표준으로 정해져(BPML,BPEL)[각주:1]있다는데 매리트를 더할 수 있다. 위에 그림은 UML의 액티비티다이어그램과 매우 흡사하다는 것을 느낀다. 프로세스 모델링 표기법중에 UML의 액티비티다이어그램은 얼마전까지 BP의 범주에 포함되었다, 하지만 사실상 지금은 BPMN이 표준으로 자리매김하고 있다.

이렇게 작성된 BPML들은 프로세스 실행엔진에 의해 실행된다.
1. 정확하게 말하면 배포하기 전에 시뮬레이션을 돌려 먼저 비즈니스 프로세스의 오류 유무를 판별하는 작업이 이에 속한다(액티비티와 액터를 포함한 인증과정).
2. 프로세스 실행엔진은 프로세스 인스턴스를 실행하고 시작 이벤트에 의해 인스턴스가 흘러, 종료하면 인스턴스가 소멸된다.
3. 이러한 인스턴스들이 각각의 조건(BRM/BRMS)에 의해 제어당하고 다시 반복자와 접근자를 통해서 다른 비즈니스 프로세스를 호출할 수도 있다.

2010:08:29 19:31:44
windchill의 워크플로우 엔진

예를들어 전문적인 워크플로우엔진을 보유하고 있는 Windchill을 살펴보자. Windchill의 workflow메니저는 이러한 복잡함을 단순한 그림으로 표현하는데 성공을 한 케이스이다. 물론 도메인 특화에 맞게 결재시스템으로 활용하는게 대부분이지만, 실제로 workflow와 BPM은 그 적용범위가 상당해서 결재시스템 이외에도 다양한 비즈니스에 활용될 수 있다.

2010:08:29 19:50:24
BPMN의 일반적인 그림

"BPM을 도입하는데 가장 큰 이점"

BPM을 도입하는데 가장 큰 이점은 민첩성(agility), 가시성(visibility),유연성(flexibility),효율성(dfficiency)이다.

민첩성 : 끊없이 변화하는 고객의 요구사항에 민첩하게 대응하며, 플러그인함으로써 애자일스러워 질 수 있다.

가시성 : 업무담당자들에게 현재 진행되고 있는 인스턴스를 모니터링함으로써 데이터를 단일화하고 다양한 뷰를 시각적으로 이해시킬 수 있다.

유연성 : 복잡한 비즈니스 사항에서 예외적이고 변화적인 처리에 대한 즉각적이고 효율적인 대응력을 가질 수 있다.

효율성 : 워크플로우 자동화로 인한 비즈니스 프로세스의 처리 속도가 향상되고, 경고 및 알림 등의 이벤트에 의해 에러 감소와 관리 업무의 부담을 줄여준다.


"컨설턴트의 기본적인 소양. 비즈니스 프로세스"

개발자에서 컨설턴트로 나아가고자 하는 이들에게 비즈니스 프로세스에 대한 원리와 이해는 필수적이다. 프로젝트가 산으로 가고 있는가? 아무도 전체적인 그림을 잡아주지 않는가? 시간이 없어 단순하게 Copy&Paste만 기다리고 있는가?
구현을 수 없이 해 봤던 어떤 개발자는 이런 BP엔진을 사용한 후, 너무나 편리한 그 사용감 때문에 아예 로직을 짤 때도 별로의 Workflow엔진을 돌리는 취미도 새로 생겼다고 한다.
다양한 Workflow엔진을 습득한 후 비즈니스 프로세스의 원리를 파악해보자. 구현에 대한 사상에서 넓은 의미의 설계영역과 큰 그림을 볼 수 있는 눈이 생기리라 확신한다.

 BPM은 개발의 사고방식을 넘어서 컨설턴트나 아키텍트로 지향하고자 하는 이들에게 권유하고 싶은 종목이다.



참고서적 :
Windchill Workflow tutorial,
Workflow Management models,methods and Systems,
OsWorkflow packt
2010:08:29 20:18:57

  1. 비즈니스 프로세스를 모델링할 때 주로 BPMN이란 표기법을 사용한다. BPMN은 OMG가 주도하는 표준 비즈니스 프로세스 모델링 기법이다. [본문으로]
저작자 표시 비영리 변경 금지
신고
크리에이티브 커먼즈 라이선스
Creative Commons License
블로그코리아에 블UP하기
  1. Favicon of http://moonlgt2.tistory.com BlogIcon 소박한 독서가

    2010.08.30 16:04 신고 [수정/삭제] [답글]

    전문적인 글이네요~ㅎ
    반 쯤만 읽었습니다.
    좋은 하루 되세요~~^^

  2. Favicon of http://ggons.tistory.com BlogIcon 꼰스

    2011.12.28 16:36 [수정/삭제] [답글]

    관리자의 승인을 기다리고 있는 댓글입니다

댓글을 남겨주세요.

애플리케이션 아키텍트 - 그의 한계

Posted at 2010.08.19 15:12 // in Principle // by MOOVA 무바㏇
한 프로젝트에서 조직의 포멧과 비즈니스 프로세스를 개정했을 때의 일이다.(Solution Engineer)
해당 프로젝트에서 AA가 작업한 결과물과 문서, 그리고 활동한 이력에 대해서 한번 살펴보았다. 그 문서는 말 그대로 공통된 템플릿 위주의 스타일로 구조를 설계해 놓았다. 보통 설익은 AA가 잘하는 것 중에 하나는 교육기관에서 정리해준 정석 스타일의 시스템 구조를 특수한 프로젝트에서도 그대로 사용하는 행위이다. 범용적인 교육을 이제 막 받은 아키텍트가 그것을 그대로 따라하는 것은 좋은데, 너무 범용적인 교육에만 의존하여 그것이 전부인 것처럼 생각하는 이들이 많아서 본 글을 시작하겠다. 


교육기관의 범용적인 지식을 넘어서.


보통 AA가 하는 롤중에 하나는 시스템 특징에 적합한 설계와 구현의 지침인 아키텍쳐를 작성하고, 이것을 개발팀 전원이 파악할 수 있도록 하는 것이다. AA가 하는 프레임웍 설계와 관련해서 예외관리, 메시지관리, 트랜젠션 관리, 로깅전략, 레거시 시스템과의 연계등은 한때 교육기관에서 한창 신나게 교육을 하고 있었고 아직도 많은 프레임웍 설계자들이 이 규칙을 따라서 프로젝트를 수행하고 있다. 이렇게 교육기관에서 행한 범용적인 지식은 모든 시스템에서 공통되게 사용할 수 있다는 이점이 있고, 규격에 따라 정의해 놓은 스타일로 그 템플릿에 맞게 프로젝트를 운용할 수 있다. 하지만, 이것은 어디까지나 범용적인 일이다. AA는 위와 같이 공통된 애플리케이션 전략을 세우는 것에 덧붙여 프로젝트 특유의 포멧과 가치 사슬을 포함하면서 공통된 구조(Common Spot)[각주:1]를 확장한 핫 스팟(Hot Spot)[각주:2]을 식별할 줄 알아야 한다.


애플리케이션 프레임워크의 영역.


애플리케이션은 크게 애플리케이션 레이어와 프레임워크 레이어로 구분된다.
프레임워크 레이어는 다시 애플리케이션 프레임워크 레이어와 시스템 프레임워크 레이어로 구분된다. 
시스템 프레임워크 레이어는 .net과 java같은 파운데이션 영역의 프레임워크 이고, 애플리케이션 프레임워크는 도메인 프레임워크와 범용 프레임워크 레이어로 다시 분할된다. (그림 1)

2010:08:19 14:19:46
그림 1. 범용 프레임워크와 도메인 프레임워크

바로 여기에서 교육기관에서 가르치는 것은 범용의 영역이란 것을 확인할 수 있다. (교육기관의 이론적 교육은 상당히 범용적인 것이어서 우리는 다시한번 실무에서 활용하고자 하는 응용력을 키워야 한다. 응용력은 교육기관에서 가르쳐주는 것이 아니다.)

범용 프레임워크는 비즈니스 도메인 지식을 포함하지 않는다. 따라서 범용 프레임워크는 비즈니스 도메인에 관계없이 대부분의 애플리케이션에서 공통으로 발견될 수 있는 컴포넌트와 서비스로 구성된다. 범용 프레임워크의 예로는 Struts,Spring Framework, Spring.NET,Seams,WebWork등이 이에 속하고, 동시에 범용적인 오픈소스들로  활용하고 있는 영역이다. 하지만 그것은 어디까지나 범용 프레임워크 레이어에 국한돼서이다.

도메인 프레임워크는 특정한 비즈니스 도메인을 대상으로 하는 프레임워크 컴포넌트로 구성되며, 특정한 비즈니스 도메인의 모든 애플리케이션에 공통된 비즈니스 지식을 구현한다. 프레임워크의 개발은 대상 애플리케이션에서 공통성과 가변성을 분석하는 것에서부터 시작한다. 공통성이 나타나는 위치를 공통 스팟(common spot)이라고 하고 가변적인 위치를 핫스팟(Hot spot)이라고 한다. 핫 스팟은 애플리케이션마다 가변적이어서 프레임워크를 커스터마이징 할 수 있는 위치이다. 이것이 바로 도메인 프레임워크 레이어를 확장할 수 있는 지점이다. 


애플리케이션 아키텍트는 프레임웍만 잡는 사람이 아닌.


그림2는 범용프레임워크가 도메인(특화된) 프레임워크로 점점 발전하는 개발 과정을 나타낸 그림이다.
2010:08:19 13:37:35
그림2, 도메인 프레임워크 레이어로의 발전

설명하자면, 범용 프레임워크로 구축된 시스템1에서 복사해서 붙여 넣기한 시스템2로 진화된다. 시스템2에서 나타난 문제점들을 개선하고 점차 도메인성격에 맞는 프레임워크로 진화된다. 시스템3과 시스템4는 초반에 범용적인 프레임워크에서 시작한 문제점을 제거하고 조직특화된(도메인특화된) 도메인 프레임워크로 점차 진화된다.

따라서 실력 있는 AA가 되고자 하려면 교육기관에서 지정한 행위이상으로 자신에 조직에 맞는 지식을 기반으로 가변성과 공통성을 식별하는 응용력이 아주 중요하다. (실제로 필자와 같은 솔루션 컨설턴트는 AA와 함께 더불어서 이러한 도메인 영역의 특수한 틀을 지속적으로 발전시켜주는 역할을 하기도 했다.)

2010:08:19 14:31:17
그림3. 아키텍트는 범용적인것을 넘어서 도메인(특화된) 영역을 볼 수 있는 자질이 필요하다.

AA는 범용적인 지식과 도메인 지식을 잘 융화시켜야.


조직A,조직B,조직C에서 사용된 프레임워크에서 공통된 레이어를 추출해서 범용적인 패턴으로 만드는 것은 매우 쉬운 일이다.
하지만 공통된 패턴을 넘어서 조직에 맞는 포멧과 가치사슬에 따른 프로세스, 또한 도메인 특화된 프레임워크를 지속적으로 키우는 노력은 오랜 기간이 필요하며 숙성된 경험이 바탕이 되어야 한다.

필자는 초보강사나 설익은 2년 미만된 아키텍트들이 단 한번의 교육을 받고 ( - 로깅전략,트랜젝션전략, 메시지전력등 공통된 전략들에 대해서 왈가 왈부하면서 ) 대형 프로젝트를 수행하는 것을 보고 상당히 의아해하곤 한다. AA가 하는 영역은 그게 전부가 아닌데 그것이 전부인 것처럼 포장하는 행위를 보고 매우 실망한 적도 있었다. 물론 모든 아키텍트들이 도메인에 특화된 영역에 대한 중요성을 모르는 것은 아니지만, 롤만 차지하고 앉아 있는 설익은 AA를 보면 좀 더 노력하라는 말을 전하고 싶다.

우리가 범용적인 교육을 받고 프로젝트를 진행하거나 컨설팅 역할을 단기간에 할 수는 있겠지만 범용적인 교육은 언제까지나 범용적일 수밖에 없다. 우리가 하고자 하는 것은 결국 소프트웨어 공학이며 소프트웨어 공학은 경험과 지속적인 피드백을 통해 발전시켜야만 하는 영역이다. 그리고 그들은 범용적인 것과 함께 또는 그것을 넘어서 수년간 개선된 도메인 프레임워크를 구축할 때 진정한 애플리케이션 아키텍트라고 할 수 있지 않을까 생각해 본다.

참고

1. 공통 라이브러리와 프레임워크는 다른 개념이다. 공통 라이브러리란 애플리케이션에서 공통적으로 사용할 수 있는 함수들의 집합이다. 그러나 프레임워크으 경우에 제어 흐름의 주도권은 프레임워크에 있다. 다시 말해, 프레임워크에서 애플리케이션 코드로 제어 흐름이 이동된다. 이것을 제어의 역흐름(inversion of control)이라고 한다.

2. 시스템 컨설턴트, 솔루션 엔지니어들은 범용적인 교육으로부터 흘러나온 지식을 전달해 주는 사람이 아니다. 수년간 숙성된 연구를 바탕으로 범용 프레임워크 이상의 도메인에 특화된 지식과 경험을 물려주는 행위를 하는 사람이다.

3. 프레임워크를 구지 분류해보고자 한다면, 스프링 프레임워크는 범용적인 프레임워크에 가깝고,(SOA What & How에서), Windchill은 도메인 프레임워크 영역이다. 또한 LafJ나 가우스,AnyFramework,WiseGrid등은 도메인프레임워크에 가깝다. 그리고 Struts나 Strtus2와 같은 경우 범용 프레임워크에서 도메인 프레임워크로 개선시켜줄 공통 패턴들을 많이 준비해 놓고있다. 만약 웹 영역에서 프로젝트 기간이 짧고 단기간에 도메인 프레임워크로 발전하고자 한다면 필자는 오픈소스인 Struts2를 선택할 것이다. 하지만 장기간에 걸쳐 도메인 프레임워크를 발전시키고자 한다면 필자는 여전히 Windchill이나 스프링프레임워크를 선택할 것이다.
 여기서 중요한 것은 이와 같은 기술의 선택은 매우 중요하지만 더욱 더 중요한 것은 지식과 경험을 지속적으로 발전시켜 조직에 맞는 특화된 도메인 프레임워크로 발전시키는 노력이다.



참고 서적 :
SOAWHAT&HOW:AROADTOSOA
카테고리 컴퓨터/IT > 웹사이트 > 웹서비스
지은이 전병선 (와우북스, 2008년)
상세보기
SOA(서비스지향아키텍처)
카테고리 컴퓨터/IT > 웹사이트 > 웹서비스
지은이 토마스 얼 (에이콘출판, 2006년)
상세보기

소프트웨어공학(제8판)
카테고리 컴퓨터/IT > 컴퓨터공학 > 소프트웨어공학
지은이 LAN SOMMERVILLE (홍릉과학출판사, 2008년)
상세보기

시스템분석과요구공학
카테고리 컴퓨터/IT > 컴퓨터공학 > 시스템분석/프로그래밍
지은이 류성열 (한티미디어, 2009년)
상세보기

프로젝트관리의해법
카테고리 경제/경영 > 경영전략 > R&D경영/CFO
지은이 J 데이빗슨 프레임 (한언, 2007년)
상세보기

THEARTOFPROJECTMANAGEMENT마음을움직이는프로젝트관리
카테고리 컴퓨터/IT > OA/사무자동화 > 오피스 > 프로젝트관리
지은이 스콧 버쿤 (한빛미디어, 2006년)
상세보기


  1. 공통성(commonality)에서부터 나온 지점 [본문으로]
  2. 가변성(variability)으로부터 나온 지점 혹은 인터페이스 [본문으로]
저작자 표시 비영리 변경 금지
신고
크리에이티브 커먼즈 라이선스
Creative Commons License
블로그코리아에 블UP하기

댓글을 남겨주세요.

티스토리 툴바