开发和架构的界限难以捉摸。有些人告诉你它根本不存在，架构只是开发者们所做的设计过程的简单扩展。 另外
一些人认为这是一个鸿沟，它只能由那些做到高度抽象，而且不会陷入实现细节的开发者才能跨越。通常，在这
两个极端的观点中间某处有个可操作的平衡点；不论如何，怎么从开发转换为架构师都是个有趣的问题。
经常被用来区分软件架构和软件设计开发的关键几点包括 伸缩性和抽象程度的增加以及作出正确设计决策意
义的增强。软件架构是通过一个全局的观点，宏观的视角来理解软件系统作为一个整体如何工作。
即使这能够帮助区分软件开发和架构，它并不能帮助理解某人如何从开发提升到架构。 并且，它也不能帮助
识别谁能够成为一个好的软件架构师，如果你想雇人的话你如何去寻找他们以及你是否是一个软件架构师。
经验可以判定但你需要更深入地了解
要成为一个软件架构师并不是一夜之间或者一个职位的提升就能简单达到的。 这是个职责，而不是头衔。这
是个进化的过程，你将会逐步得到担当这个职责所需的经验和信心。
当你寻找架构师时，需要考虑各方面的素质，他们过去的经验往往是他们有能力担当这个职责很好的判断。
由于软件架构师的职责是多种多样的，所以你需要再深入了解他们在不同领域的参与度，影响力，领导力和责任
感。一般来说，在大多数项目中软件架构可分为两个阶段，架构的定义，然后是它的交付。
软件架构的定义
架构的定义过程看起来非常简单明了。 你需要做的是理解需求并设计一个系统来满足需求。 但实际上并没有
那么简单，根据你不同的做法，软件架构的职责之间差距很大，以及如何认真看待自己的职责而定。如下图所示，
这个职责的架构定义部分，可以进一步细分成不同的元素。
1.
管理非功能性需求：软件项目经常陷入问用户要求是什么，什么是他们想要的功能，但很少问他们
“
”
需要什么非功能性需求（或系统质量）有时候，干系人会告诉我们， 这个系统必须很快 ，但是这太
主观了。非功能性需求如果要满足的话需要明确，可度量，可获得以及可测试。大多数非功能性需求
本质上是技术层面的而且经常对软件架构有很大的影响。理解非功能性要求是架构师职责非常重要的
一个部分，但假设这些需求是什么并不一定是对他们的挑战。你见过多少系统真正需要 24x7 的运行呢？