敏捷在中国这十五年

题记:2002年3月,《程序员》杂志发表了《极限编程》技术专题。以此为标记,敏捷进入中国已经十六年了。这篇文章是熊节去年为《程序员》写的年终回顾文章,发表于《程序员》2018年第1期。

时至岁末,各种年度调查报告渐次登台。其中我注意到云栖社区发布的《2017开发者调查报告》中有一项数据:45.6%软件开发者所在的组织采用了敏捷软件开发方法,在各种开发方法学中位居第一。这个数字又让我联想起,CSDN在年初发布的《2016年度中国软件开发者白皮书》中提到,64%的受访企业采用了敏捷项目管理工具。虽然之前也曾经看到某些调查声称“98%的企业计划采用Scrum”,但我对于这些调查的采样范围一向存疑。云栖社区与CSDN的这两个报告,在我看来客观而坚实地明确了敏捷在当今IT行业的主流地位。

作为站在传统企业数字化前沿的咨询师,来自各个行业甲方的动向也给我同样的感知。在电信行业,浙江移动大张旗鼓地开展敏捷转型与DevOps体系建设,并与咨询师结对公开演讲,介绍自己的转型经验。在金融行业,渣打银行的敏捷转型已经进行数年,汇丰银行以敏捷理念构建他们位于西安的研发中心,招商银行的CIO陈坤德在金融科技峰会中正面提出“银行必须敏捷化”,新成立的民营互联网银行更是从诞生第一天就把短迭代、自动化、持续交付等敏捷实践植入在基因深处。在汽车行业,7月发布的《汽车销售管理办法》打破了传统4S店对销售渠道的垄断,乘用车主机厂纷纷上马在线营销或销售系统,欲与已在地平线露头的汽车电商一争高下,短迭代、微服务、持续交付同样是他们在数字化渠道建设中的主题词。在航空行业,海航集团旗下的科技集团把自己转型成PaaS云供应商,组织文化、工作方式全面对标互联网企业,敏捷岛、看板、信息可视化等硬件设施已经成为研发团队标配。看着各行业头部企业的动向,我感到现在已经可以放心地说:敏捷,已然成为不可逆转的时代大潮。

这股大潮在中国最初的涓滴潜流,大约要追溯到十五年前。2001、2002年,彼此互不相识的几组人,几乎不约而同地向中文世界引进与敏捷相关的资料。《程序员》杂志在2001年12月专栏介绍重构、2002年3月专栏介绍极限编程,是中文出版物中有案可查的最早的先行者。同在2002年,北京软件过程改进组织(PKSPIN)的成员唐东铭向人民邮电出版社推荐了Kent Beck的《解析极限编程》,后来这一套《极限编程丛书》于2002年10月出版。到2003年,《软件研发》杂志的创刊号大篇幅介绍敏捷方法,《重构》、《敏捷软件开发》、《自适应软件开发》等一系列重量级著作引进。今日的风起云涌,即肇始于当年的青萍之末。

饶有趣味的是,唐东铭本人在后来的职业生涯中一直没有机会亲身经历一个敏捷的项目。他的经历,映出了行业的发展历程。敏捷所强调的快速迭代、持续交付,对于植根政府和大企业内部信息化、仰赖“十二金”工程哺育的尚处幼年的中国软件行业而言,是太过超前了。时至2006年,在第十届国际软件博览会上,Martin Fowler做了关于敏捷方法的主题演讲,台下报以他的是困惑的眼神与尴尬的沉默。语言固然是尚未全面与国际接轨的中国软件业理解Fowler演讲的阻碍之一,更大的鸿沟还是在于观念与意识。对于其时的行业环境与技术环境而言,每两周一次迭代、每次迭代发布上线给用户使用,既不可能、也不必要。中国的IT业还没有做好迎接敏捷的准备。

决定性的转机发生在2008年前后。通信市场的争夺日趋白热化,4G相关产品的研发已经从原来先有规范后有产品,变成了规范产品同步进行,并且运营商也开始要求越来越多的定制功能。这种竞争态势,使各家大厂把应对需求变化、缩短交付周期放上了研发能力的优先级。从2005年底,诺基亚在杭州的研发中心已经开始试点敏捷,并把试点的成果带到了2006年与西门子合资的新公司里。2008年,诺西多条产品线开始大面积推广敏捷。同在2008年,爱立信也在大范围实施敏捷,将传统的功能团队转变为特性团队,用Scrum方法运作项目,并引入了持续集成实践。华为在印度的团队于2006年小规模试点敏捷,总部得知这一经验后于2007年开启一系列试点项目,并于2009年开始全面推广,特性团队、双周迭代、故事墙、持续集成等实践切实落到了基层。2010年落成的华为南京、上海两个新基地,都大量采用开放式办公区、敏捷岛的格局。在BAT气候大成之前,通信大厂是中国技术人才的重要源泉,这几家公司培养出的大量优秀敏捷教练与持续集成专家,为后来敏捷在行业里的广泛传播起到了推波助澜的关键作用。

互联网大厂的敏捷起步也并非一帆风顺。2009年,百度把握住谷歌退出中国市场的机遇,全面对标谷歌,包括工程师的工作方式。从单一主干开发模式切入,百度大幅提高了研发过程中的自动化程度,把产品发布周期从几个月一次缩短到了每周一次发布。迟至2012年,腾讯某些产品还只能做到两三个月发布一次,通过模块解耦、提升自动化水平、拆分特性团队、持续集成等实践,得以逐步缩短发布周期,达到了每天能发布两个可用版本的水平。

