然而，並非有了建築師，房子就一定蓋得起來。
另外，有些建築師缺乏常識，只會設計，但缺乏人性化。像是台北市改建的圓環，就算東西蓋出來，但還是不能用。因此企業資訊系統的建置，也並非有了架構師設計就一定會成功。
根據我同學多年工地主任的經驗，如果按照建築師設計的圖直接蓋的話，是沒有房子可以蓋得起來的。因此在建造的過程中，往往需要按照工地的需要，適時的做一些修改與修正。資訊系統的建立過程也是一樣，系統架構師所規劃的架構在程式實作的過程當中，可能會需要按照實際環境做一些細部的調整--畢竟架構是根據需求建立的，但專案往往會有一些隱藏的變數，需要在開發的過程中才會發現。因此好的架構規劃很重要，但是有經驗的、付責任的開發團隊負責人--專案經理--也是相當重要。但就像是工地主任要修改藍圖之前需要跟建築師做確認一樣，我不認為應該由專案經理來主導或是決定規格的修改是一件正確的事。但很多案子中，專案經理為了討好客戶或是老闆，在開發的過程中任意修改規格，往往是造成最後失敗或是無法結案的原因。
建築學跟軟體工程另外一個差異，就是在於生命週期。以現在的建築技術來說，花兩年蓋好的大樓，住個50年應該是沒問題的。而一般的資訊系統可以使用10年就算超長壽的，換算成蓋房子的時程的話，應該是在半年左右就需要結案。以台灣一般MIS人員的工作量來說，這一個目標似乎是不容易達成的，因此我覺得對於企業而言，資訊系統外包才是合理的做法--既可以兼具開發效率，又可以減化MIS人員的工作。
但很可惜的是，雖然我們是以建築學的方式來看軟體工程，但是使用者卻是以坐計程車的角度來看待及使用系統。當你買房子的時候，房子的座向、大小、格局都是按照事先設計的藍圖去設計，因此在房子蓋好之前，你就必須要事先確定好規格，建商才可以按照需求進行客製化。但是轉到企業資訊系統來看時，很多企業都以為成立MIS部門的用途，就是要可以隨時客置化系統，不了解系統的建置與蓋房子是一樣的道理，把資訊系統當成計程車使用--今天要去台北、明天要去高雄、後天要去紐約--殊不知，紐約是要坐飛機才可以到的。對於企業而言，我覺得MIS部門應該比較像大樓的管理委員會。我想你既然不會想要花太多錢在管理費上面，就不要叫管委會幫你蓋房子的，不是嗎?
