SaaS服务设计决策模型

提供软件即服务：一个设计决策模型

摘要

本文通过一个理论模型，研究了软件即服务（SaaS）提供商如何做出不同的设计决策。我们考虑了两个非功能性属性：软件架构的模块化和服务的架构性能。我们对这两个属性与用户偏好、用户需求以及服务价格等因素之间的关系进行了建模。与传统的信息系统产品开发模型显著不同的是，我们引入了提供SaaS服务的边际成本和维护成本，以体现SaaS服务兼具产品和服务双重特性。我们展示了在考虑用户偏好、用户需求和服务价格等相关因素的前提下，如何找到能够最大化SaaS提供商利润的设计属性的最优值。本研究提供了SaaS提供商进行最优设计决策的首批分析模型之一。我们进一步利用该模型说明，SaaS提供商应如何根据用户偏好、相关成本及其他相关因素的变化调整服务设计。

关键词 云计算 软件即服务（SaaS） 模块化 架构性能

1 引言

“云计算”已变得如此流行，以至于在2012年被作为新词收入英语语言，其定义如下：将常用计算机数据存储在可通过互联网访问的多台服务器上的实践（韦氏词典2012年）。美国国家标准与技术研究院（NIST）提供了一个更技术性的定义：云计算是一种模型，旨在实现便捷、无处不在的按需网络访问，连接可配置的计算资源共用池（例如网络、服务器、存储、应用程序和服务），这些资源可以快速部署和释放，只需最少的管理工作或服务提供商交互-（Mell和Grance2011）。云计算既指通过互联网以服务形式提供的软件应用，也指提供这些服务的数据中心等硬件基础设施；这些基础设施本身也被作为服务提供。在云环境中以服务形式提供的软件应用被称为软件即服务（“SaaS”）（Armbrust等2010）。本文探讨了在软件即服务（ SaaS）背景下，服务提供商在服务设计中的作用。具体而言，我们构建了一个模型，针对SaaS提供商面临的两个主要设计决策——模块化和架构性能，以深入理解云计算这一快速演进且极为重要的组成部分。

云计算近年来经历了爆炸式增长。根据国际数据公司（IDC）的数据，2017年全球公共云服务支出将达到1220亿美元，预计到2020年将达到2034亿美元。软件即服务（SaaS）解决方案将占这一支出的约60%（IDC2017）。

SaaS的快速增长由Salesforce.com、SAP、甲骨文和微软等SaaS提供商的创新市场产品所推动（Kanaracus2013）。Marstonetal.（2011）将 SaaS提供商视为云计算的关键利益相关者，并详细说明其角色包括拥有和运营云计算系统以向第三方提供服务、执行系统的维护和升级、维护在云上使用的软件以及云服务的定价。

对于SaaS应用，提供商负责设计、开发、部署和运营该应用。近期的研究主要关注SaaS提供商。Ma和Seidmann（2008）研究了服务提供商在与传统软件提供商竞争时的定价策略。Jiang和Seidmann（2014）研究了服务设施的容量规划。Choudhary（2007a, b）表明，与永久许可相比，SaaS模式会导致更高的产品开发投资和更高的软件质量。Marston等（2011）在云计算的研究议程中指出了与SaaS提供商相关的若干问题，如定价策略、SaaS提供商的经济价值、风险转移等。然而，关于SaaS提供商在设计服务本身时所面临决策的研究却很少。本文试图通过探讨SaaS提供商面临的两个重要设计决策——模块化和服务的架构性能，来满足这一研究需求。

软件开发已被广泛研究，关于软件开发组织的研究文献非常丰富。尽管现有的软件开发研究为研究SaaS提供商提供了良好的基础，但SaaS提供商与传统软件开发者存在显著差异，主要原因在于SaaS应用与传统软件有显著不同。例如——传统软件被认为具有较高的开发成本和可忽略不计的生产边际成本（Krishnan和Zhu2006）。而软件即服务则可能涉及维护基础设施和服务提供的显著边际成本。同样，传统软件开发通常关注特定客户或用户的需要，而SaaS应用通常被设计用于满足具有不同需求的广泛用户群体。本文尝试借鉴经济学、市场营销和服务科学领域的研究成果，以补充现有软件开发文献中的理解，从而体现SaaS及其提供商相较于传统模式的不同特性。

云计算尤其是SaaS，是服务化趋势的一部分，即从产品与服务二分法转向产品服务连续体（Vandermerwe和Rada1989）。从产品制造商向服务提供商转型带来了显著的管理挑战，而目前可用于指导这一转型的文献却十分有限（Oliva和Kallenberg2003）。Demirkan和Dolk（2013）讨论了理解服务生态系统的必要性。这为新颖的研究提供了机会，特别是针对集成产品服务提供的设计研究（Baines等2009）。Rai和Sambamurthy（ 2006）认为，服务管理日益增长的兴趣为信息系统（“IS”）研究人员带来了研究机遇，特别是在数字化支持的服务设计原则方面。Benlian等（2011）开发了一种用于评估SaaS中软件质量的度量方法，并呼吁进一步研究SaaS服务设计以提高服务质量。其他研究人员也强调了在服务提供商面临的服务设计与部署问题上进一步研究的必要性（Spohrer和Maglio2008； Demirkan等2009；Zhang和Seidmann2010）。本文响应这一研究呼吁，聚焦于服务提供商在SaaS背景下面临的挑战。

本文其余部分结构如下。下一节回顾了多个研究学科的相关文献。在第 3节中，我们构建了一个服务提供商设计与部署决策的分析模型。第4节展示了该模型的结果及其管理和研究解释。然后在第5节中，通过讨论结果、其影响、研究局限性以及提出进一步研究的方向，我们对全文进行总结。

2 文献综述