不过互联网大厂毕竟身处在时代大潮的前沿,时刻接触海量用户真实的行为反馈,以及每一点转化率提升带来的直接经济效益,使他们有直接的动力不断缩短发布周期。大野耐一强调的“湖水与岩石”理论在他们这里得到了淋漓尽致的发挥:发布周期从几个月缩短到一两周,可以靠组织和管理的改变;从一两周缩短到一两天、甚至一天发布若干次,必然要靠技术和平台的积累。BAT自不待言,美团作为二线互联网大厂,也把技术视为自身核心竞争力。对技术人员的尊重不仅体现在管理技术双线并行的职业路径上,也体现在开放、平等、追求卓越的文化氛围上。对技术的重视带来的反哺,则是平台实力的大幅提升。借由高效的数字平台赋能,领先的互联网团队已经超越了“敏捷”的范畴,开发人员无需刻意考虑敏捷的实践,眼前的数据和背后的平台已经驱动着他们自然地按照极短的发布周期不断演进产品。

当互联网大厂以这样的高节奏从线上往线下席卷而来,各个行业的CIO们纷纷上马敏捷,看起来更像是在BAT收割之前的末路狂奔。已经被驱动起来的金融、汽车、零售行业,在一波与时间赛跑的敏捷浪潮究竟会剩下几家欢喜几家愁?有着大市场基数和高利润空间的教育行业,最近连续曝出令人不安的丑闻,这是否会成为政策放松管制、互联网竞争大举涌入的契机?医药行业树欲静而风不止,近有医药改革两票制全面触动流通环节即有利益、阿里健康倒逼医院改革,远处还有政府依托腾讯建设国家级医疗人工智能平台的愿景,医药行业的数字化、互联网化转型何时会进入快车道?航空行业谋求用数字化拉升资产效率,从民航维修、机场运营,到顾客体验、航线收益,再到搭建云生态平台,对未知场景、未知需求的快速感知和响应能力何时会排上航空业IT的优先级?这些可能都是我们在未来一两年内就会看到答案的事。

作为中国敏捷十五年发展历程的亲历者与推动者,透过敏捷被引进中国、被推介、被传播、被漠视、被抗拒、被接纳、被推崇、被转变、被淡化的过程,我看到了整个中国IT行业、乃至中国经济发展的缩影。今天敏捷成为最为广泛采纳的软件开发方法,背后折射出的是IT在国民经济生活中的地位提升、是技术人员从外包码农到企业核心竞争力的地位提升、更是中国经济在全球经济中的地位提升。过去十五年,来自美国的敏捷软件开发方法指导了中国的IT行业;未来,中国的IT行业需要什么方法来指导,这个问题可能要靠我们自己来回答了。


更多精彩商业洞见,请关注微信公众号:ThoughtWorks商业洞见

Share

保持现状与有意为之的无知

1970年9月,萨尔瓦多·阿连德当选智利总统。智利人民用自己的选票,选择了他倡导的社会主义路线。执政之后,阿连德政府开始收购智利最重要的工业企业,将它们纳入国家控制。到1971年底,国家开发公司已经必须负责指导下属150多家企业,包括智利20家最大企业中的12家。国有经济的高速发展创造了一个笨重的、智利政府从未见过的怪兽,管理已经成为国有化进程的一个核心问题。为此,阿连德政府联系到了英国控制论学者斯塔福·比尔。比尔发现,控制论中关于反馈与掌控的思想能够指导开发一套新的科技系统来改善国有经济的管理,从车间直到国家开发公司办公室。这样一个系统将会搭建起实时信息交换的网络,管理者和政府官员将能够基于实时数据来做决策,并能够快速调整行动。这个系统,就是传奇的Cybersyn,距今半个世纪前出现在智利的大数据系统

按照比尔的构想,这个基于他的“自由机器”和“可生存系统模型”理论构建起来的大数据系统,将能够兼顾国家经济整体方向的一致性与企业的自主性,并且充分调动一线工人参与企业管理体制的设计与执行。然而在Cybersyn系统实施的过程中,智利科技专家们的实践与政府的政治理念并不吻合。虽然阿连德坚持要系统鼓励工人参与管理,但工人在Cybersyn实施中扮演的角色实际上是被边缘化的。更多时候,技术官僚主义在基层车间压倒了意识形态。尽管收到明确的指示要与工人委员会协作,但工程师们经常并不这样做,而是带着优越感看待工人,或是完全忽视工人、只和管理者打交道。

1973年9月,皮诺切特的军事政变推翻了智利社会主义政府,阿连德本人丧生于总统官邸。政变之后,军队中止了Cybersyn项目,团队的工作成果要么被抛弃、要么被破坏。在新的军政府和新自由主义“休克疗法”背景下,Cybersyn没有任何意义。然而客观地说,即使没有军事政变,Cybersyn是否就能如起初设计的成为对劳工赋权、鼓励工人参与管理、兼顾民主与集中的信息系统,比尔对此也并非没有怀疑。为何科技系统——甚至是那些原本为了革命的目标而建立的科技系统——常常倾向于维持社会与经济的现状,这是Cybersyn留下的值得反思的若干问题之一。

1973年,比尔反复思考了Cybersyn遭遇的各种问题,包括项目团队在科技上花的心思多过组织变革、智利工人没能用Cybersyn来辅助生产组织和管理等,并把自己的思考写成了《现状》(Status Quo)一文。他在文中写道:

对于马克思而言,资本是邪恶的敌人;对我们而言,资本仍然是邪恶的,然而敌人是保持现状。

