本文来源：谢老师的博客
我们已经讨论过，由于软件特有的非规模经济特点，提高软件开发经济效益第一个层面的手段，就是尽可能降低软件开发的规模和复杂度。能够对于降低总体规模和复杂度最好的技术包括：管理范围、以独立单元为中心开发、基于组件的开发以及利用面向服务的架构来提升抽象度。
1，管理范围
我们通常用一组用例、特性或者需求来定义产品的范围，它指定了产品应该做什么这个最核心的问题。事实上光考虑做什么还是不够的，更重要的是要考虑要把事情到好到什么程度。管理范围必须理解三个问题：
1）业务上真正的需求到底是什么？
2）这些“需求”是不是能够较付出业务上真正的价值？
3）对特性或者需求进行经济上的权衡。
考虑范围不是拍拍脑袋说把事情做到极致这样简单的处理方式，事实上把事情做到极致并不一定就能从经济上获得好处。对于需求的经济价值研究极为重要而困难，在项目早期往往并不能透彻明了产品品那些需求具有经济价值，但这种理解会随着时间的流逝而不断进化和清晰，这有赖于项目相关人员对这个问题的关注，如果没有关注，将永远也不会清晰。
在大多数情况下，在考虑范围的时候并没有必要把范围单元的成本、价值和经济效益评估的非常准确，不过用1～10这样的级别来表示是可取的。这种评估可能是粗粒度的，但是就足以做出大多数重要决策了。在可能的情况下我们还是需要了解一些经济学概念的，否则完全依赖猜测这种1～10的级别设定，很难做出比较能说服人的决定。
下面简单的例子，说明了关于四个范围单元的成本和价值分析。
显然第二种情况，也就是更快的交付两个范围子集，可能是更有吸引力的。
事实上从经济角度考虑范围还有更多的问题需要考虑，而不仅仅是经济效益，还要考虑各个子集之间的关系。不过如果思考和度量了每个子范围的相对重要性，对于管理范围就有了比较多的依据。
既然在项目策划过程中需要考虑每个范围单元是如何达成经济指标的，上述方法虽然直观但未免太粗造了一些，很多情况下比较精细地度量经济指标是必须的。为此，我们就需要理解一个项目是如何增加收入，或者是节省支出的。在需要进行仔细的经济利益分析的时候，我们就需要对于金钱的价值及其计算方法有一些初步的概念。
经济上的考虑往往是确定优先级的重要考虑因素。如果我们可以估计每个独立单元所能产生或者节省的金钱数目，那就可以用它来帮助确定优先级。预测范围单元的经济价值是产品负责人的责任，但也是小组其他成员共同承担的。很多情况下，产品负责人还需要通过销售和市场推广部门获得商业信息和预测。
比较好的方法，是召开一次或者多次有尽可能多的这类人参加的会议，这种范围单元评估会议的目的是为每个范围单元填写一张如下显示的表格。
这种会议可以分成两阶段来开，第一次会议说明情况，介绍下面就要讨论的各个列标题的含义，然后休会再等待2～3天让所有会议成员私下进行研究和讨论，最后集中起来讨论。如果这一项没有收入，这个数据可以定为0。
讨论的时候需要表达这些数字是从哪里来的？理想的数据应该来自于启动这个项目的商业案例对市场的研究，至少表达要求实现这个范围单元的人能够量化开发它的原因。如果没有这方面的量化数据，那就要考虑这个项目启动本身是否有意义了，“因为他有了所以我也要有！”这往往就是项目失败的根本原因。
在考虑优先级的时候，并不是把数据简单的加起来然后用总量来考虑，假定两个功能收入总量是一样的，一个是第一季度收入10万，第二季度收入20万，第三季度收入50万。另一个功能的顺序与它相反（50，20，10），而从经济上看，第二个功能往往更有价值。这种分析需要一些标准的经济指标概念，包括：
1）净现值。
2）投资回报率。
3）回收期。
4）贴现回收期。
2，收入的来源
一个项目的收入可以有不同的来源，一般可以分为新收入、增量收入、留存收入和操作效率。虽然在特定的项目中，某类收入占主导地位很常见，但大多数项目会从不止一个来源获得收入。
1）新收入
毫无疑问，项目收入中最常见的贡献者就是获得新收入的机会。几乎所有公司都对自己占有的市场份额感到不满意，所以希望获得新用户。即使软件产品不是用于直接销售的，比如基于服务的软件，但增加新服务也会带来新收入。比如一家公司为某个医院开发了医院管理系统。如果略加改进，可以对医疗保险人员提供同样的服务，这样的软件提供的能力，将为这家公司带来了全新的收入来源。
2）增量收入
把来自新客户的收入和来自现有客户额外的、增加的收入区分开来，往往是有益的。产生增量收入的原因是新的系统或者产品可以：
促进现有客户购买更多的服务许可
包含了可以独立出售的、可选的、附加的模块
包含允许提高服务或者销售收费的功能
促进对咨询服务（例如，为了与独立第三方产品集成）的使用
3）留存收入
与新收入和增量收入相独立的是留存收入。留存收入指的是如果不开发这个项目或者范围单元，公司将会损失的收入。假定，您曾经为某个医院开发了医生立刻可以查询到病人病例和病史资料的程序，工作的很好，这家医院因此服务质量和效率大幅度提高，也创造了很好的经济效益。现在要把这个软件推广到整个地区的多家医院实现联网查询，病人在任何一家医院就诊，医生可以在参加这个系统的所有医院都可以查着这个病人的病史资料，这就可以大大增加这个地区整体医疗服务水准。
如果不在原有软件的基础上增加联网查询和中心服务功能，您就会失去正在增长的新业务，增加这样的功能，就可以允许公司保留这些收入。有趣的是，这里也有增量收入的机会，你可以开发针对不同医院规模和特点的版本，以收取更高的费用。
4）操作效率
没有哪个单位工作效率可以和它理论上能够达到的一样高，总会有一些可以精简和消除的工作，如果您是开发供内部客户使用的软件，您就会认识到操作效率的重要性。
改善操作效率的驱动力往往来自于预期增长，目前可能不是问题，但一旦公司变得更大效率就可能是一个问题。比如建立一个网站销售燃气灶，出现问题可能打个电话就派人去维修，这是一种正常售后服务的情况，往往也是低效的，但在当时销售额的情况下可能不是个问题。但是当销售额增大到1000%的时候，维修量也可能增加1000%，到那个时候，是不是到怎么解决这个低效问题的时候了？
要提高操作效率，一些可以考虑的地方包括：
任何在公司成长后需要很长时间的事情（当然现在就存在就更要考虑）；
部门之间更好的集成和交流；
降低人员更替；
对新雇员更短的培训时间；
任何对时间敏感的过程；
综合多个过程；
任何可以提高准确性和减少返工的工作。
3，估计项目收入的案例
上述这些概念具体计算考虑需要通过一个案例进一步说明，我们讨论一个假想的案例，由此得出计算项目收入的直观方法。这是学习软件经济学很有意义的案例，值得我们花功夫研讨。
假定某开发公司要为一个公共服务网站设计一个升级的工资服务单元，原来的业务如下图所示：
任何公司都可以购买这个服务单元，所付的费用为400元/年。购买服务的公司将得到一个注册的用户名，以及他们自己可以更换的密码。原来网站上已经有这个类似单元，它要求客户给他们的员工发工资前3天在网站上输入工资册信息，由网站工作人员在3个工作日内生成工资单和打印支票，并递送给该客户的员工。从客户利益的角度来看，这个服务可以帮助客户减少不必要的员工费用支出。而服务方的效益来自于业务的自动化所带来的海量客户收入。
但是，这个系统能力已经引起不少客户抱怨。新服务的目标是提供次日服务，只要在下午5点之前把工资信息输入到系统，网站就可以连夜自动生成工资单和打印支票，并递送它们，在第二天早上，客户的员工就可以收到支票。
在开始估计这个连夜服务的项目收入之前，需要决定在多长时间内完成它。假定开发人员已经估计过这个范围单元的用户故事，认为有150个故事点。小组历史上开发速度是每30天迭代可以开发40个故事点。开发这个范围单元需要150/40=3.75，也就是需要4次迭代。这意味着在第4次迭代以后可以得到增量收入和操作效率。
1）计算新收入
提供次日而不是3天完成的服务会给新收入带来机会。要量化这个机会，我们首先估计将会获得的新客户数量。据销售部门统计，大约有1/3的来咨询的客户，由于被要求提前3天输入工资信息，而放弃了这个服务。销售部门相信，如果提供了次日服务，今年的每个季度可吸引50个客户，明年每季度可增加到100个。在今年第二季度中期之前，虽然还不能提供次日服务，但他们仍然相信可以与50个客户签约，这就得到了表的第一列数据。
接下来我们估计每个客户带来的新收入：当前客户每年平均付给我们400元。但次日服务往往针对更小、需要反应更快的公司，过去这类客户群一般每年付给我们200元。估计在提供新服务后，可以多收取100元，也就是每个新客户的总价值为300元，折算下来每季度75元。由于该服务单元只能在第二季度中期以后运行，所以该季度每个用户带来的相应收入也减少，这就得到了计算新收入的表。
2）计算增量收入
增量收入是指我们从现有客户处可以获得的额外收入。目前现有客户有400家，根据我们对现有客户的了解，例如他们延误提交工资册信息的频繁程度等，大约100家可能转而使用连夜服务单元。在第二季度中期以后，可以产生大约每年100元或者每季度25元的收入，这就得到如下的增量收入表。
3）计算留存收入
留存收入指的是我们不会继续因为客户对产品不满意、客户成长后超出产品使用范围、或者其它原因不再使用这个服务。公司目前没有好的办法来跟踪这种损失，但已经感觉到这正在成为问题，并且在接下来的几年中这个问题会更突出。
我们估计通过连夜送达服务，我们第一年中每季度可以避免损失20个客户，第二年每季度可以避免损失40个，更重要的是，这种功能的升级使客户对服务更有信心，他们将会坚持使用这个服务。虽然知道第二季度中期以后才可能有次日服务，但这些客户机基本上会留下来等待新功能。每个现有客户值每年400元，也就是每季度100元，这样我们就可以计算下表所示的留存收入。
4）计算操作效率
连夜递送服务如果要成功，我们就要消除系统当前所依赖的几乎所有的人工干预。目前，系统依赖于这个服务两个工资册职员人工来完成核准、寄送等等工作。由于用户的增多，公司准备在今年中期再增加两个职员。由于连夜寄送系统的效率增加，预计可以把每年需要的人数减少一个。
工资册职员的收入是20000元，但每个人要占用办公空间，还要享受津贴、奖金和保险等，这些附加工资大约为工资的50%，也就是说每个员工支出为30000元，这称之为全额劳动成本。可以按照季度把未雇用的职工全额劳动成本乘在一起，得到总的操作效率。
5）估计开发成本
要完成这个服务连夜递送项目的投资分析，还需要估计这个服务的预期开发成本。我们首先列出参与这个项目所有人的工资，全额劳动成本是以比工资高50%计算的。
由于迭代是30天（日历日），每次迭代的劳动成本是全额劳动成本的1/12，再乘上每个员工在项目中的时间所占比例，就算出了每次迭代的成本及其总和。
了解每个故事点的成本是有意义的，要计算这个值，需要把调整后的每次迭代成本除以小组的平均或者预期速度。由于这个服务小组的平均速度为每次迭代40个故事点，他们每故事点的成本就是：29375/40=734。这个信息的用处在于，如果小组被问及开发一个估计有100个故事点的东西需要多少成本？他们马上可以回答说：73400。
这个服务小组的成本可以归结到下面的表中。
6）整合
从对成本、新收入、增量收入、留存收入和操作有效性的分析，我们可以整理得到如下表。连夜递送功能预期在第4次迭代，也就是16周之后完成，第一季度有12周开发，成本7340×12=88080元，第二季度还有4周开发，成本7340×4=29360。
4，经济指标
在得到对每一个范围单元产生的现金流进行估计的方法以后，接下来我们要把注意力放到分析和评估这些现金流的不同方法。我们会考虑净现值、内部收益率、回收期和贴现回收期等，这些指标中的每一种都可以用来对范围单元的收入进行比较。但是首先，了解什么是金钱的时间价值是很有意义的。
1）金钱的时间价值
如果有人和你说：“我买你一个软件，等明年再把钱给你。”只有傻瓜才会同意，原因很简单，现在的钱比明年的钱值钱。
要判断将来的钱在今天的价值，要考虑今天在银行存多少钱才能在将来涨成那么多。如果银行利率为10%，那么现在的0.91元就是一年后的1元钱。为了达到将来特定数值今天要存入的钱，我们称他为现值（present value）。
把将来的钱推回到它的现值的过程，我们称之为贴现（discount）。公司对将来的金钱进行贴现的利率，被称之为它们的机会成本（opportunity cost），反映了为进行某项投资而放弃其它机会所可能损失的百分率。
在用我们自己的钱进行投资的时候，都可以有不同的机会成本，存银行、投资股票、投资房地产，或者把它藏在床垫底下机会成本是不一样的。公司也可以把钱用于不同的投资，如果过去在一个项目中可以赚20%，现在要转而投资新项目，机会成本就是20%，因为新项目的投资意味着放弃了另一个项目可以赚取的20%。
2）净现值
我们将要对范围单元进行评估的第一个公式是净现值（Net Present Value，NPV），要确定净现值，需要把一系列将来金额的现值累加起来，公式是：
其中：i是利率，Ft是周期t中的净现金流。
我们试着看一下这个服务网站的例子，现金流指的是在上面“6）整合”1小节中“项目计划收入”表格中的净现金流一项。现值参数是计算公式中（1+i）-t的数值，这个例子假定年利率为12%。其实计算的时候，可以首先确定每季度利率为4%，（1+i）=（1+0.03）=1.03，第一季度：1/1.03=0.970847，下面每过一季度用上面的数值多除以一个1.03就可以了。
这个计算用微软Excel可以很容易进行，牵涉到经济学计算，Excel的功能也相当强。当迭代周期比较短的时候，处理的问题相对比较简单，考虑问题相对比较细腻，也可能Excel更加合用，有了合用的工具为什么我们不用呢？还是一句老话，首先关注管理的思维方式，根据管理的特点来选用工具，而不是用工具来框定管理模式。
使用NPV我们就可以据此对范围单元进行从经济上考虑的优先级安排，其优点是易于计算，也易于说明，其缺点是有可能造成误导。单单从NPV是大还是小并不能看出投资回报的大小。我们真正想要得是用百分比形式，反映范围单元带来的利润。比如，两个项目NPV是一样的，都是100000元，但一个先期投资巨大，另一个先期投资比较小，所有人都会倾向于考虑初期投资较小，而NPV是一样的项目，让我们更直接的来比较它们。
3）投资回报率（ROI）
投资回报率（Return On Investment，ROI）有时也称之为内部收益率（Internal Rate of Return，IRR），它提供了一种以百分比形式表示项目利润的方法，净现值是对一个项目预期利润到底有多少的度量（按照当前的现价），而投资回报率度量是指项目上投资的价值增长有多快，这样我们可以很容易得比较项目，比如下表所示的情况，您会选择哪一个？
如果单纯用净现值来比较，似乎项目A比较好，但是大多数人会选择项目B，因为投资回报率比较大。
很多公司设定一个最低投资回报率（Minimum Attractive Rate of Return，MAAR），只有内部收益率超过最低投资回报率的项目或者范围单元，才会得到资金支持。对净现值则没有办法设定类似的阈值，在使用NPV考虑问题的时候，小的项目，尽管很有价值，但永远不会被接受。
投资回报率的定义是：使现金流的净现值为0的利率，也就是满足下式的利率i*：
显然这个公式计算相当复杂，幸好Excel这类电子表格大多数包含了IRR计算功能。不过，即使用Excel计算投资回报率，还是需要了解一下它所需要的先决条件：
首先，现金流的开始一项或者多项必须是支出。
其次，现金流一旦变成正值，就一直保持正值。
最后，所有正值和应该大于所有负值的和，也就是说项目总体上要是盈利的。
这个连夜递送服务单元的现金流是满足上述要求的，我们可以用Excel计算这个范围单元的投资回报率。在一个单元格内送入：
=IRR({0,-86080,-23260,18250,20750,29000,29000,36500,36500})
立刻可以得到这个项目的投资回报率是10%。其中花括号内是现金流，第一个数据表示的是项目启动的第一天的先期成本。连夜递送服务是在原有项目基础上的扩充，所以先期成本为0。如果需要购买额外的服务器来启动这个项目，则就会有这个先期成本。
使用投资回报率的优点是可以直接对项目进行比较，一个投资回报率为46%的项目，投资收益总是高于25%的项目，这对优先级的决定提供了重要信息。不过，不能单纯依靠ROI作决定，例如，内部收益率46%的项目仅仅是一个小项目，而25%的项目是一个大项目，很多情况下还会选择25%的项目来获取更多的利润。
还有一种情况，两个项目回报接近，但是25%的项目一年就可以收回投资，46%的项目需要两年收回投资，如果开发公司无法负担两年的投资，选择25%的项目也是可取的。
经济学分析并不是简单的靠数据说话，而是依靠数据分析暴露出来的信息，给决策提供依据，决策还是需要根据自己对多种情况的综合判断力，这需要经验。
4）回收期
利用净现值，我们可以把一个现金流看作一个单一的现价数值，此外我们也可以把现金流看作利率。看待现金流的另一种方法，是考虑赚回初期投资需要多少时间，这被称之为回收期（paybacl period）。回收期计算是一种简单的累加，下表是这个连夜递送服务的回收期列表。
我们可以发现，在第8季度，总计金额达到了正值，也就是这个项目可以在第8季度以后收回投资。利用回收期比较范围单元有两个主要优点。首先对它的计算非常直观，解释也很容易。其次，它度量了开发公司所承担的经济风险的量和持续时间。回收期越长，项目风险就越大，因为这中间什么情况都可能发生。
回收期的主要缺点是它没有考虑金钱的时间价值，3年后的钱被看成和今天的钱具有同等价值。回收期的第二个缺点在于它不是对项目盈利性的度量，它告诉我们第8季度可以回收投资，但没有告诉我们到底能赚多少钱。
5）贴现回收期
很容易对回收期的第一个缺点进行修正，只要对现金流的每一项应用正确的贴现参数就可以了，下面是采用这种方法列表。
可以看出来，从第六季度开始就可以收回投资。
4，对利润的比较
在您对每个范围单元进行评估的时候，会建立比较这些范围单元的信息，对这些数据从多个层面进行分析，就可以做出正确合理的优先级决策，选择对用户来说具有最高价值的范围单元开展工作。假定现在有3个范围单元，如下表所示。
在这个例子中，连夜递送服务单元具有最高的净现值，但也需要最长的时间来收回投资。合作者集成回收率最高，但净现值最低。定制报告投资回报率最低，但它如果与合作者集成结合在一起，用和连夜递送同样的成本来开发，也可能是个好主意。
决策的制定并不是固定的：产品所有者和开发小组需要考虑许多与环境相关的因素，例如开发公司对风险的承受能力，对短期回收的需求，可用的资源，其它的投资选项等等。
项目管理人员与开发团队成员并不需要成为财务人员，但了解项目对经济上的影响是非常有意义的，这使得我们在确定项目优先级的问题上更加有把握。了解一些软件经济学知识，对于减少和财务部门发生矛盾和冲突的也是有益处的，还是那句老话：在所有成员都有相似的知识和思维背景的时候，达成共识要容易得多
7，设计上合理分解，减少每一部分规模
我们认为迷恋于超大型的项目是徒劳的，分别承担责任的小型团队更可能产出成功的软件。任何复杂系统，都可以分解成小问题也就是子系统，每个子系统都是具有完整系统架构的复杂系统组成部分，它可以合理的解释和证明、成功的设计与制造，然后在集成到整个系统中去。子系统还可以分解成子系统，这种分解（或逐步细化）过程会一直进行下去，以每个子系统为单位开发，可以有效减少每一部分规模，如下图所示。
正确的子系统分解应该考虑下面的原则：
1）对功能进行分布和划分，对于以最小的成本和最大的灵活性来完成系统整体的功能来说是最优的。
2）每个子系统都可以被一个小型团队所定义、设计与开发。
3）每个子系统都可以使用可行的制造技术制造出来。
4）在成功地模拟了子系统的其它子系统的接口之后，每个子系统都可以单独进行测试。
5）对于子系统的各个物理方面（大小、重量、位置、分布）都要进行考虑，并在整个系统环境下加以优化。
应该尽早对软件架构设计方案进行开发和验证，而不仅仅象概要设计那样只是为了进行评审。具体而言：
1）应该真正通过编码把架构实现。
2）应该实际对架构基线进行测试，测试的重点是运行时的质量属性，如性能、可维护性、可伸缩性等。
3）要认真评估架构基线的实现过程，以对软件架构开发期的质量属性给出评价。
4）传统意义上的架构设计评审仍然是需要的，以确保所有的功能需求能够被支持。
5）要对架构的不足之处及时进行调整，并再次进行验证。
6）要进行实际的测试，这一点很重要，否则，软件架构能否达到质量属性要求不得而知，这就埋下了众多技术风险。
从模块设计的角度，这里的关键是要保证模块的独立性。利用模块化解决方案的注意事项如下：
1）一般来说，我们倾向于每个用例定义一个模块。我们应该努力使每个模块的大小差别在一个数量级之内。如果发现某个模块规模太大，就需要实现模块切割，然后针对这种切割的结果，反过来修改需求分析时候的用例的表达。这就是设计引发的需求变更。
2）模块的大小一般以一个人在一个里程碑时间内（或者说一个迭代周期）能完成为好。
3）模块切割方法与开发成本有关。我们可以这样来思考模块化对软件工作量和成本的影响，如下图所示。
随着模块数量的增加，开发成本减低，但是系统集成的成本增加，所以最小成本的区域在一个合适的区间。也就是说，模块并不是越多越好，只有模块数量适当的时候，总体成本才可能下降。
8，降低人工编写代码的规模
充分应用商品化组件、建立产品线架构实现领域级别的复用、使用成熟的架构模式、选用高级语言编程，这些都可以降低人工编写代码的规模。一般来说，软件自行开发的部分越简单、规模越小，软件的易理解性、可靠性以及后期维护的方便性都可以提高。
产品线系统（Product Line System）是一组软件密集型系统，它们共享一个公共的、可管理的特性集，以规定的方式使用公共核心资产集开发，来满足某个特定市场或者任务的具体需要。产品线是基于在相同产品价格条件下提高竞争力的商业考虑，在生产软件产品的家族的时候，以一种规范的、策略性的方式重用资产。它包括一个基本架构以及一些可剪裁、可填充的元素。此外，它还包括设计文档、用户手册、项目管理制品（包括预算和进度）以及测试计划和测试用例。当成功建立产品线以后，就可以把可重用的资产保存在“核心资产库”中去，由于产品线系统可以对多个系统提供支持，可以明显的降低成本和缩短开发时间，提高经济效益。
在构建产品线系统的时候，关键是识别可变性。因为即使在同一个领域，软件或者服务的要求完全激扬的概率是很低的。因此设计过程中，需要识别软件产品线的各种通用和变化特征。可变性会被传递到需求，并逐层的推到领域设计、实现和测试，并在这些过程中逐步细化。除了“识别可变性”以外，更重要的是实施可变性策略。由于在产品线工程中变化问题的复杂性与敏感性，我们必须用系统的方法来分析，而不是随兴而至的处理问题，这样往往会带来巨大的风险。
9，使用云计算和面向服务的架构
云计算是对IT行业规模经济和非规模经济进一步区分的结果。一般来说，硬件平台具有规模经济的特点，因此，通过专业化分工使硬件平台具有低成本大规模处理量，把主机集中管理，以市场机制通过虚拟化层对外提供服务，按使用量收费。这就形成了云计算的基础层：基础设施即服务（IaaS，Infrastructrue as a Service）。
平台的通用性使其具备软件的规模经济的特点。可以把完整的应用程序运行平台作为一种服务提供给客户，客户不需要购买底层硬件和平台软件，只需要利用已有平台，就能够创建、测试和部署应用程序。这就形成云计算的第二层：平台即服务（PaaS，Platform as a Service）。
具体面向客户的服务一般具有非规模经济的特点，可以把满足各种具体需要的软件部署为托管服务，用户不需要购买软件，可以通过网络访问所需要的服务，或者把各种服务综合成自己的需要，而客户按照使用量付费。这就形成了云计算的第三层：软件即服务（SaaS，Software as a Service）。SaaS的出现彻底颠覆了传统软件的运营模式。它不仅仅从价格上，交付模式上，实施风险上带来了明显改观。
这三个层结合起来，就形成了典型的云计算的SPI模型。可以预期，在这个模型上，大量的创新企业可以获得更好的生存空间。云计算强调的是专业的人干专业的事，把不同特征的区域分开，这就可能有效地提高软件开发的经济效益。
云计算设计方法包含了大量的面向服务架构（SOA）的思想。SOA设计思想的本质是把业务看成一个个独立的服务，不论每个服务的实现的技术手段如何，都通过某种标准（比如SOAP、WSDL）把模块的复杂性包装起来，这就简化了编程模型的复杂性。每个业务组件是粗粒度的，在基于业务组件开发的时候，可以获得与组件技术相同的好处。并且可以以一种破坏性较小的方式演进，这就有效的降低了系统的成本。毕竟在大多数IT预算中，70%都消耗在了对现有系统的增强与维护上。所以，采用云计算或者SOA架构，可以对于软件的经济性产生显著的影响。
（待续）
0 0
