架构师应该如何判断技术演进的方向?

开发 架构
对于架构师来说,判断业务当前和接下来一段时间的主要复杂度是什么就非常关键。判断不准确就会导致投入大量的人力和时间做了对业务没有作用的事情,判断准确就能够做到技术推动业务更加快速发展。那架构师具体应该按照什么标准来判断呢?

互联网的出现,不仅加快了技术圈的快速发展,而且改变了普通人的生活方式。近观这10年的技术发展,可以说是目不暇接,大的方面有云计算、大数据、人工智能等。细分的领域有NoSQL、NOde.js、Docker容器化技术等。对于技术人员来说,技术的快速发展当然是一件好事,毕竟在这些百宝箱中有了更多的可选工具,另外也可以通过学习业界先进的技术来提升自己的技术实力。但对于架构师来说,除了这些好处,却多了“甜蜜的烦恼”:面对层出不穷的新技术,我们应该采取什么样的策略呢?

架构师在进行技术选型时,可能会面临以下的诱惑或挑战:

  • Docker虚拟化技术很流行,我们要不要引进?
  • 公有云计算这么流行,我们的业务要不要上云?
  • 我们公司的技术水平跟业界顶尖的公司相比,还相差太远,要不要投入一些人力尝试一些新技术框架?不然招聘的时候没有影响力!

关于以上几个问题的回答,基本上可以分为以下几个典型的派别:

  • 潮流派:潮流派的典型特征就是对新技术比较热衷,紧跟技术潮流,当有新技术出现时,迫切想将新的技术运用到自己的项目或产品中。
  • 保守派:保守派的特征正好和潮流派相反,他们对于新技术有着很强的戒备心,稳定压倒一切,喜欢用一种技术闯荡天下,说的直白一点,保守派就是想拿着一把锤子解决所有的问题。
  • 跟风派:跟风派与潮流派不同,跟风派不是跟着技术潮流,而是跟着竞争对手的步子走。简单地说,竞争对手用了什么技术,咱么就用什么技术,竞争对手没用咱们就等等再看。

下面我们来看一下不同的派别可能存在的问题。

1.潮流派

首先,新技术需要时间成熟,如果刚出来就用,此时新技术还不怎么成熟,实际应用中很可能遇到各种“坑”,自己成了实验小白鼠。其次,新技术需要学习,需要花费一定的时间去掌握,这个也是较大的成本;如果等到掌握了技术后又发现不适用,则是一种较大的人力浪费。

2.保守派

保守派的主要问题是不能享受新技术带来的收益,因为新技术很多都是为了解决以前技术存在的固有缺陷。就像汽车取代马车一样,不是量变而是质变,带来的收益不是线性变化的,而是爆发式变化的。如果无视技术的发展,形象一点说就是有了拖拉机,你还偏偏要用牛车。

3.跟风派

可能很多人都会认为,跟风派与“潮流派”和“保守派”相比,是最有效的策略,既不会承担“潮流派”的风险,也不会遭受“保守派”的损失,花费的资源也少,简直就是一举多得。看起来很美妙,但跟风派最大的问题在于如果没有风可跟的时候怎么办。如果你是领头羊怎么办,其他人都准备跟你的风呢?另外一种情况就是竞争对手的这些信息并不那么容易获取取,即使获取到了一些信息,大部分也是不全面的,一不小心可能就变成邯郸学步了。即使有风可跟,其实也存在问题。有时候适用于竞争对手的技术,并不一定适用于自己,盲目模仿也可能带来相反的效果。

既然潮流派、保守派、跟风派都存在这样或者那样的问题,那架构师究竟如何判断技术演进的方向呢?我们需要从以下两个方面来综合考虑。

一、技术演进的动力

这个问题之所以让人困惑,关键的原因还是在于不管是潮流派、保守派,还是跟风派,都是站在技术本身的角度来考虑问题的,正所谓“不识庐山真面,只缘身在此山中”。因此,要想看到“庐山真面目”,只有跳出技术的范畴,从一个更广更高的角度来考虑这个问题,这个角度就是企业的业务发展。

无论是代表新兴技术的互联网企业,还是代表传统技术的制造业;无论是通信行业,还是金融行业的发展,归根到底就是业务的发展。而影响一个企业业务的发展主要有3个因素:

  • 市场、技术、管理,这三者构成支撑业务发展的铁三角,任何一个因素的不足,都可能导致企业的业务停滞不前。

在这个铁三角中,业务处于三角形的中心,毫不夸张地说,市场、技术、管理都是为了支撑企业业务的发展。我们可以简单地将企业的业务分为两类:一类是产品类,一类是服务类。

产品类:360的杀毒软件、苹果的iPhone、UC的浏览器等都属于这个范畴,这些产品本质上和传统的制造业产品类似,都是具备了某种“功能”,单个用户通过购买或者免费使用这些产品来完成自己相关的某些任务,用户对这些产品是独占的。

服务类:百度的搜索、淘宝的购物、新浪的微博、腾讯的IM等都属于这个范畴,大量用户使用这些服务来完成需要与其他人交互的任务,单个用户“使用”但不“独占”某个服务。事实上面,服务的用户越多,服务的价值就越大。服务类的业务符合互联网的特征和本质:“互联”+“网”。

对于产品类业务,答案看起来很明显:技术创新推动业务发展!

例如:

  • 苹果开发智能手机,将诺基亚推下王座,自己成为全球智能手机行业的新王者。2G时代,UC浏览器独创的云端架构,很好地解决了上网慢的问题;智能机时代,UC浏览器又自主研发全新的U3内核,兼顾高速、安全、智能及可扩展性,这些技术创新是UC浏览器成为了全球最大的第三方手机浏览器最强有力的推动力。