比尔认为,科技的发展,尤其是通信与计算机领域的发展,使得资本主义已经发展出了新的生产形式与新的剥削关系。在这个新的关系中,不仅有资本家与劳动者的对立,受过高等教育的专业人士扮演了一个重要的角色。比尔从控制论的角度指出,官僚体系总是偏爱保持现状,而专业人士扮演的则往往是保持现状的力量、而非推动革命的力量。

仍然以Cybersyn为例:尽管顶层设计把它视为一个“革命的装置”,但在科技团队内部,很多人认为应该把意识形态放在一边,专注于科技性的目标,例如提升政府监管经济的能力、解决经济的效率问题、消灭官僚主义。Cybersyn项目主管埃斯佩霍说,很多科技专家想要加入这个项目是因为它“充满智力挑战”,这些科技专家对于科技与政治之间的关系有着不同的解读,并非所有人都赞同阿连德的政治理念。这个团队得以持续“健康”运转的基础,也许就是——如埃斯佩霍所做的——搁置意识形态的目标,专注于科技的目标。于是,专业人士团队基于自身利益角度出发的“求生意志”,就成为了一种保持现状的动力。

时隔四十多年以后,我们在今天的科技-社会的讨论中看到,这种来自专业人士角度的保持现状的动力变得更加强大,甚至时常被称为“科技本身的逻辑”(凯文·凯利还专门写了一本书来讨论“科技要什么”)。比尔在1970年代的反思让我们看到,这种“科技本身的逻辑”,经常是来自专业人士有意而为之的对意识形态、对社会问题的搁置。专业人士倾向于将自己的工作描述为纯粹科技的、“政治中立的”,使得自己不必接受“我的工作对社会有何影响”的追问。在快播案、魏则西案等一系列关于互联网伦理的讨论中,我们皆听到了这种纯粹科技论的辩解。我把这种“将自己的专业工作与社会/政治/伦理问题划清界限”的努力,称为“有意而为之的无知”(minded unmindedness)

这种有意而为之的无知,部分出自科技本身的复杂性与抽象性。例如广为讨论的人工智能技术,无论是向读者推荐视频、还是在读者的搜索页面显示广告,从技术的角度都可以归约为一系列在高维矩阵上进行的线性代数运算(以及与之相关的特征工程、算法优化等工作)。这种高度的复杂性与抽象性,使得科技专业人士能够埋头于诸如“计算稀疏矩阵中向量间的欧氏距离”这样的纯技术问题,而毫无愧疚地无视技术的应用对社会产生何种影响,并且在面临来自人文社科领域的置疑时轻易地给自己构建起坚固的保护壳。

然而问题并非只出在科技专业人士这一边。人文社科领域的专业人士同样有自己的有意而为之的无知,表现为对新技术的盲目恐惧,或者说是“将自己的专业工作与科技问题划清界限”。于是我们看到,来自人文社科领域的关于科技伦理的讨论经常流于表面,例如用科幻小说的方式讨论“强人工智能”,而缺乏对机器学习、神经网络等核心技术及其应用场景和局限性的基本了解。其结果是,来自人文社科领域对新科技的批评要么“脱靶”,要么在科技人士实用主义的反问“那你说该怎么办”面前黯然失语。像Cathy O’Neil这样能准确地指出科技系统中问题所在、能提出行之有效的解决方案、能持续量化监督科技公司改进的跨学科左翼人士,实在是太稀缺了。

解决这个困境需要科技与人文社科两边专业人士的共同努力。科技的专业人士当然需要更多地了解社会的问题及其渊源、更多地反思自己工作与社会/政治/伦理问题之间的关系。另一方面,我在这里想强调的是,人文社科的专业人士应该打破自己对新技术的盲目恐惧,不能坐等科技专业人士的觉醒,他们需要立即开始学习编程和人工智能的基础,使自己掌握有效批判的武器。

实际上这两项技术的门槛比很多人想象的要低得多。除了克服入门时的恐惧与不适,Python编程需要的理科知识基础约等于0——我曾经与同事半开玩笑地说,我们开发的软件只需要小学高年级数学水平,四则运算都用不全,主要是除法不怎么用。另一个学习编程的门槛是英语,然而人文社科领域的年轻学者大多具备相当良好的英语读写能力。自学一门编程语言(例如Python)这件事,我认为每位人文社科学者应该都能做到。

人工智能技术所需的理科基础则更高一些:如果想要比较深入地了解其原理(而不止是使用几个工具),需要微积分和线性代数的基础知识。以高中水平的数学能力,在一学期时间里重新捡回这两门课应该是可以做到的。(听说一些高校的文科院系大一已经不上高数课,我认为这是一个错误的导向。)

除了这一点数学基础以外,大部分数据处理和机器学习算法可以说是出人意料地简单。John Foreman的Data Smart一书教它的读者用Excel(是的,你没看错,就是你每天用的Excel)实现分类、推荐、预测等典型的机器学习算法,我认为这本书非常有助于破除笼罩在“人工智能”这个概念之上的神秘感。另外我也强烈推荐人文社科学者在学了一点Python基础之后尝试一下华盛顿大学的机器学习公开课。学完它的第一门课程,你就会发现,机器学习(乃至“人工智能”)其实是一件很简单、毫不神秘的事情——这一点,对岸的科技工作者们其实一直都知道。

科技与人文社科的失联,会导致整个左翼运动陷入一种尴尬的境地:对于资本用以牟利并同时制造社会不公的科技工具,科技工作者看不到其社会危害所在,人文学者又无法提出有效的批判和改进方向。无形之中,双方对于对方专业领域的有意为之的无知,都在帮助保持当前科技-社会结构的现状。要打破这种现状,需要双方都开始努力了解对方的专业领域,包括——我今天特别想强调的——人文社科学者学一点编程和人工智能技术。


