架构师在团队里面的角色很独特。他们不是项目经理，却确定着何时以及如何交付软件。他们不是产品经理，却要确保软件能够满足业务目标。他们也编程，但做得更多的是架构设计，而不仅仅是写算法和代码。架构师是软件开发的核心角色，肩负着与众不同的职责。
大多数架构师都是技术出身，会编程、能设计高效的算法、懂测试和部署软件，这些都是架构师必备的技能，但要从程序员成长为架构师，还需要承担一些新的职责。
定义问题
软件架构设计是一门以人为本的学科。软件的所有利益相关方都有着自己对项目的预期，因此架构师要与产品经理、项目经理一起协作，共同定义软件项目的需求与目标。
许多团队是由产品经理定义功能特性。功能需求当然很重要，但是架构师更关注质量属性。除了定义系统的质量属性，架构师还要密切关注那些影响架构设计方向的约束和特性。
在定义问题的同时考虑架构，才能确保开发出大家都满意的系统。
拆解系统，分配职责
架构师只有把软件系统进行分解，才能制定出满足质量属性和其他系统需求的策略。例如，可以指定一个组件实现用户注册功能，指定另一个组件负责识别猫的图片；这样可以分配不同的团队开发不同的模块；从而将数据读取部分从数据写入部分剥离出来，使得软件系统具备更高的可靠性、可用性、可伸缩性。
分解系统的重要性还不仅仅体现在上述方面。小对象往往更容易推演、测试、设计。当然，将系统打散之后，要确保能把它们组装回去，协同工作。
纵观全局
所有软件系统都存在于客观世界的大背景下，比如与之交互的用户、开发团队，硬件平台，甚至包括最初的开发目的，理想情况下，软件架构应该能与外围环境和谐共生。
从全局角度考虑整体系统意味着架构师需要处理的不仅仅是技术问题。人员、过程、业务需求以及其他技术和非技术因素都将影响最后的软件系统。即便是一个小小的设计决策也可能产生深远的影响。架构师必须高瞻远瞩、纵观全局，而不能只着眼于局部细节的设计。
软件设计是一个不断“挣扎”的过程，在想要达成的目标与必须接受的现实之间寻找平衡。这意味着必须深思熟虑并做出取舍。
学会取舍
假设客户要求软件具备高可用性，能够响应99.9%的请求。我们可以引入冗余元素来提高可用性。这样设计倒是简单，但有一个问题：必须采购双倍的硬件，从而成本也翻倍了。这样做就是用更高的成本换取高可用性。
放弃一些东西换取其他东西，这在软件开发中很常见。架构师要找出备选方案，再与各方一起协商如何取舍最合理。
软件系统的分解和切割也不一定那么“干净利落”。这就需要折中，也可能会犯错误。在开发系统的过程中，还会不断给架构引入技术债务。
管理技术债务
所有的软件都有技术债务。架构师知道系统是如何分解的，他们关注大局，指导划分出来的各个模块协调工作，还要将业务需求与技术决策放在一起考虑。只有这样，架构师才能游刃有余地管理技术债务。
技术债务如同一条鸿沟，一边是当前的软件系统设计，另一边是你想要的、能持续产生价值的设计。技术债务的多少可以通过填平鸿沟所需的代价衡量。技术债务就像是软件系统的副产品。出色的软件开发团队会有意引入技术债务来实现更快的交付，后续再逐步地进行偿还，从而持续地创造价值。
架构师应该指明技术债务，帮助利益相关方决定采取何种措施管理它们。
提升团队的架构技能
架构师是整个团队的导师和顾问。设计炫酷却无人理解的架构毫无意义。作为团队的架构专家，有责任向团队分享知识，让他们成功地开发出软件。
架构师应该适时地传授设计技巧和架构理念。为了传道，可以与组员结对设计，可以写文档授业、解惑，还可以提出建设性地批评。把架构设计当做一项社交活动，让团队成员都参与到设计过程中来，这是最有效地提升团队架构技能的方法。技能的提升对于团队的成败将起到决定性的作用。
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌抄袭侵权/违法违规的内容， 请发送邮件至 举报，一经查实，本站将立刻删除。
