财新传媒
《比较》 > 视界 > 正文

平台的演化发展:平台架构、治理和环境动态的协同演化

来源于 《比较》 2020年第1期 出版日期 2020年02月01日
可以听文章啦!
文丨艾姆里特·蒂瓦纳 本·康辛斯基 阿什莉·布什

  *Amrit Tiwana,佐治亚大学特里商学院教授;Benn Konsynski,埃默里大学戈伊祖塔商学院George S.Craft杰出讲席教授;Ashley A.Bush,佛罗里达州立大学商学院副教授。原文“Platform Evolution:Coevolution of Platform Architecture,Governance,and Environmental Dynamics”发表于Information Systems Research,Vol.21,No.4,2010第12月,第675—687页。

1.引言

  基于平台的软件生态系统,如火狐浏览器(Firefox)及8000个附加“扩展组件”,苹果iPhone操作系统(iOS)及14万个“应用程序”(App),正在发展成为软件开发和软件服务的主要模式。与传统软件开发不同,这些服务充分利用多元化开发人员群体的专业知识,创造性地开发平台原始设计人员没有预见的新功能,而这些开发人员掌握的技能和对用户需求的理解可能是平台所有者本身并不具备的。平台的概念是指市场营销(生产线)、软件工程(软件家族)、经济学[双向网络中将用户群体聚集到一起的产品和服务(Eisenmann et al.,2006)、信息系统(基础设施投资,Fichman,2004)和产业组织(成型系统,Katz and Shapiro,1994)]等不同事物。鲍德温和伍达德(Baldwin and Woodard,2009)总结了上述这些概念的共同之处,根据他们的归纳总结,我们将基于软件的平台定义为软件系统的可扩展代码库,它为那些与平台交互操作的模块提供共享核心功能,还提供模块交互操作的接口(如苹果公司的iOS和Mozilla基金会的火狐浏览器)。我们对模块的定义是:连接到平台并为平台添加新功能的附加软件子系统(如iPhone里的应用程序和火狐浏览器扩展组件)。我们将平台以及平台专用模块合起来称为该平台的生态系统(Cusumano and Gawer,2002)。图1列出了它们之间的区别,表1给出了相应定义。平台和平台专用模块的这种组合可以给对手平台制造强大的竞争壁垒。

3-1
点击观看大图
3-2
点击观看大图

  软件平台为信息系统(IS)研究带来了重大挑战和机遇,原因有六。

  第一,竞争正越来越多地转向以平台为中心的生态系统(Katz and Shapiro,1994),而研究信息系统开发的文献一直将独立系统视为主流。这种趋势主要见于浏览器(如火狐、Chrome和Opera),智能手机操作系统(iPhone和安卓),网络服务(谷歌支付、亚马逊云服务),社交媒体(Facebook、苹果的Ping命令),市场(SABRE、eBay),以及游戏机(Xbox、苹果的iPod Touch和索尼的PlayStation)。

  第二,传统概念中的企业边界正在扩展,企业正以前所未有的规模开发利用外部专业知识和独创性(如iOS的10万多个开发人员)。与此不同的是,公司内部的信息技术类职能的接口历来是信息系统研究中的系统创新中心。过去的信息系统开发研究无法应用在这里,因为传统的协调机制无法与当前规模相匹配。

  第三,这些平台的技术架构和组织原则共同决定了它们的演化轨迹,进而影响平台差异。生态系统这样的系统市场本身也是动态的(Katz and Shapiro,1994)。不过,信息系统的研究文献侧重于解释传统的绩效概念,强调可预测性,而不是解释系统如何随时间演化(Orlikowski and Iacono,2001),其演化轨迹的动态变化在管理学研究中也没有受到重视(Schilling,2000)。尽管架构的重要性在实践中得到了承认,但人们很少想到将它纳入信息系统的理论发展。平台生态系统在与模块开发人员相互作用时就像市场一样运作,但它们很少以现货交易为导向,因此在交互过程中需要大量协调(Katz and Shapiro,1994)。关于平台架构何时或如何促进这种协调的研究非常有限。

  第四,平台管理需要平台所有者的控制权和独立开发人员的自主权之间达到微妙的平衡。信息系统管控和信息技术管理方面的文献都没有谈到如何应对这种张力。

  第五,平台并非存在于真空之中,平台设计者的技术选择会影响平台对其环境动态的响应程度是好是坏。

  第六,信息技术构件历来不怎么出现在人们的视线中,要么被人视为一个巨大的黑匣子,要么成为“遗漏”变量(Orlikowski and Iacono,2001)。平台为信息系统学带来了一个难得的机会,可以让信息技术构件进入平台演化理论发展的核心领域,并贡献出不同于战略学、经济学和软件工程学的独到观点。这些问题与信息系统密切相关,因为如果在了解平台如何演化发展时,不考虑其技术设计属性,而仅仅从非信息系统的角度考量,就有可能误导人们忽视信息技术构件与其内外部环境的重要互动。

  本文的首要目标是:在平台所有者的内生设计、治理选择以及平台外生环境的动态变化如何影响平台演化动态方面,看看有哪些问题没有得到充分研究。虽然各个平台既争夺用户也争夺开发人员,但在本文中,我们只关注平台的供应方(开发人员),而不是需求方(消费者);只关注基于软件的平台(不包括基于硬件的平台);只关注那些在平台专用模块开发人员与最终消费者之间建立起连接的双向市场(因此不包括企业主要为自身使用、中介和单边市场构建的信息技术平台)。

  本文的其余部分内容如下。在第2部分,我们明确了五个概括性研究议题,这些议题涉及平台所有者内生选择与平台外生环境的协同演化如何影响第3部分所述的生态系统和模块在不同时间范围内的演化动态。我们在第4部分讨论了四个理论视角,在生态系统和模块层面建立起平台架构、管理和环境背景与演化动态之间的因果关联。在第5部分,我们阐述了这些研究议题的解决有可能带来哪些理论贡献。

