微信号:infoqchina

介绍:有内容的技术社区媒体

技术不应成为业务的工具,一个资深架构师的思辨

2016-07-22 07:33 陈昌
有人说,驱动技术发展的动力是业务的增长。而本文作者却认为,技术不应成为业务的工具。对此,你怎么看?

如果大家认为一个互联网企业的收益这个事情是归业务或产品经理管,那很遗憾事情就发生了:这个技术研发团队估计被业务驱动走,演变成技术成为业务的工具。

导致技术被产品牵着鼻子走这个现象,个人觉得主要原因在于架构师太关注技术而忽略业务本质,交付的是系统架构或应用架构,而不是可产品化的架构设计。

而我觉得收益简单分为二种:1、如何赚钱 2、如何省钱,为此这几年我一直尝试用这样思路进行架构设计,希望真正意义上做到技术驱动业务。本文作者陈昌,携程高级架构师。

在过去几年里我一直从事架构设计相关的工作,我发现一个有意思的现象,在企业初创阶段或者研发部门想做大做强的时候,架构师的作用相对比较明显,因为他可以根据产品的需求进行功能性与非功能性的设计,然后进行系统设计考虑如何运维、HA、扩展、减少系统之间的依赖等一系列工作,最后和研发经理们和高级工程师过架构评审,识别架构风险和技术选型。

然而,当业务的需求发生了变化或者产品经理想做第二期时候,架构师又开始进行上一阶段的复用,开始修改接口契约文档、扩容机器等,演变成一个文档“高手”

此时架构师忽略了一点:旁边的研发经理们一直盯着看或学,当他们发现一个新的PRD(产品需求文档)过来,架构师原来就这些“套路”,此时研发经理也会做些工作了,加上有些架构师也不参与编码,久而久之,研发会觉得架构师这个角色有点不接地气,可有可无。同时,架构师对业务知识不够了解,容易被产品和研发“排挤”,此时发现架构师仅仅起到是布道传播的作用。

导致这个现象的原因,我个人认为:

  • 架构:输入产品PRD、输出设计文档(架构师为产品打工,项目成功取决去产品经理能力)。

  • 缺少一个“钉子”(譬如:业务框架)植入到研发和业务中。

  • 过度重视技术而没有去思考产品收益点在什么地方。

如何提升架构师在研发地位,个人觉得:

  • 首先,架构应该是和商业对齐,甚至是业务生态圈对齐。

  • 其次,在商业中挖掘收益点。

  • 最后,将这些收益点设计一个可产品化的架构。

架构组织

当然作为作为一个架构师,他首先要知道,架构有哪些(如图):平台架构、业务架构、系统架构、应用。

架构、数据架构(离线架构+实时架构)、基础架构、技术架构、峰值架构,目前自己所关注点在哪里,最好是全部了解并且实践过,这样设计出的架构生命周期会更久。

自上而下的架构思想

我以自己的工作场景为例来介绍。因为旅游是一个非常复杂的业务领域,所以接下去通过其中一个案例,表达自上而下的架构思想。当时自由行SBU这个部门刚刚成立的时候,其实我的重心和时间并不在业务需求细节中,而是不断和各条产品线的业务产品负责人了解他们的愿景和业务价值,最终将每条产品线商业价值整合一起形成一个业务生态圈(如图)。


旅行前

我举一个生活中例子来阐述下这个商业架构:

当你想买个商品,有2个商场(东方商场和第一百货),你为什么会去其中一个商场,可能朋友推荐、也有可能你要的商品在某一个商场里面,商场其实就是流量的入口就被抽象成销售端(门户)。

旅行中

在你购物中,突然接到一个电话或一条短信通知,说旁边的商场搞活动全场7折,这个时候你可能被这个优惠信息转移另外商场去了(优惠平台+消息通知+会员管理)。

  1. 在新的商场里面,你开始从货柜上挑选商品,这个过程就抽象成 Shipping模块。

  2. 当你相中心仪的商品,会问营业员库房是否有你要的规格的商品,当确认有货,将商品放入购物车,商品的库存被扣了一件(锁库存),这个过程就抽象成Booking-commite模块。

  3. 推着车购物车走向收银台去支付,这时可能你会将购物车的商品还回柜台(主动释放库存)也可能新增商品,到了收银台最终确认好商品进行支付(可能信用卡么余额导致失败),这个过程就抽象成Booking-cofirm。

  4. 客户走了后,剩下事情就是商家处理环节:盘点库存、采购商品、供应商费用结算等,这个就抽象一个backend。

