Search Results for 'architect'

2 POSTS

  1. 2006.09.06 대안 그리고 선택 그 중간에 아키텍트
  2. 2006.08.31 아키텍처를 서비스 하면서 이것이 공학이 아님을 다시 생각한다. 2

대안 그리고 선택 그 중간에 아키텍트

Posted 2006. 9. 6. 02:02
0
요즈음 일을 하면서 많은 생각을 한다.
아키텍트는 무엇인가 ?
ABC 하면 다인가? 흠...아래 그림은 ABC그림...

항상느끼지만 이거 말고도 아키텍트는 할일이 많다. 위의 그림은 Sun사의 아키텍트에 대한 ABC 에 대한 그림인데

요즈음 절실히 느끼는 나의 아키텍처에 대한 생각은 아래와 같다.

1. 대안 아키텍처는 준비 되어있는가? 반드시 준비 되어 있어야 한다.

2. 아키텍트는 어떤 자료를 수집(실제 수집이 아니고 거의 탐정의 추적에 가깝다고 생각함)하고 반영하여 현실세계의 아키텍처에 흡수 시키는가?

3. 아키텍트는 코드를 알아야 하는가 ?

4. 품질속성만 잘 비고하면 아키텍트로서의 일이 끝나는가 ?

5. 아키텍트와 업무와는 무슨 관계가 있을까? 나의 생각은 업무는 관계가 깊다. 라고 말하고 싶다.

6. 아키텍트는 어떠한 구도로 아키텍처 문서를 만들며 이를 아키텍처로서 가이드 할때 어떠한 뷰를 가져야 하는가? 아키텍트는 스테이크홀더 관점의 여러 뷰를 가져야 하며 스테이크홀더의 관점이 아니더라도 뷰를 여러가지로 판별 가능해야 한다. 사물은 한가지 모습이 아니라 여러가지 모습이며 보는 구도가 달라지면 많이 달라지므로 그렇다고 생각한다. 때문에 그들의 마음으로 그들의 언어를 써야 하며 그들의 생각을 이해하려고 노력해야 한다.

7. 스터디만 가지고 아키텍트는 가능한가?  

8. 전문 지식을 모르는 경영진에게 아키텍트로서 그들을 설득하고 기술을 이해하게 할수 있는가?

9. 아키텍처 혹은 아키텍트가 시스템과 개발 조직에 미치는 영향은 ?

8번의 능력은 특히 중요하다. 8번과 함께 아키텍트는 뷰로서 사물을 접근하고 그사물을 얼마나 추상화를 잘하며 실체화 하는지에 대한 스킬이 필수라는 생각이 지배적이다. 특히 문제의 접근과 해결에서 이것으로 인한 도움을 많이 받았기에 더더욱 그렇다.

최근엔 Ajax에 대한 문제가 많이 도출 되는데 많은 생각을 하며 아키텍처 정의서에 대안 아키텍처로서 비교를 하고 Ajax가 가지는 장단점과 현 아키텍처에 미치는 영향도 등을 조사하고 대안 기술에 대해서 생각을 다각도의 측면에서 가져야 한다. 더군다나 보안에 대해서 아무런 대책도 없이 이것을 쓴다면 차후 나타나는 결과는 뻔할듯....

그때 그때 기술을 준비하기 보다는 시간이 날때 이것들을 비판하고 이것을 사용하기 위한 대안및 비교자료를 만들어야 할것으로 생각된다.....
(항상 기술자료및 기술에 안테나를 세우고...이를 추상화하고 구체화하는 일을 해야 한다.)
스테이크홀더들에게 쉽게 이야기한 기술들이 많은 영향을 미치며 아키텍처가 흔들린다면 쓰지 않는 편이 낳을수도 있지 않을까 조심히 생각한다.

신기술을 사용하는 사람들은 그것을 쓰는것이 무섭지 않겠지만...
신기술을 하나 쓰고 안쓰고가 중요한것이 아니다. 전체 프로젝트에 미치는 영향과 그 영향도에 따른 파급효과 그리고 신기술로 인해 바뀌게 되는 문화 ( 요즈음은 문화까지도 고려해야 하는 시대가 되었나 보다. ) 그리고 개발조직의 밤샘시간.... 모든것을 고려 해야 한다. WEB 2.0 에 대한 많은 이야기가 나오고 문화에 대한 관점의 뷰가 많이 보인다.

이러한 문구가 와닫는 오늘 하루다.

  1. ARCHITECTURES ARE INFLUENCED BY SYSTEM STAKEHOLDERS
  2. ARCHITECTURES ARE INFLUENCED BY THE DEVELOPING ORGANIZATION
  3. ARCHITECTURES ARE INFLUENCED BY THE BACKGROUND AND EXPERIENCE OF THE ARCHITECTS
  4. ARCHITECTURES ARE INFLUENCED BY THE TECHNICAL ENVIRONMENT
  5. RAMIFICATIONS OF INFLUENCES ON AN ARCHITECTURE
  6. THE ARCHITECTURES AFFECT THE FACTORS THAT INFLUENCE THEM
    0
                                                        The Architecture Business Cycle

아키텍처는 분명 진화하고 진보한다. 하지만 좋은 기술을 썼다고 진화하고 진보하는 것은 아닌듯 싶다는 조심스런 생각을 해본다.
오늘 하루도 상당히 힘든 하루

아키텍처를 서비스 하면서 이것이 공학이 아님을 다시 생각한다.

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

진짜 자야 한다. 이러다 쓰러져...케케켁



« PREV : 1 : NEXT »

티스토리툴바