转载

重构技术架构首先解决组织架构

技术架构来源于人员组织架构

过去两年做了不少大型的中台项目,什么是中台?这篇文章就不多说了,自行百度一下,总而言之最后我得出了一个结论——企业什么样的人员组织架构就会什么样的系统技术架构。我们先以下一幅图:

重构技术架构首先解决组织架构

1、第一阶段:小型企业

这个阶段就是企业的初创阶段。公司就几个员工,甚至就老板一个员工,开发是他,销售是他,人事是他,搬运也是他。这个时候需要配置系统就是典型的单机应用,特点:简单快速、易于开发、易于部署;重点是---省钱!

重构技术架构首先解决组织架构

2、第二阶段:中型企业

这个阶段就是老板熬过了生存阶段,开始有些小钱可以招聘员工,但这时没算富裕,会在淘宝买些便宜的系统支持一下业务,自己的系统服务器扩容一下,从2核买到了4核

3、第三阶段:大型企业

这个阶段老板正式暴富了或者拿到融资了,公司人员越来越多,有了部门的概念了,每个部门也需要管理,业务也需要更多功能模块来支持,这时候我们系统就需要集群来支持更多的访问量和业务量了,如下图:

重构技术架构首先解决组织架构

4、第四阶段:

这个阶段我就不多说了,整个公司至少拿到B轮或者已经有三位数以上的员工了,也猜到我会说用微服务或者更高大上中台的架构。

重构技术架构首先解决组织架构

前面说的都是些大概,我直接说我的案例吧,我在上一家公司(乙方)时候已经做了不少中台项目,自以为对这种架构已经有些了解了,直到遇到到了这家企业(甲方)实际做需求的时候才遇到这些坑。

真实案例

业务背景:

我们这企业主要做移动共享充电宝业务,和国内几大x电不一样,我们是做国际化,需求方在日本、中国台湾、泰国、中国香港地区,所以看起来简单的租借逻辑变得异常复杂,因为仅仅是第三方支付公司就十几家,支付方式积分、优惠卷也十几种。而且这也是一个国际化团队,因为日本的需求非常特殊,所以他们有自己的开发,由于领导层原因而我们的核心代码又不能给日本开放,所以每次上线都要有专人去拿日本方的代码合并到我们master分支里面去。

犯下的错误:

  • 为了做中台,直接把负责每个地区的核心开发抽取出来做中台
  • 在没有调理好开发的组织架构前,直接安排开发任务

就是这两个错误,导致我们的业务线在接下来一个月直接瘫痪,泰国、日本需求线全面告急;一个跟了我很长时间的开发兄弟直接跟我提离职;bug数量直线上升;产品总监跑来跟说,再这样下去,产品团队就不玩了。

但问题又来了,中台架构如果不这样做,让不熟悉业务的人去做重构我完全不放心,业务层给的压力特别大,不然现有架构支持不了几大需求方的并发。

后面我发现是我方法论错误了,我没有太多甲方的经验,那我应该怎么做呢?后来,我把业务拆了出来进行了分析!

重构技术架构首先解决组织架构

经过讨论和调研,每次新需求都离不开主要几大的业务模块开发:

  1. 支付对接业务 占比30%
  2. 机柜业务 占比20%
  3. 营销活动 占比20%
  4. 代理合作商 占比10%
  5. 日常报表 占比20%

于是我对组织架构做了微调

重构技术架构首先解决组织架构

不知道有没有发现我把组织架构从业务线拆出来以后,我的中台架构,自然就出来了,过程中我没有重构过任何代码,只是慢慢把业务从业务线剥离出来,增加了一个接口层,而且几乎没有增加过多的代价和成本,这就是我的结论,改变技术架构首先解决组织架构。

本文作者:子祖

阅读原文

本文为云栖社区原创内容,未经允许不得转载。

原文  https://segmentfault.com/a/1190000020191949
正文到此结束
Loading...