关于云计算的文献仍在不断发展。在本节中，我们将首先回顾现有的有关云计算的相关文献，然后通过探讨软件开发和服务领域的相关文献来加深我们的理解科学、市场营销、经济学和运营。我们将文献综述的重点放在SaaS提供商以及软件即服务的两个非传统属性——模块化和架构性能上。

云计算被Vaqueroetal.（2008）定义为：一个易于使用且可访问的虚拟化资源（如硬件、开发平台和/或服务）的大型池。这些资源可以动态重新配置以适应可变负载（扩展），从而实现最优资源利用。该资源池通常采用按使用付费的模型，基础设施提供商通过定制化的服务级别协议（SLA）提供保障。上述定义指出了两个主要利益相关者：基于云的服务提供商和服务客户。本研究聚焦于服务提供商。该定义还表明，服务提供商可以提供一系列服务。

服务可以根据为客户提供特定访问和控制的类型，以不同的抽象层次提供。基于云的服务通常被分为以下三个抽象层次：

• IaaS—基础设施即服务 IaaS是将硬件及关联软件作为服务进行交付。它允许用户按需配置资源。IaaS提供商的责任仅限于保持数据中心的正常运行，而用户则自行部署和管理软件服务（Bhardwaj等etal.2010）。典型的 IaaS示例包括亚马逊弹性计算云（EC2）和安全存储服务（S3）。

• PaaS—平台即服务 PaaS在IaaS的基础上提供了更高的抽象层次。除了硬件基础设施外，PaaS还为用户提供用于开发和运行自身系统的软件平台（ Vaqueroetal.2008）。著名的例子包括谷歌AppEngine和微软Azure。

• SaaS—软件即服务 SaaS允许客户使用在云基础设施上运行的提供商应用程序。这些应用程序可通过Web浏览器等界面进行访问（Mell和Grance2011）。SaaS使提供商能够通过在其自身的IT基础设施或从IaaS提供商处获取的基础设施中托管信息系统应用，将IS应用作为服务提供给客户。在这种情况下，客户仅需最少的IT基础设施即可消费该服务。客户仅拥有有限的用户特定配置能力，且不管理或控制底层基础设施和应用平台（Ho¨fer和Karagiannis 2011）。常见的示例包括GSuite、SalesforceCRM、微软Office365。

在三个类别中，软件即服务处于最高抽象层次，因为客户可以通过云基础设施访问一个完全开发的、自给自足的软件服务。SaaS提供商承担软件即服务的设计、开发和交付的全部责任。本研究聚焦于SaaS提供商在设计软件即服务时面临的设计决策。

已有一些发表的研究尝试通过分析模型的视角来研究云计算，特别是提供商的决策。Niyato等（2011）采用分层合作博弈模型研究了多个云服务提供商之间的合作，以探讨当合作能够带来更高利润时，云服务提供商的决策行为。Toosi等（2011）研究了在云联盟背景下，IaaS提供商提高资源利用率的问题。云联盟允许提供商之间相互交易资源，以克服其本地基础设施中的资源限制（Rochwerger等2009）。延续这一思路，Goiri等（2010）建立了一个云联盟运营模型，用以研究提供商如何利用联盟提升自身利润。Carroll和Grosu（2010）则通过博弈论框架分析了类似的虚拟组织概念，设计了一个支持虚拟组织的资源管理系统。尽管上述研究为分析云计算提供商的决策提供了基础，但据我们所知，尚无研究构建针对SaaS提供商设计决策的模型。本研究试图弥补这一空白。

SaaS架构和服务设计已引起广泛的研究关注。本文的文献综述聚焦于 SaaS服务设计中对本研究至关重要的两个方面：模块化和架构性能。

在产品、服务和系统（包括信息系统）的设计中，模块化已被广泛研究。然而，模块化仍然是一个定义模糊的构念。在服务模块化的背景下，Hyo¨tylainen和Moller（2007）认为，模块化的目标是将独立功能打包，使得同一模块内的功能具有尽可能多的共性，并且模块本身尽可能可重用。Booch（1993）将模块化定义为系统被分解为一组内聚且松散耦合模块的属性。耦合是指两个模块之间的相互依赖程度，而内聚性是指模块自身的单一功能性（Yourdon和Constantine1979）。在采用面向服务的架构(SOA)作为其架构模型的信息系统应用中，软件服务通过其服务接口进行访问。因此，如果客户使用服务接口构建自定义应用程序，服务提供商可以在不影响服务接口的前提下修改模块内部的元素，从而不影响客户，使得模块的更新或替换变得更加容易（Janssen和Joha2008）。

在他的开创性贡献中，Parnas（1972）讨论了模块化设计作为一种提升系统灵活性和可理解性的机制，同时能够缩短系统的开发时间。软件架构中的模块化允许信息隐藏或抽象，并将大型程序分解为模块，从而简化软件开发过程（Parnasetal.1985）。研究表明，模块化架构能够提高灵活性，并降低适应与协调的成本与难度（SanchezandMahoney19962000）。在服务设计方面，Pekkarinen和Ulkuniemi（2008）确定了模块化的四个维度：服务、流程、组织和客户界面；并表明模块化可用于更灵活且高效降低成本地开发和交付服务。Hsu和Lin（2016）研究了企业对云服务的采纳。Ruleetal.（2008）讨论了衡量设计模块化的方法。

软件架构中的模块化也被证明会影响软件的维护成本。维护成本已被证明与模块的大小成正比；此外，非模块化产品的维护成本高于模块化产品（Banker等1993）。设计中的模块化长期以来被认为是应对设计复杂性负面影响的有效机制（Baldwin和Clark1997，2000；Welch和Waxman 2003）。具体而言，模块化可通过按订单组装实现大规模定制，即通过少量模块构建出大量不同的配置（DaCunha等2007）。Vitharana等（2004）指出，商业战略和管理目标可指导模块化、基于组件的系统的设计，以提高业务与IT的一致性。模块化程度已被证明能够支持深度定制和快速新产品开发（Voss和Hsuan2009）。架构中的模块化使得不同模块之间的捆绑更加容易，而捆绑已被证明可提高生产者的利润（Bakos和Brynjolfsson1999）。Chidamber和Kemerer（1994）提供了一个面向对象设计的综合度量套件。它包含六个软件架构设计度量，例如类间耦合、方法内聚性不足、类的响应，可用于实际应用。该度量套件的设计基于坚实的理论基础，并已在两个大型实际工业项目中进行了测试。