2.平台的设计、治理和环境

  我们提出了一个总体思路,即平台生态系统及其模块的演化动态受到平台所有者的生态系统内生选择(如平台架构和管理)和生态系统外生环境动态的影响。根据这个三方协同演化观点,我们确定了五个概括性研究议题。每个问题都可以在生态系统或模块/平台这两个分析层面进行研究;分析层面不同,因果解释和潜在贡献也有所不同。

  图2列出一个研究框架,为后面的探讨提供了路线图。该框架所列的总体研究议题是:平台所有者的生态系统内生选择和平台外生环境动态如何影响生态系统和模块的演化动态。这一框架并不旨在包罗万象,而只是选取代表性示例。首先,我们会阐述平台架构、治理和环境动态及其协同演化的各项要素。它们构成了与我们的五个研究议题相呼应的核心研究要素。然后,我们会阐述演化动态在不同时期的不同方面,我们的研究既可以在生态系统层面也可以在模块层面,两种方法有可能带来不同但互补的贡献。随后,我们会探讨四个理论视角。我们认为,以这些视角为起点,可以从理论上为平台架构、治理和环境(以及它们的契合和不契合)如何影响演化动态提供中层解释。通过图2左侧和右侧要素的选择性组合,我们用示例说明了在理论构建中如何使用不同的视角。

