到目前为止的内容可以帮你专注于构建好的解决方案，但并不能保证成功。把最好的设计和最好的技术简单地拼凑在一起，并不意味着整个架构就会成功。你选择的技术是否真的奏效，也是个问题。很多团队都有“做不如买”的战略，为了可能会节约成本而去使用一些（商业或开源的）产品。然而，很多团队也因为听信供应商网站或西装革履的销售人员的宣传，结果遭了殃。似乎很少人会问技术是否真的以设想的方式工作，能证明的人更少。
技术选择其实就是风险管理，当复杂度或不确定性高的时候降低风险，有利可图时再冒点险。所有的技术决策，在做出选择时都要把全部因素考虑在内，这些技术决策也需要评审和评估。这可能包括一个软件系统所有的主要结构单元，下至在开发过程中引入的库和框架。
你要问自己的问题是，你的架构是否“管用”。对我来说，一个架构如果能满足非功能性需求，在给定的环境约束下有效，能为其他代码提供必要的基础，作为平台能解决潜在的业务问题，那就是管用的。软件最大的一个问题就是，它复杂而抽象，很难通过图表甚至代码本身可视化一份软件在运行时的特征。此外，我并不总是相信自己第一次就能做好。当然了，说不定你可以！
在整个软件开发的生命周期中，为了有信心让所构建的系统在交付时能正常工作，我们会进行多种类型的测试。那为什么不对架构也这样做？如果能测试架构，我们就能证明它是管用的。如果可以做得尽可能简单，我们就能降低项目失败的整体风险。架构师应该像优秀的主厨一样，品尝自己生产的东西。概括地说，就是主动发现、减轻和承担高优先级的技术风险 ，这样才能保住你的项目和工作。