具有模块化架构的软件通常被认为是更优的软件。SaaS服务中的模块化尤为重要，因为它会显著影响客户与服务的交互方式。例如——研究发现， SaaS中的模块化架构在实现任务分解方面具有重要作用，从而有助于更轻松地进行管理，并通过强激励机制进行治理（Susarla等etal.2010）。作为最成功的SaaS提供商之一，Salesforce.com的销售业绩和客户基础持续增长，这归功于其应用程序编程接口（API）Force.com所提供的灵活性，该接口允许用户快速组装自己的定制化应用。Salesforce.com网站指出： Force.com提供了60个预定义组件，这些组件可在构建-blockfashion时几乎无需编码即可组装。其中一些组件实现了常见的Salesforce界面元素，而另一些则提供了新功能，例如基于AJAX-的部分页面刷新（Salesforce.co m2014）。同样，对于另一个成功的云计算提供商亚马逊网络服务，其产品管理和开发者关系副总裁指出：为了使外部开发者能够访问其能力，亚马逊将其流程分解为许多模块化服务。这种模块化使亚马逊能够将其业务扩展至提供完整的在线零售环境（PWC2010）。因此，我们可以得出结论：模块化架构在SaaS中是可取的，并且可以带来更高的客户需求。然而，SaaS客户对SaaS服务架构的模块化可能具有不同程度的偏好。在本研究中，我们特别考虑客户对模块化的偏好，并构建我们的模型，以允许SaaS提供商设计具有最优模块化水平的服务，从而最大化其利润。Voss和Hsuan（2009）认为，模块化这一概念在服务设计中的应用尚未达到显著程度。我们通过明确考虑服务提供商在所提供服务中构建模块化水平的决策，来弥补这一研究空白。

关于架构性能的文献并不十分丰富。在此，我们对架构性能与运行性能做出了重要区分。我们认为架构性能是软件架构的一个属性——即该架构是否支持高水平的性能。因此，本文所定义的架构性能可被视为一种设计特征。相比之下，服务也可以通过投入更多资源（例如在SaaS情况下增加带宽、更强处理能力、更多存储等）来实现更高的性能，但这会导致成本上升。然而，这并非本研究的重点，因为我们仅关注服务的设计阶段，而非交付阶段。做出这一区分对于SaaS而言是必要的，因为SaaS兼具产品和服务的特性（ Vandermerwe和Rada1989）。其中，架构性能与SaaS的产品部分相关，而运行性能则与SaaS的服务部分相关。

影响性能的软件架构特征在软件工程文献中已得到广泛研究。研究表明，软件架构对软件性能具有显著影响（Williams和Smith1998）。确定最优架构是一项重要决策，因为架构在设计阶段即已确定，若后期软件出现性能不足，难以轻易更改（Williams和Smith2002；Balsamo和Marzolla 2005）。架构性能对于SaaS提供商尤为重要，因为SaaS架构通常包含虚拟化和资源时间共享等特性，这些可能对服务性能产生显著的负面影响（Iosup 等2008）。此外，信息系统服务的性能已被证明对服务的定价和需求具有重大影响。例如——在线服务的更高性能已被证明可使供应商收取更高的价格（Jain和Kannan2002）。Hosanagar等（2005）研究了性能对信息系统服务定价的影响，并表明即使客户可获得免费服务，服务提供商仍有可能就增值服务收费。

一些研究者主张在软件开发过程中，特别是在软件设计阶段，集成性能分析（Balsamo等2004）。传统软件开发方法主要关注功能需求与软件正确性或无缺陷开发，而将性能问题留到开发过程的后期考虑。这种方法未考虑到性能问题可能需要对软件架构进行重大修改。本研究试图通过在服务设计阶段引入性能考量，并明确将架构性能作为提供商决策的关键要素，来弥补这一研究空白。我们从一个直观假设出发：更高的运行性能将导致更高的客户需求。由于更高的架构性能会带来更高的运行性能，因此我们得出结论：更高的架构性能将导致更高的客户的需求也是如此。然而，与模块化类似，我们允许软件即服务的客户在对架构性能的敏感性上存在差异。因此，我们的模型允许提供商通过选择能够使其利润最大化的架构性能水平，来应对客户对性能的敏感性。

软件即服务定价是服务提供商做出的主要决策之一。Harmonetal.（ 2009）主张对信息技术服务采用创新的基于价值的定价，而非传统的基于成本的定价（Rohitratana和Altmann2012）。Rohitratana和Altmann（2012）利用基于代理的仿真模型表明，需求驱动定价方案对于SaaS服务而言是最有效的方法，但由于需要完全掌握市场状况而难以实施。本文通过分析特定情境下的最优定价，进一步推进了该领域的研究。

3 模型构建

我们采用理论建模技术进行模型构建。理论模型可分为两种不同类型——文字型或数学型。本文使用数学建模。数学模型包含针对所研究现象的适当变量，以及关于这些变量之间关系的合理假设和优化标准。例如——在本文中，我们以SaaS提供商的利润最大化作为优化标准。

建立数学模型后，研究人员通过考察数学模型中某些变量变化的影响来进行理论实验。根据上述理论实验的结果，提出命题，并从命题中揭示出现象的管理启示（Moorthy1993）。

