软件开发和软件架构之间有一条微妙的线。有人会说，这条线根本不存在，架构只是开发者设计过程的简单延伸。
另外一部分人则说，这是一条巨大的鸿沟，只有少数出类拔萃的开发者才能跨越，这些开发者都认为你必须不断地向上抽象，避免陷入令人生厌的实现细节的泥沼。
如果以务实的眼光看，那这两者之间必定存在某个平衡点，但这接着也提出了问题：如何从开发者变成架构师？
将软件架构从软件设计和开发中区分开来的关键因素包括：规模的上升、抽象层次的上升， 以及做出正确的设计决策带来的影响的上升等等。
软件架构就在于能有一个全局视角、能具备更大的视野，理解软件系统作为一个整体是如何工作的。
这些因素对区分软件开发和软件架构也许有帮助，但还是无法解释一些人如何从开发转到了架构。
进一步地，对于如何识别哪些人将会成为出色的架构师，作为 HR 如何发现这些人，以及自己是不是一名架构师，上述定义也无能为力。
尽管经验是一个很好的衡量指标，但你应该看得更深。
没有人是在一夜之间或一次升职就成为软件架构师的。架构师是一个角色，而非级别。
这是一个演进的过程，在这个过程中你会不断获得承担架构师角色所需的经验与自信。
架构师身上有许多不同的品质，而他们过去的经验通常是承担这个角色所需能力的一种很好的度量。
架构师角色包括很多方面，因此需要在更深的层次地去理解架构师在不同方面展现出来的参与度、影响力、领导力和责任。
宽泛地说，大部分项目的软件架构过程可以分成两个阶段：定义阶段和交付阶段。
架构的定义过程似乎相当直接：确定需求，然后设计一个满足这些需求的系统。
但实际上并没有这么简单，由于参与程度和对待自己角色的认真程度各有不同，软件架构的角色也有很大的区别。
如下图所示，角色的架构定义部分可以进一步分解为几个子部分：
①非功能性需求的管理
软件项目经常将注意力放在用户的功能特性上，而很少问用户有什么非功能需求或系统性能要求。
有时需求方会告诉我们说“系统必须足够快”，但这种表述太主观了。要满足非功能需求，那这些需要必须是具体的、可测量、可实现以及可测试的。
大部分非功能需求本质上是技术性的，而且通常对软件架构有很大影响。理解非功能需求是架构师角色的核心能力之一，但试图理解这些需求与质疑这些需求的合理性有所不同。
毕竟，你见过多少真正需要 7x24 小时运行的系统呢？
②架构定义
弄清了非功能需求后，下一步就要思考如何定义架构，解决需求方提出的问题。
我们可以说每个软件系统都有架构，但不是每个软件系统都有现成的架构。这才是关键点。
软件定义过程需要思考如何在给定的限制下满足提出的需求，进而解决问题。架构定义过程是在项目的技术方面引入结构、规范、原则和领导力的过程。
定义架构软件架构师的工作，但从头设计一个软件系统与扩展一个现有系统还是有很大的差别。
③技术选型
技术选择通常是一个愉快的过程，但当考虑到成本、授权、供应商关系、技术策略 、兼容性、互操作性、支持、部署、升级策略、终端用户环境等问题时，挑战往往相当大。
这些因素综合起来，经常会把一个简单的选择某些东西，例如设计一个功能丰富的客户端，变成一场噩梦。
接下来还有另一个问题：这些技术能否像期望的那样运行。
技术选型的本质管理风险：在复杂性或不确定性较高的地方减少引入风险，在可能带来收益的地方适当接受风险。
技术决策需要考虑所有的因素并需要评审和评估，包括软件项目的核心组件，以及开发过程会用到的库和框架。
如果正在进行架构定义，你需要确信自己的技术选型是正确的。同样地，为一个新系统开展评估技术与向现有系统引入新技术有着很大的区别。
④架构评估
如果让你来设计软件，需要问自己：我的架构能否工作？
对于我来说，这样的架构可以工作：满足非功能需求，为其他部分的代码提供了必要的 基础设施，为解决底层业务的问题提供了一个平台。
软件最大的问题之一就是复杂性和抽象，很难从 UML 图或代码去想象出软件运行时的特点。
在软件开发的过程中，会采用多种测试技术确保交付的系统在上线之后能正常工作。为什么不对架构设计采用同样的方式呢？
如果可以测试架构，就可以证明该架构可以正常工作。这项工作做得越早，就越能减少项目失败的风险。而不是简单寄希望于它能正常工作。
⑤架构协作
与世隔绝的软件系统很少见，大部分软件系统都是需要靠人来理解。开发人员需要理解后按照架构实现；需求方出于安全、数据库、运维、支持等角度，也可能对架构实现感兴趣。
软件要成功，就需要与这些需求方紧密合作，保证架构能够和环境成功集成。不幸的是，即便在开发组内架构协作都很少发生，更遑论外部的需求方了。
