EA와 ISP를 통해 아키텍처를 고민한다면 개발부분까지도 고려해야 한다.
근 1년간 프로젝트를 하면서 항상 고민하는 부분이다.
플레닝 단계에서 레벨을 낮게 잡은 부분에 대해 개발업체는 항상 고민을 할 수 밖에 없다.
때문에 컨설팅을 하고 나면 개발업체/개발팀등등....는 무얼 해야 하는지 모르는 경우 태반....
그러다 보면 EA한 결과를 받아 들이고 싶지 않기에 또다른 플레닝을 하는 그런 모습들이 보인다.

이 갭을 채우려면 EA 컨설턴트는 낮은 단계까지 플레닝을 해야 하며 개발영역과 컨설팅 영역을 채우워야 하는 필요성이 생긴다. 그런데 상위레벨의 아키텍처와 구현레벨의 아키텍처의 갭을 메우기란 쉽지 않다.
EA는 Owner단계와 Planner단계에 집중을 하는 경우가 많고 Designer단계로 내려오면 설계부분에 대한 압박이 있기 때문이다. 디자인 단계까지 내려간다 하더라도 구현의 레벨로 들어서면 또 갭이 생긴다. 그러다 보면 의사결정을 위한 도구라는 냄새는 점점 사라지게 되는 것이다....이러한 이유로 EA는 실체가 없다는 말을 하는 사람들도 있었다.
그렇지만 상위단계의 플레닝이나 구도를 잡아주는 모습을 보여주는 역활로 본다면 아주 중요한 작업이지 않을 수 없다.

비지니스와 기술을 연결해주는게 아키텍트라면 이러한 단계를 연결해줘야 하는 사람은 누구인가? 아무도 없다???? T.T 결국은 아키텍트나 아키텍트 그룹이 이갭을 채워줘야 하는데
지금 내가 이 갭을 채우는 작업을 하고 있다. 서로 안하려고 발버둥 치는 경우도 있었다.

EA를 알아야 하며 이것을 분석하고 이것을 구현레벨까지 끌어내리는것이 나의 회사에서의 존재 목적인 것이다....
일을 하다 보면 상위레벨과 구현레벨의 차가 작지 않아 이러한 영역을 채우려면 많은 것을 알아야 한다. .....기술 , 디자인 말고도 알아야 할게 태반이다. 더군다나 아키텍트라면 코드레벨까지 알아야 한다. 이러한 경우라면 더더욱..... 뿐만아니라 EA의 상위레벨도 알아야 한다.
코딩을 직접 하지는 않더라도 상위레벨과 하위레벨을 연결하고 그들의 뷰로 설명을 할수 있는 문서와...언어등이 필요한것이다. 그냥 박스나 몇개 그리고 말꺼라면 또다시 그자리인것이다... 안하느니 못한 아키텍처정립인 것이다. 쯪....

게다가 상위레벨의 개념적인 생각들이 개발 영역으로 들어오면서 퇴색하는 경우도 있고 변경되는 경우도 있고..... 아키텍처에 대한 통합 관리가 필요한데 이러한것을 개발조직들은(현업은 다르다고 할수 있겠지만 전문지식성이 없기에 별 이견없음 ) 더군다나 알고 싶지 않아 한다. 이러한 것은 기업의 자산이 되는 경우가 많지만.... 별로 중요시 여기지 않는 경우가 태반.....

조직의 리더들이 생각하는 바가 많이 달라지는 경우도 있고....
심지어는 그들이 변절 ( ? ) 하는 경우도 있다. 그들의 생각이 서로 상충하여 조직에 분열이 생기는 경우도 있다.
어떻게 보면 기술때문에 생기는 문제도 문제이지만 사람때문에 생기는 문제가 더 많은 듯하기도 하고..... 거버넌스라는 말을 해야 하는 경우도 생기는 것이다.....

이러한 것이 내가 가지고 가야할 숙제... 인지도 모르지.... 음냐...뭐해먹고 살지 ??
 

토요일 아침엔 커피를 마신다. 종로에서 마신다.
토요일 아침의 커피향이 너무나 좋다. 그런데 나는...커피를 못마신다. 속이 매우 아픔..

내 블로그를 보시는 분중에 나와 함께 커피를 마시고 싶으신 분은 아침 일찍 종로로 오면 됨다...... 아마 웨이크업하기 힘드실 것입니다....

물론 나는 커피를 못마시기에 보통 석류주스나 혹은 다른 음료를 마신다. 주로 단호박 센드위치를 토요일 아침밥으로 먹는데 자꾸 먹으니까..좀 지겹기도 하고....ㅋ