我们首先对需求函数进行建模。我们假设存在一个垄断供应商，并考虑一个固定时期（即服务生命周期），在此期间提供软件即服务。然而，对服务的建模与对传统产品的建模有很大不同。服务可以被定义为生产者与客户之间建立的一种创造和获取价值的关系，其中客户积极参与（Gadrey2000； IBM无日期）。换句话说，在服务的情况下，客户可被视为共同生产者（ Fitzsimmons和Fitzsimmons2004）。这就要求我们以创新的方式对需求进行建模。当客户在整个完整生命周期内订阅该服务时，我们将其记为单位需求。我们将价格视为在整个完整生命周期内服务的总订阅费用。因此，客户可能仅在少于完整生命周期的时间段内购买服务，并仅支付总价的一部分。与传统产品不同，软件即服务的需求可能不是整数。

我们对模块化和架构性能对需求的影响进行建模。在信息系统领域，模块化和架构性能都不是新的概念。然而，我们认为有必要通过服务视角来审视这些概念，据我们所知，这方面的工作尚未开展。

库马尔（2004）指出，产品设计中的模块化使生产者能够提供大规模定制产品。德万等人观察到，通过使用大规模定制，生产者可以在不同价格下提供产品的不同变体，从而通过使产品吸引更广泛的客户群体而增加利润（Dewanetal.2003）。对于服务而言，生产者与客户之间的关系在整个服务生命周期中持续存在；通过使用模块化，生产者将能够对服务进行更改，并为客户进行适当的定制。因此，我们假设模块化水平的提高将导致对该服务的需求增加。

接下来，我们重点关注架构性能这一属性，因为它对服务具有一些独特的优点。设计为更高架构性能的服务，提供商可以在不改变基础设施的情况下，将其用于为更多客户提供更优质的服务。更高的架构性能将使服务对更多客户具有吸引力。因此，我们假设更高的架构性能将带来更高的需求。

我们假设一个线性需求函数，并引入模块化和架构性能对需求的敏感性，以捕捉SaaS提供商对客户在模块化和架构性能方面需求偏好的响应。尽管线性需求函数存在一些局限性，但在文献中被广泛使用，并被认为是一个合适的起点（Barua等1991；Choudhary2007a，b）。

$$ d = a - bp + cm + ds \quad (1) $$

其中，$p$是SaaS应用在其生命周期内摊销的价格，$m$是SaaS应用的模块化水平，$s$是SaaS应用的架构性能水平。

$a$是由于SaaS应用的功能属性以及其他非功能属性（如质量（不包括模块化和架构性能）、品牌形象、一般经济事实）而产生的主要需求，这些因素超出了本文的讨论范围。

$b$表示需求的价格敏感度，$c$表示模块化水平提高带来的需求增长，$d$表示架构性能提升带来的需求增长。

$a$、$b$、$c$和$d$均假设大于零。本文档中用于构建模型的所有术语均汇总于 “附录 1”中提供的术语表。

正如我们之前讨论的，我们还假设服务的需求和价格均在服务生命周期内摊销。如果一个客户在整个服务生命周期内订阅该服务，则价格是客户将支付的总金额，相应地，需求为一个单位。

接下来我们来构建成本函数。与传统信息系统不同，由于软件即服务不是开发密集型产品，因此对服务成本的建模要复杂得多，且SaaS提供商会产生三种不同类型的成本——固定和边际成本。我们将首先研究固定成本，它包括产品开发成本以及为向客户提供SaaS应用而建立必要IT基础设施的成本。

我们假设，开发模块化软件将需要供应商投入更多的生产成本（即更高的前期或固定成本）（Bush等2010）。同样，设计高性能架构也需要大量努力和时间，从而导致更高的开发成本。我们假设因模块化水平和架构性能提升而产生的固定成本分别为模块化水平$m$和性能$s$的二次函数。这与信息系统文献中的标准做法一致。例如——为提高产品质量所产生的固定成本是产品改进曲线斜率的凸函数（Choudhary2007a, b）。

我们可以将固定成本函数表示为：

$$ c_1 = A_1 + Cm^2 + Ds^2 \quad (2) $$

其中，$A_1$是由模块化和性能以外的因素引起的固定成本，$C$是应用程序设计和开发过程中与模块化相关的参数，$D$是应用程序设计和开发过程中与架构性能相关的参数。

先前的研究表明，模块化软件更易于维护且维护成本更低（Bankeretal.1993）。我们将维护成本（$c_2$）视为在产品生命周期内摊销的固定成本。因此，$c_2$可以表示为：

$$ c_2 = A_2 - Bm \quad (3) $$

其中，$A_2$是在产品生命周期内摊销的维护成本，$B$是与模块化相关的参数，表示由模块化设计带来的维护成本节约，该节约也已在产品生命周期内摊销。

现在我们转向边际成本。服务提供商在提供服务时会产生每项服务的边际成本，因为为了向大量客户提供服务，必须拥有持续且维护良好的IT基础设施。该边际成本由两部分组成：一是购买基础设施的一次性成本，二是维护基础设施和提供服务的可变成本。或者，基础设施可以从IaaS提供商处以服务形式获取，在这种情况下，边际成本仅包含可变部分。第三，还需要承担SaaS应用本身的维护成本。在我们的模型中，我们将维护成本和每产品的边际成本均视为在产品生命周期内摊销。

提供软件服务的边际成本是服务提供商特有的——传统软件供应商通常没有显著的边际成本。该边际成本既包括建立基础设施（如硬件、软件）的成本，也包括提供服务的摊销成本。因此，提供服务的边际成本$c_3$可视为与需求成正比： 因此，$c_3$可以表示为：

$$ c_3 = Zd \quad (4) $$

其中，$d$是服务生命周期内摊销的服务需求，$Z$是服务生命周期内摊销的单位服务提供边际成本。

将(2)、(3)和(4)相加，我们的总成本函数可以表示为：

$$ h = A - Bm + Cm^2 + Ds^2 + Zd \quad (5) $$

其中$A = A_1 + A_2$。

我们观察到，上述成本中大多数项与需求无关。因此，这表明规模经济在软件即服务中起着重要作用。

