「架构」一词意味着什么呢？这个看似学术的名词，其实在我们的日常生活中也常会听到的，例如，文章架构、组织架构、发展架构，它在形容事物的一种风格、组织方式或着决策方向。在这里我们要谈的是软件架构，顾名思义它也是指软件的一种风格、组织方式或着决策方向，不过这样的解释可能不好理解，毕竟软件本身是一个复杂的创意。软件架构的重要，就如同每个人的体质，从身体的最深处，一层一层的影响到外表的美丽。

软件架构杂乱，项目失败风险高
我曾经历过一个经典且传统的软件项目，那是一个旅游网站，旅客可以在网站上透过聪明的航程规画精灵实时地比较机票的价格，然后直接订机票并且在线付款，流程中几乎不用和旅行社的票务人员交涉，除此之外，在那个网站上也可以查到各式旅行信息。

和大部份的软件项目一样，在这个案子里有一位野心勃勃的老板，另外，我们有一些极热心但是拥有模拟脑（完全不懂计算机）的旅游专家──就是票务小姐及票务经理，然后我们需要和信用卡系统及一个世界级，但是稳定度及整合接口是古迹级的票务系统介接，最后还有一群从没搭过飞机，但视加班为进补的程序开发人员，我们要做的系统包含了旅客会直接使用的订票网、票务小姐管理票务的后台系统、跨平台介接的实时订票系统及在线付款系统等等。

这个项目包含了许多不同的「角色」及「需求」。角色有旅客、老板、票务人员及软件开发人员等等。他们都有各自己的需求，例如，旅客希望票价便宜并且系统使用安全、方便及稳定、老板希望以最少的成本及时间就能上线、票务小姐希望系统能减轻她们后台票务的工作量、营销业务希望什么功能都有、开发人员希望系统设计弹性或者使用熟悉的技术来开发。

于是乎，开发人员为了符合大家的需求或者某个特殊活动的需要，开始了一夜夜悲壮的软件开发战役。而在系统尚未稳定之时，没想到老板竟想要复制「成功」经验，开始建立两岸三地的作战堡垒，因此系统也由小恐龙渐渐地变成了究极大怪兽。

「使用接口风格不一致、订票系统容易断线、订票响应速度太慢……」，一连串的问题陆续出现，然而最终没有人真正了解问题的来源或者可以解释细节。这个没有人能控制的大怪兽终于带来了最后的审判日──失败的软件项目。这个项目失败的原因很复杂，包括了使用者接受度、商业模式（Business Model）、政治因素、项目管理控制等等，当然有很大的一部分原因是：它拥有一个杂乱的软件架构及一个无法控制的系统。

软件系统的最高指导原则
所谓的软件架构，简单的来说，就是定义一个软件系统未来发展的「最高指导原则」，就像宪法一样，在未来的发展中不可抵触，例如，系统该分成哪些模块、要用哪些技术、组件间的沟通接口是什么、组件间的互动行为要用哪些Pattern。

这些最高的原则当然是由各种需求或者开发团队的能力分组所引导出来的，例如，分成三层，并分给三个不同能力的小组来完成，或者使用讯息中介软件介接外部系统，缩短使用者的等待时间并增加系统的稳定度及可靠度等等。这些最高指导原则订定了整个软件系统发展的大方向，也等于限制住系统技术发展的最大范围，进而防止系统开发走向错误的方向，并且让开发人员有一个技术的依归，可以踏实地完成系统开发。当然，宪法是可以修的，只不过必须经过正式的修宪会议而已，软件架构也是一样，不然在偏离架构范畴下所开发出来的软件，最后还是很可能会误入歧途而失败。

在《Software Architecture in Practice》一书中，作者Bass、 Clements、Kazman对于软件架构以比较学术的方式来解释：「软件架构是一种系统的结构，「包含」并「定义」了许多软件组件及其间的组织方式和互动行为」。换句话来说，软件架构有许多软件组件、一个以上的结构以及它们之间的各种关系。除此之外，架构还包含了非功能面的条件，像是QoS （Quality of Service）或是SLR（Service Level Requirement），它包含可用性（Availability）、可信赖（Reliability）、可扩充（Scalability）和安全性（Security）等等。
上述这个定义也暗示着任何一个软件系统都有软件架构，只不过和系统本身的好坏无关。对于一个软件系统来说，架构并没有绝对的好与坏，只有适不适合而已。例如，一个时间紧迫并且规模小的网站系统，就没有必要一定要用MVC的架构来开发，它也可以很简单的利用Layer的观念并且配合资料封装技术来实作。建立软件架构的关键在于能够提供软件系统未来实用而稳固的发展基础，这是很重要的一点，因此架构不应由错误尝试中得到，它应该是经过认真的设计及规划出来的，而架构文件则是架构设计后所该留下的重要结果，也是未来开发的依据。清楚的架构设计有利于开发过程的「沟通」、系统的「演化」以及未来产品线开发的「再利用」。

平衡软件项目元素，建立扎实软件架构
通常一个软件系统，打从娘胎开始就会不断地受到各种需求的影响，但同时满足所有的需求是不容易的，因为有许多的需求是相互抵触或者是有隐含的意义。软件的「开发过程」就是在协调及满足这些需求，而过程中，如果没有好好地规画软件设计的发展策略，软件系统很容易会变成多头马车，进而演变出迭床架屋的架构，充满随时倒塌的危险。

架构师的责任就在于利用自己的经验来「平衡」项目相关人员需求、开发团队技术能力、技术环境及成本等元素，进而建立出扎实的软件架构。虽然我们都知道软件的本质是「恒变的需求」，但是在我们拥抱改变的信念下，还是不可能从咖啡机中煮出红酒来的。
「软件架构」就像是一个人的体质，它会影响软件系统未来的生老病死，因此在开发软件系统前，请先好好的调理它。