Message-ID: <9992735.1075855885330.JavaMail.evans@thyme> Date: Mon, 4 Dec 2000 05:27:00 -0800 (PST) From: mary.solmonson@enron.com To: sally.beck@enron.com Subject: Deal Database Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-From: Mary Solmonson X-To: Sally Beck X-cc: X-bcc: X-Folder: \Sally_Beck_Dec2000\Notes Folders\Notes inbox X-Origin: Beck-S X-FileName: sbeck.nsf 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.