软件生产商的利润$\pi$可以表示为：

$$ \pi = dp - h $$

利用(1)和(5)，上述利润可以重写为：

$$ \pi = (a - bp + cm + ds)(p - Z) - (A - Bm + Cm^2 + Ds^2) \quad (6) $$

我们的目标是找到能够使上述利润函数最大化的最优价格$(p)$、模块化$(m)$和架构性能$(s)$的最优值。

3.1 边界条件

我们假设边界条件为：产品的主需求$a$大于边际成本$Z$与价格敏感度$b$的乘积，即$a > bZ$。

在任何信息系统应用中，可以合理地假设功能属性比非功能属性重要得多。尽管在此情况下非功能属性也很重要，但模块化和性能等非功能属性的重要性不太可能超过功能属性以及其他非功能属性（如安全性）。生产者不太可能仅基于模块化和性能来生产产品而不考虑其功能性。我们考虑一种情况，即性能敏感度（$d$）和模块化敏感度（$c$）均接近零，换句话说，客户并不关心产品的模块化和性能。根据方程（1），我们可以将需求函数重写为： $d = a - bp$。

在上述情况下，生产者不太可能生产预计需求为负的产品。因此，我们假设在这种简单的情况下，需求也应为正的。因此，我们得到：$a > bp$。

由于$Z$是单位边际成本，可以合理假设$p$必须始终大于$Z$，否则生产者生产任何产品都将无利可图。由于我们建模的是设计和生产阶段的情况，因此排除了亏本清仓的可能性。因此可得：

$$ a > Zb \quad (7) $$

我们将在模型中假设上述边界条件。

4 结果与分析

我们考虑两种情况。在第一种情况下，我们假设两个决策变量——模块化和架构性能——之间没有关系。在第二种情况下，我们假设模块化和架构性能相互关联。

4.1 案例1：模块化与架构性能无关

在此情况下，我们假设软件架构中的模块化与架构性能相互独立。为了找到使利润函数最大化的决策变量的最优值，我们对利润（方程6）分别关于$p$、$m$和$s$求偏导，令其等于零，并表示为$p^ $、$m^ $和$s^*$。经过一些简化后，我们得到以下表达式。

$$ p^* = \frac{a + Zb + cm + ds}{2b} \quad (8) $$

$$ m^* = \frac{B + c(p - Z)}{2C} \quad (9) $$

$$ s^* = \frac{d(p - Z)}{2D} \quad (10) $$

通过将$p^ $、$m^ $和$s^*$分别代入$p$、$m$和$s$来求解上述方程，我们得到决策变量的最优值如下所示。

$$ p^* = \frac{2CD(a - Zb) + BDc}{4CDb - Dc^2 - Cd^2} + Z \quad (11) $$

$$ m^* = \frac{4BDb + 2Dac - 2DZbc - Bd^2}{2(4CDb - Dc^2 - Cd^2)} \quad (12) $$

$$ s^* = \frac{(2Ca + Bc - 2CZb)d}{2(4CDb - Dc^2 - Cd^2)} \quad (13) $$

将(8–10)代入(1)和(6)，最优需求和利润可表示为：

$$ d^* = \frac{Db(2C(a - Zb) + Bc - 2C)}{4CDb - Dc^2 - Cd^2} \quad (14) $$

$$ \pi^* = \frac{4D(a - Zb)(Bc + C(a - Zb)) + B^2(4Db - d^2)}{4(4CDb - Dc^2 - Cd^2)} - A \quad (15) $$

基于上述需求和利润的最优值，我们首先对模型进行合理性检验，并验证模型是否能得出合理的最优值解。

引理1 当$4CDb > (Dc^2 + Cd^2)$时，所有决策变量以及最优需求和利润均为正值。

证明 上述条件源自海森矩阵。在本例中，海森矩阵是利润函数关于变量$p$、$m$和$s$的二阶偏导数。

$$
H =
\begin{pmatrix}
-2b & c & d \
c & -2C & 0 \
d & 0 & -2D
\end{pmatrix}
$$

为了确保利润存在局部最大值，海森矩阵的行列式需要是半负定的。当一个矩阵的各阶顺序主子式符号交替变化，且一阶顺序主子式为负时，该矩阵是半负定的（Winston 1993）。因此，三阶顺序主子式必须为负。唯一的三阶顺序主子式即矩阵本身的行列式，其值为$2(-4CDb + Dc^2 + Cd^2)$，从而得到以下条件。

$$ 4CDb > (Dc^2 + Cd^2) \quad (16) $$

我们注意到二阶第一主子式为$(4Cb - c^2)$。然而，当假设方程(16)成立时，它是正的。利用方程(16)以及边界条件，方程(11–15)中的分子和分母均为正的。

我们的模型考虑了两个客户参数——客户对模块化的敏感度$c$和客户对性能的敏感度$d$。该模型包含三个供应商决策参数——价格、模块化和架构性能。我们预期，客户对模块化敏感度的变化会影响供应商所提供的模块化水平以及针对特定模块化水平所收取的价格，从而影响需求。同样，我们预期客户对性能敏感度的变化会影响供应商所提供的性能水平以及针对特定性能水平所收取的价格，进而影响需求。我们将在以下命题 A1–A4 中探讨这些关系。

命题 A1 当客户需求对模块化更敏感时，供应商将提供更具模块化的产品，并能够收取更高的价格。这将为供应商带来更高的需求和更高的利润。

我们表明，如果所有其他参数保持不变，顾客对模块化的偏好增加将使供应商能够通过提供更高模块化的产品来收取更高的价格。由于该产品现在更能满足顾客的模块化偏好，供应商将面临更高的需求，并且还能够收取更高的价格，从而为供应商带来更高的利润。

命题 A2 当客户需求对性能更敏感时，供应商将提供具有更高性能水平的产品，并能够收取更高的价格。这将为供应商带来更高的需求和更高的利润。

