到目前為止的內容可以幫你專注於構建好的解決方案，但並不能保證成功。把最好的設計和最好的技術簡單地拼湊在一起，並不意味著整個架構就會成功。你選擇的技術是否真的奏效，也是個問題。很多團隊都有「做不如買」的戰略，為了可能會節約成本而去使用一些（商業或開源的）產品。然而，很多團隊也因為聽信供應商網站或西裝革履的銷售人員的宣傳，結果遭了殃。似乎很少人會問技術是否真的以設想的方式工作，能證明的人更少。
技術選擇其實就是風險管理，當複雜度或不確定性高的時候降低風險，有利可圖時再冒點險。所有的技術決策，在做出選擇時都要把全部因素考慮在內，這些技術決策也需要評審和評估。這可能包括一個軟件系統所有的主要結構單元，下至在開發過程中引入的庫和框架。
你要問自己的問題是，你的架構是否「管用」。對我來說，一個架構如果能滿足非功能性需求，在給定的環境約束下有效，能為其他代碼提供必要的基礎，作為平台能解決潛在的業務問題，那就是管用的。軟件最大的一個問題就是，它複雜而抽像，很難通過圖表甚至代碼本身可視化一份軟件在運行時的特徵。此外，我並不總是相信自己第一次就能做好。當然了，說不定你可以！
在整個軟件開發的生命週期中，為了有信心讓所構建的系統在交付時能正常工作，我們會進行多種類型的測試。那為什麼不對架構也這樣做？如果能測試架構，我們就能證明它是管用的。如果可以做得盡可能簡單，我們就能降低項目失敗的整體風險。架構師應該像優秀的主廚一樣，品嚐自己生產的東西。概括地說，就是主動發現、減輕和承擔高優先級的技術風險 ，這樣才能保住你的項目和工作。