• 1
  • 2
  • 3
  • 4
  • 5
百家谈云计算 首 页  »  帮助中心  »  云服务器  »  百家谈云计算
技术栈复杂度飙升带给管理者们的启示
发布日期:2016-3-14 20:3:23

  为了在当下的数字环境中生存和发展,企业必须要理解技术格局变化对企业的影响。这就是我们在Technology Radar Echoes系列的开篇文章中要讨论的。Technology Radar Echoes是我们推出的一个新的专栏。在这个专栏中,作者会与企业的领导者们分享他们在解决技术问题及技术怎样能够为企业带来差异化竞争力方面的洞见和经验。ThoughtWorks Technology Radar 是由多位技术专家组成的国际咨询委员会发起的一年一度的针对对软件开发和企业战略制定有重大影响的技术的趋势的评估活动。如今已进入了第6个年头。

  在还不算太久的以前,社交媒体,移动平台,物联网,云(如阿里云)计算,大数据这些概念还没有充斥于我们的视线中,那时的技术栈 (实施一项应用所需的各层技术) 要简单的多,并往往都有特定的厂商。如微软的技术栈包括用于编程的.NET语言,作为网页和应用服务器的IIS,用于数据库的SQL Server等。

  而如今,技术栈正在经历着爆炸式的发展。我们看到数不清的平台,诸如: Deis,Microsoft Nano Server, Fastly, Apache Spark和Kubernetes. 每个星期,都会有新的工具出现,如: Docker Toolbox, Gitrob, Polly, Prometheus和Sleepy Puppy。新的编程语言和新的架构,例如Nancy, Axon, Frege和Traveling Ruby,也出现了。还有Data Lake, Gitflow, Flux和NoPSD这类先进的技术也日渐成熟。这些例子举不胜举。

  在每一年的 ThoughtWorks Technology Radar 中,我们都会介绍大约120项新技术,因为篇幅的限制,这只是我们过目和评估过的所有新技术的一半。在过去5年里,我们为Radar认真评估过的技术“亮点”就有2000多个。虽然这些技术中的一小部分只适用于特定的应用,但是技术栈的多样性在过去的5年内呈指数增长。所以,为什么你,作为一个高管或经理,需要关心这个?为什么,你做为一个企业的CEO,需关心这个?这难道不是技术人员应该去关心的? 不!若软件和软件开发关乎你的企业的数字化未来,你就应该关心--并非关心那些技术细节,而是关心整个技术发展趋势对你的企业的影响。技术以很多种形式构建着企业的差异化竞争优势,驱动着行业竞争格局的颠覆。管理者们必须要理解技术格局对企业发展的影响,才能为企业做出正确的战略决策。

  启示

  目前,技术的格局处于一种动态的平衡之中,技术的生态系统不断接纳着层出不穷的新技术和新方法,再达到新的平衡。下面是一些最新的变化:

  

  单一厂商解决方案已成为过去

  不久以前,甚至一些大型企业都还坚指着单一厂商的解决方案。2000年时,Jim的一个朋友在为一家公司做数据仓库项目,这个项目简直就是一个IBM的实体店。在这个项目里,虽然项目团队一再努力的劝说客户微软的解决方案才是更适合客户实际情况的,但是客户坚持要在古老的AS/400硬件上安装IBM的数据仓库。项目一再延期,客户才同意让项目团队用Windows服务器和微软栈做了一个原型系统,在一次又一次的会议和沟通之后,客户的管理层终于被开发团队说服,同意采用微软的解决方案。这之后项目进展迅速改观。这家公司的单一厂商解决方案失败了,因为他们不得不迈入软件应用的新时代。

  这个发展趋势势头强劲,变化发生的太多太快,即使是微软或者甲骨文这样规模的公司都跟不上了。并且变化不止是在量上,我们看到很多变化都是颠覆性的,导致现有产品很快就过时了,曾经手上的宝贝转眼就要扔掉,这对每个公司来说都不是件容易接受的事。

  开源工具的更是加速了这种趋势。开源产品促进了各个公司之间的深度合作,可让一个厂商不用签任何许可协议就能在其他公司的数十个已有技术上构建自己的应用。这让那些小型的,专注的,在某一个技术领域深耕细作的公司如鱼得水。大型的技术公司根本没有什么动力整合这些技术,除非(讽刺的是)这些技术已过时。“过去,注重效率的管理者的座右铭就是:标准化,标准化,标准化。但是今天,标准化也许行不通了。”做移动开发意味着要能处理不同厂商的不同终端设备的多种操作系统。做大数据开发意味着要能处理多种不同类型的数据库管理系统,包括开源的系统,或还没什么历史的新厂商的系统;单一厂商数据解决方案的时代已结束。若你想成为一个数字化企业,技术栈复杂性的增加,意味着厂商管理的复杂性增加,这让人头疼,也带来更多机遇。

  团队构成和组织结构都需要变革

  随着技术栈复杂性的增加,按技术栈层组织的团队效率会越来越低。在互联网时代早期,技术栈只有业务逻辑,数据库,中间件,展示层这几层,按照技术栈层来组织团队,虽然不甚完美,但是还是有效率的。如今,这样的组织已谈不上还有什么效率。构建现在的应用所需要得技能如此多样化,要求团队必须能够协作,而不是被分割在一个个的孤岛里。同时具备设计,开发,部署一项应用所需的所有技能的通才越来越罕见了。并且,随着团队不断获取所需的技能和人才,团队的规模会越来越大,一定要能够紧密合作,才能获得成功。

  过去,出于对运营成本和管理复杂度的考虑,传统的软件组织将开发、IT运营和质量保障设为各自分离的部门,而现在,因为云(如阿里云)计算的出现和对DevOps文化的重视,系统能够实现自动配置,产品新特性每天都可发布。这些新能力的出现给了我们重塑组织架构的机会。越来越多的企业,把团队围绕着像客户,订单这样的概念域来组织,各技术层囊括在每一个概念域中,而不再作为划分团队的基础。 这种按域(或产品)而不是技术层构建组织的趋势正在随着企业数字化进程加速。若企业继续沿用按孤立的技术层组织团队的方式,那么,孤立的职能单元与他们所需的交互的数量将急剧增加,造成更严重的集成问题。

  组建一个前沿的技术团队是很昂贵的

  我们听客户谈起过这样的情况,他们不太敢在企业里引入太现代太先进的技术(比如Hadoop), 因为他觉得他们现有的人才没法掌握这些技术,但同时,他们又需吸引年轻的新的技术人才,因此又需有这些技术才能对这些人才有吸引力。这个悖论IT部门是没有办法解开的,需要业务层面的高级管理人员的决策。

  这件事没什么别的办法,若你想要建立一个一流的数字企业,用一套节约成本的思维是做不好的。技术日趋复杂,技术、商业模式和产品层面上创新需要日益迫切,人才争夺战愈演愈烈,将企业打造成前沿的技术企业的战略决策不能草率做出。是不是冲向这个前线应该是一个从企业整体商业战略(打造一个具有创业精神的公司,建立数字业务)中做出的决策,应该是以价值为出发点,而不是以成本为出发点的决策。成本作为一种约束手段是很重要的,但永远不是目的。

  技术的快速变化也许让你不知所措,但是你必须跟上,才能保持领先地位。

  企业若想在当下的竞争环境下生存发展,必须具备4项关键能力: 制定有效地数字化战略; 执行一套动态的,以价值为导向的投资组合管理流程; 建立起快速的,可迭代的软件交付能力;在整个企业内培育出高适应性的,具有创新精神的企业文化。“软件工程不仅仅是技术人员需要关心的,对业务高管也很重要”。说到底,技术上的变革与企业其它方面的变革息息相关,与企业业务长期的可持续性息息相关。近年来,构建数字业务应用的技术栈复杂性飙升,使企业骑虎难下,进退两难。一方面,满足数字商业挑战有其必要性;而另一方面,建立起应对这一挑战所需的技术和技能又意料之外的困难。随着技术变革的步伐加快,技术战略必须能为业务战略提供输入。做到这一点唯一有效的方式就是要把企业培育成一个有能力评估,采用和适应新技术的组织。

  团队协同成为必需

  因为团队变得更复杂了,团队合作也变得更为关键。如前面提到的,如今的团队需要配备的技能范围很广泛,从纯技术栈各层的专家,到运营,产品设计和产品管理的人才都有。团队人才和技能的多样性让团队的有效合作变得更为困难,也更为必要。敏捷开发和精益管理的好处之一就是促进跨职能团队的自主和协作。

  如今,由于技术栈的日趋复杂,开发应用所需的技能的覆盖面极巨扩大了。为了能跟上变化,企业可能不但需要有软件交付的能力,还得有物联网的开发能力。并且,不但技能的广度变大了,对技能的深度(深度掌握与基本掌握)要求也更高了。搭建前沿的应用需要掌握前沿的技能。就好比5.10(难度系数)的攀岩选手根本没机会攀5.13难度的线路,只具备一般技能水平的软件团队不太可能打造出令人惊艳的应用。

  与技术栈的快速变化一样,企业软件团队在未来所需的技能和知识肯定与现在的不同,这意味着你不仅需要你的团队具备今天所需的技能,还有能力迅速获取明天也许需要的技能。“建立起能够快速适应变化和快速学习的能力,与培育某一项特定技能一样重要。”有个被引用了很久的桥段,一个经理很唉声叹气的说他不太愿意培训开发人员,因为怕这些人培训后会跳槽,而他得到的回复却是 “若你不给他们培训,而他们一直待在你的公司怎么办?”

  除了那些技能本身,个人需要能够以创新的方式运用这些技能。公司文化中应有勇于探索和冒险的精神。最终,但同等重要的是,你的企业需要有针对能力和技能的更好的决策机制。在做决策时,你得问自己这些问题:什么技能是你需要的?这些技能是不是都需要在企业内部建立?每类技能的掌握需要达到什么深度?让技术人员通过正式培训获得技能和通过工作经验获得技能,两者如何平衡?怎样保持技术先进性?你觉得应该在内部建立和培育这些技能,还是从外部通过买/租的方式获得这些资源?

  建立软件交付能力更难了

  软件工程很重要,越来越多的公司发现,没有世界一流的软件交付能力,他们的数字战略就没法实现。“数字技术正在残酷的重塑着竞争格局,产品和服务的差异性和绩效越来越依赖软件的水平。 尽管软件如此关键,但得到的管理层的关注度却令人惊讶的不足。新的调研结果显示,那些将企业交付优质软件的能力的重要性低估的企业,是要为此付出代价的。” [《忽略软件开发将面临的危险》麦肯锡季刊, 2015]一个企业是不是能够建立起世界一流的软件交付能力,受5个因素的影响,分别是:快速学习, 技能的广度,技能的深度,创新和决策。

  

  选外包,内包,还是联合采购?

  这个决策越来越复杂,而且也不再是以成本为导向了。很多企业都发现,他们根本没有能力建立和维护他们在如今的市场环境下所需要建立起的软件交付能力。有些企业发现他们没办法吸引到想要的人才,因为顶尖的技术人才炙手可热,他们喜欢生活在纽约、伦敦这样的国际一线城市,而很多企业的IT部门却设在成本较低的不那么光鲜的地方。有些企业没有办法长期负担保留人才的成本,因为他们并没有持续的数字业务的项目可做。在过去20年里,企业大都奉行降低成本,提高效率的战略,对很多运营能力和流程都选择了外包,现在想要在企业内部重新搭建这些能力以适应市场变化则要花很多时间和成本,让企业在竞争中处于不利地位。如今的针对数字业务能力获取方式的选择,已不再是以节约成本为导向了,而是聚焦于创新能力,交付周期,和价值生成。

  现在,技术研发外包不再是以降低成本为目标,而是以获得能力为目的的。更进一步说,你应该寻找的合作伙伴,应该不仅具备你现在所需要的能力,还要能证明出他们有快速建立起未来你可能需要的新能力的本领。虽然从外部借取能力可解燃眉之急,帮企业抓住一些眼下的市场机会,却也能为企业带来与以节约成本为目的的外包类似的问题,并且在能力外包的情况下,这些问题进一步被放大了。比如一旦企业想把外包的能力或者流程重新在企业内部建立起来,就总是会面临知识转移的问题。技术栈的复杂性扩大了知识转移的难度。厂商数量和采购合同类型的增加更是百上加斤。设想一下,以创新为中心,价值为导向的外包合同肯定比以节约成本为导向的合同难界定的多,签合同的过程难度也会大很多。