与模块化的命题A1类似，命题A2为SaaS供应商提供了一条途径，即通过调整产品设计以更好地契合客户偏好，从而吸引更大的需求、收取更高的价格，并最终实现更高的利润。

客户仅感知服务的整体性能。这种性能可以通过更好设计（架构性能）或通过部署更好的操作参数（如更快连接、更强处理能力、更大存储容量等）来实现（运行性能）。尽管这两种途径都能带来更高的性能，但它们对成本的影响却大不相同。架构性能的提升依赖于更高的开发成本或固定初始成本，但不会影响持续边际成本；而运行性能的提升则可通过使用更好基础设施（导致更高固定成本）或更高效地运行和维护基础设施（导致更高边际成本）来实现。我们认识到，服务提供商可能选择不自行开发基础设施，而是从另一提供商租用其基础设施。然而，更好基础设施的成本仍然更高。

现在我们考虑模型中涉及的三个环境参数——与模块化相关的固定成本参数（$C$）、与架构性能相关的固定成本参数（$D$）以及提供服务的边际成本（$Z$）。命题A3探讨了与模块化相关的固定成本参数对最优价格、最优模块化水平和最优性能水平的影响。命题A4探讨了与性能相关的固定成本参数对最优价格、最优性能水平和最优模块化水平的影响。最后，命题A5探讨了边际成本对最优价格的影响。

命题 A3 当软件中提高模块化的成本增加时，最优模块化水平、最优性能水平和最优价格将降低，导致供应商的需求和利润下降。

命题 A4 随着提高软件架构性能的成本增加，最优性能水平、最优模块化水平和最优价格将降低，导致供应商的需求和利润下降。

命题A3和A4表明，随着提高模块化和架构性能的成本增加，价格以及最优的模块化水平和架构性能水平都会下降。值得注意的是，我们的模型得出了一个反直觉结果：某一成本要素的增加会导致价格降低。然而，这一结果在逻辑上是一致的。因为当提高模块化的成本变高时，在其他条件不变的情况下，SaaS提供商将无法获益。通过降低产品的模块化水平。相反，供应商将生产模块化水平较低的产品，并不得不接受该服务的较低价格。

命题 A5 随着边际成本$Z$的增加，最优价格：
- 当$b > \frac{c^2}{2C} + \frac{d^2}{2D}$时，增加
- 当$b < \frac{c^2}{2C} + \frac{d^2}{2D}$时，减少
- 当$b = \frac{c^2}{2C} + \frac{d^2}{2D}$时，保持不变

命题A5具有重要的管理启示。随着边际成本的增加，除最优价格外的所有决策变量均会下降。根据上述关于价格敏感性、固定成本及其他参数的不同条件，最优价格可能保持不变、增加甚至减少。

4.2 案例2：模块化($m$)与性能($s$)相关

模块化与性能之间的负相关关系在文献中已有明确论述（Ulrich 1995）。Lau Antonio 等（2007）指出，尽管产品设计中的模块化被认为是实现产品成功的关键推动因素，但模块化并不一定会改善产品的所有属性。互联网工程任务组(IETF)强调了模块化对性能的负面影响：“在追求良好性能的过程中，模块化是主要的罪魁祸首之一，因此设计者不得不在良好的结构与良好的性能之间进行微妙且不可避免的权衡”（Clark 1982）。因此，我们修改了模型，以包含架构性能与模块化之间的反向关系，即模块化水平$m$的提高会导致架构性能水平$s$下降，反之亦然。

我们首先假设模块化与架构性能之间存在以下关系：

$$ s = X - Ym \quad (17) $$

其中$X$和$Y$是参数。$X$表示最大性能水平，$Y$表示$s$随$m$变化的比率。同时可知，$m$的最大值为$X/Y$（当$s$为零时）。我们还注意到，$X$和$Y$都不是固定的。我们认为测量$X$和$Y$可能存在困难，仍需更多研究。然而，我们设想如果考察软件产品线领域（Bosch 2010），有可能估算出$X$和$Y$。如果一个软件项目通过持续集成实践（Sta˚hl et al. 2017），并在不同版本中测量诸如继承树深度(DIT)和子类数量(NOC)等广为人知的软件度量指标，则可以研究DIT或 NOC在不同版本中对架构性能水平的影响。利用这些数据，有可能开发出测量$X$和$Y$的度量指标。

使用方程(1)并利用方程(17)消除$s$，可将线性需求函数重写为：

$$ d = a - bp + (c - dY)m + Xd \quad (18) $$

使用(6)和(17)，我们可以将利润函数重新表述为

$$ \pi = (a - bp + cm + ds)(p - Z) - (A - Bm + Cm^2 + D(X - Ym)^2) = (a - bp + (c - dY)m + X)(p - Z) - (A - (B + 2DXY)m + (C + DY^2)m^2 + DX^2) \quad (19) $$

我们对利润分别关于$p$和$m$求偏导，令其等于零，然后求解$p$和$m$。在进行一些简化后，得到最优价格和模块化的如下表达式：

$$ p^*_{ms} = \frac{2(a + bZ)(C + DY^2) - Z(c - Yd)^2 + 2X(Cd + DYc) + B(c - Yd)}{4b(C + DY^2) - (c - Yd)^2} + Z \quad (20) $$

$$ m^*_{ms} = \frac{2Bb + 4DXYb + (a - Zb + Xd)(c - Yd)}{4b(C + DY^2) - (c - Yd)^2} \quad (21) $$

利用方程(17)和(21)，我们可以将最优性能表示为

$$ s^*_{ms} = X - Y\left(\frac{2Bb + 4DXYb + (a - Zb + Xd)(c - Yd)}{4b(C + DY^2) - (c - Yd)^2}\right) $$

$$ s^*_{ms} = \frac{4bXC - 2bYB - (c - Yd)(Y(a - Zb) + Xc)}{4b(C + DY^2) - (c - Yd)^2} \quad (22) $$