更多精彩内容,请关注微信公众号:软件乌托邦

Share

数字化企业的数据自服务

什么是数据自服务

数据在企业中的处理过程,能清晰地映射出康威定律对IT系统的影响。在各个部门分别建设IT系统、组织内部大量存在信息筒仓(silo)的年代,数据的操作由OLTP应用系统的开发团队同步开发,那时几乎每个政府信息化、企业信息化系统都会有一块“报表需求”。随后众多组织认识到筒仓系统导致信息在组织内不能拉通,不能产生对整体业务流程的洞察,于是开始建设以数据仓库为代表的OLAP系统。

这些系统在支撑更高级、更复杂的数据分析的同时,也对应地在组织中造就了一支专业的“数据团队”。这些人使用非常专业的技术和工具对数据进行提取、转换、装载、建立数据立方、多维钻取、生成报表。这些专业的技术和工具,普通的软件开发人员并没有掌握,因此对数据处理、分析和呈现的变更都必须归集到这个数据团队来完成。结果是,数据团队的backlog里累积了来自各个部门的需求,需求的响应能力下降,IT系统从上线到获得市场洞察的周期变长。

微服务架构鼓励小型的、全功能的团队拥有一个完整的服务(及其对应的业务)。这样的全功能团队不光要开发和运维IT系统,还要能从数据中获得洞察——而且要快,不然就会跟不上市场变化,甚至使一些重要的业务场景无法得到支撑。因此他们不能坐等一支集中式的、缓慢的数据团队来响应他们的需求,他们需要数据自服务能力。 要赋能数据自服务,企业的数字化平台要考虑“两个披萨团队”的下列诉求:

  • 需要定义数据流水线,使数据能够顺畅地流过收集、转换、存储、探索/预测、可视化等阶段,产生业务价值。
  • 需要用实时的架构和API在短时间内处理大量、非结构化的数据,从中获得洞见,并实时影响决策。
  • 为了提高应变能力,系统中的数据不做ETL预处理,而是以“生数据”的形式首先存入数据湖,等有了具体的问题要回答时,再去组织和筛选数据,从中找出答案。
  • 更进一步把数据包装成能供外人使用的数据产品,让第三方从数据中获得新的洞见与价值。
  • 为了支持数据产品的运营,需要实现细粒度授权,针对不同的用户身份,授权访问不同范围的数据。

数据自服务解读

下面是ThoughtWorks的数字平台战略第三个支柱“数据自服务”中所蕴涵的具体内容。

数据流水线设计

所谓流水线,是指用大数据创造价值的整个数据流。流水线从数据采集开始,随后是数据的清洗或过滤,再然后是将数据结构化到存储仓库中以便访问和查询,这之后就可以通过探索或预测的方式从数据中找到业务问题的答案,并可视化呈现出来。

(图片来自:tuplejump Inc.)

一条运转良好的数据流水线,能有效处理移动/物联网等新技术制造出的极其大量的数据,缩短数据从获取到产生洞见的反馈周期,并以开发者友好的方式完成数据各个环节的处理,赋能一体化团队。

数据流水线的实现有两种可能的方式。一种方式是在各个环节采用各种特定的工具,例如前面介绍的数据流水线,各个环节都可以用开源的工具来实现。当然,选择这种方式也并非没有挑战:组织必须自己编写和维护“胶水代码”,把各种专用工具组合成一个内聚的整体。对组织的技术能力有较高的要求。

(图片来自:tuplejump Inc.)

除了基于开源软件实现自己的数据流水线,也可以考虑采用云上的数据流水线PaaS服务,例如DatabricksAWS Data PipelineAzure Data Factory等。这个方式的优点是对技术能力要求较低,缺点则是造成对特定云平台/PaaS提供商的依赖。

实时架构和API

实时的数据架构和API支持短时间内处理大量、非结构化的数据,从中获得洞见,并“实时”影响决策。正如Mike Barlow所说:“这是关于在正确时间做出更好决定并采取行动的能力,例如在顾客刷卡的时候识别信用卡欺诈,或者当顾客在排队结账的时候给个优惠,或者当用户在阅读某篇文章的时候推送某个广告。”

Cloudera的一篇文章中介绍了实时数据处理的4个架构模式,整个流水线架构在Flume/Kafka基础上:

  • 数据流吸收:低延迟将事件持久化到HDFS、HBase、Solr等存储机制
  • 近实时(100毫秒以下)的事件处理:数据到达时立即采取警告、标记、转换、过滤等初步行动
  • 近实时的事件分片处理:与前一个模式类似,但是先对数据分片
  • 复杂而灵活的聚合或机器学习拓扑,使用Spark

数据湖设计

数据湖概念最初提出是在2014年Forbes的一篇文章中。它的概念是:不对数据做提前的“优化”处理,而是直接把生数据存储在容易获得的、便宜的存储环境中;等有了具体的问题要回答时,再去组织和筛选数据,从中找出答案。按照ThoughtWorks技术雷达的定义,数据湖中的数据应该是不可修改(immutable)的。

数据湖试图解决数据仓库几方面的问题:

  • 预先的ETL处理终归会损失信息,如果事后才发现需要生数据中的某些信息、但是这些信息又没有通过ETL进入数据仓库,那么信息就无法寻回了。
  • ETL的编写相当麻烦。数据仓库的schema发生改变,ETL也要跟着改变;应用程序的schema发生改变,ETL也要跟着改变。因此数据仓库通常由一个单独的团队负责,于是形成一个功能团队,响应速度慢。
  • 数据仓库的分析需要专门的技能,大部分应用程序开发者不掌握,再度强化了数据仓库专门团队;而数据仓库团队其实离业务很远,并不能快速准确地响应业务对数据分析的需求。

