예를 들어 프로젝트 초기에는 개발 속도를 높이려고 모놀리식 방식(monolithic)⁸ 설계에 중점을 두었다가, 이후 독립적인 업데이트와 배포를 위해 느슨하게 결합된 소규모 서비스 설계에 중점을 두는 원칙으로 바뀔 때가 있습니다.

보통 이 문제는 별다른 원칙 없이 그저 변경 최소화와 빠른 배포에 중점을 두었다가 이후 신뢰성, 유지 보수성, 품질 등 명시적인 원칙을 강조할 때 흔히 생깁니다. 새로운 원칙은 신규 설계와 수정된 설계에만 적용하는 것으로는 충분하지 않습니다. 보안이나 확장성, 비용 같은 속성은 이 문제를 다루지 않은 가장 취약한 부분에서 문제가 될 소지가 많기 때문입니다. 극단적인 경우에는 새로운 아키텍처 원칙을 적용하려고 기존 설계를 모두 재작업해야 할 수도 있습니다.

이처럼 아키텍처 원칙이 바뀌는 문제는 소프트웨어 개발에서 해결하기 어려운 문제입니다. 동시에 소프트웨어 개발에서 빈번히 마주하는 문제이기도 합니다. 소프트웨어 첫 버전을 출시할 때와 성공적으로 검증한 뒤 중요하게 여기는 원칙이 다르기 때문입니다. 보통 초기에는 신속한 출시를 중요하게 여기다가 이후에 우수한 품질과 지속 가능성으로 자연스럽게 우선순위가 바뀝니다.