将(20–22)代入(18)和(19)，可得最优需求和利润表达式为：

$$ d^*_{ms} = \frac{b(2(a - Zb)(C + DY^2) + 2X(YcD + C) + B(c - Yd))}{4b(C + DY^2) - (c - Yd)^2} \quad (23) $$

$$ \pi^*_{ms} = \frac{B^2b + B(a - Zb + Xd)(c - Yd) + D((Y(a - Zb) + Xc)^2 + 4bXYB) + C((a - Zb + Xd)^2 - 4bDX^2)}{4b(C + DY^2) - (c - Yd)^2} - A \quad (24) $$

4.3 边界条件

我们对这个模型做出以下假设：
与案例1相同，我们假设方程（7）或$a > Zb$。

从方程（18）可以看出，需求函数的模块化敏感度为$(c - dY)$。可以合理地假设模块化敏感度永远不会是负的，即：

$$ (c \geq dY) \quad (25) $$

引理2 当$4b(C + DY^2) > (c - Yd)^2$时，所有决策变量以及最优需求和利润均为正值。

证明 海森矩阵是

$$
H =
\begin{pmatrix}
-2b & c - Yd \
c - Yd & -2C - 2DY^2
\end{pmatrix}
$$

为了确保利润存在局部最大值，海森矩阵必须是负半定的。当一个矩阵的各阶顺序主子式符号交替且以负号开始时，该矩阵为负半定（Winston 1993）。因此，二阶顺序主子式必须为正。由此可得

$$ 4b(C + DY^2) > (c - Yd)^2 \quad (26) $$

使用方程(26)以及上述边界条件，方程(20)、(21)、(23)和(24)中的分子和分母均为正的。

我们还假设$m$的最大值为$X/Y$。

因此，

$$ m^*_{ms} = \frac{2Bb + 4DXYb + (a - Zb + Xd)(c - Yd)}{4b(C + DY^2) - (c - Yd)^2} < \frac{X}{Y} $$

从上述不等式中，

$$ X(4b(C + DY^2) - (c - Yd)^2) > Y(2Bb + 4DXYb + (a - Zb + Xd)(c - Yd)) $$

$$ 4bXC > 2BYb + (Y(a - Zb) + Xc)(c - Yd) $$

上述不等式表明，方程（22）的分子为正的。因此，$s^*_{ms}$也是正的。

由于模块化与性能相关，我们无需分别考虑它们的影响。在这种情况下，我们将重点关注模块化。我们将首先考虑客户对模块化的敏感性对三个供应商参数——价格、模块化和性能的影响。我们在命题B1中探讨这些关系。由于命题B1的证明与之前已给出的命题A1的证明类似以及A2，为了简洁起见，我们仅在此提供以下命题。完整的证明已在“附录2”中给出。

命题 B1 当客户需求对模块化更敏感时，供应商将提供模块化程度更高的产品，并能够收取更高的价格。这将为供应商带来更高的需求和更高的利润。

现在，与案例1一样，我们考虑模型中所涉及的环境参数的影响。由于下面的命题B2与其在案例A中的对应命题类似，因此为了简洁起见，此处仅给出命题，其证明完整地提供在“附录2”中。

命题 B2 随着产品中引入模块化的成本增加，供应商将降低最优模块化水平、最优性能水平和最优价格，从而导致更低的需求和利润。

命题 B3 随着边际成本$Z$的增加，最优价格：
- 在$b > (c - Yd)^2 / 2(C + DY^2)$时增加
- 在$b < (c - Yd)^2 / 2(C + DY^2)$时减少
- 在$b = (c - Yd)^2 / 2(C + DY^2)$时保持不变

与案例A类似，我们得到一个解决方案：当边际成本增加时，最优应对策略可能包括提高价格、降低价格或保持价格不变，具体取决于价格敏感度和其他因素。

现在我们来看案例B中独有的命题：当SaaS提供商能够调整模块化与架构性能之间的关系时，如何实现利润最大化。

命题 B4 当模块化与架构性能相互关联时，生产者的利润关于$X$和$Y$达到最大值

$$ X = \frac{2(a - Zb)(DYc + Cd) + B(4DYb + d(c - Yd))}{2(4CDb - Dc^2 - Cd^2)} $$

在上述情况下，所有决策变量均等于模块化与性能无关时的取值。

这一命题提出了一个有趣的管理启示：如果SaaS提供商能够自由调整$X$和$Y$，那么其最优值与案例A中的相同。因此，提供商可能无需考虑案例B。

5 讨论和结论

本研究为SaaS提供商的设计决策提供了经济基础。我们的模型为服务模块化、架构性能和服务价格提供了最优值，以实现供应商利润最大化。这是首次尝试为供应商所起的重要作用提供一个分析结构云计算。然后，我们使用该模型为多个命题提供了证明，以确定客户偏好和环境变量对SaaS供应商设计决策的影响。

我们的结果为SaaS提供商针对成本参数、用户需求和用户偏好的变化，就软件即服务的模块化水平和架构性能水平提供了最优响应方案。我们表明，如果用户偏好趋向于更高的模块化或更高的架构性能，则提供商将通过分别提高模块化水平或架构性能水平来调整设计，以继续实现利润最大化。我们进一步表明，提供模块化或架构性能的成本增加时，提供商将相应降低模块化水平和架构性能水平。接下来，我们指出，随着服务提供的边际成本上升， SaaS提供商可根据需求的价格敏感性采取不同的定价策略作为应对。