오늘까지 OOAD를 본 진도는 100Page다. 다시 한번 느끼는 건데 가장중요한건 고객의 요구사항.... 이게 결론...T.T

ModelAndView()           Default constructor for bean-style usage: populating bean properties instead of passing in constructor arguments.

ModelAndView(String viewName)           Convenient constructor when there is no model data to expose.

ModelAndView(String viewName, Map model)           Creates new ModelAndView given a view name and a model.

ModelAndView(String viewName, String modelName, Object modelObject)           Convenient constructor to take a single model object.

ModelAndView(View view)           Convenient constructor when there is no model data to expose.

ModelAndView(View view, Map model)           Creates new ModelAndView given a View object and a model.

ModelAndView(View view, String modelName, Object modelObject)           Convenient constructor to take a single model object.

이건 조금더 복잡한 건데 저 모델이라는 놈이 가만히 보면 Object이다. 그런데 로드존슨은 왜 이놈의 이름을 ModelAndView라고 지었을까....?? 저 오브젝트에 이런 저런 클라스들이 다 들어가겠지...오라클의 탑링크...IBatis 등등등....

스프링에서 생각하는 모델을 스프링에서는 어떻게 정리 했을까...라는 생각이다. DTO, VO, Entity라 불리우는 객체들을 저 모델의 값으로 넘겨주는 경우에 대한 생각이다. 아는 사람은 알다 시피 하이버네이트 세션을 대략 이용하면 화면에서 비지니스를 처리 하는 겪이 된다. 이러한 가정은 DTD나 VO를 EJB에서 처럼 사용하지 않았다는 가정하에 가능하겠다. 뭐 내 생각이지만......
언젠가 하이버네이트를 보다가.... 이상한 오픈소스 프레임웍을 봤는데 테그라이브러리로 Hibernate를 제어하는 것이다. 결론적으로 보면 화면에서 바로 써버리겠다는 말인데....
그때는 이런 황당한걸 왜 만들지 하는 생각이 많이 들었다.  어이 없었다...그때가 2004 초던가 였는데...다분히 내 머리속엔 EJB적인 생각 ㅋㅋㅋ ( 반성중 ) EJB는 그렇게 코딩 안하기에 그렇다. 그러니까 문제....
왜냐면 Lookup때문에 많은 자원이 소비 되어 몇몇 프락시성 클라스를 넣어줘야 하기 때문이다. 만일 EJB가 아니었다면 나는 Struts나 다른 프레임웍을 안배우고 오히려 View관련 Framework에 관심을 기울였을것 같다.

이렇게 이야기 하면 결론적으로 c/s의 아키텍처가 되는데 c/s의 db연동과 다른게 없다라는 생각이 또 들었다. ....하여간 쓰잘떼깅 없기능ㅋㅋㅋ
그러나 Layer구조로 된 도메인 모델이라면 그리 염려는 안해도 될듯 하기도 하고...
Layer를 횡단하는 구조는 아직도 의문이다. 그런데 어쩌는 수 없이 횡당하는 경우가 생긴다는 것은 인정한다. 억지로 Layer 구조를 갖추기 위해 몇몇 아키텍처적인 더미 클라스를 넣는  패턴을 쓰기도 하지만.... T.T

토요일날 아침부터 쓰잘때기 없는 생각하고 있음....
도메인 모델링을 하게 되면 어쩌면 고질적인 DTD나 VO가 없어질지도 모르겠다는 생각이 조금들었다. 물론 없어지기는 힘들지도 모르겠다. 트렌젝션이나 세션문제가 그리 간단하지 않을꺼라는 생각이 들었기에 말이다..... 왜냐하면 사람들의 편견문제부터 시작이 될듯....
서비스의 시작이라는 그리고 그 서비스에 대한 트렌젝션까지 알아야 할것이다.
고려할게 많은 상황....

그런데 이렇게 하면 또 문제가 나중엔 도메인 모델링된 구현체에 화면의 로직이 섞을지도 모른다는 생각이 조금들었다. 또 상상력 발동중....도메인모델링 구현된 코드에 AOP섞으면...
음..... 멋지겠엄...ㅋㅋ

암튼 상상을 한 4시간 정도 하면서 토요일 아침을 보냈다.
그리고 나서 집에와서 와이프하고 영화 한편을 봤다. 영화 이름은

와이프는 보다가 잠들었음....ㅋㅋ 꼭 봐야 하는데....




http://movie.naver.com/movie/bi/mi/review.nhn?code=64354#01
보면 10점 만점에 까탈스런 우리나라 넷티즌이 9.11점 줬음...
음..어제보다... 0.3점 깎였네....ㅋ 9점이면 대단한 영화인데....