为何对于产品类的业务,技术创新能够推动业务发展呢?答案在于用户选择一个产品的根本驱动力在于产品的功能是否能够更好地帮助自己完成任务。用户会自然而然地选择那些功能能更加强大、性能更加先进、体验更加顺畅、外观更加漂亮的产品,而功能、性能、体验、外观等都需要强大的技术支撑。例如,iPhone手机的多点触摸操作、UC浏览器的U3内核等。

对于“服务”类的业务,答案和产品类业务正好相反:业务发展推动技术的发展!

为什么会出现截然相反的差别呢?主要原因是用户选择服务的根本驱动力与选择产品不同。用户选择一个产品的根本驱动力是其“功能”,而用户选择一个服务的根本驱动力不是功能能,而是“规模”。

例如,选择UC浏览器还是选择QQ浏览器,更多的人是根据个人喜好和体验来决定的;而选择微信还是Whatsapp,就不是根据它们之间的功能差异来选择的,而是根据其规模来选择的。当“规模”成为业务的决定因素后,服务模式的创新就成为了业务发展的核心驱动力,而产品只是为了完成服务而提供给用户使用的一个载体。以淘宝为例,淘宝提供的“网络购物”是一种新的服务,这种业务与传统的到实体店购物是完全不同的,而为了完成这种业务,需要“淘宝网”“支付宝”“一淘”和“菜鸟物流”等多个产品。随便一个软件公司,如果只是模仿就能发展出类似的产品,只要愿意投入,半年时间就可以将这些产品全部开发出来。但是这样做并没有意义,因为用户选择的是淘宝的整套网络购物服务,并且这个服务已经具备了一定的规模,其他公司不具备这种同等规模服务的能力。即使开发出完全一样的产品,用户也不会因为产品功能更加强大而选择新的类似产品。

以微信为例,同样可以得出类似的结论。假如我们进行技术创新,开发一个耗电量只有微信的1/10,用户体验比微信好10倍的产品,你觉得现在的微信用户都会抛弃微信,而转投我们的这个产品吗?我相信绝大部分人都不会,因为微信不是一个互联网产品,而是一个互联网服务,你一个人换到其他类微信类产品是没有意义的。

因此,服务类的业务发展路径是这样的:提出一种创新的服务模式→吸引了一批用户→业务开始发展→吸引了更多用户→服务模式不断完善和创新→吸引越来越多的用户,如此循环往复。在这个发展路径中,技术并没有成为业务发展的驱动力,反过来由于用户规模的不断扩展,业务的不断创新和改进,对技术会提出越来越高的要求,因此是业务驱动了技术发展。

其实回到产品类业务,如果我们将观察的时间拉长来看,即使是产品类业务,在技术创新开创了一个新的业务后,后续的业务发展也会反向推动技术的发展。例如,第一代iPhone缺少对3G的支持,且只能通过Web发布应用程序,第二代iPhone才开始支持3G,并且内置GPS;UC浏览器随着功能越来越强大,原有的技术无法满足业务发展的需求,浏览器的架构需要进行更新,先后经过UC浏览器7.0版本、8.0版本、9.0版本等几个技术差异很大的版本。

综合这些分析,除非是开创新的技术能够推动或者创造一种新的业务,其他情况下,都是业务的发展推动了技术的发展。

二、技术演进的模式

明确了技术发展主要的驱动力是业务发展后,我们来看看业务发展究竟是如何驱动技术发展的。

业务模式千差万别,有互联网的业务(淘宝、微信等),有金融的业务(中国平安、招商银行等),有传统企业的业务(各色ERP对应的业务)等,但无论什么模式的业务,如果业务的发展需要技术同步发展进行支撑,无一例外是因为业务“复杂度”的上升,导致原有的技术无法支撑。

按照复杂度分类,复杂度要么来源于功能不断叠加,要么来源于规模扩大,从而对性能和可用性有了更高的要求。既然如此,判断到底是什么复杂度发生了变化就显得至关重要了。是任何时候都要同时考虑功能复杂度和规模复杂度吗?还是有时候考虑功能复杂度,有时候考虑规模复杂度?还是随机挑一个复杂度的问题解决就可以了?

所以,对于架构师来说,判断业务当前和接下来一段时间的主要复杂度是什么就非常关键。判断不准确就会导致投入大量的人力和时间做了对业务没有作用的事情,判断准确就能够做到技术推动业务更加快速发展。那架构师具体应该按照什么标准来判断呢?答案就是基于业务发展阶段进行判断,这也是为什么架构师必须具备业务理解能力的原因。不同的行业业务发展路径、轨迹、模式不一样,架构师必须能够基于行业发展和企业自身情况做出准确判断。

责任编辑:未丽燕 来源: 今日头条
相关推荐

2015-12-09 15:16:03

架构师京东架构

2021-12-28 07:20:43

架构师技术架构

2021-12-29 06:58:41

架构师数据应用

2021-02-01 07:40:55

架构师阿里技专家

2019-07-23 18:15:26

技术大数据数据库

2012-08-04 16:02:00

架构师

2018-03-12 15:21:20

2018-04-17 10:53:51

2015-12-23 10:50:24

运维OPS运维架构师

2011-04-07 16:20:24

软件架构师架构师架构

2009-12-17 17:40:45

架构师

2017-10-18 15:19:23

架构师技术开发

2012-06-17 12:58:04

架构师架构

2015-11-11 11:09:41

微软Azure架构师容器技术

2017-10-10 19:43:44

架构 搭建 技术

2010-02-06 15:14:36

ibmdw架构师

2020-08-24 08:50:12

架构师TL技术

2015-08-12 10:10:44

2018-12-29 09:58:19

码农架构师Leader

2021-01-29 09:18:09

技术研发架构
点赞
收藏

51CTO技术栈公众号