아키텍처 비즈니스 사이클(ABC)

소프트웨어 아키텍처는 기술과 비즈니스, 사회적인 영향 요소가 어우러진 결과물이며, 아키텍처는 기술과 비즈니스, 사회 환경에 영향을 준다. 또한 이런 환경 요소들은 다시 미래 아키텍처에 영향을 미친다. 아키텍처에서 환경으로, 환경에서 아키텍처로 서로 영향을 주고 받는 순환관계를 아키텍처 비즈니스 사이클(ABC, Architecture Business Cycle)이라고 한다.

아키텍처에 영향을 주는 요인

아키텍처는 업무적 요소와 기술적 요소가 결합된 결과물이다. 아키텍처를 설계하는데 영향을 주는 요소는 여러 가지고 있다. 이런 영향 요소는 아키텍처가 실제로 수행될 환경에 따라 변하기 마련이다.
아키텍트는 제품과 관련된 이해관계자들이 요구사항에 영향을 받는다. 뿐만아니라 개발 조직의 목표나 구성, 기술 환경, 아키텍트의 지식과 경험 등도 영향을 주는 요소라 할수 있다.

▪ 이해관계자
개발할 시스템에 관심을 갖고 있는 모든 사람을 조직을 이해관계자라고 한다. 고객, 사용자, 개발자, 프로젝트관리자, 유지보수 담당자, 심지어 마케팅 담당자도 포함될 수 있다. 이해관계자는 각자 시스템에 대한 다양한 요구사항을 제시한다.
다음의 일반적인 시스템 특성은 아키텍처의 전반적인 설계사항을 결정하게 된다. 모든 특성들은 시스템의 이해관계자와 깊은 관계가 있으므로 아키텍터는 반드시 그들의 목소리에 귀기울여야 한다.

일반적인 시스템 특성
- 성능(Performance)
- 신뢰성(reliability)
- 가용성(availability)
- 플랫폼 호환성(platform comopatibility)
- 메모리 사용 효율(memory utilization)
- 네트워크 사용량(network usage)
- 변경용이성(midifiability)
- 사용편의성(usability)
- 타시스템과의 호환성(interoperability)

이해관계자마다 목적이 다르고 따라서 이들의 요구사항이 서로 상충될 수 있다. 일반적인 특성들은 요구사항 기술서에 정의되지만 시스템의 특성은 충분히 표현되지 않을 뿐만 아니라 테스트 가능한 수준까지 기술되지 않는다. 아키텍트는 이렇게 부족한 시스템 특성을 모두 기록해서 테스트 가능한 수준까지 작성할 수 있어야 하며 시스템의 품질속성 간에 상충되는 부분에 대해 합의점을 찾아내야 한다. 

▪ 개발조직
조직의 목표는 일반적으로 요구사항에 반영되지만, 개발 조직의 특성이나 구조는 아키텍처에 영향을 준다. 개발자들의 숙력도, 개발 일정과 예산도 아키텍처에 영향을 주는 요인이다.

개발 조직이 아키텍처에 끼치는 영향은 단기 사업, 장기 사업, 조직 구성 세 부분으로 나눌 수 있다.
- 아키테처나 아키텍처를 구현한 제품으로 단기 사업을 진행할 수 있다.
제품뿐 아니라 제품의 아키텍처 또한 유사한 프로젝트에서 재사용돼 프로젝트 개발 비용을 줄일 수 있음으로 제품으로서의 가치를 지닌다.
- 장기 사업에 투자하는 것을 전략 목표로 가져갈 수 있다.
제안 시스템을 재무 수단으로 삼아 조직 가반을 확장 할수 있다.
- 조직은 아키텍처의 형태를 결정한다.
하위 시스템은 특정한 기술을 필요로 하므로 그 기슬을 가진 별도 조직과 계약을 하게 된다. 이것은 아키텍처를 기능으로 나누는 중요한 요인이므로 아키텍트는 특정 기술의 하위 시스템을 별도의 모듈로 나눠 아키텍처를 수립해야 한다.
 
▪ 배경과 경험
아키텍트의 교육과 연습, 자주 사용되는 아키텍처 패턴, 시스템에 적용해본 경험 등을 통해 아키텍처가 수립된다. 또한 책이나 교육을 통해 새로 배운 아키텍처 패턴이나 기술들이 새로운 시스템에 성공적으로 적용되는지 확인하고 싶을 것이다.

▪ 기술적 경험
아키텍트의 지식과 경험은 대개 기술적  환경과 관련이 있다. 아키텍처를 수립하는 단계에서 당시의 기술적 환경은 아키텍처에 영향을 미친다. 기술적 환경은 업계의 표준적인 관행이나 아키텍트 전문가 커뮤니티에 널리 퍼진 소프트웨어 공학 기법 등을 말한다.

▪ 기타요인
아키텍트는 다양한 요구사항과 특성을 세밀히 파악해야 하고, 어느 요구사항이 더 중요한지 프로젝트 초기에 파악할 수 있어야 한다. 반드시 이해관계자들과 자발적이고 능동적인 토론을 통해 그들의 요구사항과 기대치를 알아내야 한다. 프로젝트 초기에 이해관계자들이 참여시켜 제약사항을 파악하고 기대치를 관리하면서 우선순위를 협의하고 트레이드 오프를 찾아내야 한다. 또한 이해관계자에게 모든 요구사항을 동시에 수용할 수 없음을 설명해야 한다. 상충되는 요구사항 중 어느 하나를 선택한 이유에 대해 타당한 근거를 들어 설명해야 한다. 
아키텍트가 갖추어야 할 능력은 기술 지식 뿐만아니라  절충 능력과 협상력, 대화 능력을 반드시 지녀야 한다.