MDM - If You're Willing to Pay the Price
Use Cases and Deployment Scope
<p>Oracle Utilities' Meter Data Management module is used by our metering services department, with tangential use by multiple other departments throughout our utility company. As an electric-only utility, MDM is used only to measure and manage electrical meter data. </p><p>From the meter setup, to the initial measurement, to the algorithms and logic that determines a final measurement, MDM process this entire data flow. The main use of the finalized meter data is for billing customers in an integrated cross-application connection with our customer-centric system (which is Oracle's Customer Care and Billing module). Beyond this, meter usage statistics are used for revenue forecasting and daily and monthly load expectations for our public utility commission.</p><p>One of the primary reasons OU's MDM product was chosen was that we were moving off a mainframe system and wanted our customer-based and meter-based applications to be serviced by the same software, reducing any sort of integration errors or headaches. Though integration has not been an issue, MDM itself is not the most intuitive tool, and is likely the lesser of the two products.</p>
Pros
- Integration-wise, MDM syncs with the OU product CCB without issue.
- The documentation behind the functional use of MDM is well maintained. This helps functional analysts when business issues arise and DBAs for technical issues.
Cons
- Integration-wise, MDM is flawless with CCB, but the amount of time it takes to load and interpret daily reads is nearly prohibitive. Through a process called "meter interrogation," Oracle is supposed to process initial reads into final measurements. This is supposed to run three times a day, but because the process is so resource-intensive, we are only able to run it barely twice a day. Production resources lag during this time and user experience is reduced.
- The amount of data the MDM require to be kept in just two of the thousands of database tables indicates a very poor design, or at least a poor integration of the Lodestar product that they purchased and turned into MDM. The initial measurements and final measurements tables take up around 85 to 90 percent of the database. This bloatedness in database size translates into slower performance for the front-end user as well as real costs in terms of data storage. Any user using Oracle's Exadata software will pay dearly for not having a purge and archive strategy.
Likelihood to Recommend
<p>Oracle Utilities MDM is well suited for users that have plenty of money to invest in technical hardware resources to support the requirements of this application. With the electric utility industry becoming more and more precise data-wise, the requirements for data storage and processing are only going to increase. For example, electrical usage measurement used to be a once-a-month practice; in the 1990s, hourly reading was introduced; recently, 15-minute interval readings have been introduced and will become the new norm. Going from one reading a month, to 720, to now 2,880 requires expensive hardware. MDM is able to handle this load, in our experience, only if you purchase Oracle's Exadata hardware, which is priced at a premium. Beyond data storage itself, we have also found that MDM real-time usage for users is also, unfortunately, best with Exadata. Likely because Oracle developed this hardware, and because it has built-in compression, portioning, and tuning features, performance is better.</p><p>One note is that Oracle does provide a purge-and-archive strategy in the more recent versions of MDM (i.e. ILM). However, implementation of this is a small project in itself, although worthwhile in the long run. </p>
