电力正在从一个变数和数据量相对较少的 IT 环境移入另一个环境中，在这个新环境中，每个客户电表现在都是一个联网的计算机，作为一个控制点将新数据推入电网并将数据传播到底层遗留系统。技术数量、运算次数、以及任何一个能源公司的 IT 系统和基础架构需要处理的数据量都呈指数增长。

　　我们来看一个非常简化的典型能源软件基础架构视图。图 2 突出显示了新的且令人印象深刻的高风险努力，实现了智能电网和智能电表，提供了新级别的控制和预测。 

图 2. 不可用系统和未完成系统如何约束新 “智能” 技术的交付 

　　这个简化图展示了一个能源公司的典型软件架构以及由此引起的约束推出新技术。

　　您的开发团队期望如何交付一个巨大的任务，特别是一夜之间，使用一个互相依赖的软件环境，而这些软件并没有全部建立或全部可用?

　　我们发现电力的 IT 团队正在同这些交付问题作斗争：

　　◇ 高度依赖不可用或者受限系统。

　　◇ 数据复杂度和可变性影响集成和测试效果。

　　◇ 在事务方面惊人的增长，通过整个电网影响系统。

　　◇ 无法验证端到端系统的精确性和服务性能。

　　我们来仔细看看这些问题。

　　问题 1：增长的依赖性

　　开发团队很难接受一个复杂的分布式系统支持新的使用场景：

　　◇ 一个 meter-to-customer 事务可能需要经过十几个不同的消息协议来进行转换，然后与记录和服务系统进行通信，那些记录的服务系统在您开发和集成系统来支持 AMS 时可能很少(或者几乎不)访问。

　　◇ 运营团队可能会限制访问关键系统，每周只向您的开发团队预留 2 小时。

　　◇ 您的系统需要同第三方服务或系统进行通信，这在您的团队控制之外。

　　◇ 一些您需要使用的组件可能还没有开发。

　　从一个用户角度来看，开发和 QA 团队需要验证系统中数千个事务场景 — 每次只有一个系统在使用环境，但是对于其他团队来说它会污染环境中的数据。

　　问题 2：数据复杂性

　　电力 IT 团队不得不根据实时系统和波动的事务模式来构建软件;这种情况的一个主要副作用是很难建模真实、健壮的测试数据来贯穿整个软件生命周期：

　　◇ 客户和能源事务数据的波动性，以及跨实时系统跟随状态性事务的需求，使自动化 AMS 实现 VS 应用程序的测试看起来似乎不可能。

　　◇ 为了避免法规遵从和数据损坏问题，敏感的客户账户信息和实时事务数对于测试和开发团队需要被控制和屏蔽。

　　◇ 团队经常要花费 60% 的测试周期或者更多时间来构建和拆卸数据，给其他团队发电子邮件或者打电话来证实或者重置特定数据场景等等。这种效率和成本是不能接受的。

　　我们需要减轻测试数据对实时系统和架构中其他团队的影响。

　　问题 3：增加的交易量

　　数千个新智能端点增加到一个正在运行的智能电网实现中将生成大量不确定性的系统可靠性：

　　◇ 如果大部分电表损坏，将会发生什么?它们能够准确地记录断电时期吗?如果数百万的电表每小时向系统发送一次使用数据，电网会做何反应?成千上万个 Transactions Per Second (TPS) 对基础架构有何影响?

　　◇ 我们发现一些公司正在尝试逐个测试遭受智能电表端点攻击的系统的可靠性，通过将几个物理电表钉在一个木板上然后在网络中运行或者手工编码伪造 “存根” 来模拟这些电表。但实践不足以解释所有可能的使用状况和交易量需求。

　　传统电力 IT 基础架构从来不需要解释这个水平的使用状况。

　　问题 4: 无力验证端到端系统

　　跨越现代电力系统的很多技术层和依赖性增加了验证软件可靠性的困难和成本：

　　◇ 人工测试 — 既可以在用户接口进行、也可以在单个端点进行 — 是电力行业当时的规则。这些测试方法对根用户提供较少的可视性，可能会引发很多问题。

　　◇ 验证也是一个常见的人工任务;测试人员必须花费时间试着通过电话验证输出，人工在记录系统中查看预期数据结果。

　　◇ 误报和故障是常见的。例如，可能会有一个网站或者服务说它 “确定” 某个事务发生了，但实际上在首段没有状态改变。

　　团队需要能够以一个自动模式确定一个端到端命令是否被正确处理，以及数据是否依据预期策略在每个中间层传递。