在数据湖概念背后是康威法则的体现:数据能力与业务需求对齐。它要解决的核心问题是专门的数据仓库团队成为响应力瓶颈。当IT能力与业务需求组合形成一体化团队以后,数据的产生方不再假设未来要解决什么问题,因此也不对数据做预处理,只是直接存储生数据;数据的使用方以通用编程语言(例如Java或Python)来操作数据,从而无需依赖专门的、集中式的数据团队。

数据湖实施的第一步是把生数据存储在廉价的存储介质(可能是HDFS,也可能是S3,或者FTP等)。对于每份生数据,应该有一份元数据描述其来源、用途、和哪些数据相关等等。元数据允许整个组织查看和搜索,让每个一体化团队能够自助式寻找自己需要的数据。任何团队都可以在生数据的基础上开发自己的微服务,微服务处理之后的数据可以作为另一份生数据回到数据湖。维护数据湖的团队只做很少的基础设施工作,生数据的输入和使用都由与业务强关联的开发团队来进行。传统数据仓库的多维分析、报表等功能同样可以作为一个服务接入数据湖。

在实施数据湖的时候,有一种常见的反模式:企业有了一个名义上的数据湖(例如一个非常大的HDFS),但是数据只进不出,成了“数据泥沼”(或数据墓地)。在这种情况下,尽管数据湖的存储做得很棒,但是组织并没有很好地消化这些数据(可能是因为数据科学家不具备分析生数据的技术能力,而是更习惯于传统的、基于数据仓库的分析方式),从而不能很好地兑现数据湖的价值。

数据即产品

数据产品是指将企业已经拥有或能够采集的数据资产,转变成能帮助用户解决具体问题的产品。Forbes列举了几类值得关注的数据产品

  • 用于benchmark的数据
  • 用于推荐系统的数据
  • 用于预测的数据

数据产品是数据资产变现的快速途径。因为数据产品有几个优势:开发快,不需要开发出完整的模型,只要做好数据整理就可以对外提供;顾客面宽,一份数据可以产生多种用途;数据可以再度加工。数据产品给企业创造的收益既可以是直接的(用户想要访问数据或分析时收费)也可以是间接的(提升顾客忠诚度、节省成本、或增加渠道转化率)。

在实现数据产品的时候,不仅要把数据打包,更重要的是提供数据之间的关联。数据产品的供应者需要提出洞见、指导用户做决策,而不仅仅是提供数据点。数据产品需要考虑用户的场景和体验,并在使用过程中不断演进。

细粒度授权

当数据以产品或服务的形式对外提供,企业可能需要针对不同的用户身份,授权访问不同范围的数据,对应不同的服务水平和不同的安全级别。一些典型的细粒度授权的场景可能包括:企业内部和外部用户能够访问的数据范围不同;供应链上不同环节的合作伙伴能够访问的数据范围不同;付费与免费的用户能够访问的数据范围不同;不同会员级别能够访问的数据范围不同等等。

允许访问的数据范围属于数据产品/服务自身的业务规则。《微服务设计》的第9章建议,“[服务]网关可以提供相当有效的粗粒度的身份验证……不过,比允许(或禁止)的特定资源或端点更细粒度的访问控制,可以留给微服务本身来处理”。

小结

为了加速“构建-度量-学习”的精益创业循环,业务与IT共同组成的一体化团队不能依赖于集中式的数据团队来获得对业务的洞察。他们需要规划适宜自己的数据流水线,在必要时引入实时数据架构和API,用数据湖来支撑自服务的数据操作,从而更快、更准确地从数据中获得洞察,影响业务决策。更进一步,数据本身也可以作为产品对内部用户乃至外部用户提供服务,并通过细粒度授权体现服务的差异化和安全性需求。通过建设“数据自服务”这个支柱,企业将真正能够盘活数据资产,使其在创新的数字化业务中发挥更大的价值,这是企业数字化旅程的第三步。

了解更多关于数字平台战略的信息,可下载《数字平台战略》白皮书。


更多精彩商业洞见,请关注微信公众号:ThoughtWorks商业洞见

Share

数字化企业的API架构治理

前文中我们说到,传统企业在逐步建设自己的数字平台过程中,需要抓住交付基础设施、API和架构治理、数据自服务、创新实验基础设施和监控体系、用户触点技术这五个支柱。今天我们就来谈一谈API、架构治理这些听起来非常技术性的概念与企业的数字化战略之间有何关系。

企业资源服务化

从1990年代起,企业资源计划(ERP)一直是企业信息化的核心议题。植根于供应链管理,ERP通过对企业内部财务会计、制造、进销存等信息流的整合,提升企业的计划能力与控制能力。然而近年来,在互联网的冲击下,传统企业开始面临全新的挑战。尤其是在互联网的去中介化效应影响下,原本在供应链上下游各安其位的企业突然间都被压缩到了“生产-流通-消费”这个极度精简的价值链中。药品购销两票制就是这个极简价值模型的直观呈现。在这个模型中,掌握技术优势和消费者入口的互联网企业有可能形成一家独大的超级垄断,挤死传统的流通企业,把生产企业变成自己的OEM厂商,这是传统企业对来自互联网的竞争者恐惧的根源。

为了对抗互联网企业的竞争,传统企业最好的办法不是硬拼互联网上的技术和流量,而是在自己擅长的领域开战:把自己多年积累的线下资源变成线上服务,构建起本行业的线上生态系统,不仅支撑本企业的线上经营,而且为上下游周边企业提供线上经营的平台,从而把线下优势转化为线上优势,以资源优势对抗技术优势。

