架构愿景实际是回答了哲学家经常思考的三个问题:
我是谁? (问题是什么,现状)
从哪里来? (原因:为什么出现问题)
到哪去? (愿景和目标是什么)
一、前言:架构设计的步骤
架构设计非常适合使用瀑布模式开发，特别是需要升级架构的系统。
瀑布开发模式简单直接，思路清晰，将项目从头到尾划分为不同的阶段，严格定义每个阶段的输入输出，并且十分重视文档。瀑布模型的特点：
1、简单直接，思路清晰，需求明确。2、需要有完善的文档并需要实时更新维护。
其优点：
1、可以保证系统在整体上的充分把握，可以保证整个软件产品有较高的质量，保证缺陷能够被提前发现和解决。
2、可以使系统具备良好的扩展性和可维护性。
二、架构愿景和目标
有时候我们经常把愿景和目标混为一谈,我们首先需要区别愿景和目标:
1、愿景笼统,目标具体，。比如：架构设计做做到高可用，高性能，高可扩展，这些是笼统的概念，没有具体的指标要求。
2、目标是即将实现，能够通过努力实现的规划，愿景是一幅前景，能够指引我们前进的理想。
3、 愿景有助于确定发展目标，发展目标为实现愿景服务。
架构愿景：是一种团队内心的愿望，是脑筋的一幅图画，是一种驱动力，愿意实践、追求，来达到某一个境界，能追求到某一种成就。是团队成员希望架构往哪个方向发展，包括具体目标、设计原则、质量要求。
架构目标：架构达成某些具体的指标，比如可用性达到99.99%等。
因此我这里认为架构的愿景分析是包含目标.
三、架构愿景的层次
架构的愿景是相对于一个范围来说的，在一个特定的软件功能范围之内，谈架构愿景才有实际的意义，例如针对软件的全局或某个子系统/模块。在这个特定的范围中，订立了架构愿景之后，这个范围内的所有设计原则将不能违背架构愿景。这是非常重要的，是架构愿景的最大的用处。有了这样的保证，我们就可以保证设计的一致性和有效性。任何一项设计的加入，都能够融入到原先的架构中，使得软件更加的完善，而不是更加的危险。
我们根据架构适用范围的不同，把架构愿景分为几个类别讨论：
1、软件系统全局(架构模式)
软件全局的架构是我们所最关心的，因此也会花费最多的笔墨。
软件全局中的架构愿景一般很难具体化到代码级别，其实你会发现，就算是具体化到了代码级别，也会因为实际中存在的问题，导致代码没有太多的价值。因此，为软件全局设置的架构愿景可以以原则、或是架构模式的方式体现，并用自然语言或伪代码描述。例如，可以为一个系统规定三层架构作为其愿景，并指出三层的分类原则和具体目标。注意，我们需要指出分类原则，否则规定三层架构并没有太大的意义，因为三层架构随着实现平台的不同、开发人员的不同而有很大的差异，如果不能够规定一个可操作的规范，那么愿景是没有意义的。
2、子系统/模块级、或是子问题级的架构愿景
这时候的架构愿景已经是比较明确的了，因为已经存在明确的问题域。例如界面的设计、领域模型的设计、持久层的设计等。这里的愿景制定本质上和全局的愿景制定差不多，具体的例子我们也不再举了。但是要注意一点，你不能够和全局愿景所违背。在操作上，全局愿景是设计团队共同制定出来的，而子/系统模块级的架构愿景就可以分给设计子团队来负责，而其审核则还是要设计团队的共同参与。这有两个好处，一是确保各个子模块（子问题）间不至于相互冲突或出现空白地带，二是每个子设计团队可以从别人那里吸取设计经验。
在设计时，同样我们可以参考其它的资料，例如相关的模式、或规范（界面设计指南）。在一个有开发经验的团队，一般都会有开发技术的积累，这些也是可供参考的重要资料。
我们在这个层次的愿景中主要谈一谈子模块（子问题）间的耦合问题。一般来说，各个子模块间的耦合程度相对较小，例如一个MIS系统中，采购和销售模块的耦合度就比较小，而子问题间的耦合程度就比较大，例如权限设计、财务，这些功能将会被每个模块使用。那么，我们就需要为子模块（子问题）制定出合同接口（Contact Interface）。合同的意思就是说这个接口是正式的，不能够随意的修改，因为这个结构将会被其它的设计团队使用，如果修改，将会对其它的团队产生无法预计的影响。合同接口的制定、修改都需要设计团队的通过。此外，系统中的一些全局性的子问题最好是提到全局愿景中考虑，例如在源自需求模式中提到的信贷帐务的例子中，我们就把一个利息计算方式的子问题提到了全局愿景中。
3、代码级的愿景 (代码设计模式)
严格的说这一层次的愿景已经不是真正的愿景，而是具体设计了。但是我们为了保证对架构设计理解的完整性，还是简单的讨论一下。这一个层次的愿景一般可以使用类图、接口来表示。但在类图中，你不需要标记出具体的属性、操作，你只需要规定出类的职责以及类之间的相互关系就可以了。该层次愿景的审核需要设计子团队的通过。
而设计细分到这个粒度上，执行愿景设计的开发人员可能就只有一两个左右。但是比较重要的工作在于问题如何分解和如何归并。分解主要是从两个维度来考虑，一个是问题大小维，一个是时间长短维。也就是说，你（设计子团队负责人）需要把问题按大小和解决时间的长短分解为更细的子问题，交给不同的开发人员。然后再把开发人员提出的解决方法组合起来。
四、架构愿景的形成过程
架构愿景的形成的源头是需求，需要特别指出的是，这里的需求主要是那些针对系统基本面的需求。比如说，系统的特点是一个交互式系统，还是一个分布式系统。这些需求将会影响到架构愿景的设计。在收集影响架构愿景的各项需求之后，按照需求的重要性来设计架构愿景。
架构愿景的设计并不需要很复杂的过程，也不需要花费很多的时间。我们已经提过，架构远景的主要目的就是为了能够在开发团队中传播设计思路，因此，架构愿景包括基本的设计思路和基本的设计原则。
1、问题或者需求的背景或者特点:
1)、公司背景: 了解公司主要干嘛,成立多久,涉及哪些业务, 业务发展情况(过去,现在,未来)等。
2)、业务特点: 业务特色(业务核心价值), 业务流程(流程是否复杂, 要求是否灵活), 业务变化(业务需求是不是经常变化)情况等
3)、系统特点: 这是主要针对需要重构的系统架构设计而言:主要内容:
系统整体特点: 如系统庞杂: 如业务特色经多年的快速发展， 内部系统越来越多， 彼此间交互和依赖越来越复杂。
系统划分特点: 系统边界模糊、 职责不清、 耦合过深， 导致系统难以维护和扩展。
业务流程特点: 流程过于分散以及流程的硬编码导致,对流程变化的支持缓慢。
数据分布特点: 多系统间的数据的不合理的集中与分散， 在系统越来越复杂的情况下，严重影响系统的性能与可扩展能力。
开发模式特点: 多种技术并存的情况下， 开发模式的选择， 直接关系到开发效率及运维效率。
4)、技术特点: 主要了解现在系统使用哪些技术: 系统版本是否统一, 开发平台是否统一,数据库, 开源组件或者框架是否统一.
2、提出期望目标(愿景范围)
期望目标也是来源于需求，主要指客户(可能是老板)或其他利益相关人提出的项目（产品）愿景。愿景表达了客户的目标以及对系统的期望。从愿景中我们可以获得许多架构分析所需要知道的知识，例如明确客户最期望达到的目标，以此可以确定场景与风险的优先级；了解客户的不同目标，可以由此识别系统客户的不同角色，明确不同的利益相关人的态度。
1) 、业务响应能力:
降低系统耦合， 提升对变化的响应速度。
改善系统架构， 更好地支持业务扩展。
建立流程引擎， 更灵活地支持业务流程变化。
2) 、系统质量:
合理地增加或减少系统间交互及补偿， 提升系统性能、 稳定性。
3)、开发效率:
合理划分系统， 通过系统职责的分离， 对开发组的职责进行合理分配， 同时建立更完整的公共平台、 基础框架、 基础类库， 提高开发效率。
4)、运维水平:
完善配置、 监控、 预警、 日志系统， 提升系统运维配置效率及排查问题的速度.
3、指定架构具体目标:衡量系统好坏的标准.
通过愿景范围，就可以确定架构的实现具体目标。识别架构目标，就需要了解是谁需要使用架构，理解架构的约束（技术约束、使用约束和部署约束）。如同架构在软件开发中起到的作用，架构目标一方面是业务需求和用户的要求，另一方面也是技术和应用系统的要求。架构目标是架构师、 团队和用户( 可能老板)达成的一致共识，而一旦确立了架构目标，该目标就会成为团队的一致共识。一个系统的架构，最终实现了架构师的设计目标，我们就可以说这是一个好架构.
架构旨在为业务需求和技术需求之间搭建起相同的桥梁，并找到合适的方式实现这些需求。好的架构必须能够减少与技术解决方案相关的业务风险。它最好是灵活的，能够处理软硬件以及业务需求等的变化，考虑整体影响设计决策的因素，在质量属性之间权衡，并努力满足用户、系统和业务的需求:
用户的目标: 首先需要明确用户的分类，因为不同类别的用户，他们的关注点是不相同的。例如管理层关注的目标，可能更多地是考虑组织因素，例如项目成本，周期与收益。如果是系统的使用者，则主要考虑业务因素，关心的是与自己工作相关的功能是否满足需求。如果是系统的运维成员，则主要考虑技术因素，例如系统的可维护性、健壮性、可扩展性、可伸缩性等质量属性。
业务目标: 我们并不需要了解每个细节功能的需求，而是关注业务的期望值。了解业务目标，不是要识别业务流程、业务规则或者业务所要处理的数据。例如业务目标提出了提升工作效率，改善工作质量的要求，确定了应该由系统自动完成的功能，明确对业务需求变化的处理。
系统的目标: 和技术直接相关，尤其是架构的质量因素。系统目标可能包含对系统规模、用户数、并发量等的要求。系统目标也可能对软硬件平台提出了约束性要求。
具体目标指标:
正确性:系统首先需要正确，运行稳定
可用性: 系统必须非常可靠，一般业界更倾向用 N 个9 来量化可用性， 最常说的就是类似 “4个9(也就是99.99%)” 的可用性。
开发效率: 降低开发成本和降低公司在快速巨变的行业里面的时间和机会成本。互联网目前是一个快鱼吃慢鱼的时代，已经不是大鱼吃小鱼了。因为小鱼在一夜之间就长大了，把大鱼吃掉了。
伸缩性: 用户激增的时候，系统可以伸缩来支持用户的增长或流量高峰。安全性:安全也是一个商业公司的命脉，攻击、泄密、破解，前一段闹的沸沸扬扬的各种用户信息泄露，足以说明安全的重要性。
扩展性:在增加新模块或者新的技术时，能比较容易的扩展。
高性能:性能其实也是用户体验的一部分，尤其是用户量不断增多，性能是节省成本的重要手段。
可维护性:一个系统上线之后，80%时间需要不断的更新及增加新的功能，可维护性是一个架构的基本需求。
4、确定架构质量要求
5、规范架构设计总体原则
五、架构愿景目标和需求分析关系
架构目标和需求分析是可以并行进行，但从一开始明确架构目标才是最佳的选择，因为架构目标是整个架构过程所要努力达到的方向。不了解架构目标，搭建出来的系统架构再好，也可能不符合客户的需求。
由于需求非常贴近现实，若直接拿来当作目标的话，一叶障目不见森林的缺点。甚至，会有短视而缺乏远见之嫌。于是，透过观想愿景来汇集更多视角、扩大视野、产生洞见，成为系统开发的理想目标。
架构愿景和目标可以衡量需求是否合理: 在需求分析阶段, 从需求方收集到的需求,不一定是合理的. 比如需求要求可用性必须是100%。可能需求方也没有想清楚自己想要的是什么，可能在沟通过程中有信息失真，可能需求方的需求太局限于当前现实而忽略了未来发展.因此衡量需求是否合理和依照需求表象来挖掘真实需求是很重要的。这就是需要架构设计立足现实，着眼未来。
任何架构设计都需要一定灵活扩展性，但是基于现实需求去推演往往不能正确充分的判断需求的发展方向；但是基于未来愿景的回溯所作的设计，已经具备了未来性，决策的未来型是由愿景的正确性来保证的。
需求分析从现实出发，不但找出问题，并且理清它的现实条件和限制。
观想愿景则指引出我们的方向和目标。
架构设计就从这个目标出发，以终为始，从愿景映射到现实。恰好与需求分析是相反的视角，两者互补而相成，殊途而同归，才能得出一条从现实通往目标之路(或蓝图)，这就是所谓的架构了。
参考: 总结网上相关资料
https://www.ibm.com/developerworks/cn/linux/software_engineering/Methodology/part8/index.
《携程架构变迁》