3-3
点击观看大图

  2.1平台架构

  我们对平台架构的定义是:它是一种概念蓝图,阐述了生态系统如何被划分成一个相对稳定的平台、一套对之形成补充的模块(模块的变化在此是受到鼓励的)以及对两者都具有约束力的设计规则(参见图1,Baldwin and Woodard,2009;Katz and Shapiro,1994;Sanchez and Mahoney,1996;Ulrich,1995)。因此,平台架构将生态系统划分成了理想情况下具有低多样性和高复用性的平台代码库和在生态系统内展现高多样性和低复用性的模块(Baldwin and Woodard,2009)。第一组颇有成效的研究机会主要围绕下面这个研究议题:平台架构如何影响平台生态系统和模块的演化动态?

  我们面临的挑战是,平台架构的选择(这种选择往往是不可逆转的)必须适应平台创建时无法预测的变化(Baldwin and Woodard,2009)。它们必须允许单个模块得到修改,同时又不会破坏这些模块再次协同运作的能力;因此我们将这个问题标记为“蛋头先生问题”(Humpty Dumpty)。架构选择带来的商业影响是持久的,因为平台所有者可能会在相当长的一段时间内都受困于其中(Pil and Cohen,2006)。一个理想的架构应该支撑起当前的多样性以及日后的可演化性(Baldwin and Woodard,2009)。平台架构的属性可以从三个不同的角度进行研究:(a)分解,(b)模块化,(c)设计规则。

  分解。分解指的是平台生态系统的形式和功能如何拆分为原子子系统(Simon,1962)。它定义了哪些子系统和功能是平台代码库的一部分、哪些子系统和功能位于平台代码库之外以及两者的可分性。一个平台生态系统可以逐级分解成更小的子系统,直到进一步分解不再有助于描述和理解(这个原子层次是主观的)。平台或模块可被分解成的子系统数量代表了它的跨度(Simon,1962)。分解使生态系统组件在演化过程中的相互依赖性降到最低程度,它支持修改和变化,同时也有助于应对复杂局面。但是,这需要先期的设计成本,并且有可能不可逆转地限制或过度扩大生态系统各个组件的范围和跨度。后文我们会说到,这样的矛盾会带来演化方面的影响。

  模块化。模块化指的是子系统内部变化不会使生态系统其他部分的行为产生连锁反应[即我们所说的“封装”(encapsulation)]。与此相反,低模块化有可能导致生态系统因任何变化产生广泛而又无法预测的后果(Baldwin and Woodard,2009)。架构可以处于完全模块化和完全一体化之间的任何一点(Ulrich,1995)。模块化可以通过

  增加模块之间的解耦和标准化平台模块的接口来实现。所谓解耦,是指模块或平台内部的更改不会影响该生态系统其他部分的行为。因此,解耦会向生态系统的其他部分隐藏模块的内部决策,只突出其可见的外部特征。接口标准化代表了模块在多大程度上使用稳定且有据可查的预定义标准(比如,通过应用程序编程接口)与平台进行交互。因此,标准化降低了模块的资产专用性(Schilling,2000)。虽然模块化方面的研究文献声称模块化全面降低了模块的协调成本和交易成本(Baldwin,2008),但这一论点尚未得到实验的验证。一方面,提高模块化程度可以降低平台生态系统各组成部件之间的协调成本,释放开发人员的认知资源,使他们能够专注于更具挑战性的问题(Tiwana,2008a),并鼓励更进一步的专业化,从而推动生态系统组成部件差异化功能的开发。另一方面,它也有可能促进模仿,逐渐削弱模块和生态系统的独特性(Pil and Cohen,2006),缩小平台所有者的学习范围,导致协同专用性的丧失(Schilling,2000)。协同专用性是指平台通过模块之间的异质性实现功能增强。生态系统之间的相互依赖也是一个与此相关的问题,这个问题虽然超出了本文的研究范围,但是相当重要(比如,一个生态系统中的一个模块可能是另一个生态系统中的平台)。

  设计规则。设计规则是指平台所有者希望模块开发人员遵守的规则,以确保与其他生态系统的交互可操作(Baldwin and Clark,2000,2006)。设计规则有两个属性至关重要:它们在一段时间内相对于平台能够保持多大的稳定性;它们的多功能性(Baldwin and Woodard,2009)。设计规则的稳定性确保了不同时期加入平台的模块开发人员可以对生态系统的其他部分做出相同的设想而无须验证。然而,这种稳定性也意味着,设计规则的特性无法随时间推移而改变[比如,持续了30年之久的个人电脑视频图形阵列(VGA)标准],这就要求它们同时也得具备多功能性。多功能性意味着它们不能以降低生态系统整体多样性和灵活性的方式过度限制模块。因此,平台所有者面临的挑战是,如何使设计规则既足够稳定,可以充分约束开发人员,同时又足够灵活,不会过度限制开发人员。

  2.2平台治理

  我们对平台治理的定义是“谁做出有关平台的什么决策”。第二组研究机会围绕的研究议题是:平台治理如何影响平台生态系统和模块的演化动态?集中治理面临的一个挑战是,平台所有者必须保留足够的控制权以确保平台的完整性,同时又得放弃足够的控制权以鼓励平台模块开发人员的创新。一个平台的治理水平可能太高、太低或达到理论上难以捉摸的“恰到好处”,因此我们称之为“金凤花治理问题”。我们可以从三个不同角度研究平台的治理设计:(a)决策权分配,(b)控制权,(c)专属所有权与共享所有权。这三个角度从理论上来说就是:通过分享责任和权力进行治理,通过协调激励机制进行治理,通过共担利益进行治理。

  决策权分配。决策权分配是指平台所有者和模块开发人员之间如何分配决策权。决策权仅指谁拥有做出具体决策的职责。三大类决策权的划分将有助于未来的理论发展:(a)子系统应该做什么(比如,特点和功能);(b)它应该如何做(比如,设计、概念实施和用户接口);(c)谁控制生态系统的内部接口。接口可能持续更长时间并且比平台本身更稳定,同时它们也定义了模块的边界(Baldwin and Woodard,2009)。对接口的控制等同于对平台及其演化发展的控制(Baldwin and Woodard,2009);要想理解“如何”“为什么”之外的决策权,接口控制显得格外重要。因此,平台治理涉及如何在平台所有者和模块开发人员之间划分每类决策的权限和责任(即分权程度)。认为与平台相关的决策权必须完全属于平台所有者的观点是错误的(Baldwin and Woodard,2009),同样,与模块相关的决策权并不一定完全属于模块开发人员。还有一个更重要的问题,那就是他们应该如何以及何时分享决策权。决策权分配给开发人员的自主性和生态系统整体协调之间的平衡带来了张力;与模块相关的专业技能和知识是分散在模块开发人员之中的,但它们的输出又需要与生态系统的其他部分进行集成。根据分析单元的不同,中心子系统既可能是与单个模块相关的决策权,也可能是与生态系统相关的决策权。两者都是富有成效的选择,有可能产生不同类型的见解。

  控制。控制是指由平台所有者实施的正式和非正式机制,用以鼓励模块开发人员的理想行为,反之亦然。正式控制有两种形式:(a)输出控制(平台所有者预先设定标准,用以评估、奖励或惩罚模块开发人员的输出)和(b)进程控制(平台所有者为模块开发人员制定方法和步骤)。非正式控制是通过小团体控制实现的(培养共同的价值观、共同的信念和规范,以此指导模块开发人员的行为)。平台控制由于三个细微差别而显得与传统控制有所不同。第一,控制的前提是各方存在不同的利益。与此相矛盾的是,平台所有者和模块开发人员之间的关系并不像控制理论假设的那样(Kirsch,1997),是传统的委托代理关系(也就是说,平台所有者并不是聘用模块开发人员来完成自己指定的任务)。然而,我们在平台中普遍观察到各种控制机制。正如控制理论家普遍认为的那样,控制机制发挥的可能是协调作用,而不是减轻代理风险的作用。第二,平台所有者和模块开发人员不一定存在分歧,两者的利益也未必是零和博弈。此外,输入控制(Cardinal,2001),比如,苹果公司严格控制在其iTunes平台上发布的应用程序,在信息系统研究文献中基本上被忽略了。因此,开放式平台架构与封闭式平台架构仅仅代表了平台所有者在输入控制方面的差异。第三,控制可以是双向的,模块开发人员也可以同时对平台所有者施加控制。因此,从控制视角来看,平台治理在概念上可以被定义为不同控制机制的方向性、多样性和使用程度。

  专属所有权与共享所有权。治理的最后一个属性是平台本身是专属于单个公司还是由多个所有者共享(Eisenmann et al.,2006)。这一属性在概念上不同于开放式与封闭式架构的区别或者开放源代码与封闭源代码的区别,也不应该与之混淆(详细论述请参见Gawer,2009)。(例如,谷歌Chrome浏览器是专有产品,但属于开放源代码;GNU Linux属于开放源代码,由多个开发人员共享;苹果的iOS是专有产品,属于封闭源代码。)这一属性可能影响平台的演化发展,因为它决定了平台的股权及所有权的分散或集中程度。

  2.3 内部契合:平台架构与平台治理的相互作用

  第三组研究机会与下面这个研究议题有关:平台架构和平台治理之间的内部契合如何影响平台生态系统和模块的演化动态。关于这种相互作用的理论发展,最重要的是互补性(替代)这个概念,也就是说,一方的增长会导致另一方的增长具有更多(更少)价值。平台架构可以加强(积极的交互)或弱化(消极的交互)平台治理对演化动态的影响,这是一个值得进一步发展的概念。此外,在架构随时间推移而变化的时候,治理的协同演化可能会影响生态系统组件的理想演化结果(接下来我们会在第4部分举例阐述这一点)。

  2.4环境动态

  第四组有望取得成果的研究机会与如下问题有关:生态系统的外生环境动态如何影响平台生态系统和模块的演化动态?这其中有三种环境动态尤其需要理论研究者予以关注。第一,技术发展轨迹,如互补和替代技术出现的快速性、不均衡性、范围和不可预测性,可能会影响平台生态系统和模块的演化。由于数据、视频、语音和硬件的整合,与生态系统邻近的应用领域的技术变化可能对生态系统的演化轨迹产生积极和消极的影响。这种技术融合可能提供机会,使平台扩展到邻近但不相关的领域,同时允许不相关平台在多产品组合中提供中心平台的功能(Eisenmann et al.,2006)。因此,技术融合带来了包抄(envelopment)机会,这其中尤为重要的原因是邻近平台的用户和开发人员经常是重叠的(Eisenmann et al.,2006)。比如,iPod等数字音乐播放器已经扩展到电影播放器、电子邮件等相邻应用领域,并具备了个人计算机、支付设备和导航系统的网络功能。第二,多归属成本(Armstrong and Wright,2007),或者说开发人员与多个平台打交道的成本,会影响中心平台的发展。归属成本代表开发人员为保持与平台的联系而产生的适应成本、运行成本和机会成本的总和。当多归属成本过高时,模块开发人员需要有很好的理由才会加入多个平台(Eisenmann et al.,2006)。平台竞争对手提供的开发工具包在降低开发人员的多归属成本方面能起到什么作用呢?它们又如何影响生态系统层面的演化?卡茨和夏皮罗(1994)描述的“适配器”在克服平台竞争对手之间的不兼容性方面能发挥什么作用?竞争平台通过向模块开发人员提供软件开发工具包、适配器或兼容接口,降低多归属和切换成本,在这个过程中他们可能造成卡茨和夏皮罗(1994)所说的“倾斜”(tipping),即竞争平台开始让开发人员逐渐远离中心生态系统。第三种环境动态是直接或间接为一个或多个平台提供服务但不属于模块开发人员的互补者(complementors)施加的力量或影响。具体的例子包括服务提供商和监管机构,前者如,AT&T(美国电话电报公司)为苹果iPhone提供网络带宽,华纳兄弟向Netflix(网飞)提供电影内容;后者如,联邦贸易委员会和联邦通信委员会。平台所有者和互补者之间的利益可能存在分歧,这种内在的矛盾可能影响生态系统的演化动态。

  2.5 环境契合——环境动态与平台内生属性的相互作用

  第五组有前景的研究机会围绕着下面这个问题:生态系统内生属性(架构、治理)与其外生环境动态之间的环境契合如何影响平台生态系统和模块的演化动态?环境动态可能影响平台生态系统的内生决策,也可能受其影响。比如,适用于一种环境的架构和治理选择可能并不适用于另一种环境;因此我们将这个问题标为“锤子和钉子”问题。平台所有者的内生选择会影响预期、促进协调并实现生态系统之外的兼容(Katz and Shapiro,1994)。平台所有者的选择与平台赖以存在的环境之间不契合既可能加速平台的死亡,也可能为平台繁荣发展提供条件。比如,平台治理与环境动态的不契合可能导致平台所有者不能很快意识到包抄机会,而与架构的不契合又可能导致平台所有者无法很快调动资源利用这些机会。相比之下,在生态系统中嵌入各种实际选择权的架构可能使主动包抄攻击成为可能。当技术迅速或非匀速发展时,架构选择可能在新的输入出现时允许或阻止平台扩展其生态系统。这个问题也关注到了某些内生选择在什么时候是合适的(而非是否合适)。举例来说,平台模块化还涉及事先投入的初始成本,因此,生态系统什么时候进行模块化以及进行到什么程度比较合适,是一个有待回答的问题。围绕这些问题的理论发展有可能着重研究图2中平台设计/治理与环境动态的相互作用以及它们的协同演化。此外,随着平台外生环境动态的变化,平台架构和治理的协同演化可以将平台生态系统引向更为理想的演化轨道。在有关内部契合和环境契合的理论发展取得足够进展之后,我们相信研究两者之间的元契合(metafit)有望取得成效。

  [《比较》印刷版,点此订阅,随时起刊,免费快递。]

版面编辑:杨胜忠
财新私房课
好课推荐
财新微信


热词推荐
中央军事委员会 e租宝登记平台 郭瑞民 陈小鲁 阿根廷总统 立法法 社会抚养费 非洲象 三年自然灾害 武警部队 二胎政策 陈有西 朱明国 王传福 宏观调控