为了支撑企业资源的服务化,在设计在线服务的API和架构时需要考虑以下问题:

  • 平台架构和API的设计应该注重开发者体验。
  • 在API的背后,应该从业务功能的角度出发划分合理的限界上下文和服务边界,对外提供高内聚低耦合的服务。
  • 在服务边界之间,应该考虑使用异步的事件机制实现服务之间的通信,来解耦领域模型,客观地描述运行时间比较长、甚至本质上不可能立即完成的操作。
  • 为了方便使用,应该提供API网关作为所有服务使用者的单一入口,在API网关背后去处理众多内部IT系统的复杂性。
  • 整个API架构应该以微服务的风格呈现,避免典型SOA架构中普遍存在的过于复杂的ESB编排逻辑。

ERP之后是什么?

进入2010年代以来,“后ERP时代”这个说法不断被提出。在谈到ERP的发展方向时,通常都会涉及业务与技术两个角度。例如一种观点认为,ERP需要从以流程为中心转变为以客户为中心,并且需要用好云计算、社交网络、大数据和移动化等新技术。

ThoughtWorks认为,ERP在互联网时代的发展方向将是企业资源服务化(Enterprise Resource Servicification,ERS),通过数字平台的技术能力,把一家企业的资源融入一个行业的互联网生态,为企业铺下明确的数字化道路。

API和架构治理解读

下面我们来近距离看看,在“API和架构治理”这顶帽子下面,有哪些具体的问题需要被考虑到。

开发者体验

当企业资源以服务的形式对外提供,也就意味着不可能——像传统的IT系统建设那样——强迫别人使用这些服务。尤其是要把这些服务提供给第三方开发者、希望他们开发出形形色色的应用程序,那么服务的API是否易用就会很大程度上影响它能吸引到多少第三方开发者。ThoughtWorks第16期技术雷达还专门把开发者体验作为一个重要的技术主题。

在讨论开发者体验时,可以从开发工具和开发环境的安装、配置、管理、使用、维护等角度来考量。具体而言,开发环境和测试环境是否能弹性地随需获得,开发/测试基础设施和持续交付流水线是否以源代码的形式提供并完全自动化,是否提供对主流开源软件的支持,是否提供可编程的、命令行友好的(而不仅仅是图形化的)工具界面,安全、数据访问权限等企业规章是否严重影响开发者的效率和感受,这些都是影响开发者体验的要素。

服务边界

和所有的面向对象设计一样,服务的设计应该是高内聚低耦合的:与一个业务相关的修改只在一个服务内部进行,并且一个服务的修改/部署不需要影响其他服务。和一个代码库内部的对象设计不同,每个服务通常有专属的代码库,并且由专人负责维护(而不是所有人拥有所有代码),因此服务边界的改变会带来更大的变更成本。所以,服务边界的划分需要投入精力认真对待。

从设计原则上来说,服务的边界应该体现业务的边界,而不是单纯从技术角度出发划分服务边界。从业务功能的角度出发划分合理的限界上下文,以领域模型和领域事件的聚合为出发点来划分服务,更可能得出与业务边界一致的服务边界。随后再以业务目标驱动建设全功能一体化团队,就能做到业务、技术、团队三者对齐(康威定律再次起作用)。四色建模事件风暴等方法都能有效地实现领域驱动设计,从而建立起良好的领域模型及服务边界。

事件驱动架构

使用异步的事件机制实现服务之间的通信。对于运行时间比较长、甚至本质上不可能立即完成的操作(例如涉及人工操作),使用异步通信是合理的选择。即便不考虑响应的实时性,事件驱动的架构还表达了领域模型之间的松散耦合关系:跨领域的协作以事件而非方法调用的形式来表达,系统追求最终一致性而非强一致性。这一结构准确地映射了真实世界中多支相关但独立的团队之间的协作关系,避免了过度依赖其他服务的响应速度或可靠性等服务质量指标,使服务真正具有技术上的独立性。

在设计系统时,借助事件风暴方法,可以通过领域事件识别出聚合根,进而划分微服务的限界上下文。当出现跨多个聚合根的事件时,可以很自然地将其实现为异步的领域事件,从而获得与领域设计高度吻合的实现。关于如何设计和实现领域事件,可以参阅ThoughtWorks咨询师滕云的文章:《在微服务中使用领域事件》

在实现事件驱动的架构时,当然可以沿用传统的SOA架构中的消息中间件。但由于微服务架构中,业务逻辑都存在于各个服务内部,没有庞大臃肿的ESB(稍后我们还会详谈这个问题),因此消息机制也不需要强大的服务编排(orchestration)能力。RabbitMQ这样标准的消息代理当然很好,也有很多系统(例如Bahmni)采用更简单的做法:领域事件发生时,以ATOM格式发布;关心特定领域事件的其他领域模型则订阅特定的ATOM feed主题。这种基于HTTP的事件传播方式最大的好处就是简单,几乎不需要增加新的软件就可以实现。不过这个方案在处理低延迟的场景时表现不佳。

公共网关

微服务提供的API粒度与客户端的需求不同,所以客户端一个请求经常需要多个服务;服务端和客户端之间可能需要通信协议转换;不同的客户端对数据的需求不同,例如浏览器客户端需要的信息可能多于移动客户端;服务的终端信息(主机+端口)可能变化;不同数据片可能由不同的服务终端来提供——以上这些因素都指出:有必要对服务做一层门面封装,提供API网关作为所有服务使用者的单一入口点。

