软件体系结构师工作过程
软件体系结构师和建筑师在许多方面都是相通的，都是对于一个原本不存在的事物设计出轮廓，然后分步骤的对单个模块进行设计，同时要从全局角度考虑，保证整体的正常运行。通过课上的一期《梦想改造家》节目，我觉得无论是建筑师，房屋设计师在新建或者改造一座房子前，一般也会需要经过需求的调查获取，然后对需求进行分析，发现其中的问题和问题的本质，然后根据发现的问题本质提出多种解决方案，选择一种比较适合的方案，进行有步骤的实施，同时对于实施过程中出现的新问题也需要能够及时的解决，最后项目完成之后，需要交由用户检验。对于不同的项目也没有一套通用的解决方案可以解决所有的项目问题，只能根据具体的情况再做具体的解决方案。
总结起来就是软件架构师的工作流程大概可以分为需求调研与分析，需求分解与规划方案，工程实施，工程交付用户。
需求调研与分析阶段，需求人员先听取用户当前出现的问题，全程快速记录，对于不太明白的地方要及时和用户进行沟通，同时分析用户是否还有潜在的需求没有表达出来，可能这种需求会在以后的软件中起到重要作用，所以需求阶段这部分需求尤为重要。在项目开发过程中，架构师是在需求规格说明书完成后介入的，需求规格说明书必须得到架构师的认可。架构师需要和分析人员反复交流，以保证自己完整并准确地理解用户需求。
需求分解与规划方案时，分析人员将记录的需求告诉架构师，架构师根据得到的这些需求将需求进行逐层分解，层层分离，逐渐探究出问题的本质问题。架构师通过对系统的一系列的分解，最终形成了软件的整体架构。技术选择主要取决于软件架构。Web Server运行在Windows上还是Linux上？数据库采用MSSql、Oracle还是MySQL？需要不需要采用MVC或者spring等轻量级的框架？前端采用富客户端还是瘦客户端方式？类似的工作，都需要在这个阶段提出，并进行评估。架构师对产品和技术的选型仅仅限于评估，没有决定权，最终的决定权归项目经理。架构师提出的技术方案为项目经理提供了重要的参考信息，项目经理会从项目预算、人力资源、时间进度等实际情况进行权衡，最终进行确认。根据这些本质问题，与分析人员和用户反复交流，共同商量，探究出比较好的，双方都可以接受的解决方案。解决方案确定之后，需要与客户研究项目的交付日期，还有软件的交付质量等问题。最后将整个需求文档补充完整，进行需求总结，接下来就开始实施具体的解决方案。
工程实施阶段，需要组件软件的开发团队，测试团队等其他相关人员，给每个人分配适当的任务，要让每个人都能适宜的完成交代给自己的工作任务，同时要保证任务在确定的期限内完成。期间，架构师的任务则是继续与用户沟通开发当中出现的问题，同时还要兼顾软件的开发进度以及软件的开发质量。在开发过程中遇到的新问题，架构师也要能够及时的思考出对应的解决办法，对各个方面进行全面的思考，保证开发工程的顺利进行，在规定期限内完成开发工作。
项目完成之后，需要交付项目给用户。交付软件给用户时，需要让用户检验软件是否符合约定的期望，并且能否正常的顺利使用，此时应该交给用户详细的使用说明书等文档内容，如果软件与约定的质量有差别，则应向用户说明情况，并商量解决办法。如果后续有升级，则可以在后续版本当中弥补当前的不足情况。
软件的架构师和建筑师其实在很多方面还是很相似的，在工作的流程上也存在很多的相似之处，善于倾听并引导用户的需求，分析需求当中的问题，抽取本质，并根据存在的问题提出解决方案，最后实施解决方案，达到用户的要求。
一个好的软件架构师基本的工作职责是在一个软件项目开发过程中，将客户的需求转换为规范的开发计划及文本，并制定这个项目的总体架构，指导整个开发团队完成这个计划。主导系统全局分析设计和实施、负责软件构架和关键技术决策的人员
在能力要求方面，在技术全面、成熟练达、洞察力强、经验丰富，具备在缺乏完整信息、众多问题交织一团、模糊和矛盾的情况下，软件架构师能迅速抓住问题要害，并做出合理的关键决定的能力 l、具备战略性和前瞻性思维能力，善于把握全局，能够在更高抽象级别上进行思考。主要包括如下：
1.对项目开发涉及的所有问题领域都有经验，包括彻底地理解项目需求，开展分析设计之类软件工程活动等
2.具备领导素质，以在各小组之间推进技术工作，并在项目压力下做出牢靠的关键决策；
3.拥有优秀的沟通能力，用以进行说服、鼓励和指导等活动，并赢得项目成员的信任；
4.以目标导向和主动的方式来不带任何感情色彩地关注项目结果，构架师应当是项目背后的技术推动力，而非构想者或梦想家（追求完美）；
5.精通构架设计的理论、实践和工具，并掌握多种参考构架、主要的可重用构架机制和模式（例如J2EE架构等）；
6.具备系统设计员的所有技能，但涉及面更广、抽象级别更高； 活动确定用例或需求的优先级、进行构架分析、创建构架的概念验证原型、评估构架的概念验证原型的可行性、组织系统实施模型、描述系统分布结构、描述运行时刻构架、确定设计机制、确定设计元素、合并已有设计元素、构架文档、参考构架、分析模型、设计模型、实施模型、部署模型、构架概念验证原型、接口、事件、信号与协议等。
在知识体系方面，软件架构（softwarearchiecture）也称之为软件体系结构，它是一组有关如下要素的重要决策：软件系统的组织，构成系统的结构化元素，接口和它们相互协作的行为的选择，结构化元素和行为元素组合成粒度更大的子系统的方式的选择，以及指导这一组织（元素及其接口、协作和组合方式）的架构风格的选择。软件架构是对系统整体结构设计的刻划，一直以来，对于架构的理解有两个基本概念，一个称之为组成，另一个称之为决策。
组成：架构的组成概念强调"计算机及组件之间的交互"。例如在的初步设计中，"表示层"和"业务层"是两个粗粒度的黑盒，当内部也表达了一些粒度比较细的组件的时候，这两个黑盒变成了"灰盒"。交互的概念表现在架构描述了它们之间的关系，例如数据如何读取、功能如何调用等。
决策：架构决策不但表现了系统组织、元素、子系统的组织风格决策，还包括了非功能性需求的决策，例如对于可扩展性的决策，对于表示逻辑与业务逻辑变化的隔离，第三方工具包变化的隔离等，这就使架构有了弹性。架构的组成与决策是架构设计的两个基本概念，这两个概念并不矛盾，在架构设计中，往往是同时体现这两个概念，确保架构满足产品要求。由这两个概念出发，我们自然会提出：软件架构的核心思维到底是什么呢？
首先，任何软件系统都是以满足需求作为目的，所以，好的架构设计必须以全面深入的需求分析作为基础，根据需求来组织合理的产品架构。事实上架构设计是没有统一的模式的任何模式只有针对问题才有意义。作为架构设计来说，必须对需求分析有足够的理解，这样才能有针对性地解决问题，才可能设计出真正优秀的产品来。
其次，一个软件系统的质量，很大程度上是由架构设计的质量决定的，所以架构师的眼光一般都专注于质量属性上，应该根据产品质量属性的要求提出合理的架构决策。但是很长时间以来，人们大都把目光关注在流程、方法、结构原理甚至编码的本身，而不太注意架构设计最本质的东西，思考的深度也欠深入，结果，很多产品即使设计出来，后期运行中也是问题百出，特别是发生变更的时候带来了很大的困难。这就给我们提出了一个问题，架构设计的思维到底是什么？
另一方面，任何架构思想的实现，必须与具体的项目组织相匹配才能发挥作用。因此，系统架构师应该仔细研究现代项目管理的思想和方法，吃透其中的精髓，根据自己的设计思想，提出合适的软件工程策略。反之，一个软件工程策略，也不可避免的也会影响到架构设计的特点。
上述讨论引发了三个核心思维，一个是架构设计的源泉来自于需求分析，第二个是架构设计重心和特点来自于质量需求（非功能性需求），第三个观点是，架构整体特征应该考虑项目管理特征。因此，软件架构设计是一个系统工程，它需要系统构架师有很宽的知识面，从需求分析、架构设计到类设计甚至代码实现一直到项目管理都需要有透彻的理解，这之间的关系是你中有我我中有你，是不可能截然分开的。必须说明，软件系统设计的方法不是一个僵化的规则，关键是在实践中实事求是的摸索规律，从而找出符合实际达到要求的设计来。
参考文档：
http://developer.51cto.com/art/200912/169389.htm
https://www.douban.com/note/484776935/