이 영화 정말 감동적인데 꼭 봐줘야 하는 영화다..가볍게 보고 억지로 감동받으려고 보려한다면 안보는게 좋고....귀여운 꼬마는 윌스미스의 친아들....
윌스미스가 연기를 정말 잘하네...ㅋ
영화보는 동안 계속 한숨을 쉬어야 했던 그 영화....
마지막 황제를 보고 눈물을 흐렸고..그 이후 그럴듯한 영화 안보였는데...이영화는...
음...

왜 저 포스터 보면 happyness라고 적었을까요 ?? 아시는분 ??
우리나라 말로 치면 행복을 향복이나 항복으로 적은건데....
영화자세히 보면 아실듯.....

ps : 영화는 크리스 가드너 라는 분의 실제 이야기인데...
본받아도 될 아름다운 사람의 이야기 이다. 나도 저런 의지를 가져야....
http://en.wikipedia.org/wiki/Chris_Gardner : 멋진사람
http://www.gardnerrich.com/ 차린 회사

이전에 오프라 쇼에 나왔을 때는 그런갑다 했는데 (영어를 다 이해 못해서)
사람들이 마구 마구 울어서 그냥 그런갑다 했는데... (이쑈 보면 눈물바다가 많아서)
영화와 위키를 보니 더 대단하시다는....

블로그에까지 논리적으로 적기 시작하면... 대강 끝내야....

오늘 빡센 하루 보내고 내일은 일어날 수 있을지 모르겠다. 지금 집에와서 컴터 앞에 앉은지..5시간째....막 가트너와 포레스트리서치의 자료를 뒤지고... 자려고 하는데
도통 잠이 안온다. 두 회사의 리서치 자료중 그래도 맘에 드는건 가트너...
공통점은 둘다 최근들어 ESB관련 자료를 토해낸다..... 토해낸다는 의미는....^^;;;;

최근에 본 자료의 양은 태어나서 가장 많이 본듯.... 정말 끔찍하게 많은 양이다. 머리속에서 자료들이 둥둥 떠다니는듯.... 이 많은 양의 자료를 함축하고 추상화 하느냐가 지금은 중요하다....

포레스트리서치의 자료는 CIO나 혹은 CEO전용인듯...그래서 몇번 좌절.... 그러나 나에게는 너무나 좋은 자료들....그들의 레벨에서 많은것을 생각해야하니...
다행히 엔지니어링 자료는 여기저기 뒤지면 많이 있어 다행...

얼마전 쓴 블로그에서 마이크로커널이 왜 훌륭하다고 하는지... 아는 사람은 알겠지만
JBoss의 마이크로 커널이야 말로...SOA의 실체라는 생각이 들어서 이다.
너에게만 TRUE SOA라는 말을 내가 붙여준다. ^^

그거와 관계없이...여기저기 레포트를 뒤지다 레드헷의 이야기를 보게 된다.
오라클이 탐냈던 JBoss결국은...레드헷이...가졌다.
결국 레드헷은 SOA플레폼을 원했던 것이다.

엄청난 자료속에 내가 필요한 것은 별로 없던데...한숨이 핑핑 나온다.
내일은 또 무슨 일이 있을랑가.... 토요일만 기다려진다.

이번주에 알아야 했던 사실은 이전에 알았던 그 무엇보다 광범위 했다.
특히 기업이 오픈소스를 도입할때 얼마나 신중하여야 하는지...
또 경영자, 그 중간, 개발자들간의 갭등에 대해서 다시 생각해보는 좋은 시간이 되었다.
다시 한번 부끄러워지는 하루였다. 그래서 더 힘이 빠졌나....
아래 그림은 오늘을 생각하며 넣은 뽀나스 T.T

갑자기 심기 불편 .... 용어때문에...머리가 나빠서 맵핑하면서 읽으려니깐..힘듬....끙끙...
용어정리가 AOP엔 아직 잘 안된듯.... 조만간 되었으면....


PS : POSA 1 브로커패턴 정리중 하기 싫지만... 오기로 POSA파는중....
좀더 많은 것을 하고 싶은데... 그러지 못해서 매우 화가남...

토비형은 내가 Spring을 x하고 다닌다고 하지만..그렇지 않다고 다시 말함. 절대 x하고 다닌적 없음. 다만 무조건 쓰는 사람을 x한적은 있음.... spring훌륭함...

2006년에 건강을 해침. 매우 많이...
어찌하다 보니... 쯪... 현재 턱밑과 귀밑이 퉁퉁 부었음. 내일 아침에 당장 검진들어가야 할듯
와이프도 걱정을 많이 함... 저번주에 몸을 너무 부려먹었나... 일단 와이프에게 너무나 미안함
미안해... 여보야.... 내일부터는 일찍 퇴근해야 할듯.....


