从系统架构来看TI资源共享

我们构建的那些"烟囱"

"烟囱" 是什么？

系统架构中的"烟囱"（川字架构）

简化举例：以打车平台举例

业务线

架构形态

每个业务线都是独立的系统。

   

为什么会有这么多"烟囱"

   

业务（产品）的发展：

多条业务线同时快速开阔市场。

业务线直接外购/外包。

各个业务线功能定位模糊，团队人员反而有非常明确的划分。

代码上的"黑箱"

开发一个新系统，传统思维逻辑："自己写的代码，才放心"。

通过"黑箱"的方式加强自己的"重要性"，降低自己的机会成本。

数据混乱又独立：

混乱：

都在使用同一个库的同一张表。

独立：

每个业务自身对同一个数据同一张表中的数据含义与定义又不通。

组织架构行程墙壁且墙壁太厚：

举例： 打车平台

出租车事业部

快车事业部

顺风车事业部

人员被划分为清晰的"党派"，"党争"被用作"平衡"的主要手段。

相互进行"零和博弈"竞争"资源"，而不是引入更多"资源"。

   

应该是什么样的架构？

   

给川字加一笔 ：

山字架构

   

看山还是山：

业务的事情交给业务，技术的事情回归技术。

当组织架构中只有一个IT部门的时候，回归我们的本质。

技术的对业务的支撑方式。

但是！业务有国界，而技术无国界。

认清业务与技术的本质关系： 多对一！

多个业务部门 对应的是一个IT技术部门！

当组织中多个业务线清晰独立。

业务线独立必然就是相关可共享内容减少。

通过新的业务线来沉淀"技术资产"。

要求技术负责人需要有较高的"视觉"和"认知"

   

构建"中台"？

   

谁然现在都在说"拆中台""做薄中台"。但是中台的概念和方式还是需要继承的。

大概分层：

UI层

业务层

基础层

概括分层：

业务AUI层

各个***平台（中心）：相同领域模块组织在一起，以领域整体的形式对外提供服务。

通用层（基础层）：抽象设计，模块预备通用能力，能够支持多个相近需求。

持续上浮与下沉：

总体思维： 变化性相关的上浮，非变化性的下沉。

变化的更加贴近用户层。

不变化的更加靠拢基础层。

   

摸清楚"中台"的本质与可达到的效果，弄清楚"中台"中的业务中心是个什么东西。

   

IT资源共享？

   

明确概念：

IT部门在消耗研发经费的同时所产出的"系统"等，都应该是企业资产的一部分。

IT部门的"资源" 不仅仅包括："研发经费"、"IT人员"、"管理人员"、"基础设施（服务器，网络等硬件资源）"，也包括"代码"、"功能模块"、"系统"等。

只有将这些资源重新看待，才会有共享共用的可能。

共享的是什么？

本质是"沉淀"是"底蕴"。

   

最后

思想的转变大于形式上的转变。