年终将至，聊聊架构的主持人郭蕾向我催稿，今年我工作有变动，作为架构师我今年没有特别的沉淀和积累可以拿得出手的干货和大家分享，但是答应郭蕾在先，我该分享点什么呢？何不来一篇2016年度架构思考总结，把我近期对技术型组织转型提升的一些思考心得总结出来分享给大家，既作为自己的总结沉淀，又可以输出给感兴趣的人学习，岂不是一举两得。况且如果这次分享成功的话，说不定以后每年可以来一篇20xx年度架构思考总结。
本文假设针对提供SaaS服务的软件研发型组织，其它类型涉及IT系统的组织也可从中获得借鉴。本文属于个人思考心得总结，如有理解不当偏颇之处，还请各位不吝指教。
先上三个图，分别说明企业，特别是成长型企业，所面临的普遍困局，下面是第一个：
图1：方型轮子困局1
这个图对于从大公司（如BAT）跳到初创和成长型公司的童鞋来说感触特别深刻，你跑到随便一家刚刚熬到B或C轮融资的互联网公司，看到这里的童鞋还在用非常落后的技术（方型轮子）支持业务，童鞋们很忙很累，加班超严重，但是效率和产出很低，你忍不住搬出在大公司已经司空见惯的高端技术（圆形轮子，如云计算、容器、微服务和DevOps等一堆天花乱坠的新技术和理念），结果得到的反馈却是：“对不起，我们赶业务太忙没时间升级”，然后你就只能无语了！
图2：方形轮子困局2
第二个图是另一个版本的方轮子困局，在大部分企业里头也是非常常见的。一方面，受到市场竞争的压力，企业中拉车一方（业务方和管理层）和推车的一方（员工），都迫于赶业务而无法停下来做系统改进提升，尽管提升的技术手段存在企业内部（车里的圆形轮子）。第二种可能的情况是，企业一线的推车员工可能是意识到企业面临的效率问题的，但是企业的拉车方由于长期脱离生产一线，看不清业务支撑系统的效率问题，无法从上到下推进系统提升改进。
图3 谷仓困局
第三个图称为谷仓（Silo）困局，反映企业内部各自为政，缺乏领导力、信任和合作所造成的困局。
上图反映一个典型的场景：
-
业务方领导层：我们的增长太慢了，为啥我们不能比竞争对手更快推出产品？
-
产品管理层：我们现在不招新人了，技术团队不给力，一大堆项目堆着无法推进，研发团队是不是出了问题？
-
产品研发团队：没有按时交付项目不能怪我们，我们要求的机器运维一直拖着没有到位，我们的运维太挫，要换个头了。
-
运维团队：客户都气疯了，我们大部分时间在救火保证系统稳定性，不要再丢东西给我们了，我的团队天天熬夜都嚷嚷要离职…
谷仓困局还有一个典型的问题是，企业团队倾向自立门户，重复造轮子（基础设施）、造成大量重复劳动，企业效率低下，成本骤增和浪费严重。
对谷仓困局描述最生动的要数小说《凤凰项目：一个IT运维的传奇故事》，推荐有兴趣的童鞋进一步阅读（参考附录1）。
针对这些困局，背后的深刻原因是什么？我们该如何破局？下面是我近期的三点学习和思考。
1. 要事第一和压强原则
Stephen R.Covey博士的《高效能人士的七个习惯》（附录2）中的第一个习惯称为要事第一，Covey还为我们提供了一个时间管理的重要工具~四象限工作法则，把事情按照重要性和紧迫性分在四个象限里头，我们的注意力应该主要放在和重要性相关的两个象限里头。
A. 重要但不紧迫：通常是一些基础性长期重要的事情，比如抢占市场的新产品规划，人才引进和培养，基础设施建设，系统提升型项目等。
B. 既重要又紧迫：通常是一些火烧眉毛的事情，比如系统故障救火，网站紧急bug修复等。
这两个象限的时间分配是门平衡的艺术，理想70%的时间应该放在A象限，即未雨绸缪象限，20%的时间放在B象限，用于应急。A象限做好了，B象限事件的概率会变小。如果一个公司大部分时间在B象限救火，通常说明是A和B两个象限的时间分配失衡或者倒挂了，需要关注投资那些长期重要但不紧迫的事情。
图4：四象限工作法
实力上处于劣势的企业如何与优势企业竞争？华为公司的实践表明，要实行“压强原则”，也就是将有限的资源集中于一点，在配置强度上大大超过竞争对手，以求重点突破，然后迅速扩大战果，最终达到系统领先。华为公司总裁任正非先生曾用坦克和钉子的比喻说明“压强原则”。坦克重达几十吨，却可以在沙漠中行驶，原因是宽阔的履带分散了加在单位面积上的重量；钉子质量虽小，却可以穿透硬物，是因为它将冲击力集中在小小的尖上，二者的差别就在于后者的压强更大。
同样的道理应用到企业战略上，就有了“压强原则”。华为公司靠“压强原则”突破了万门数字程控交换机，突破了GSM全套移动通信设备，突破了光网络设备……几乎所有的重大产品，最初都是这么突破的。公司规模小时如此，如今公司规模大了，每年的研发费用超过了100亿元，但在项目资源配置上，还要继续贯彻“压强原则”。
在《华为基本法》中是这么描述的：“在成功关键因素和选定的战略生长点上，以超过主要竞争对手的强度配置资源，要么不做，要做，就极大地集中人力、物力和财力，实现重点突破”。
抓不住重点，克制不住做新产品的冲动、妄图全面开花，常常是制造方轮子和谷仓困局的一个主要诱因。 初创或成长型公司，本身资源匮乏，研发能力相对较弱，更需贯彻“压强原则”，应抓住重点，集中资源各个击破。
2. 系统思考、反馈环和试错文化
我们大部分人都有在高速或高架上堵车的经历，因为两辆车的事故，常常造成整个高速的流量急速下降（用我老婆的话说是龟速）甚至瘫痪。
图5：瓶颈理论
上面这个图很形象的展示了企业管理中知名的瓶颈理论（也称约束理论），整个系统的吞吐是由系统的瓶颈决定的，例如上图，瓶颈处的容量是4，那么整个系统的吞吐量是4。在瓶颈上游的优化，上图中上游的容量是6，只会造成上游的进一步拥堵和积压，而在瓶颈下游的优化，上图中下游的容量是6，则对整个系统的吞吐没有任何帮助，反而造成资源的闲置和浪费。
IT运维管理畅销书《凤凰项目》（附录1）的作者Gene Kim在调研了众多高性能IT组织后总结了支持DevOps运作的三个原理(The Three Ways: The Principles Underpinning DevOps)（附录3），可以认为是系统改进提升的一般性原理，见下图：
图6：支持DevOps运作的三个原理
原理一：系统思考(Systems Thinking)
，开发驱动的组织，其能力不是制作软件，而是持续的交付客户价值。价值从业务需求开始，经过研发测试，到部署运维，依次流动，并最终以服务形式交付到客户手中。整个价值流速并不依赖单个部门（团队或个人）的杰出工作，而是受整个价值链最薄弱环节（瓶颈）的限制，所以局部优化通常是无效的，反而常常导致全局受损。
Gene Kim特别指出，在瓶颈之外的任何优化提升都只是幻象。Any improvements made anywhere besides the bottleneck are an illusion. — Gene Kim
在研发型组织中，常见的系统瓶颈如运维机器资源提供（Provisioning）缓慢，发布流程繁琐容易出错，遗留系统耦合历史负担重，研发基础平台和框架薄弱等等。这些瓶颈点是研发型组织特别需要关注和优化的。
原理二：强化反馈环(Amplify Feedback Loops)
，过程改进常常通过缩短和加强反馈环来达成，原理二强调强化企业和客户之间，企业组织团队间，流程上和系统内的反馈环（如图7）。没有测量就没有提升（图8），反馈要以测量和数据作为基础，通过反馈数据来优化和改进系统。强化反馈环在技术上的一些主要手段包括大数据分析和监控告警等。
图7：强化反馈环
图8：没有测量就没有提升
