通过课堂上观看梦想改造家这个节目，我想到了软件架构师的工作流程，在梦想改造家中，王仲平这个建筑师首先是了解用户需求，然后根据用户需求制定相应的方案和改造计划，其中考虑到了用户的方便性，安全性，重用性，空间利用性。对于我们软件架构师来说，同样如此，非常相似。
软件架构师在需求分析阶段介入。在这一阶段软件体系架构师与软件需求人员一起将所有的需求从不同的级别分层数理列表归纳总结建立跟踪矩阵，并划分为不同的类型进行数理列表归纳总结建立影响分析表，找出不同需求类型之间的相互支持、相互制约关系的影响。并同需求分析人员共同建立需求规格说明书。
第二步是确定对架构关键的需求，软件架构师将所有的需求进行筛选，在深思熟虑之后做出合适的需求权衡和取舍，最终确定对软件架构其关键作用的子集，控制架构设计时需要详细分析的用例个数，找到架构的重点非功能需求。要根据需求确定架构目标（即是组成设计过程、确定使用范围并确定什么时候该结束的因素）。并且要了解架构的消费者。要确定架构是否会被其他设计师、开发人员、测试人员、业务人员或管理人员使用。确定架构涉众的需求，以让架构更为成功、更有影响力。了解条件限制。了解技术限制、使用限制、和部署限制。从一开始就要了解这些限制，这样你才不会在将来遇到一些意想不到的麻烦。为后面的工作打下坚实的基础。
第三步进行概念性架构设计，首先分析关键用例和有用例规约，运用鲁棒图（检查用例规约是否正确和完善）等方法构造系统理想化的职责模型（如分层），然后明确架构模式（如MVC），确定交互机制，形成初步的概念性架构，最后通过质量属性分析，制定出满足非功能性需求的高层设计决策，并根据这些决策对之前的工作成果进行增强、调整，以保证概念性架构体现这些设计决策。设计架构的时候还应该对应用进行一定的了解，因为了解应用在完成的时候的大概情况。这将会使架构更实际，并与具体的条件限制和决定有更密切的联系。创建应用的大概视图应该包括以下步骤：决定应用的类型。了解部署限制。确定重要的架构特点。确定相关的技术。还要确定出主要的危险区域即容易出错的区域，可以可以通过质量属性和交叉问题对危险区域进行整理。然后找出对于应用和场景很重要的质量属性。
第四步是细化软件架构，考虑具体技术的运用，设计出实际架构。概念性架构所关注的关键设计要素、交互机制、高层设计决策与具体技术无关，而最终的软件架构设计方案必须和具体技术结合，为开发人员提供足够的指导和限制。必须从系统如何规划、如何开发、如何运行等角度揭示软件系统的结构和机制。一般分别从逻辑架构、开发架构、运行架构、物理架构、数据架构等不同架构视图进行设计。在设计的时候可以使用质量属性帮助设计。
第五步是验证软件构架。不管软件体系架构师有多优秀，都不能保证软件架构是完全符合要求符合标准的，所以要验证软件架构。进行验证的时候要根据架构框架来计划并整理构架测试。利用不同的测试方法来验证构架的各种质量属性。
最后，由于软件项目的不同、开发组织结构的不同、开发团队情况的不同，软件架构的设计粒度是不一定的。比如，航天航空领域中的软件系统对系统的可靠性等质量属性要求非常高甚至可以认为是荷刻，这种情况下对架构的设计详细程度的要求也会比较高；象大的团队中又有小的团队共同开发，架构的设计粒度到子系统级就足够了，各个小团队精通的技术各不相同，可以让其对子系统采用敏捷开发，对缩短工期、人尽其材有好处；有类似项目经验或项目团队所有成员整体技术水平较高的团队架构粒度可适当粗犷，而分布团队或涉及外包的情况则更强调架构的明确性。总之，架构设计对软件的不同部分的设计程度不应是整齐划一的，特别是具体的业务功能模块在架构设计中往往设计程度不深。