量化应用程序敏捷性

引言

为了实现企业的敏捷性，通常会采取一项 SOA 转型计划，无论是否实施 BPM/BRM 产品。成熟的 BPM/BRM 产品加上治理良好的实施通常能确保企业敏捷。精心执行的 SOA 计划也能确保敏捷性。如果企业有明确定义的业务流程支持，或者有潜力在 SOA/BPM 计划的投资中获得良好 ROI，那么所有这些都会很好地契合。

考虑这样一种情况：企业缺乏进行长期 SOA 计划投资或购买复杂 BPM 产品的充分业务理由，但只能负担得起较小的定制解决方案开发来满足其日常业务需求。如果企业的业务领域不稳定，并且经常受到监管变化或市场动态变化的影响，那么敏捷性就成为任何 IT 解决方案/计划的重要属性。在这些情况下，企业选择的技术栈也应该足够强大，能够支持敏捷解决方案的开发。

我们如何定量衡量一个组织的敏捷性？我们如何具体衡量定制应用程序的敏捷性？除非我们有一种方法来量化其应用程序的敏捷性，否则我们将无法了解企业的敏捷性。一旦我们有了量化应用程序敏捷性的方法，我们也可以清楚地了解我们业务运营的服务级别协议 (SLA) 承诺。对这种可见性的追求促成了这篇文章。

方法

在我之前的文章 .NET 中 AOP 框架的评级 中，我强调了一些可能对企业业务和系统产生潜在影响的因素。它们可以归类为

1. 业务因素
2. 技术因素

业务因素是指会触发业务逻辑/业务规则变化的方面。

技术因素是指会触发解决方案所在的技术栈/平台变化的方面。例如，更换数据库、替换日志组件等。

当一个系统声称“敏捷”时，它应该能够适应这两种因素的影响，而不会对业务运营造成重大干扰。当我们说一个系统能够以最小的干扰或最小的努力做出响应时，那么应该有一种方法来衡量——它有多高效或有多小！没有量化这些词语的方法，它们将保持主观。

如果我们有衡量或量化此类陈述的方法，那么就会出现这些问题：

• 我们达到基准了吗？
• 还有多久？
• 我们还能走多远？
• 我们是否还有进一步调整系统的潜力？

基于以上背景，我将通过一个简单的例子，介绍一种量化应用程序敏捷性（可以称为“敏捷指数”）的方法。

敏捷指数

假设需要衡量其敏捷指数的定制解决方案是基于分层架构设计的：表示层、业务层、数据层。在典型情况下，由于跨越这些层的组件数量会发生变化，解决方案的架构将对测量产生影响。此外，假设企业只有以下因素会影响其业务运营：

• 监管
• 市场状况
• 消息传递适配器

这会根据各自的企业运营领域（如银行与金融、制造业、零售业、电信业等）而有所不同。此处为保持简单，我只考虑了 3 个主要因素。这些因素下面可能有很多子因素。

在本篇文章的语境中，“频率因素”指的是该因素每年影响企业并触发变化的总次数，需要企业付出一定的努力来调整其解决方案以适应这些变化。

我还为这些因素分配了一些数字 [频率因素]：

因素	频率因子
监管	2
市场状况	2
消息传递适配器	3

此处，第一行的数字“2”表示预计每年会有 2 次监管变化。

假设根据 IT 部门的生产力因素（针对应用程序开发的平台和技术栈），完成不同组件、不同层更改所需的天数如下所示：

平均人天 [复杂、中等、简单平均值]
业务类	存储过程	UI 页面	数据库表
4	4	3	2

此处，“业务类”列下的数字“4”表示更改业务类需要 4 人天（包括测试）。为保持简单，我只取了复杂、中等和简单任务的平均值。在实际情况中，应单独考虑复杂性级别。

为适应上述因素的影响而需要更改的单元（组件）数量假设如下：

		单元数
		业务类	存储过程	UI 页面	数据库表
因素	频率因子	估计	估计	估计	估计
监管	2	4	5	7	8
市场状况	2	4	5	7	8
技术栈	3	4	5	7	8

第四行第三列的数字“4”表示，为了适应法规的变化（此处未详细说明变化是什么），需要修改 4 个业务类。

基于以上假设，计算出响应所需的总工作量为：

工作量
业务类	存储过程	UI 页面	数据库表
估计	估计	估计	估计	总计 - 估计
16	20	21	16	146
16	20	21	16	146
16	20	21	16	219
			Average	170

计算

估计工作量（业务类）=	所需修改的业务类数量 X 每人天数
总估计工作量 =	{ 估计工作量 [业务类] + 估计工作量 [存储过程] + 估计工作量 [UI 页面] + 估计工作量 [数据库表] } X 频率因子

最终平均值就是敏捷指数。在此案例中，为 170！敏捷指数越低，企业越敏捷。我对它进行了平均，因为因素的数量会根据领域而变化。也许在长期来看，这将有助于我们为不同的业务领域建立行业标准的敏捷指数。

此处，该练习是为一种定制解决方案执行的。同样，如果企业的 IT 组合包含 10 个应用程序，那么就需要为所有这 10 个应用程序执行此练习。这 10 个应用程序各自敏捷指数的平均值将成为该企业的敏捷指数。

上述方法应通过更多的分析元素和计算得到进一步增强，以便我们能够得出更准确的敏捷指数值。目标是强调评估应用程序敏捷性的方法的必要性以及量化应用程序敏捷性的重要性。

结论

• 在开发早期阶段对可能影响解决方案的因素和频率进行分析，将有助于相应地进行规划。此分析练习可以成为 SDLC 需求分析阶段的强制性要素，其中业务领域专家将深度参与。

• 一旦量化“敏捷指数”的方法达到成熟水平并获得更广泛的行业认可，就可以将其视为一项关键指标，除其他指标（如市盈率、重置成本和折现现金流等）外，在评估企业在合并与收购过程中的价值时。如果一个企业声称具有良好的 IT 敏捷性，则意味着它拥有一个架构良好且设计精良的应用程序组合，因此在架构和模式方面已进行了大量的努力和投资。

通过拥有一个衡量应用程序/系统敏捷能力的方法，可以建立一个量化企业敏捷性的途径。这将允许以支持数据来回答“企业有多敏捷”，为 SLA 承诺进行规划，并且还可以将其视为一项资产。尽管从传统的 SDLC 角度来看，这种方法可以被视为一种影响分析或工作量估算方法，但它试图为敏捷性提供一个定量的视角，而不是将其仅仅视为定性陈述。一种新的量化敏捷性的分析方法可能是这种提议方法的更好、更长期的替代方案。