首先，了解一下软件架构师的解释，百度百科上，在介绍软件架构师时，是这么说的，软件架构师是软件行业中一种新兴职业，工作职责是在一个软件项目开发过程中，将客户的需求转换为规范的开发计划及文本，并制定这个项目的总体架构，指导整个开发团队完成这个计划。主导系统全局分析设计和实施、负责软件构架和关键技术决策的人员软件架构师与软件设计开发的。
这与室内设计师有着一些相似之处，在梦想改造家中，设计师通过与客户交流，了解了客户的需求，并结合实际情况将房屋改造，并同时指导其它相关工作人员共同完成。软件架构师与设计开发人员的不同在于伸缩性和抽象程度的增加以及作出正确设计决策意义的增强。软件架构是通过一个全局的观点，宏观的视角来理解软件系统作为一个整体如何工作。
我们可以了解到，对于软件架构师的能力有如下几点要求
⒈对项目开发涉及的所有问题领域都有经验，包括彻底地理解项目需求，开展分析设计之类软件工程活动等
⒉具备领导素质，以在各小组之间推进技术工作，并在项目压力下做出牢靠的关键决策；
⒊拥有优秀的沟通能力，用以进行说服、鼓励和指导等活动，并赢得项目成员的信任；
⒋以目标导向和主动的方式来不带任何感情色彩地关注项目结果，构架师应当是项目背后的技术推动力，而非构想者或梦想家（追求完美）；
⒌精通构架设计的理论、实践和工具，并掌握多种参考构架、主要的可重用构架机制和模式（例如J2EE架构等）；
⒍具备系统设计员的所有技能，但涉及面更广、抽象级别更高； 活动确定用例或需求的优先级、进行构架分析、创建构架的概念验证原型、评估构架的概念验证原型的可行性、组织系统实施模型、描述系统分布结构、描述运行时刻构架、确定设计机制、确定设计元素、合并已有设计元素、构架文档、参考构架、分析模型、设计模型、实施模型、部署模型、构架概念验证原型、接口、事件、信号与协议等。
以及软件架构师的主要任务有
⒈领导与协调整个项目中的技术活动（分析、设计和实施等）
⒉推动主要的技术决策，并最终表达为软件构架
⒊确定和文档化系统的相对构架而言意义重大的方面，包括系统的需求、设计、实施和部署等“视图”
⒋确定设计元素的分组以及这些主要分组之间的接口
⒌为技术决策提供规则，平衡各类涉众的不同关注点，化解技术风险，并保证相关决定被有效的传达和贯彻
⒍理解、评价并接收系统需求
⒎评价和确认软件架构的实现 专业技能
一般来说，在大多数项目中软件架构可分为两个阶段，架构的定义，然后是它的交付。
软件架构的定义
架构的定义过程看起来非常简单明了。你需要做的是理解需求并设计一个系统来满足需求。 但实际上并没有那么简单，根据你不同的做法，软件架构的职责之间差距很大，以及如何认真看待自己的职责而定。
管理非功能性需求
软件项目经常陷入问用户要求是什么，什么是他们想要的功能，但很少问他们需要什么非功能性需求(或系统质量)有时候。“这个系统必须很快”，这太主观了。
非功能性需求如果要满足的话需要明确，可度量，可获得以及可测试。大多数非功能性需求本质上是技术层面的而且经常对软件架构有很大的影响。理解非功能性要求是架构师职责非常重要的一个部分。
架构定义
捕捉到了非功能性需求后，下一步是开始思考如何去解决这些问题并义它的架构。公平的说每个软件系统都有一个架构，但并不是每个软件系统都有一个定义好的架构，这正是问题的关键。
架构定义过程让你想清楚你打算怎么在兼顾需求和限制的情况下把问题解决好。架构定义是将结构，方针，原则和领导力引入软件项目的技术层面。定义架构是作为软件架构师的工作，但是从头开始设计一个软件系统和对已存在的系统扩展是相当不同的。
技术选型
技术选型通常是一个有趣的练习，但它也有公平的挑战。因为你需要综合考虑成本、许可、供应商关系、技术策略、兼容性、协作性、支持、部署、升级的政策以及最终用户环境等各方面。
接下来的问题就是这些技术是否能真正有用。技术选型是彻头彻尾的风险管理;复杂性或不确定性太高的时候要减轻风险，当有机会或利益的时候要引入风险。
技术决策需要考虑多种因素，而且所有的技术决策需要被检查和评估。这包含软件项目的主要组成部分乃至开发中引入的类库和框架。如果定义一个架构，你还需要有信心认为选择这项技术是正确的。同样在技术评估中也还是存在开发新系统和向现有的系统增加新技术的不同点。
架构评估
评估一个架构是成功的：它满足非功能性需求，而且为其他部分的代码提供必要的基础，并为解决和存在的业务问题提供足够的平台。
软件的一个最大的问题就是它复杂而抽象，导致很难从UML图或代码本身去设想出运行时的特性。在软件开发周期中我们进行了很多不同类型的测试，这样我们能够有信心我们发布的系统在推出时能够正常运行。
我们为什么不对架构也这样做呢? 如果能够测试你的架构，那你就可以证明它是有效的。如果你能尽早做到这一点，你就能减少项目失败的风险，而不是简单地希望一切都好。
架构协作
任何一个软件都不是与世隔绝的，需要很多人理解它。 包括从需要理解和切入架构的直接开发团队到其他对安全性、数据库、运营、维护、支持等有兴趣的人。
要想让一个软件项目成功，你需要和所有的系统干系人紧密协作来保证架构和所在的环境很好的集成。不幸的是，现状是与开发团队的架构协作很少发生，更不要说外部干系人了。
软件架构的发布
对于架构的发布也是同样，成功的软件项目参与程度的不同，也决定了软件架构职责的不同。
拥有全局的视角
为了把一个架构成功地实现，我们需要具有全局的视角并把贯穿软件开发生命周期的愿景加以宣传与推广，必要的话在整个项目中展开和完善，并对成功发布负责。
如果如果你定义了一个架构，参与并保持不断发展架构才是有意义的，而不是选择把它传递给一个“执行小组”。
领导力
拥有全局的视角是技术领导的一个方面，但是还有其他事情在软件项目发布阶段需要做。
这包括承担责任、提供技术指导、作出技术决策以及具有权力作出这些决定。作为架构师，你需要确保每件事都被考虑到，而且团队在朝着正确的方向持续前进。
软件架构师职位是需要内在领导力的，虽然这听起来很明显，但很多项目团队并没有获得他们所需要的技术领导，因为架构师认为一个成功的发布并不一定是他们所关注的问题。
教练和指导
在大多数软件开发项目中，教练和指导经常不被重视，团队成员得不到他们需要的支持。
虽然技术领导是引导整个项目，但个人也经常需要帮助。除此以外，教练和指导提供强化技能的方式，帮助提升职业生涯。这应该是软件架构师份内的事，而且指导团队架构和设计与帮他们解决代码问题是截然不同的。
质量保证
即使是世界上最好的架构和领导，很糟糕的交付也足以让一个具备其他成功条件的项目失败。质量保证在架构师职责中占很大一部分，但这并不只是简单做代码检查。
比如，你需要一个基线来确保，这意味着引入新的标准和工作实践。从一个软件开发的角度来说，这可能包括代码标准、设计原则和源码分析工具甚至于使用持续集成，自动化单元测试以及代码覆盖工具。
可以说大多数项目质量保证做的并不够，所以你需要搞清楚什么是重要的并给予它足够的保证。对于我来说，一个项目的重要部分包括架构上的重点，关键、复杂或高度可见的业务。你要关注实效并认识到你并不能保证一切，要知道做总比不做好。
设计、开发和测试
软件架构师的最后一件事是设计、开发和测试。作为一个实际动手的架构师并不是需要你每天都要写代码，但是它的确意味着你一直在参与项目，而且积极帮助打造和交付它。
说了这么多，为什么每天写代码不应该成为一个架构师职责的一部分呢?大多数架构师都有写代码的经验，因此让这些技能保鲜是有意义的。而且，架构师能体会到团队里其他人的痛苦和感受，这样能让他们更好地理解他们的架构从开发角度看是什么样的。
很多公司有政策阻止软件架构师从事写代码，因为架构师“去做那些廉价的工作太贵了” ，这显然是个错误的态度...如果架构师已经花了那么多时间精力为项目做架构，何必从政策上不允许他们多走一步来帮助项目达到最终的成功呢?
当然，有些情况下卷入代码级别并不现实。比如，一个大的项目通常意味有一个更大的“全局观” 来考虑它，而且可能有时候你就是没有时间。但一般来说，一个写代码的架构师比只在旁边观望要更高效和快乐。
总之，为软件系统的架构作出贡献和自己负责定义它有很大的区别，拥有持续的、跨不同领域的技能、知识和经验构成了软件架构的职责。跨越软件开发者和架构师的界限取决于你自己，但是首先你要明白你的经验水平，才能开始架构师之旅的第一站。
参考网址：