API网关处理请求的方式有两种:一种是直接代理/路由给合适的服务;另一种是由一个请求扇出/分发给多个服务。API网关可能针对不同客户端提供不同的API,可能包含针对客户端的适配代码。横切需求(例如安全)也可能在API网关实现。

当服务数量变多、API网关变大以后,维护一个通用的API网关会增加API网关层的复杂度,导致一个独立的“API团队”出现,协调和沟通的工作量加大。这时可以考虑引入公共网关的一个变体:为特定前端设计的后端(Backend For Frontend,BFF),即为每个前端应用提供一个单独的API网关,使对齐业务的一体化团队能够拉通前后端开发、而不必等待“API团队”完成他们的backlog。

API网关可以实现为一个独立的服务端应用,其代价则是增加一层复杂度(和出错的可能性)。为了降低这一代价,可以考虑用Zuul等工具来实现API网关。

微服务SOA拓扑

与传统的SOA架构相比,所谓“微服务”最大的特点可能就在于没有一个重量级的ESB。重量级的ESB有其历史原因。在2000年代业界刚开始采用SOA时,很多企业尽管把业务系统包装成了web服务,但IT团队的组织结构并没有发生改变,仍然是由一组人集中式地掌管整个业务流程——只不过系统集成的方式不再是直接的方法调用,而是服务编排(orchestration)。原本存在于集成代码中的复杂逻辑,现在被转移到了ESB中。而这个“ESB团队”成了IT交付的瓶颈:不论发布事件的服务还是消费事件的服务、或是编排逻辑本身的改变,与事件相关的变更都需要通过ESB团队。这个团队的backlog堆积起来,使得每个服务、每个应用都无法提供快速响应。

微服务架构更重视服务与业务的对齐。贝索斯所说的“两个pizza的团队”不仅负责一个IT系统的交付,而且要负责用这个IT系统来支撑一个业务的成功。为了做到单个服务能够独立开发、独立部署、独立运行,这支团队应该能够在很大程度上掌控自己的进度,而不依赖于一个集中式技术团队的进度。因此微服务应该通过服务注册与发现机制获得自己需要的依赖服务、自己判断是否要直接调用或订阅依赖服务的事件,每个服务包含与其业务对应的复杂度,而不是把整个系统的复杂度集中在ESB和编排逻辑上。整个系统的架构(以及团队的架构)应该呈现为若干个端到端拉通的、与业务对齐的纵切服务,而不是一个横切的大块(ESB)覆盖所有业务。

小结

为了激活企业线下资源、打造行业线上生态,IT需要一套有效的服务API和架构治理方法。首先从领域驱动设计入手,划分出合理的限界上下文和服务边界,然后用异步消息机制来描述领域事件。设计好的服务通过API网关或BFF暴露给前端应用,把依赖关系和集成逻辑约束在与业务对齐的一体化团队内部。在整个服务架构的设计中,需要保持对开发者体验的关注。顺畅地将企业资源服务化,这是企业数字化旅程的第二步。

了解更多关于数字平台战略的信息,可下载《数字平台战略》白皮书。


更多精彩商业洞见,请关注微信公众号:ThoughtWorks商业洞见

Share

数字化企业的交付基础设施

前文中我们说到,传统企业在逐步建设自己的数字平台过程中,需要抓住交付基础设施、API和架构治理、数据自服务、创新实验基础设施和监控体系、用户触点技术这五个支柱。那么,当我们谈“交付基础设施”,我们究竟在谈什么?怎样的交付基础设施能加速数字化项目的交付?

什么是交付基础设施

云时代的研发环境应该以原生支持云计算的方式提供、管理和维护。在提供基础的弹性计算能力的IaaS平台之上,交付基础设施负责为交付团队提供便利的、最好是自助式的工作环境,让交付团队专注于交付软件的功能性需求,而不必操心软件功能之外的“脚手架”工作。按照ThoughtWorks数字平台战略的定义,这些脚手架包括:

  • 弹性基础设施,交付团队使用底层云计算平台的方式,既包括各种虚拟机和镜像的管理,也包括生产环境的水平伸缩能力。
  • 持续交付流水线,交付团队编写的代码需要通过这条流水线最终变成可以上线运行的软件。
  • 部署运行时,软件在开发、测试、试运行、用户验收、培训、生产等各种环境需要部署的环境。
  • 监控,为交付团队提供生产环境(及其他环境)的可观测性,方便他们发现和解决问题。
  • 安全,把安全内建在软件的研发过程中,尽量避免因为人为失误造成安全隐患。

从前这些交付基础设施脚手架通常是由每个交付团队的技术领导者(Tech Lead)来负责搭建和维护的。并且由于软硬件资源的稀缺和不灵活,团队经常需要微调自己的实践来适应不同的环境。所以,即使在同一家公司,各支团队所使用的交付基础设施也可能大相径庭。交付基础设施不一致、不规范的情况会迫使团队花费额外的精力去操心脚手架工作,并且使最佳实践不易推广普及。走上数字化道路的企业必定有大量的软件项目,尤其是微服务架构风格的引入会使企业拥有数量更多、单体规模更小的软件应用,此时交付基础设施不一致、不规范的情况就会对企业的数字化进程带来更大的阻力。

云计算带来的弹性和灵活性让组织级的交付基础设施标准化、规范化成为可能。一个跨越项目团队的、组织级的交付基础设施团队现在可以在IaaS的基础上封装标准的脚手架,甚至把脚手架本身以PaaS的形式提供给交付团队。通过把整个企业优秀技术领导者的知识与经验内嵌在交付基础设施脚手架中,降低了对单个交付团队的技术要求,帮助企业缓解优秀技术领导者难以获得的人才挑战。从这个意义上,以PaaS形式提供的交付基础设施本质上是技术领导者作为服务(Tech Lead as a Service)的云计算应用形式,它解决的是优秀技术人才的弹性和灵活性问题,让企业能够以一种创新的方式使用这些人才。

