‘구체적’이 되어야 한다는 것은 두 가지 측면에서 강조됩니다. 한 가지는 결정된 결과뿐만 아니라 진행되어 가는 과정까지도 구체적이어야 한다는 것이며, 다른 한 가지는 평면적이 아닌 입체적으로 정밀하게 표현되어야 한다는 것입니다.

우리가 비록 아키텍처의 접근 방법을 여러 단계로 나누었다고 하더라도 과정 없이 바로 결론에 도달할 수는 없습니다. 과정을 무시한다면 그 결과 또한 믿을 수 없기 때문입니다. 결과는 단지 과정의 한가지 형태이므로 과정이 투명하고 구체적으로 진행되어야 좋은 결과를 얻을 수 있습니다. 마치 수학문제를 풀 때처럼 진행되는 과정을 있는 그대로 구체적으로 관리할 수 있어야 합니다.

세부적인 중간과정을 구체적으로 관리한다면 보다 객관적이고 체계적인 접근이 가능하며, 변화에 보다 유연하게 대처할 수 있습니다. 더불어 각 과정을 지원하기 위한 구체적인 접근 방법과 객관적인 판단 기준들이 제시된다면 매우 합리적인 결과를 얻게 될 것입니다.

도면에는 개략적인 형태만 나타나 있는 평면도와 구체적인 형태와 내용이 나타나 있는 입체도가 있습니다. 아키텍처가 지나치게 개념적인 선에서 끝나 버리면 단순한 지침이나 안내서에 지나지 않으며, 이것은 앞으로 개발자들의 작위적인 판단에 의한 전횡(?)을 예고하는 것이기도 합니다.

내용이 구체적이지 못하다는 것은 그것이 단지 흉내만 내는 요식행위에 지나지 않는다는 것이며, 이것은 결국 아키텍처를 부실하게 하여 품질을 떨어뜨리고 일과성에 그치게 하여 존재가치 자체를 부정하게 됩니다. 데이터 설계 과정에서 나타나는 모든 과정의 집합들을 구체적인 객체로 표현하고 상세한 정의를 할 수 있어야 합니다.