一年之计在于春，适合做点儿总结与计划什么的。有时候与非IT行业的人聊天，人家问：架构师是做什么的？我会说，把软件行业比作建筑行业，主要是做三件事。一是平地起楼，画图的。二是旧楼改建，拆迁的。三是高楼失火，救火的。
一、平地起楼
【场景】
公司开展新业务新项目，在没有技术债务的情况下，建设新应用系统。可能是初创企业刚开始研发应用系统，可能是中型企业开展新业务于是成立了新的项目，可能是大型企业成立了新的业务部门甚至分公司子公司要建设全新的应用系统。
【HOW】
没有技术债就相当于没有包伏，轻装上阵自然满心欢喜。万丈高楼平地起，地基最重要。但此时处于业务探索的阶段，往往不会有非常清晰的业务需求与发展方向。要想打好地基，最重要的是分析业务需求，了解市场的发展变化，洞察行业发展趋势。知道竞争对手是怎么做的，评估未来的变化节点。唯有这些前期调研工作做好，才能真正开始架构设计，才能设计出一个刚好满足当前需求的低成本架构方案，而且地基扎实，预留了合适的扩展点能满足未来一段时期内扩展需要。
二、旧楼改建
【场景】
旧楼改建，说的是一个软件系统因为业务需求出现了较大变化，难以基于原有的架构扩展功能，核心架构难以支撑未来的发展，需要进行架构演变。这时候需要有V2.0.0了，即变动应用系统版本号第一个数字。
如同一个工厂厂房，因为环境变化或者政策变化或者战略转移，厂房要改成旅馆。这原来的空间布局显然是不能满足的，不是软装能解决，需要重新硬装，增加房间隔间房内还要增加卫生间，还得重新排布各种水电设施。
【HOW】
这类工作场景是比较扎手的，通常都是有着大量的技术债，撇不开的包袱。但这类场景却是架构师很常见的。一般没有那么多的子公司成立，没有那么多的全新业务开拓。但市场变化多端，往往不是我们预想的路线。有下面三种思路。
1. 新建系统
这种思路看似最容易其实最难。新建系统在建设期间不会阻断原有业务的连续性，但如何无缝切换呢？原有的系统经过了多年的缝缝补补，很多补丁是为了适应业务变化，来不及规范设计而匆忙上线的。但它体现的却是业务精华。新建系统在抛弃技术债的同时，也容易遗忘这些重要的补丁。所以功能测试的难度是非常大的，难以保障业务无缝切换。
2. 重构系统
这种思路也不好做，难在立项与宣导。通常业务为了追赶市场变化，总是有做不完的功能需求，很难挤得出资源立项重构。如果没有正确的宣导，让业务团队充分理解系统架构重构的价值，即便辛辛苦苦的做成了也得不到业务团队的好评，一旦上线后有重要BUG更是麻烦缠身。唯有争取到业务团队的理解、上级领导的支持，多方协力才能做好。
3. 演化系统
何谓演化系统？实质是随着每一次的敏捷开发功能迭代，逐步的改变系统架构。没有专门的立项，但系统架构总是经常性的微小的改变自身适应市场变化。感觉系统架构没什么大的变革，总是1.0的版本，但其实不知不觉的便完成3.0、5.0的升级。润物细无声，正是所谓的“能缝缝补补过三年的架构师才是好架构师”。这种思路对架构师的要求是最高的。一是要持续追踪，跟着开发团队了解业务需求，跟着开发团队评审代码。二是要保持对业务的敏感性，当市场发展变化时，能及时意识到对系统架构的可能冲击。三是要及时找出一条可行的架构演变之路，就是如何从当前的系统架构历经多次迭代后到达规划的系统架构。四是要精通项目管理，知道如何将架构演变之路拆成一个个小的技术点，明确这些技术点的依赖关系，安排到每一次的功能迭代中跟随上线。五是要有良好的沟通能力，让开发团队信任。因为上面拆出来的技术点有的时候不在业务团队的功能需求里，可能需要“夹带私货”跟随上线。如何说服他人是需要相当功底的，需要长期建立起来的技术专家的威信。六是要适时的宣传演讲，不然事情虽然默默的做成了，却无人欣赏，就像《鶡冠子·卷下·世贤第十六》扁鹊的大哥那样，最终不利于工作。
三、高楼失火
【场景】
高楼失火，说的是一个软件系统经过多年的开发维护后，已经变得比较复杂了。突然某一天运行出现了故障，需要及时的解决问题，恢复运行，找到根因，根治问题。
【HOW】
现在流行分布式架构风格、微服务架构风格，一个复杂的软件系统往往不会只部署在单一机器上。会涉及的也不只是代码Bug，问题也可能是出现在硬件、网络、流量、虚拟机、上下游等。面对复杂的系统故障，往往需要架构师的坐镇。
首先，快速恢复，减少影响
要想做到快速，单靠临场发挥是不够的。更重要的是平时做好各种监控预防措施，做好应急预案。这要求架构师熟悉各种技术，要全面。还得拥有临场指挥的能力，紧急时刻可以协调各方面的行动。与业务团队沟通，及时通报进度，让其放心。协调运维团队，让其提供监控数据，协助分析。巧妇难为无米之炊，监控措施如同人的眼睛耳朵，如果看不见听不着也就难以分析。如果确定是软件系统的问题，心中能浮现出系统的各个组件及其部署，协调开发人员进一步的分析、定位、修复。
其次，定位根因，根治问题
有些简单的故障通过机器重启就可以恢复业务运营，但如果不能定位根因，就被各种不确定性威胁，随时可能再爆发一波。根治问题除了在信息系统上修复Bug，增强自愈能力，还要从规范流程上改进，避免再次踩进相似的坑。
四、六大技能要求
1、软件开发能力：编程语言、技术框架、中间件、协议原理。是作为软件开发工程师实现具体功能的能力。
2、建模设计能力：熟悉UML、PPT等工具。归纳、演绎、抽象的能力。
3、需求分析能力：熟悉业务领域行业知识及其发展趋势。例如要想设计账户系统，得先学学会计。
4、沟通演讲能力：销售与布道的能力。
5、项目管理能力：推动技术方案落地的执行能力。
6、技术决策能力：技术判断力，是作为技术管理者的核心能力。基于在技术领域与非技术领域的长期积累，对技术方案的可行性、风险、投入产出的判断。包括但不限于技术选型、利益平衡。