架构师写代码吗?

关于“架构师是否应该写代码”这个问题,业界有各种不同的声音。在敏捷的社区里,意见倾向于认为架构师需要写代码,因为这是他们获得关于技术决策的反馈和建立技术领导力的重要方式。将交付基础设施明确提出来,就给了架构师又一个清晰的编程目标——他们需要用代码的形式描述软件交付中的基础设施和最佳实践。除了培训、开会、代码评审等我们已经知道效率并不太高的方式以外,架构师对交付团队的指导和监管现在可以用实实在在的代码来承载。当交付团队不理解架构师说的某件事应该怎么做,现在他们更有理由要求架构师“show me the code”。

交付基础设施解读

下面我们来看看,在“交付基础设施”这顶帽子下面,架构师/技术领导者们究竟应该关心哪些问题,又有哪些最佳实践应该被纳入他们的视线。

弹性基础设施

允许交付随需获得计算能力。在微服务语境下,这种弹性有两层常见的含义:在生产环境下,服务可以随负载动态获得和释放计算资源,从而更高效地使用计算资源,更自动化地应对负载变化;在研发环境下,开发、测试、运维等不同角色可以随需动态获得完整的环境,从而统一环境、标准化研发实践、规范化研发能力,并且给研发提供体验更好的开发环境。

为了实现弹性基础设施,一方面基础设施需要支持弹性,例如使用支持弹性计算的公有/私有云,并且有对生产环境的监控和自动化手段;另一方面应用本身需要有可扩展性,例如服务能分别独立部署、无状态化、容器化、有透明的前端负载均衡机制。有状态服务(比如数据库服务)的弹性伸缩问题是特别需要考虑的重要挑战。

持续交付流水线

用持续交付实践打通微服务的开发、构建、验证和部署流程。在数字化、服务化的背景下,众多互相依赖的微服务形成的系统架构,对构建、验证和部署造成更大的压力:各个服务有独立的代码库和构建流程,又需要随时能组合成可用的软件;构建产物需要有统一的存储管理;完整的运行时环境应该能按需获得;配置和部署应该能快速准确地完成。

为了应对这些挑战,交付基础设施中应该包含完整的持续交付概念:流水线、环境管理、构建产物管理等。应该鼓励对服务虚拟化,最好是每个主机运行一个微服务,而不共享使用主机。应该包含配置自动化工具,例如Chef、Puppet等。在服务化的背景下,持续交付流水线需要体现服务间的依赖关系和团队间的协作关系,设计一个运转良好的流水线不是容易的任务。

部署运行时

交付基础设施应该包含生产系统所使用的运行时环境,并把生产环境前向拉通到验证和研发环节。为了在研发流程的出口得到服务化友好的交付物,最好是在整个开发过程中一直使用与生产环境近似的环境。例如开发人员应该使用全套环境随时验证,自动化测试和手工测试都基于全套环境开展。在这种情况下,环境的设置、管理、更新不可能由每个开发人员和测试人员自己进行,所以环境的管理更新必定是集中进行的,环境的设置必定是自动化的。

《技术栈管理:云时代的研发环境》一文中,我们已经介绍过“一个平台、两个PaaS服务、三个运行时环境”的技术栈管理理念。特别需要注意的是,如何将生产数据拉通到验证和研发环节。

监控

在微服务架构中,系统由多个小服务组成,且广泛使用异步通信,使问题和故障更难定位。因此交付基础设施需要提供全面可靠的监控机制,帮助交付团队了解系统的整体状况。

监控的实现涉及日志、服务指标跟踪、业务语义综合监控等方式。在云环境下如何划分和管理监控的层级,监控系统如何无侵入的在各个微服务体系中收集故障和信息,如何有效管理监控的反馈环,如何在前后端分离和移动应用情况下收集和监控客户端日志,都是常见的挑战。

安全

当数字化、服务化IT系统的数量剧增,安全的设置会变得更加复杂。在微服务架构下,系统的安全性需要有一个整体的考虑。例如单点登录、服务间的身份验证和授权、各种防御措施等安全考量不应该下放到交付团队,而应该被涵盖在交付基础设施中统一提供、统一管理、统一更新。

交付基础设施还应该鼓励安全实践内建(Build Security In),例如团队应该熟悉OWASP安全列表和测试框架、需求分析中应该包含安全需求和恶意用户需求、测试过程中应该包含安全性测试、应该进行自动化安全性测试并纳入持续交付流水线。这些流程与工作方法虽然不能完全以软件代码的形式承载,但它们同样是交付基础设施的重要组成部分。

小结

数字化、服务化的IT大背景会让企业开发和拥有的IT系统数量剧增。当企业IT交付更多地以“两个pizza团队”的形式组织,依赖于每个交付团队的技术领导者来搭建和维护一套完整高效的交付基础设施脚手架,这种期望即使不是完全不现实,也会对企业的人才积累提出非常高的要求。因此,企业应该集中优秀的技术人才(包括架构师们),打造一套标准的交付基础设施,充分考虑生产环境与研发环境的弹性、持续交付、部署运行时的统一、监控、安全等因素,并借助云计算的弹性和灵活性将其提供给交付团队。用便利的脚手架赋能一支能快速交付的团队,这是企业的数字化旅程的第一步。

了解更多关于数字平台战略的信息,可下载《数字平台战略》白皮书。


更多精彩商业洞见,请关注微信公众号:ThoguthWorks商业洞见

Share