정초부터 화가 나기 시작하는군.... 열심히 일한 결과가 당장 보인다는게 병이라니....
기가 막힘...

이상태에서 조금만 틀어져도 화가 많이 날듯....걸리면 재미없어.... 누구든....
몸을 조심해야 겠군.... 어차피 몸 버려봐야 보상도 없자나.... 누가 알아주는 것도 아니고...

오늘은 레포팅을 마무리 하려고 책상 머리에 있다. 놋북 켜고...
처형댁에서....

경영관점에서의 과거 비지니스들이 프로세스화 되고...이젠 컴포넌트화에서 서비스화로 되어가고 있다는 생각이 바싹 든다. 그런데 내 머리속에선 그러한 것들이 받고 싶진 않다.
이러한 겝을 IT에서 줄이기 위해 SOA라는 추상화 도구를 만들었고...나는 지금 레포트에 이 추상화 도구가 벤더 집약이어야 한다고 적고 있다.
벌써 SOA의 원칙을 하나 깨고 있지만
직접 구현해야 하는 웹서비스들의 트레이드 오프때문이다. 직접 구현하려면 적어도 좀더 많은 아키텍처를 위한 대안들이 필요하고 서비스간의 오케스트레이션 (어플리케이션말고 서비스레이어에서의) 에 문제가 있어 보인다. 그런데 더 황당한건 벤더 제품을 쓴다고 완전해 보이지도 않는다. 암튼 문제점이 아닐 수 없다.


경영 + 아키텍처...
엔터프라이즈 환경에서의 비지니스와 기술에서 최고이다.
그러나 두개의 관계를 만족하는 것은 세상에 없나....
맨날 싸움만 하니....그런데 더 웃긴건 SOA가 이러한 갭을 매꾸려고 생겼고...벤더들의 잔치가 되고 있는듯 한 생각이 든다.  어쩌냐... 내가 막는다고 되는것도 아닌데 T.T

오히려 경영자들은 모델링툴에 관심만 보인다.... 아흑.....
툴이 이것들의 갭을 매꾸어 줄것이라고 믿는것 같다. 물론 맞는 것도 있지만...
그다지 인정하고 싶진 않다.


메리크리스마스 ^^

한번에 하나씩....
요즈음 가장 생각이 많이 드는 문구...
연말이어서 좀더 생각이 나는 걸까 ??

피터드러커의 책을 보면 이런 말이 나온다. First things first
도데체 무엇이 가장중요한 것인가?
가장 먼저 해야 하는 것인가?
지금 내가 해야 할 우순 순위는.... 무엇인가?


지금 당장 마인드를 바꾸어야 하는것 ?
1) 미래를 준비
2) 과거 청산
3) 용기
4) 창의
5) 지속성


ps : 지금까지의 안좋은 과거는 잊어라. !!!
It is more productive to convert an opportunity into results than to solve problem - which only restores the equilibriium of yesterday - 피터드러커

오늘도 역시 현실과 이론에 대한 강력한 이론에 괴리가 있음을 봉착했다.
공부 잘하는 놈이 돈잘 번다 라는 이상한 논리가 맞지 않음을....

결국 공부 많이 한 인간은 자기가 보는 것만 최우선이라서...
오히려 다른걸 못본다. 때문에 아키텍처 흐리는 거지.... 물론 안 그런 경우도 많다.

미꾸라지 잡다가 논뚜렁 망가지고 한해 농사 다 망칠라..... 아키텍처에서 작은것 하나도 무시 못할 것들이 많다. 에자일이 꼭 좋은 것만은 아니며 모든 아키텍처에는 트레이드 오프가 있다.


보수적인 소프트웨어 아키텍처가 좋다.
그러나 간간히 개발자들은 새로운 아키텍처를 원한다. 호기심 채우려고 그런 사람도 있고 아닌사람도 있고 ....

만일 자신의 호기심을 채우기 위해 제품을 선택하거나 오픈소스를 쓰거나...
혹은... 재미로 프로젝트를 한다면.... 그것이 바로 미래의 불행을 만들 수 있다고 생각한다.



오늘은 말많은 Ajax가 또 하나 해먹었다. 으으.....
아무런 검증없이 썼다면.... 아마 지금 매우 힘들어 하고 있지 않을까....
당연한거 아냐....

오늘도 하루 이렇게 가네...
다시 처음 처럼 도전할 시간이 다가온다.

무에서 유를 창조할때 가장 힘든 것이... 새로운 마음가짐....

요즈음 너무 한심한 생각을 많이 했다.
처음으로 돌아가야 겠다.....

ps : 스스로에게 동기유발이 되지 않는다면...
나 스스로의 경영에 실패한것 아닌가....