Who Needs an Architecture?

가끔은 영화를, 특히 많은 사람들이 보는 그런 영화는 꼭 볼 필요가 있나 봅니다. 매트릭스와 같은.
 
 
몇 일간 Martin Fowler가 [IEEE Software(July/August 2003)]에 기고한 [Who Needs an Architect?]라는 글을 들고 출퇴근을 하고 있습니다.
 
의역하면 "도데체 누가 아키텍트를 필요로 하는가?"가 될 도발적인 제목은 글을 여러차례 읽어도 쉽게 그 의미가 다가오지는 않습니다. 풀어야 할 숙제 또는 응전해야 할 화두가 다소곳이 놓여져 있을 뿐입니다.
 
3 페이지가 채 되지 않는 글은 Martin Fowler의 동료로 소개되는 Dave Rice의 "We shouldn't interview anyone who has 'architect' on his resume."라는 푸념으로 시작하며, [What is architecture?], [The architect's roles], [Getting rid of software architecture]로 구성되어 있습니다.
 
Martin Fowler는 ThoughtWorks의 주요 아키텍트로 소개되는 Dave Rice의 명칭 분열증(Title schizophrenia)의 원인을 아키텍트의 독선적인 또는 잘난척하는 이미지(the smug controlling image at the end of Matrix Reloaded)와 아키텍트가 수행하는 기술적 리더십의 필요성의 갈등에서 찾습니다.
 
 
[What is architecture?]
 

I define architecture as a word we use when we want to talk about design but want to puff it up to make it sound important.

                                                                                                                        - Martin Fowler
 
 

In RUP defines Architecture as the highest level concept of a system in its environment. The architecture of a software system is its organization or structure of significant components interecting through interfaces,...

                                                                                                                                     - RUP
 
 

There is no highest level concept of a system... Customers do not care at all about the structure of significant components. So, perhaps an architecture is the highest level concept that developers have of a system in its environment.... What makes a component significant? It is significant because the expert developers say so.

                                                                                                                     - Ralph Johnson
 
 
 
냉소적인 Martin Fowler의 정의를 옆으로 비켜 놓는다면, 이 글을 GoF의 한 명인 Ralph Johnson의 생각을 Martin Fowler가 정리하는 혹은 빌리는 방식으로 진행됩니다.
 
우선 Ralph Johnson은 아키텍쳐가 정의되는 범주를 전체 환경이 아닌 개발자가 생각하는 환경으로 묶습니다.
 

In most successful software projects, the expert developers working on that project have a shared understanding of the system. This shared understanding is called 'architecture'.... it makes clear that architecture is a social construct because it doesn't just depend on the software, but on what part of the software is considered important by group consensus.

                                                                                                                     - Ralph Johnson
 

Architecture is the set of design decisions that must be made early in a project.

                                                                                                        - Another style of definition
 
 
Ralph Johnson이 든 예를 확장하면, 소프트웨어를 J2EE로 구현할지? .NET으로 구현할지는 후자의 정의로는 아키텍처의 구성요소가 되지만, 두전자의 정의를 따르면 아키텍처의 구성요소가 아닌 것이 됩니다.
 

So, this makes it hard to tell people how to describe their architecture. 'Tell us what is important.' Architecture is about the important stuff. Whatever that is.

혹시 Presentation Layer, Business Layer, Integration Layer 등을 칠판에 그리고는 이게 우리가 개발할 시스템의 아키텍처라고 하시지는 않습니까? 뻔한 그림을 가지고. 끊임없이 지루하게 반복되는 교수의 지껄임처럼.
 
 
 
[The architect's roles]
 

So, if architecture is the important sutff, then the architect is the person who worries about the important stuff.