|
Server : Apache/2.4.62 System : FreeBSD fbsdweb2.web.rcn.net 14.1-RELEASE FreeBSD 14.1-RELEASE releng/14.1-n267679-10e31f0946d8 GENERIC amd64 User : www ( 80) PHP Version : 8.3.8 Disable Function : NONE Directory : /domains/enrgy/techcor/ |
Upload File : |
<html>
<head>
<title>Platform, Platform, Platform - Part 1</title>
</head>
<body style="font-family: Arial" vlink="#808080">
<div align="center"><center>
<table border="0" cellpadding="8" cellspacing="0" width="98%" bgcolor="#000000">
<tr>
<td width="100%" valign="middle"><a name="top"></a><img src="../images/pmamagsm.gif" alt="PMA Online Magazine" border="0" align="right" WIDTH="229" HEIGHT="100"></td>
</tr>
</table>
</center></div><div align="center"><center>
<table border="0" cellpadding="8" width="98%">
<tr>
<td width="25%" valign="top" align="center"><!--webbot bot="ImageMap" rectangle="(14,297) (97,322) http://www.powermarketers.com/adrates.html" rectangle="(11,230) (95,257) http://www.powermarketers.com/pmajobs.htm" rectangle="(12,163) (96,189) http://www.powermarketers.com/main.htm##_parent" rectangle="(12,95) (96,121) http://www.powermarketers.com/power2.htm##_blank" rectangle="(11,29) (96,54) ../pmamag.htm" src="../images/magmenu.gif" alt="PMA OnLine Magazine Menu" border="0" align="center" startspan --><MAP NAME="FrontPageMap"><AREA SHAPE="RECT" COORDS="14, 297, 97, 322" HREF="http://www.powermarketers.com/adrates.html"><AREA SHAPE="RECT" COORDS="11, 230, 95, 257" HREF="http://www.powermarketers.com/pmajobs.htm"><AREA SHAPE="RECT" COORDS="12, 163, 96, 189" HREF="http://www.powermarketers.com/main.htm" TARGET="_parent"><AREA SHAPE="RECT" COORDS="12, 95, 96, 121" HREF="http://www.powermarketers.com/power2.htm" TARGET="_blank"><AREA SHAPE="RECT" COORDS="11, 29, 96, 54" HREF="../pmamag.htm"></MAP><a href="../_vti_bin/shtml.dll/techcor/9809frst.htm/map"><img src="../images/magmenu.gif" alt="PMA OnLine Magazine Menu" border="0" align="center" ismap width="110" height="350" usemap="#FrontPageMap"></a><!--webbot bot="ImageMap" endspan i-checksum="22224" --><p><a href="../searchpma.htm"><img src="../images/archives.gif" alt="Archives Search" border="0" align="center" WIDTH="70" HEIGHT="40"></a></p>
<p align="left"><font face="Arial"><strong><small>About The Author:</small></strong></font></p>
<font size="3"><p align="left"></font><font size="2">Jeffrey Frost, a PMTC Senior Partner,
has years of experience as a banking treasury executive, trading room technology
innovator, and Internet electronic commerce pioneer. </font></p>
<p align="left"><font size="2">While Jeffrey's prior executive and entrepreneurial roles
have demanded numerous skills, much of his career has revolved around one simple theme:
The use of new computing technologies applied to existing information to create profitable
new business alternatives. </font></p>
<p align="left"><font size="2"><a href="http://www.pmtcweb.com/" target="_blank">The Power
Marketing Technology Consortium</a> is an IT and electronic commerce power marketing
consulting organization which integrates and supports technologies related to energy
trading and marketing.</font></p>
<p> </p>
<p> </p>
<p> </p>
<p> </p>
<p> </p>
<p> </p>
<p> </p>
<p> </p>
<p> </p>
<p> </p>
<p> </p>
<p> </p>
<p> </p>
<p> </p>
<p> </p>
<p> </p>
<p> </p>
<p> </p>
<p> </p>
<p> </p>
<p> </p>
<p> </p>
<p> </p>
<p> </p>
<p> </p>
<p> </p>
<p> </p>
<p> </p>
<p> </p>
<p> </p>
<p> </p>
<p> </p>
<p> </p>
<p> </p>
<p><a href="9809frst.htm#top"><img src="../images/b-t-top.gif" alt="Back To Top" border="0" WIDTH="71" HEIGHT="35"></a></td>
<td width="90%" valign="top"><img src="..\images/techcor2.gif" alt="Technology Corner" align="top" border="0"><p> </p>
<p><b><u>September 1998</u><br>
</b><font size="6"><strong>PLATFORM, PLATFORM, PLATFORM<br>
PART I</strong></font></p>
<p><strong>by Jeffrey Frost -- Power Marketing Technology Consortium<br>
</strong><font face="Arial" size="2">(<em>originally published by PMA OnLine Magazine:
09/98</em>)</font></p>
<blockquote>
<p align="left"><em><a href="http://www.pmtcweb.com/" target="_blank">The Power Marketing
Technology Consortium</a> (PMTC) is pleased to join PMA’s list of regular
contributors to the PMA ONLINE Magazine. In this space, we will be discussing the enabling
software applications required to support today’s power marketing organizations. Your
feedback is always welcome (<a href="mailto:[email protected]">[email protected]</a>).</em><br>
<br>
</p>
<div align="center"><center><table border="2" width="80%">
<tr>
<td width="100%"><font size="3"><strong>Note:</strong> This is an opinion article. Email
responses are welcome from persons holding alternative points of view. All readers need to
reach their own conclusions based upon their own good judgement.</font></td>
</tr>
</table>
</center></div>
</blockquote>
<p align="left"><font size="3"><br>
</font></p>
<p align="left"><font size="6"><strong>NEXT BEST THING</strong></font><font size="3"><br>
Consultants are renown for nostrums and advice. But the real world is tough to fathom and
silver bullets are rare. So it is a great pleasure to offer the next best thing to a
Silver Bullet, a sound insight. If you are purchasing or developing an RMTP (Risk
Management and Trade Processing) application suite, your assessment of the underlying
software architecture, of the software platform <strong><em>is at least as important as
any other single issue</em></strong>. "Platform" (software architecture) is to
wholesale energy RMTP application suites as "location" is to real estate. And
how do you identify the right location (platform) for your wholesale energy RMTP
applications? Easy, just identify the critical issues concerning integration and
communication between disparate and distributed applications and choose a solution to meet
your needs.<br>
<br>
Perhaps the best manner in which to illustrate this point, and to simultaneously offer
insight into how to choose a platform, is to look at an example. This example is about
Cyberwatt Energy, a hypothetical Power Marketing organization with substantial generation
assets. <strong>Figure 1</strong> is a logical depiction of the internal major departments
and external entities with whom Cyberwatt Energy interacts.</font></p>
<p align="center"><br>
<br>
<big><big><strong>FIGURE 1 - POWER MARKETER CYBERWATT ENERGY</strong></big></big></p>
<p align="center"><br>
<br>
<br>
<img src="../images/PLATFRM1.gif" alt="PLATFRM1.gif (19739 bytes)" WIDTH="396" HEIGHT="288"><br>
<br>
<br>
</p>
<p align="left"><strong><font size="6">THE WAY WE WERE</font></strong><font size="3"><br>
Many wholesale energy trading and risk management application suites were created by the
integration of individual stand-a-lone applications. There were Gas Management, Risk
Management, Power, Financial Trading and other applications. Originally they did not talk
to each other, exchange data, or otherwise interact. But this isolation proved cumbersome
and difficult. Risk Management is the obvious best example. A Risk Management system needs
to be connected to the Gas and Power trading and scheduling systems.</font></p>
<p align="left"><font size="3"><br>
</font><strong><font size="6">NOW WE ARE GETTING SOMEWHERE</font></strong><font size="3"><br>
Application developers and integrators typically first connected stand-a-lone applications
by creating interfaces between different pairs of applications, creating an unwieldy set
of point to point connections. that looks like this. This can work for many purposes, but
it tends to be expensive, costly to maintain, and inflexible.</font></p>
<p align="center"><font size="3"><br>
<br>
<img src="../images/platfrm2.gif" alt="platfrm2.gif (4841 bytes)" WIDTH="388" HEIGHT="416"></font></p>
<p align="left"> </p>
<p align="left"><font size="3">Next developers began to use improved technologies to
create the shared database approach which looks like this:</font></p>
<p align="center"><font size="3"><br>
<br>
<img src="../images/platfrm3.gif" alt="platfrm3.gif (3107 bytes)" WIDTH="346" HEIGHT="318"><br>
<br>
<br>
</font></p>
<p align="left"><font size="3">Multiple applications sharing a single database works very
well for most purposes. The majority of RMTP (Risk Management and Trade Processing)
applications in use today operate off of this type of two tier (or three tier) client
server architecture. Of course far too many of these applications were originally
developed for one energy commodity or for the financial world and then pressed into
service for all energy commodities (power, gas, liquids, oil, coal, emissions,
transmission and transportation) as well as Risk Management. These origins do show through
- often in an unfavorable manner - when one delves deeply into the performance and
capabilities of these systems. But this evolution to shared database client server is
natural and made sense to undertake for users and developers alike. It was a good means to
cost effectively and rapidly react to many of the earlier industry changes.<br>
<br>
At this point in the typical evolutionary cycle both users and the IT department start to
feel pretty good. Trades are being processed for multiple physical and financial energy
commodities, Risk Management is producing daily updated position reports, including
various VAR results and interpretations. Counterparty risk is being calculated and the
middle office is approving or denying deals based upon daily reporting they receive. Of
course the applications won't handle certain types of complex derivatives and the front
office has purchased a few of its own analytic tools which would benefit from connection
to the larger set of systems. But user and IT management at least feel secure if not 100%
confident.</font></p>
<p align="left"><font size="3"><br>
</font><strong><font size="6">OUCH, THAT HURT</font></strong><font size="3"><br>
And then the summer of 1998 hits and EVERYONE who trades wholesale energy feels exposed.
No one is blaming the applications nor IT departments for the losses which hit some
entities. But EVERYONE is rethinking how they measure and monitor market price risk,
credit risk, legal risks, portfolio risks, operational risks, all risks of being in this
business. Along with this assessment the demands for improved applications start to
arrive. In the list of examples below, note three themes: Nearly everything needs to be
INTRADAY (and usually real time), triggered by some market event, and involves sending
messages (data) between previously independent application systems.<br>
<br>
</font><font size="4"><strong>MANAGEMENT & RISK MANAGERS ARE OR WILL BE SAYING THAT
APPLICATIONS:</strong></font></p>
<ol>
<li><p align="left"><font size="3">Must update all positions and all limit monitoring
INTRADAY based upon forward curves and OTC option prices continuously recalculated from a
variety of trader, middle office and market data service price updates in real time.</font></p>
</li>
<li><p align="left"><font size="3">Must update native load and owned generation
incremental/decremental cost curves for local service territories and for aggregate market
generation and load in neighboring NERC regions. Forecasts must allow for weather driven
updates and transmission constraint updates. INTRADAY updates and scenario analysis
against existing portfolios and existing forward curves will be required.</font></p>
</li>
<li><p align="left"><font size="3">Must identify when limits of any type have been exceeded,
INTRADAY, with real time alerts to all affected parties in the front, back, and middle
office.</font></p>
</li>
<li><p align="left"><font size="3">Must automate the OASIS interface and tagging process
both right away and in a manner that accommodates the greatly expanded Transaction
Management Systems (TMS) now in place in MAPP, FRCC, and SPP as well as the planned
standardized, national TMS to be implemented starting next year.</font></p>
</li>
</ol>
<p align="left"><font size="3">The summer's upheaval was not truly an IT problem. But when
management starts to demand the above very reasonable and quite achievable forms of
improvement, the majority of RMTP systems will hit the wall. This includes not just the
majority of systems now in place, but probably the majority purchased in the past six
months - and sadly, even perhaps the next six months. Many of these systems are NEVER
going to accommodate the above type of capabilities in a reasonable manner at a reasonable
cost in a reasonable amount of time. The majority of RMTP systems have a client/server
architecture which will not meet the grade for event driven messaging between independent
applications. This is the wrong platform for highly integrated real time trading
environments. This has been known to be a limiting platform for quite some time.
Investments made in these types of platforms are going to be one more kind of stranded
cost, a functional dead end.<br>
<br>
<strong>Exceptions and Limitations:</strong> For some smaller shops with very limited
objectives, these client server applications and their inherent limits are acceptable and
even advisable. Client server is simpler, maturer, and in this case the applications are
more turn-key in nature. But for any sizeable shop desiring to compete with all comers on
a regional or national basis in one or more of the energy commodities, there are better
answers. The platform issue is just one of seven major system development or selection
criteria<a href="#footnote1"><strong><sup>1</sup></strong></a> <a name="ret1"></a>, and in
fact, important other criteria can favor the choice of an RMTP application suite based
upon a traditional client server platform. It can be very difficult to avoid the pitfall
of selecting a limiting architecture.<br>
<br>
The summer of 1998 will be, it turns out, painful to a number of third party application
vendors and to a number of purchasers of these systems as the industry advances toward
second generation wholesale application suites. Less visible, but equally under pressure
are any in-house developments which have been progressing based upon traditional client
server.<br>
<br>
</font><font size="6"><strong>OPPORTUNIES FOR EXCELLENCE WITH MIDDLEWARE</strong></font><font size="3"><br>
The majority of wholesale energy applications in existence today, custom and third party,
rest upon platforms which offer limited flexibility for wholesale energy's required types
of rapid evolutionary change. Here is why this is true. The majority of development talent
is inevitably expert in the older tried and true methods. In recent years this has meant
basic client server, database applications. Development has been fast, sure, and
predictable with this traditional client-server.<br>
<br>
But for the type of change and flexibility needed in the wholesale energy markets today,
some of the newer "n-tier", middleware based, distributed architectures are
considerably more viable over time. The key word here is middleware. Middleware is the
middle layer, the glue if you will, which connects applications to each other. It is an
isolation layer which permits applications to communicate and share data with each other
in ways not otherwise feasible. Middleware comes in a variety of forms (e.g. messaging and
transaction processing monitors) and is available from a variety of vendors (e.g. Tibco
and BEA). It has been developed to accommodate communication and data sharing between
components within a single application suite distributed over a network and also to
accommodate the integration of entirely separate applications not otherwise related.
Graphically it looks something like this, though there is a great deal of flexibility in
how the pieces are arranged.</font></p>
<p align="center"><font size="3"><br>
<br>
<img src="../images/platfrm4.gif" alt="platfrm4.gif (6883 bytes)" WIDTH="438" HEIGHT="362"></font></p>
<p align="center"><font size="3"><br>
<br>
</font><font size="6">- TO BE CONTINUED -</font></p>
<p align="left"><font size="3"><br>
This month's column identified the "platform issue" and introduced examples of
four current and future RMTP application capabilities which middleware based platforms can
accommodate in a manner not possible with traditional client server. Next month's column
is "Platform, Platform, Platform - Part II". In Part II the topic is
"middleware", what is it, why is it important to RMTP systems, and why
middleware is needed to meet the four example requirements from above as well as other
future demands. The author is reluctant to use this column to disparage or to promote
specific vendors. A guess will be ventured, however, as to exactly how many of the nearly
forty vendors PMTC tracks in the RMTP space actually have a middleware based platform.<br>
</font></p>
<hr>
<font SIZE="2"><sup><p><a name="footnote1"><strong>1</strong></a></sup>The hundreds of
important criteria for an RMTP application suite can be grouped in a variety of ways. PMTC
uses a system assessment methodology based upon seven top level categories: Scope,
features, technical architecture (PLATFORM), performance, customer support, vendor rating,
pricing and contracts. <a href="#ret1">Return</a></font></p>
<hr>
<blockquote>
<p><font size="3"><em><strong>Disclaimer</strong></em></font></p>
<blockquote>
<p><font size="3"><a href="http://www.pmtcweb.com/" target="_blank">The Power Marketing
Technology Consortium</a> (PMTC) consults on applications, but has none of its own. Nor
does PMTC have any financial interest in the recommendations it makes to its clients
regarding particular vendors. PMTC funded and performed this research solely as a means to
better serve its target market.</font></p>
</blockquote>
</blockquote>
<hr color="#FFFF00">
<blockquote>
<font size="3"><p>Jeffrey Frost, a PMTC Senior Partner, has years of experience as a
banking treasury executive, trading room technology innovator, and Internet electronic
commerce pioneer. While Jeffrey's prior executive and entrepreneurial roles have demanded
numerous skills, much of his career has revolved around one simple theme: The use of new
computing technologies applied to existing information to create profitable new business
alternatives. </font></p>
<p><a href="http://www.pmtcweb.com/" target="_blank">The Power Marketing Technology
Consortium</a> is an IT and electronic commerce power marketing consulting organization
which integrates and supports technologies related to energy trading and marketing.</p>
<p align="left">Jeffrey C. Frost may be contacted at (802) 864-9903; e-mail: <a href="mailto:[email protected]">[email protected]</a></p>
</blockquote>
<hr color="#FFFF00">
</td>
</tr>
</table>
</center></div>
<p align="center"><a href="9809frst.htm#top"><img src="../images/b-t-top.gif" alt="Back To Top" border="0" WIDTH="71" HEIGHT="35"></a></p>
</body>
</html>