我们考虑了两种情况：第一种是模块化与架构性能无关，第二种是两者相关。我们最有趣的结果是发现了一种条件，在该条件下，这两种情况会导致相同的设计决策最优值。如果供应商能够调整控制模块化与架构性能之间关系的参数$X$和$Y$，则在这两种情况下，最优的模块化水平和架构性能水平是相同的。因此，供应商可以忽略更复杂的 情况B，而基于较简单的情况A进行服务设计以达到最优解。只有在由于某些原因无法实现 情况A 的最优解时，供应商才可以通过命题B4计算出最优的$X$和$Y$，并将系统设计得尽可能接近这些最优值，以寻求最接近最佳的解决方案。

我们认为本研究对研究和实践均做出了重要贡献。在接下来的部分中，我们将详细阐述本研究对研究和实践的贡献，指出本文的主要局限性，并提出未来研究的方向。

5.1 研究意义

本研究对云计算领域的研究，特别是对SaaS服务开发的研究做出了多项贡献。与传统软件开发的分析模型假设软件的边际成本可忽略不计不同，我们特别考虑了SaaS的“服务”特性，明确纳入了服务整个生命周期内的维护成本和提供服务的边际成本。此外，尽管大部分软件开发文献关注所设计软件的功能属性，我们将重点放在两个非功能属性——模块化和架构性能上，我们认为这些是值得研究的重要特征。通过我们的模型，我们提供了首个稳健的框架之一，用于研究SaaS提供商在成本变化、用户需求和用户偏好背景下的设计决策制定。

我们的研究进一步贡献在于明确考虑了模块化与架构性能相关的情况，并表明在某些情况下在这些条件下，最优决策参数与两个属性不相关时的参数相同。我们借鉴现有的服务科学文献、软件工程文献以及营销与运营文献，构建了一个关于 SaaS提供商设计决策制定的稳健模型。该模型可作为基础，用于开发能够考虑更多现实情境（如供应商竞争、互补产品和用户偏好分布）的扩展模型，从而进一步推动云计算领域的现有研究。

5.2 实践意义

我们的研究结果对参与SaaS服务设计的管理者具有重要意义。对于SaaS供应商而言，本研究为设计决策提供了经济依据；具体而言，我们的模型提供了两个非功能性设计属性——模块化和架构性能的最优值，以最大化供应商利润。我们进一步展示了SaaS提供商针对用户偏好以及引入模块化和架构性能成本变化的最优应对策略。

我们还考虑了模块化与性能相关时更为现实的情况，并展示了当这两个设计属性相互关联时，参数的最优值如何变化。我们证明了在某些表示模块化与架构性能关系的参数取值下，设计参数的最优值与模块化和架构性能互不相关时的情形相同。

我们的模型为构建扩展模型提供了基础，这些扩展模型可考虑更多现实条件，例如多个提供商提供多种服务的情况，并同时考虑运营决策和设计决策。我们预期，此类扩展模型将能够为SaaS提供商的决策提供进一步的管理洞察。

5.3 局限性与未来研究

我们关注了SaaS供应商决策中的一个方面：与模块化和架构性能相关的设计决策。尽管这是构建分析结构以理解供应商在SaaS生态系统中作用的良好起点，但供应商的其他各种决策以及客户、基础设施提供商和其他利益相关者的决策也为本研究的扩展提供了机会。

此外，我们的模型仅限于设计层面的考虑，未涉及SaaS供应商的运营决策。我们明确区分了架构性能与运行性能，并专注于架构性能。本研究可通过显式纳入运营因素，特别是运行性能，进一步拓展。

我们的模型还假设了单一供应商和单一产品的背景。该研究可扩展至多个供应商和多产品的背景。多个供应商的情境将允许对供应商之间的竞争以及客户在竞争选项之间进行选择的行为进行显式建模。

偏好。多产品场景将有助于扩展本研究，其中多个产品的设计决策相互影响，从而形成一个更具动态性的决策模型。例如，SaaS供应商可以从设计点的角度提供在本质上互补的服务套件。此类产品组合将导致与本模型所计算出的不同的设计决策参数。

我们的模型采用了若干简化假设以实现分析可处理性。例如——我们采用了一种简化的定价结构，仅考虑服务生命周期内SaaS服务的总摊销价格。这忽略了软件即服务行业所使用的定价创新，如固定定价、按使用付费且无固定费用、批量折扣等。

最后，我们使用了线性需求函数。将复杂情况过度简化为简单函数形式所导致的问题已有充分记录（Montgomery 和 Bradlow 1999年）。然而，在本文所考虑的单一卖家、单一产品和统一客户偏好的简化情景下，我们 认为线性形式是一个合适的起点。该模型在未来的研究中可以通过采用非线性函数来建模各种参数加以扩展。此外，我们假设了一个具有统一特征（如模块化偏好和性能偏好）的静态客户群体。我们的分析可以通过建模一个动态客户群体来进一步扩展，其中个体客户在客户特征的不同取值范围内分布。

5.4 结论

本研究探讨了SaaS提供商的设计决策制定。我们考虑了SaaS提供商需要做出的两项设计决策：SaaS服务的两个非功能属性的最优水平，即软件架构的模块化和软件的架构性能。我们对这两个属性与用户偏好、用户需求以及服务价格等因素之间的关系进行了建模。与传统的信息系统产品开发模型有显著不同的是，我们考虑了提供SaaS服务的边际成本和维护成本，以认识到 SaaS服务兼具产品和服务的特性。

我们考虑了本研究中涉及的两个设计属性——模块化和架构性能——之间的两种关系情况。我们的结果展示了在考虑用户偏好、用户需求和服务价格等相关因素的情况下，能够最大化供应商利润的设计属性的最优值。我们的研究提供了首个针对SaaS提供商最优决策的分析模型之一。我们表明，SaaS提供商能够根据用户偏好的变化、相关成本及其他相关因素，适当调整服务设计。

本文开发的模型是一个良好的开端，成功地模拟了SaaS提供商如何以最优方式设计所提供的服务以最大化利润。我们期待未来的研究进一步完善该模型，以分析更多现实情境，例如多个提供商与多产品的情况，从而深入了解SaaS提供商如何实现其服务的最优设计。