Deal Database

This is the response I put together for Louise.

This may be better done in person. If so, give me a call when you have time.

Here is my vision of the two worlds - Enron and Commodity Logic.

There are two basic alternatives:

If you see Commodity Logic as an independent venture, then we should build-in
independence in our communication of deal data. The "Transaction Store" does
this. Beth's DriveTrain project being led by John Simmons will provide
this. In this model, not every function/system currently performed will be
supplanted by a Commodity Logic module. Complete reliance on Commodity Logic
to provide deal data needed for these systems would certainly complicate the
integration as Commodity Logic may reside outside the firewall. The
systems/functions we don't think we'll outsource to Commodity Logic are:
Trade Capture, Contracts, Valuation, Credit, and SAP functions.
Additionally, we would like to see the development of more reporting support
for the DPR, Operations Pricing Model, EnTelligence, and SAP Warehouse data;
the implementation of a workflow, issue-tracking tool; and an Enron-branded
site for Customer Information. This vision was arrived at by asking the
question: "What would you never consider outsourcing, either due to
competitive advantage, control issues, or confidentiality?"
I started shopping this vision around last week and will continue to do so
this week to get feedback for finalization.

If the two are really one and will be managed as one going forward, then
certainly a single deal database could suffice. In this case, there should
not be separately managed IT functions as redundant development efforts may
occur and we could focus the resources on the top priorities. Right now,
Commodity Logic is heavily dependent upon Beth's resources to provide the
data from the legacy systems. The work to do these data feeds competes with
other priorities currently underway such as Unify Performance, Alberta Open
Access for Power, etc. I think it is important to note that we have two
different requirements for deal data. One - to support Commodity Logic
functions - is transactional and near-realtime in nature. The second - to
support reporting functions is probably a batch end of day process. The
technical design of the two would be different to meet functional and
performance requirements. So, in a combined world, there would still
probably be two sources of deal data, one present on our network as separate
messages for each deal that transactional systems build a listener to
subscribe to and a second source in a warehouse for reporting.

Either alternative can be approached, however organizational alignment and
priorities might be different. Further, if the intent is to break Commodity
Logic off into a separate entity, then the first alternative is preferred to
maintain arms-length independence.

Another alternative is to consider Operations and Commodity Logic as a
combined entity that is separate from Enron that offers systems and
back-office services to Enron and other industry players. I think this may
be what Sally is envisioning. If this is where we are headed, then some of
Beth's resources that are directly tied to support of Operations' systems
should be combined with Commodity Logic resources so we can have a focus on
coordinated priorities. I believe this alternative has the same issues as
the first in terms of what is outsourced, e.g. becomes part of Commodity
Logic, and what remains proprietary and confidential to Enron.

Let me know your thoughts.