一家公司的组织架构，能够维持单纯状态的时间大概也就初创的那么1-2年，这之后要么公司倒闭，要么业务扩展最终养活自己。相伴而生必然带来公司内部新势力的崛起，这时候“部门”之于CEO、就像是诸侯之于周天子，是一种维持公司各方势力、凝聚一致对外的工具。公司要想活下去就要不断的适应市场、而随着业务的转变也就带来了组织架构的不断变更调整，最近的例子像是2天前的雷军内部信
工作十几年、看着国家企业信息化喊了十几年，期间即待过项目外包型公司——给传统企业做IT项目，也待过产品型公司——直接面向互联网C端用户，还待过业务型公司——传统行业的IT支持部门，甚至自己创过业……
除开创业那阵业务线简单、怎么快怎么来以外，其他所有公司都会有一个叫做“基础研发部”，或其他类似名字的部门，职能范围大体上包含：
- 统一公司底层IT技术架构：这样出现项目进度紧张、人力缺乏的时候也好做人员间的互调；
- 提供基础服务：把一些公共的业务逻辑抽象剥离出来，做成公共服务来提供，减少二次开发的人力成本浪费；
- 探索新技术新方向：对市场上的热点新技术进行探索、进行技术储备。
按照这样理想化的设计来看，公司组织架构会是像下面这样的划分：
整个IT部门被拆分成专注于基础服务开发的“基础研发部”和业务线直接对接的业务线团队，事实上这也是目前我所待过的绝大部分公司IT部门组织架构划分方式：既依托于业务线配备专职团队、再以基础研发作为底层技术支持。
不过别看图上基础研发部的图形占据了大部分面积，但真正掌握着公司优势资源、集中了核心人力的还是各明星业务线的IT小团队，无他、离业务近KPI好考核，自然钱也多，最后往往基础研发部就只能在夹缝中求生存，疲于应付各业务线的定制化底层服务不说，最后还被人说响应不及时、出工不出力，或者更强势一点儿的团队干脆就脱离了基础研发部的依赖，直接拉出来单干，也就是实际上的架构演变成了下面的样子：
基础研发部被架空成了一个可有可无的部门，而各业务线团队则发展成为了一个个独立的庞然大物，一个比较明显的例子就是当你发现同一家公司的APP，其登录账号还不能通用的时候多半就是这种情况了。
所以说一家公司最终采用的IT架构，就是这家公司实际组织架构在现实中的投影。曾经一度以为，或许只有一个比较强势的IT部门领导，以行政的手段才能破开这种重复建设、严重资源浪费的局面，直到前一阵翻见下面这本书：
从书中描述来看，至少阿里也是经历过这种基础研发部门尴尬定位的困惑期的，并且当整个公司体量上来，到了不得不进行变革的地步，而最终阿里给出的方案是“大中台、小前台”，也就是像下面这样：
一个个服务中心是作为公司整体业务重叠部分的一个抽象，比如：用户中心、商品中心等，也就是所谓的“中台”，而上面直接业务支持的IT团队则是基于这些服务中心来做不同的业务流程组合以满足不同的产品需求，相对于那种简单粗暴的“基础研发部”划分来说，阿里的中台划分主要有如下的好处：
持续活力的保持：传统的基础研发部划分最大的问题是脱离业务，很多需求更像是自己想象出来、或是业务IT团队消化的二手需求，完成的东西要么是推广难、要么就是任务性质的缺乏激情；服务中心的概念则是把服务当成一个产品来持续运营跟进，更加专注，也就更能给人带来发展的成就感。
破解人力短缺：往往单一的基础研发部承接的底层业务多而杂，很难做出业绩将自己的部门发展壮大，看起来什么都可以做成底层服务，但又缺乏人力进行跟进，从而导致一个恶性循环；服务中心的好处就是将基础部分更加细化，确实复杂、重要的业务就投入更多的人力跟进、否则可以是少量人力。
加快业务相应速度：之前可以看到跟业务更近的团队往往更能发展壮大，重要的一点原因就是业务都需要快速的响应实现速度，而疲于奔命的基础部门响应不过来自然就给业务团队有了自己拉人单干的理由，当这些底层基础服务都有一个快速相应团队来持续推进迭代的话，一个很小的业务团队也可以完成复杂的业务组合，一方面可以保持前端团队的轻量、快速试错，另一方面确实也保证了业务迭代的快速。
对于阿里的这套方案虽然还没有亲自执行实施过，但至少从书面上来看如果建立起来后是一个可以完成自我循环的生态，不会太依赖于IT领导的个人修养。