하루가 재미있다. 신난다. 즐겁다. 뭐든 하고 싶다.
그런데 어제 오늘은 많은 생각을 별로 못했다.
음.... 뭐 잼난거 없을까....??
책이 젤 잼나긴 한데...
잠은 자야 하고...z.z.z.z.z.z.z

http://management.about.com/cs/generalmanagement/a/Pareto081202.htm
http://www.emh.co.kr/xhtml/80_20_principle.html

이것만 읽고 자야지...

Some Sample 80/20 Rule Applications

기회비용이라는게 있기에 더욱 agile하게 진행하여야 한다.

S/W 아키텍처 서비스를 시작하기 전에 가장먼저 check해야 할것은 기업의 정책이다. 아키텍처 서비스를 하면서 기업의 정책이 생길수 있으나 이미 정한것이 있는것을 반드시 확인해야 한다. 그렇지 않으면 혼란이 올 수 있기 때문이다. 생각하지도 못한것이 그 속에 숨어 있고 시간이 지나면 위험요소로 다가올 수 있는 듯 하다.
S/W 아키텍트라고 하면 고객이 무엇을 하는지 알아야 한다. 그러려면 그사람과 많은 시간을 보내야 한다. 그러기 위해서는 가장좋은 방법은 그들을 관찰하는 것이다. 그러나 컨설팅에서 1주일 단위의 무언가는 많은 시간이므로 절충이 필요하겠다.
시스템은 기업의 비지니스를 위해 움직임으로 기술이 먼저가 되어서는 절대 안된다. 그러나 개발자와 설계자들에게 명확한 아키텍처를 제공할 의무가 있다.
회의록을 작성할때는 상세하게 적어야 하며 그사람이 기침했다는 것까지도 적고 무슨 생각을 하는지 알아내야 한다. 그정도로 자세하게 써야 한다.
시스템은 살아움직인다고 생각하고 그것들의 입장에서 그것을 쓰는 사람의 입장에서 생각해봐야 한다. 시스템이 아파한다면 왜 아픈지 끄집어 내야 한다. 사용자가 힘들어하면 왜 그런지 알아내어야 한다. 그 절충점을 찾아내는것이 S/W 아키텍트의 역활이라고 생각한다.
무언가 요건 혹은 요구사항을 찾을 때는 fact 뿐만 아니라 story를 알아야 한다. 스토리는 깊이가 있지만 공식문서가 아니라도 작게라도 이면을 이해하기 위해 적어두면 좋다. 내면 스토리는 회의록에도 많이 나타나게 된다. 회의록을 자세하게 적으면 스토리가 되기도 한다.
S/W 아키텍트는 멘토링만 해서는 안된다. 현업과 한몸이 되어 파도의 한가운데 있음을 알아야 한다.  
만일을 대비해서 많이 신중해야 하며 아키텍트는 혼자 일할 수 없다. 혼자라는 의미는 모든것을 혼자 결정하는 것을 말하며 기업은 거버넌스 체계를 가져야 한다는 것이 무리가 아니다.
S/W 아키텍처에서 인터페이스는 가장중요한 것이며 이것을 통해 이루어 지는 것이 가장먼저 보이며 이것으로 인해 시스템의 완성도가 결정된다. 인터페이스라고 해서 화면을 말하는 것은 아니다. 단적인 예를 들면 ajax 같은 것도 포함되기도 한다. 만일 웹이 나올때 이 기술이 지금보다 더 부각되었다면 지금 웹의 판도는 많이 달라져 있지 않을까 생각한다.
S/W 아키텍처가 어려운 이유는 추상적이어서 이며 이 추상으로 인해 많은 사람들이 어려워 하지만 실체보다 추상은 항상 생명력이 길다. 즉 구현보다 오래 간다는 이야기 .....