http://www.sei.cmu.edu/str/descriptions/cbsd.html
http://www.cebase.org/www/frames.html?/www/researchActivities/COTS/integrationmodels.html
http://www.ncca.navy.mil/services/software/cots.pdf
http://www.computer.org/portal/cms_docs_software/software/content/value.pdf
http://tharkun0.ucsd.edu/ResearchCentral/download.jsp?id=138
http://www.stargroup.uwaterloo.ca/~ltahvild/courses/ECE750-11-S05/CBSS-Lecture10.pdf
http://www.eetkorea.com/ARTICLES/2004FEB/2004FEB02_ICD_EDA_TA.PDF?SOURCES=DOWNLOAD
http://www.omg.org/news/meetings/workshops/MDA-SOA-WS_Manual/02-3_Cummins.pdf
http://aswec07.cs.latrobe.edu.au/14.pdf
http://sunset.usc.edu/GSAW/gsaw2006/s4/hohwald.pdf
http://csdl2.computer.org/persagen/DLAbsToc.jsp?resourcePath=/dl/proceedings/&toc=comp/proceedings/iccbss/2007/2785/00/2785toc.xml&DOI=10.1109/ICCBSS.2007.46
http://colab.cim3.net/file/work/SOACoP/2006_05_2324/CCasanave205222006.ppt
http://www.army.mil/armybtkc/test/sa/soa.htm

오래된 이야기..거버넌스가 힘들다. Cots에 대한 Integration은...

현재 몸으로 겪고 있음.

몇개월째..T.T

※ 아키텍처는 소프트웨어 아키텍처를 뜻합니다.

최근 아키텍처에 대한 품질 평가를 하면서 몇몇 새로운 것들을 느끼고 있다.

엔지니어들이 느끼는 아키텍처란게 무얼까? 6년전에 만든 아키텍처 문서를 보면서 품질팀에서 아키텍처에 대한 품질을 검사 할 수 없음을 다시 한번 느끼고 있다.

아키텍트는 아키텍처의 품질 담당자이며 이로 인해 아키텍트가 책임을 지는 일은 상당히 크다라고 할 수 있다.

어떤 품질에 포커스를 하느냐에 따라 QA( Quality Attribute ) 의 느낌감도 (?) 는 상당히 다르다는 것이다.

어떤 이는 ATAM을 너무나 쉽게 거론하기도 한다.

최근 모 회사의 아키텍처 문서를 평가하면서 많은 것들을 느꼈는데… 최근에 제품위주(COTS) 의 아키텍처가 아키텍트들의 머리에 또 다른 사고를 만든다는 것도 알았다.

그러기 위해서는 COTS를 위한 아키텍처가 필요하며 이에 맞는 적절한 평가가 필요하다고 생각된다. 페이지수가 많거나 학구적이라고 해서 아키텍처 문서라고 하기엔 너무나 고리타분하고…. 외국서적에 나온 듯이 그대로 배낀 패턴이나 스타일로 뒤덮힌 아키텍처 문서도 난무하며… 정말 그런 문서들이 아키텍처 문서인지는 잘 모르겠다.

개발자입장에서 디자인패턴을 써놓는다고 해서 아키텍처라는 말을 붙이기엔 아키텍처라는 말이 너무나 광범위하고 어떤 면에서는 협소하다고 생각한다.

최근 몇 년간 SEI 에서 나온 시리즈 물을 몇 번 정독하고…

포사1.2를 쪼개고…

각종 Object문서를 봐도 봐도…

현장에서의 아키텍처문서엔 어떠한 면에선 현실적인 내용이 들어가긴 힘들다는 것이다.

그저 현학적인 문서들….. 책을 아무리 많이 봐도 익혀지지 않는 것들이 많은 것은

책의 장수만을 세거나 아니면 너무나 현학적인 책을 봐서 아닐까….. 반성해야 한다.

아키텍처 문서에는 이러한 것들이 들어있으면 좀더 많은 이해관계자들이 공감하기 좋을 것이다.

• 1.여러 이해관계자가 이해가 가능한 View를 가진 문서
• 2.비 전문가가 봐도 어느 정도 이해 가능한 합리적이고 쉬운 아키텍처 문서
• 3.회사나 집단의 아키텍처적인 의사평가를 내리는 과정이나 기술적인 평가를 위해 쓰이게 될 문서
• 4.회사의 아키텍처 전략 ( 품질속성 ) 을 내포하며 이를 지키기 위해서 어떠한 것들이 내재 되어야 하는지 어떠한 것들이 패턴화 되었는지 등등에 대한 문서, 이를 위한 대안이나 원칙, 정의 등이 포함된 문서
• 5.비즈니스와 기술을 연결하기 위해 최적의 메커니즘 효율성을 찾아내는 메커니즘적인 문서
• 6.기타 등등

하도 많아서 기술하기 힘들지만…. 대략 저러하다.

또다른 뷰에서 본다면 아키텍처 정의를 위한 문서들은 어려워서는 안되며 가장 쉬운 것으로 추상화되어 표현되어야 한다는거….