程序员的终极之路—系统架构师！放心吧，好多人都做不了的
这篇书评可能有关键情节透露
架构师所扮演的承上启下的角色非常关键，尤其是在大型组织里，部门之间业务语言不同、观点不同、目标不同甚至冲突。掌握相关信息或专业技能的人没有权力做出决策，而决策者却缺乏相关信息。彼此间误解的“大山”往往无法翻越。
在本文开始之前，我想问大家一个问题：程序员职业生涯的顶点是什么？
如果你的脑海中首先蹦出来的还是“高级工程师”、“首席科学家”之类的字眼，那么我想说：Too naive！小白才会一直搬砖敲代码，牛人都是设计程序实现流程，架构产品！
俗话说：不想当将军的士兵，不是好士兵。将军是更优秀的士兵，同理，架构师作为程序员中的将军，也就要求比程序员更加“优秀”。这个“优秀”不是指谁的代码敲的快又好（当然，对于架构师来说，也是要会敲代码），而是指具有足够的技术深度、广泛了解行业内的主流技术，能很好地设计架构和技术选型。同时还能协调指挥团队内的成员，跨部门和产品、运营、项目经理等人员做及时有效的沟通，在完成本职的架构工作外，协调好项目中各干系人的关系，做出合理的分工，最终完成全部工作。
可以说架构师在任何一家IT公司里都有着极为重要的地位，是团队的灵魂人物！
架构师现状
近几年，架构师成为国内外发展最为迅速、最被看好的岗位之一，是企业急需的高级技术人才。美国的一项调查显示，架构师在最高薪资待遇、最具发展前景的排名中位列第一名。国内也有类似的调查，同样显示架构师是最抢手的技术人才。（据说在比尔·盖茨的众多称谓中，他更偏爱“首席架构师”。同样，在网易创始人丁磊名字前，也有“首席架构师”这样的称谓。）
对于企业来说，架构师就是灵魂的创造者，大厂对系统架构师给出的薪酬也更能证明架构师的重要性。
架构师，顾名思义，第一职责就是在软件设计阶段做好软件「骨架」的设计。他们需要把产品的需求翻译成软件工程的设计文档，确定各个系统与模块的边界，评估系统的量级。从概念上讲，架构师是负责设计整体架构的，从需求到设计的每个细节都要考虑到，使设计的架构尽量符合效率高、开发简便、维护方便、升级简单等要求。从本质上讲，架构师应当是一个成熟的、丰富的、有经验的、有良好教育的、学习快捷、善于沟通和决策能力强的人。
然而，尽管架构师在企业中发挥着日益重要的作用，但国内很多架构师仍处在两难的境地：一方面从事着架构师的本职工作，另一方面还同时要兼顾程序开发。于是乎，他们在不同公司扮演的“角色”也各不相同。
但他们扮演的常见角色就是“架构师”么？答案是否定的！
架构师是什么？
有时候，和明确定义某个事物是什么相比，定义它不是什么更容易。针对架构师在公司中经常扮演的4种角色，我们可以简单拆分说明：这究竟是不是架构师的职责？消防员：很多管理人员都期望，架构师能随时分析并解决任何突发的危机（因为架构师对当前系统有足够全面的了解）。然而，时刻都在忙着“救火”的架构师根本就没有时间去做真正的架构，也无法发现产品架构上面的设计缺陷。
资深开发人员：开发人员常常会把架构师这个角色作为其职业生涯（和薪资水平）的下一个目标。但其实，成为架构师和成为明星工程师完全是两条不同的路线，架构师需要有更广的知识面，包括组织和战略方面的能力，工程师则需要专攻可运行软件的交付，两者虽没有高低之分，但工作职责有很大不同。
项目经理：架构师必须能够并行处理多个不同但相关的主题，他们在做决策时也需要考虑项目时间表、人员配备以及所需技能。因此，上层管理者经常会通过架构师获取有关项目的信息和决策，但这会让架构师陷于两难，因为架构师虽然为管理层提供的项目信息和决策也是有价值的工作，但它毕竟不是架构师的主要职责，而是项目经理的职责。
科学家：架构师要才思敏捷，要能够从系统和模型的角度进行思考，还需要为具体项目和业务计划制定决策。这常常让人误解首席架构师与首席科学家的角色定位，尽管这两个角色的界限很模糊，但首席工程师更强调架构师除了撰写文档外还需要做其他事情。科学家常常把事物理论化和复杂化，而架构师的工作则是化繁为简。
毫无疑问，以上这些“角色”都不是架构师！那么架构师到底是什么呢？
架构师——变革促进者！
一言以蔽之，架构师是“变革促进者”！在大型企业里，架构师往往能填补一项重要的空白：他们既能在项目上和技术人员密切地工作和沟通，也能在不丢失信息本意的前提下，向上层管理者传达和解释技术主题。换句话说，架构师能理解公司的经营战略，并且能将其转化为技术决策（尤其是在企业转型过程汇总，架构师必不可少）。在企业中，一个常见的错误是：“住在”顶层豪华套间里的管理者只看见并重视位于楼层上半部分的架构师。相反，很多开发人员或者技术架构师都认为所谓的“企业”架构师没多大作用，因为他们认为，架构师压根就不写代码，全部都是“嘴皮子”功夫，而非实战派。
过去，IT 决策和经营战略几乎没有关系：IT 只被看作附加品，它的主要参数是成本。但是，如今的业务目标和技术选择之间的联系已经变得越来越直接了，即使是“传统”的业务也是如此。高层管理者把架构师看作企业转型的关键推动者，而“发动机房”的员工也很开心有人真的理解和欣赏他们的工作。用一两句话就将业务需求转换成了应用程序和基础设施设计，这一事实凸显了架构师“承上启下”的重要性。
一直都有段子调侃说：国内做程序员，30岁左右就得转型，不然就会被嫌弃。
毕竟每一年，都有大量高学历的年轻人不断涌入程序员行业，他们朝气蓬勃，快速吸收着行业里最新的知识；而30岁左右的行业前辈，如之前并无可靠的沉淀，自然是会焦虑不安，转型也就提上了日程。
对于工作多年的程序员而言，日后的职业发展无非是继续专精技术、转型管理或者晋升架构师三种选择。而管理职位数量有限，技术在不断变化，所以转型架构师是首选。
那么如何才能成功转型架构师呢？
在这里推荐给大家一本“神书”——架构师应该知道的37件事！ 之所以会称它为“神书”，是因为这本书的作者很强——格雷戈尔·霍培 （Gregor Hohpe ）是 ArchitectElevator CXO 云转型顾问，并为新加坡政府科技局提供技术决策咨询。曾任谷歌（新加坡）技术总监兼 CTO、谷歌（日本）高级软件工程师、Allianz 公司首席架构师、ThoughtWorks 集成架构师。
在IT领域有20多年的经验积累，拥有3项美国专利。与人还合著过《企业集成模式》一书！在企业转型和管理方面的经验可谓是异常丰富！
不同于其他书籍，这本书里所有的主题都是作者20多年来在 IT 领域里作为创业合伙人、系统集成员、技术顾问、作家、互联网软件工程师和大型跨国组织的首席架构师的经验积累、呕心之作。同时作为首席架构师的作者也深知沟通的重要性，针对其他图书数据化严重、理论化语言生硬的问题，作者在这本书中特意避免了此种现象，采用了诙谐幽默的故事化语言，让人轻易就能读懂并了解作者意图。
因此，这本书不仅适合项目管理人员和 CTO 门阅读，也适合软件开发人员和为转型架构师做准备的小白程序员阅读。通过阅读这本书你将获得以下内容：分别对应在帮助大型企业进行 IT 转型的过程中，首席架构师必须高效处理的 5个方面：
- 企业或 IT 架构师的角色和能力
- 架构工作在大型企业中的价值
- 与各种干系人的沟通
- 对组织结构和系统的理解
- 对传统组织进行转型
这本书并不是纯粹的技术书，而是旨在讨论架构师应该如何开拓视野，从而更好地在大型组织中发挥一技之长。本书并不会教你如何配置 Hadoop 集群，或是如何使用 Docker 搭建容器编组，而是教你如何构思大型架构，如何确保你的架构对经营战略有益，如何利用供应商的专业能力，以及如何与高层管理者沟通。
我相信，通过阅读本书，你将获得的远远不止如书名所言的“37件事”，你获得的将会是更大的视野、思考问题的角度和与人沟通的方法，这些对于一个合格的架构师来说才是至关重要的！
