아키텍트는 직접 실무를 담당해야 한다.

- John Davies

John Davies는 현재 미국 Revolution Money사  최고 아키텍트이다. 그는 최근 Incept5 라고 하는 새로운 기업을 시작했다.










좋은 아키텍트는 사례를 통해 팀을 이끌어야 합니다. 아키텍트는 네트워크를 설치하고 빌드 프로세스를 설정하는 것에서부터 단위 테스트를 작성하고 벤치마킹을 수행하는 것까지 자신의 팀 내 어떠한 역할도 수행할 수 있어야 합니다. 기술에 대한 모든 영역에 충분한 이해 없이는 아키텍트는 그저 프로젝트 관리자에 지나지 않습니다. 팀 멤버들이 자신들의 특정 영역에 깊은 지식을 많이 갖고 있는 것은 당연한 일입니다. 그런데 만일 아키텍트가 해당 기술을 이해하지 못하고 있다면 팀 멤버들이 어떻게 그 아키텍트를 신뢰할 수 있을지 상상하기 어렵습니다. 어딘가에 언급되었듯이 아키텍트는 비즈니스와 기술 팀 사이의 인터페이스 역할을 하고 있어야 합니다. 그러므로 항상 다른 것들을 참조하지 않고서도 팀에게 비즈니스를 이해시킬 수 있는 해당 기술의 모든 측면들을 이해하고 있어야 합니다. 마찬가지로 아키텍트는 비즈니스 지원이라는 목표를 향해 팀을 이끌고 가기 위해 비즈니스를 이해하고 있어야 합니다.

아키텍트는 비행기 조종사와도 같습니다. 온종일 바쁜 것처럼 보이지 않을 수도 있지만, 아키텍트는 자신의 수십 년 동안의 경험을 상황을 모니터링하는데 사용하는 동시에 원칙에서 벗어나는 것을 보거나 들었을 때 즉각적으로 조치를 취합니다. 프로젝트 관리자(동료 파일럿)는 아키텍트에게 일상적인 작업과 인력 관리라는 골치 아픈 일들로부터 벗어나게 하며 매일 매일의 관리를 수행합니다. 궁극적으로 아키텍트는 프로젝트의 품질과 비즈니스로의 연결에 대한 책임을 져야 합니다. 이는 권위 없이 달성하기 어려우며, 이것이 모든 프로젝트에서의 성공에 중요한 부분입니다.

사람들은 다른 사람을 바라봄으로써 가장 잘 배우게 됩니다. 이는 바로 어린아이들이 배우는 방식입니다. 훌륭한 아키텍트는 문제를 찾아내어 팀을 소집하고, 희생자를 지적해내지 않고, 무엇이 문제인지를 설명하고, 정교한 대안이나 해결책을 제시할 수 있어야 합니다. 아키텍트가 팀에게 도움을 요청하는 것은 참으로 존중 받을 만한 방식입니다. 팀은 그것이 문제 해결의 일부임을 알아야 하며, 아키텍트는 그 회의를 주관하고 올바른 해결책을 정해야 합니다.

아키텍트는 프로젝트 초반부터 팀 일에 관여해야 합니다. 말로 지시하면서 상아탑 에 앉아 있는 것이 아니라, 팀과 함께 작업하면서 현장에 있어야 합니다. 방향 질문이나 기술 선택이 별도의 조사나 새로운 프로젝트로 분리되어서는 안되며, 직접 조사를 하거나 (모든 훌륭한 아키텍트들은 서로 잘 연락이 되므로) 다른 아키텍트들로부터의 조언을 이용하여 실용적으로 결정되어야 합니다.

훌륭한 아키텍트는 예를 들어, IDE 와 같은, 일하는데 필요한 최소한 한가지 이상의 도구에 전문가가 되어야 합니다. 아키텍트들은 직접 실무에 참여해야 함을 명심하십시오. 소프트웨어 아키텍트가 IDE를 알아야 하며, DB 아키텍트가 ER  도구를 알아야 하고, 정보 아키텍트가 XML 모델링 도구를 알아야 하는 것은 당연한 일입니다. 하지만, 기술 아키텍트나 엔터프라이즈 아키텍트는 Wireshark 를 사용하여 네트워크 트래픽을 모니터링할 수 있는 능력에서부터 XMLSpy 에서 복잡한 금융 전문을 모델링하는 것까지 – 너무 낮거나 혹은 너무 높은 수준이란 있을 수 없습니다 - 모든 수준의 도구에 대해 최소한의 능력이 있어야 합니다.

아키텍트는 보통 훌륭한 이력과 인상적인 경력을 갖고 있습니다. 아키텍트는 비즈니스와 기술자들에게 깊은 인상을 줄 수는 있지만, 자신의 능력을 직접 실무에서 검증할 수 없다면, 팀의 존경을 얻기 힘들며, 그 팀은 기술을 습득하기 어렵게 되고, 그 팀 멤버들은 원래 하려고 했던 일을 해내기가 거의 불가능하게 됩니다.


원문 : 모든 아키텍트가 알아야 하는 97가지 사실 - Architects must be hands on