中台战略一
最近公司进行战略调整，组建中台部门，《企业IT架构转型之道-阿里巴巴中台战略思想与架构实战》这本书是中台理论鼻祖之作，赶紧拜读
对照此书，结合当前公司状况，进行一些思考记录
中台概念
因为中台的火起，所以现在不管是不是中台，在谈论时，都会带上中台两字，如业务中台，技术中台，数据中台
这些中台名词有人追捧，就有人抵制。何为中台，必须关联业务，所以只会有业务中台，而技术中台，只能称为技术平台，不能叫技术中台，数据中台也一样，只能称为数据平台
那到底什么是中台呢？
不阐明定义，无从说起，但要定义，又无话可说，做人难啊
在这本书中，也没有给出具体定义，但给出了一些指导，尤其以阿里共享服务体系为实例，介绍了前因后果
中台是居于前台与后台之间，“厚平台，薄应用”架构
中台战略：构建符合DT时代的更具备创新性和灵活性的“大中台，小前台”的组织机制和业务机制
这儿说明中台是两种机制的结合，一是组织，二是业务
组织
先讲组织，很多观点认为中台战略是否成功，关键在于组织协调能力
为什么呢？中台是场革命，利益之地，生死之地；淘宝，天猫这些核心业务，凭什么要把核心业务流程置于共享服务中心的手上，卧榻之下岂容他人酣睡
这时，说教式让他人从公司整体发展去考虑，唐僧都不行，除非大家都遁入空门了
因此在公司组织架构层面通过组织架构调整，物理拆分独立的中台部门
这点，当前公司也是这样处理的，成立了中台部门，但架构还是不够全部，组织架构的调整毕竟关系重大，涉及各大业务线，利益分配，以及现在员工都业务的理解程度(公司没有几个人对业务清清楚楚的)，此间种种吧，估计后面还会再调整
对于中台部门的人选，是个考虑点，比如是选新招员工呢，还是对业务了解的员工呢？新老员工搭配？
像我们现在的情况，公司本身对业务了解的人就不多，都需要支撑各个业务线，如果抽调到中台，那势必影响业务线的正常需求迭代；但中台都是新兵蛋子，怎么办呢？而且每根业务线的项目代码现状也不大相同，如果说从每根业务线抽人，那中台人员估计要超标
从大局考虑，中台战略是重要的，但也不成一时之就，所以不从现有业务线抽人，都是新人，对业务都一知半解人
业务
在公司业务层面通过把公共能力下沉为服务，并做好服务连接，赋能业务部门
现在公司业务线比较多，拿主业务讲，公司从成立开始到现在，已经建立了4个版本，1.0，2.0，3.0，4.0每一版本都是前一版本的改进版本，但迁移都没有成功
这其实算是技术债的大成本，比如一般一家公司主产品只会有一个版本，但现在公司是个奇特，在一个版本无法继续扩大业务时，没有考虑迭代优化，而是从零起炕，而且是to B，客户迁移也没能平滑过渡，然后就出现了个个版本都在线，个个版本又都不完整，又有重复部分
除了主产品版本多，还有各个子业务线，重复业务多了，这也岂不是中台的绝佳实施场所
此种方式，也正是“烟囱式”系统建设模式
SOA服务重用
SOA很多年前已经火了，但现在虽着微服务的新起，很多人已经忘记了SOA，但作者认为微服务不过是SOA的不同实现而已
中心化
SOA是在2004年左右提出的，当时正是各大公司“烟囱式”系统建设模式，各个系统需要交互时SOA架构相对点对点直接互通，很好地避免了因为服务提供者服务接口的变化需要调用此服务的服务调用者都进行修改的现象
非中心化
在企业内部，运行中心化，是没有问题的；但到了互联网，中心化不合适了。
- 服务调用方式的不同带来业务的响应和扩展性
- 雪崩效应束缚了中心化服务框架的扩展能力
服务重用
SOA的核心价值就是服务重用
但在实施过程中，会变成系统的集成，就类似ESB模式，各系统间交互带来成本
像公司现在的“烟囱式”模式，或者“项目制”方式，必然实现不了服务重用
“烟囱式”模式，就是之前说的各个系统都是独立的
“项目制”方式，就是有新的客户，都是建立项目，从原来的项目复制代码，再开始开发一些定制需求
像我司是财税行业的，涉及到开具发票
比如现在要统计发票数量，怎么办？需要去各个系统分别统计，再求和
数量的数据模型很简单，只有一个int。但还有复杂的
比如想查看一下当天开出的所有发票呢？此时怎么办，虽然发票主体差不多结构，但在各个系统中，各个系统的发票领域数据模型是不一致的，那通过ESB来结合时，必须就会涉及数据转换，此时就是SOA实施成了集成的样子，而不是服务重用
最好就是形成共享服务：发票中心。所有的发票模型统一
打造中台
在阿里中台这本书中，大多数内容都是为什么需要中台，以及共享服务体系在阿里的成长，几处技术难点，是1到N的过程，而0到1的过程却没有阐述
像我司各个业务都在进行中，怎么去抽取公共服务，并下沉成中台呢？
虽然有类似DDD样的理论支撑，但实施起来难度很大，也许正是各家难处都不一样，所以作者没有去阐述
这个中台战略系列中，将一一道来，详细记录下0到1的过程，作为后期总结与反省的依据