소프트웨어 시스템은 이해관계자에게 행위와 아키텍처를 제공한다.
행위
이해관계자가 요구한 내용을 만족하는 코드를 작성하는 것을 행위라고 한다. 요약하자면 행위는 기능이다.
이들은 요구사항을 기계에 구현하고 버그를 수정하는 일이 자신의 직업이라고 믿는다. 슬픈 일이지만 그들은 틀렸다.
아키텍처
소프트웨어는 부드러운 제품이다. 언제나 변경이 가능하고 유연해야 한다. 소프트웨어 개발 비용 증가는 변경사항의 범위에 달려있는데, 변경사항이 클수록, 시간이 오래 지날수록 개발 비용은 증가한다.
아키텍처는 변경하기 어려운 부분. 소프트웨어 큰 틀이라고 이해할 수 있다.
문제는 당연히 시스템 아키텍처다. 아키텍처가 특정 형태를 다른 형태보다 선호하면 할수록, 새로운 기능을 이 구조에 맞추는 게 더 힘들어진다. 따라서 아키텍처는 형태에 독립적이어야 하고, 그럴수록 더 실용적이다.
더 높은 가치?
행위와 아키텍처 중 어느 것이 더 중요한가? 대부분의 사람들 그리고 개발자들도 행위가 더 중요하다고 말할 것이다. 일단 당장의 기능이 중요하고 변경 가능한 유연한 설계(아키텍처)는 추후의 문제라고 생각한다. 개발자는 이런 생각들, 이런 주장들과 싸워야 한다.
아이젠하워 매트릭스
아이젠하워 매트릭스에 따라 일의 우선 순위를 매기면 아래와 같다.
- 긴급하고 중요한
- 긴급하지 않지만 중요한
- 긴급하지만 중요하지 않은
- 긴급하지 않고 중요하지 않은
행위는 주로 긴급하지만 중요하지 않고(3번), 아키텍처는 주로 긴급하지 않지만 중요(2번)하다. 업무 관리자와 개발자가 주로 저지르는 실수는 3번을 1번으로 격상시키는 것이다.
