重构技术架构首先解决组织架构-阿里云开发者社区

开发者社区> 阿里云MVP> 正文

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

简介: 我通过重新理顺人员组织架构,在几乎毫无代价的情况解决了技术架构的问题,从简单的单机应用演变到中台架构

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

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

图片 1.png

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

图片 1.png

  1. 第二阶段:中型企业
    这个阶段就是老板熬过了生存阶段,开始有些小钱可以招聘员工,但这时没算富裕,会在淘宝买些便宜的系统支持一下业务,自己的系统服务器扩容一下,从2核买到了4核
  1. 第三阶段:大型企业
    这个阶段老板正式暴富了或者拿到融资了,公司人员越来越多,有了部门的概念了,每个部门也需要管理,业务也需要更多功能模块来支持,这时候我们系统就需要集群来支持更多的访问量和业务量了,如下图:

图片 1.png

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

图片 1.png

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

真实案例

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

犯下的错误:

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

就是这两个错误,导致我们的业务线在接下来一个月直接瘫痪,泰国、日本需求线全面告急;一个跟了我很长时间的开发兄弟直接跟我提离职;bug数量直线上升;产品总监跑来跟说,再这样下去,产品团队就不玩了。
但问题又来了,中台架构如果不这样做,让不熟悉业务的人去做重构我完全不放心,业务层给的压力特别大,不然现有架构支持不了几大需求方的并发。
后面我发现是我方法论错误了,我没有太多甲方的经验,那我应该怎么做呢?后来,我把业务拆了出来进行了分析!图片 1.png

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

  1. 支付对接业务 占比30%
  2. 机柜业务 占比20%
  3. 营销活动 占比20%
  4. 代理合作商 占比10%
  5. 日常报表 占比20%
    于是我对组织架构做了微调

图片 1.png

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

欢迎大家扫码进群领取物联网最新资料以及获取一手直播资讯

image.png

版权声明:本文中所有内容均属于阿里云开发者社区所有,任何媒体、网站或个人未经阿里云开发者社区协议授权不得转载、链接、转贴或以其他方式复制发布/发表。申请授权请邮件developerteam@list.alibaba-inc.com,已获得阿里云开发者社区协议授权的媒体、网站,在转载使用时必须注明"稿件来源:阿里云开发者社区,原文作者姓名",违者本社区将依法追究责任。 如果您发现本社区中有涉嫌抄袭的内容,欢迎发送邮件至:developer2020@service.aliyun.com 进行举报,并提供相关证据,一经查实,本社区将立刻删除涉嫌侵权内容。

分享:
+ 订阅

阿里云最有价值专家,是专注于帮助他人充分了解和使用阿里云技术的意见领袖。

官方博客
官网链接
精彩专题