問題提起
業務とインフラがうまく整合があっていないとか、あっているかわからないというような事に出会ったことは無いでしょうか？わたしはよくあります。
システムアーキテクチャはシステムを実現するに当って一貫性を持って設計する必要があります。そのためには○○システムアーキテクトが実現する業務を踏まえてグランドデザインを行い、それをトップダウンで細分化して実装に落としていく必要があります。
とはいえ、現行システムのリプレース案件などで各サブシステムからのボトムアップでシステムをくみ上げる例もどうしても出てきます。
その場合にありがちなのが、システムの全体はすでになんとなくできてしまっいて、それぞれがその「制限」の中で実装を工夫している状態です。この「制限」が問題で実は一貫性のあるシステムでは変えるべきところである可能性があります。これを放置すると、ねじれたシステムが出来上がります。

どうしてそうなるのか。
いくつか原因は考えられますが、ちゃんと調整している(と思っている)にもかかわらず起きてしまう場合もあります。システムの内部課題として各々から質問として「これはどうなっているのか？」というものに対して、質問を受けた側は実装を考えた上で「こうなっている」と回答をすると、それが質問をした人にとっては前提条件となり大変だと思いつつもそのまま解決する方法を工夫して進めてしまっている場合です。本来は、実装に関して相談をしながら進めるのが良いのですが、お互いにその時点では案が無かったり時間が無かったりすると質問で終わらせてしまう場合にそうなりがちです。

全体整合をあとからとる
この場合はどうしたら良いでしょうか。今からでも遅くありません。全体の整合性を検証(システムウォークスルー)してみましょう。業務からHW・運用まで全般にわたっての人を集める必要があります。大人数になるかもしれません。
一人が全部わかるならばその人をシステムアーキテクトにして設計すれば良いだけなのですが、この場合は複数の人の知識や知恵を出し合って検証する必要があることを前提としています。
効率的なシステムのデザインという観点をぶらさなければ、全体工数を抑えることができるかもしれません。無理を解決する工数が削減できるからです。
システムリスクも減りますから後工程での工数も削減できます。
ここで言うシステムウォークスルーは、
「業務運用：業務AP：インフラAP：ミドルウエア：ハードウエア：監視運用
にわたって一貫性のある問題の無い設計になっているかの検証」とします。
アーキテクトはシステムグランドデザインを行う「役割」です。

システムウオークスルーの具体的な進め方についてお話いたします。
①テーマの洗い出し
②ウオークスルーの実施
③議事録の展開とトラッキング
という流れになります。

例によって、気ままに書きますので順番の前後等あります、気長にお待ちください。