旅行后

当用户购物成后,她可能向自己朋友对商品进行评价,当好评情况下,他的朋友会问他哪里购买的,这样促使一个新的客户引向了那个商场(闭环)。

应用架构

在这个业务架构中,关键服务包括user、product、shopping、booking、order。如图是根据业务架构设计的应用架构(这里不详细说明,不是本文重点)。


构建业务生态圈后,我认为接下去最重要一步:如何识别收益?

在生态圈图中,每个有收益的地方我都以绿色字体标识出来,在这里我就举其中1个进行说明。

booking(预定服务)

在早期,由于旅游产品形态分为二种:固定行程、非固定行程,为产品形态量身定做2套预定接口,2组研发维护,2位产品经理。虽然消耗资源比较多,但使用过程比较稳定(不同的商场有各自预定服务)。

从技术角度,统一性、可维护性,架构师一定想办法将2个接口合并成一个。这个想法肯定没有错,但存在一个问题:如何说服业务,要给研发几个月时间进行技术改造,效果是从二个接口变成一个接口。相信很少有业务会答应,将他们稳定的预定进行改造。

From API To CRS

换个角度,我们思考如何让一个预定接口带来一些商业价值(收益)或解决业务痛点:

如果这个预定服务给其他的部门或供应商对接,不就可以按每笔订单提成佣金?

每个渠道接入预定接口,统一数据后知道哪些产品是热门、哪些渠道是高产量的、什么产品在什么时候是旺季,不就可以做产品定价(不同时候不同价格)和渠道资源分配?

业务想新增N个产品形态,不需要再考虑新增N个预定接口,不就可以让业务关注点转移到多接新渠道上去了,不就可以让业务响应市场变化更加敏捷?

让孤岛(线下旅行社门店)连接到一个中央系统上,进行产品管理、发布、销售,不就可以覆盖更多的产品,提高产品竞争力,节约业务人工成本?

越想越觉得应该设计成一个中央预定系统(CRS)产品来覆盖所有的预定需求。

这样不仅解决了业务痛点同时带来更多的订单量,又实现了技术可维护性、统一性、独立性。

无独有偶,公司一个海外部门研发了国际线路产品,但是觉得预定这块非常复杂,询问是否接入我们预定服务,并提出按每笔订单返佣。

一个系统是否被更多人使用,不仅仅看他是否高可用、是否可扩展,更多还是看该系统可以带来多少的收益。

小技巧:架构设计可以大而全,但实施过程最好是简化,化整为零,以最快速度先上线,通过迭代方式不断的完善。(船小好调头)

设计应用架构后就进入是系统物理部署(如图):

总结

  1. 架构师应该是让产品经理有更多的选择而不是约束。

  2. 架构最好是和商业愿景(收益)对齐。

  3. 我心目中架构应该像App Store那样,设计成一个容器,只要符合平台 规范和协议就可以发布上去,关注是应用本身是否work,其他交给平台完成。

  4. 收益可以通过多种形式表现:提高产量、节约成本、挖掘用户价值、加强服务质量、优化用户体验、快速响应市场变化等。

  5. 架构:将产品、技术、运营有机的结合起来。

延展阅读(点击标题):


【云原生沙龙】从微服务着手,讨论如何建立起“快速试错”和“自动化第一”的DevOps文化,确保微服务策略的成功。也将用案例说明如何利用Spring Boot和Spring Cloud来降低工作的复杂性,缩短投产期,从而提高阿里、票务大师以及网飞这样的企业的生产效率。8月13日全天,北京车库咖啡,戳阅读原文限时免费抢位!



本文系【聊聊架构】原创首发,未经授权谢绝转载。

 
InfoQ 更多文章 海量用户下,微信的复杂网络与应用实践丨视频PPT下载 技术人的职场晋升指南:如何从20万到50万,再跨越到100万?大咖说回放 开心网创始人程炳皓:八年开心网,一个成功的“失败”案例 IT职业技能图谱(全套13张官方高清下载) 不谈架构,看看如何从代码层面优化系统性能!
猜您喜欢 让你编程得到升华:开发者需知的10个真理 从编程语言、算法、项目等层面深谈读研如何提高技术 统计学思考导论读书心得 当我们谈论 Bot 的时候,我们在谈论什么 写让别人能读懂的代码