【架构设计】37-架构师应该如何判断技术演进的方向?

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

架构师三种派别的分析:

架构师基本上可以分为这三种:

  • 潮流派

    潮流派的典型特征就是对于新技术特别热衷,紧跟技术潮流,当有新技术出现时,迫切想将新的技术应用到自己的产品上。

    例如:

    • NoSQL很火,要大规模的切换到NoSQL。
    • 大据据很牛,将MySQL切换到Hadoop。
  • 保守派

    与潮流派完全相反,对于新技术抱有很强的戒备心,稳定压倒一切,已经掌握了一门技术,就一直用这门技术,不管理任务业务场景。

    • Mysql我们用了很久了,业务用MySQL,数据分析用MySQL,报表也是用MySql。

    • java语言很熟悉,业务用java,工具用java,平台也用java

  • 跟风派

    跟风派与潮流派不同,这里的跟风不是指跟着技术潮流,而是指跟着竞争对手的步子走。判断技术的发展看竞争对手,竞争对手用了我们就用,竞争对手没有用就在等等。

不同派别的不同做法本质上是价值观的不同:潮流派的价值观是新技术肯定能够带来很大的收益。稳定派的价值观是稳定压倒一切。跟风派的价值是别人用了我也用。

不同派别可能存在的问题。

  • 潮流派

    • 新技术需要时间成熟,如果刚出来就使用,新技术还没有成熟,实际使用过程中会出现很多的“坑”,自己成了小白鼠。
    • 新技术需要花费时间学习,需要一定的时间掌握,这也是一个较大的成本。如果等掌握了又发现不合适,那也是一个较大的浪费。
  • 保守派

    保守派主要的问题是无法享受新技术带来的收益。因为新技术很多都是为了解决以前存在的固有缺陷。很多时候带来的收益不是线性变化的,而是爆炸式变化的。

  • 跟风派

    跟风派的最大问题在于如果没有风可以跟的时候怎么办。另外,就是竞争对手的信息并不那么容易获取,即使获取到信息,大部分也是不全面的,一不小心就成了邯郸学步。

    即使有风可跟,有时候适合竞争对手的技术,并不适合自己,盲目模仿可能带来相反的效果。

技术演进的动力

究竟架构师该如何判断技术演进的方向呢?为什么很多人对于这个问题很困惑,在于无论是潮流派、保守派、跟风派都是站在技术本身的角度来考虑问题的。只有跳出技术的范畴,从一个更广更高的角度来考虑这个问题,这个角度就是业务发展。

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

Alt 企业发展三要素

业务处于三角形的中心,市场、技术、管理都是为了支撑业务的发展。

我们可以把业务简单分为二类:一类是产品类、一类是服务类。

产品类:如UC浏览器、IPONE手机,这些产品本质上和传统产品类似,都具有某种功能,单个用户通过购买或者免费使用这些产品来完成自己相关的业务,用户对于这些产品是独占的。

服务类:百度的搜索、淘宝的购物、新浪的微博等都属于这个范畴,大量的用户使用这些服务来完成需要需要与他人交互的任务,单个用户使用但不独占某个服务。事实上:服务的用户越多,服务的价值越大。

对于产品类服务,答案看起来是:技术创新推动业务发展。因为用户选择一个产品的根本驱动力在于产品的功能是否能够更好的帮助自已完成任务。用户自然而然会选择功能更加强大、性能更加先进、体验更加流畅、外观更加漂亮的产品。而功能、性能、体验、外观都需要强大的技术支撑。

而对于服务类的业务,则是业务推动技术的发展。在于用户选择服务的驱动力与用户选择产品的驱动力不一致,用户选择服务的驱动力是规模。

当“规模”成为业务的决定因素后,服务模式的创新就成了业务发展的核心驱动力了,而产品只是为了完成服务的而提供给用户的一个载体。

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

回到产品类业务,在技术创新开创了一个新的业务后,后续的业务发展也会反向推动业务的发展。

综合来看,除非是开创新的技术能够推动或创造一个新的业务,否则都是业务推动技术的发展

技术演进的模式

业务模式千差万别,但无一例外,都是业务“复杂”度上升了,导致原有的技术无法支撑了。复杂度要么来源于功能不断的增加、要么来源于规模的扩大,从而对性能和可用性有更高的要求。因为,判断到底是什么复杂度发生了变化就特别的关键了。是任何时候都要考虑功能复杂度和规模复杂度吗?还是有时候考虑功能复杂度、有时候考虑规模复杂度?还是随便挑一个复杂度呢?

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

架构师应该基于业务发展阶段来判断复杂度。这也是架构师必须具备业务理解能力的原因。不同行业业务发展路径、轨迹、模式不一样,架构师必须能够基于行业发展和企业自身情况做出准备的判断。


   转载规则


《【架构设计】37-架构师应该如何判断技术演进的方向?》 孤独如梦 采用 知识共享署名 4.0 国际许可协议 进行许可。
 上一篇
【架构设计】39-互联网架构模板:“存储层”技术 【架构设计】39-互联网架构模板:“存储层”技术
39-互联网架构模板:“存储层”技术互联网的标准技术架构如图: 该篇主要了解存储层技术 SQLSQL即指我们通常说的关系数据。之前很多人认为NOSQL可以完全替代SQL,但是这几年的试验发现,NOSQL不是NO SQL,而是NOT ONL
2019-05-29
下一篇 
【架构设计】36-微内核架构详解 【架构设计】36-微内核架构详解
36-微内核架构详解简介微内核架构也被称为插件化架构,是一种面向功能进行拆分的可扩展的架构,通常用于实现基于产品的应用。例如Eclipse这类的IDE软件、UNIX这类操作系统、淘宝APP这类客户端。 基本架构微内核架构包含两类组件:核心系
2019-05-29
  目录