有时，看到一些软件开发者设计的系统具有漂亮的架构，但他们却声称自己反对软件架构。这种反对声音事实上是反对那种官僚主义严重的预先设计(up-frontdesign)过程，设计的那种华而不实的架构；抑或是反对将大量的时间浪费在绘图(而非设计系统)上。
架构师
工作头衔、开发过程及工程制品三者是可分离的，因此重要的是，要避免将“架构师”的工作头衔、构建系统的过程及工程制品(即软件架构)这三者混为一谈。
工作头衔：架构师在软件组织中，一种可能的工作头衔(或角色)就是所谓的“软件架构师”。一些架构师偏坐一隅，在那里“闭门造车”；另一些架构师则与开发团队打成一片，完全投入软件的构造过程中。不管怎样，头衔与办公室都不是设计或软件构建工作的本质所在。所有的软件开发者都应该理解他(她)所开发的软件架构，而不仅仅是架构师。
开发的软件架构
过程：构建软件是随着项目开始从无到有的，项目结束，就能交付一个能运行的系统。在此之间，团队会执行一系列活动(例如，遵循某种开发过程)去构造系统。一些团队偏向于预先设计，而另一些团队则喜欢一边构建，一边设计。团队遵循的过程与呈现的设计无关。团队可以遵循不同的过程，以便开发不同的产品，例如，三层式系统。换言之，单看最后完成的软件，几乎不可能判断出这个团队究竟遵循了哪种构建过程。
工程制品：架构只要看一眼汽车，就可以分辨汽车的类型，也许是全电动汽车、混合动力汽车，或是内燃机汽车。汽车的类型特征既不同于设计汽车所遵循的过程，也不同于设计者的头衔。汽车的设计是工程制品。例如，设计一款混合动力车，选择不同的过程及不同头衔的设计师，会对最终的设计产生影响。软件的研发与之相似。只要看一眼完成的软件系统，就可以分辨出不同的设计，例如，基于语音 络的端对端协作的节点、信息技术(IT)系统的多层架构或位于互联 系统中的可并行化映射-还原(map-reduce)节点。每个软件系统都有自己的架构，正如每辆汽车都有自己的设计一样。有些软件是拼凑起来的，没有常规的设计过程，但仍可看出其架构。
我们要把架构当做一种工程制品对待，即架构是可以被分析、理解及设计的产出物。只有这样，才能构建更好的系统。不同的开发者倾心于不同的设计过程。一些人推崇敏捷过程，提倡不做或少做预先设计。另一些人则对那种深入细节的预先设计情有独钟。那么，你的选择呢？理想情况下，你应该找到一些指导原则，以帮助作出恰当的选择。
把架构当做一种工程制品对待
所以建议使用风险(risk)来权衡实施架构的度。那么风险是如何指导你对架构作出明智的选择呢？或许下面一位父亲安装信箱的故事可以给你一些启发。
这位父亲拥有机械工程学的双学位，但他安装信箱的办法并没有显得与众不同：先在路边刨个坑，接着安放信箱的立柱，最后用水泥填满缝隙就大功告成了。他懂得计算动量、压力和拉力，但这并不意味着为了这么点儿小事，还得大动干戈。要是换一种情形，若是忽略了这些分析，又显得愚不可及了。他是怎么知道何时运用这些知识的？
软件架构是门相对较新的技术，包含了系统建模及分析等多种技术。每种技术都会花费构建系统的时间。软件架构的风险驱动模型，该模型可以帮助你选择合适的架构技术，做到“行于其所不得不行，止于其所不得不止”，从而设计出恰如其分的软件架构。
软件架构思考
失败的风险有多高，你付出的努力就有多大。或许系统需要良好的可伸缩性，因为它是个大众化的Web服务。在你为系统设计冥思苦想(或者在站点正式上线)之前，最好是确保系统能够满足预期数量的用户访问。如果系统不在乎它的可修改性(或者可用性等)，就没有必要再为该风险浪费时间了。
每个项目都将面临不同的风险，因此，设计软件架构并没有唯一正确的方式：你必须评估每个项目存在的风险。有时，这个答案却是没有架构工作可做，因为一些项目已有先例存在，完全可以重用那些经历了考验得到证明的架构，这几乎没有什么风险。然而，如果你面临的是全新的领域，或者要将现有系统推向未知的“疆域”，你就必须小心翼翼了。
BarryBoehm提出的软件开发螺旋模型(spiralmodel)(Boehm,1988)认为，不断地工作有助于降低工程风险。螺旋模型是完整的软件开发过程，能够指导项目首先处理最高的风险项。项目同时面临管理和工程两方面的风险，因此管理者必须为所有的管理风险(例如，被客户拒绝的风险)和工程风险(类似系统不够安全及低效的风险)排定优先级。
软件开发模型
相比螺旋模型，风险驱动模型有助于解答一些范围更窄的问题：该做多少架构工作，以及选择何种架构技术？因为风险驱动模型只用于设计工作，这意味着可将它应用于敏捷过程、瀑布过程及螺旋过程。因为无论何种过程，都必须设计软件——区别在于何时开始设计，以及运用何种技术。
?
声明：本站部分文章及图片源自用户投稿，如本站任何资料有侵权请您尽早请联系jinwei@zod.com.cn进行处理,非常感谢！