|
|
Enron Mail |
I agree that we need to remove last paragraph and shorten the text (I would remove 2nd paragraph, also).
-----Original Message----- From: Piper, Greg Sent: Wednesday, June 06, 2001 10:21 AM To: Bibi, Philippe A. Cc: Webb, Jay; Guadarrama, Michael; Zipper, Andy Subject: FW: Enron Concerns about JavaSoft Scott McNealy at Sun asked us to send in an e-mail to him our issues with JavaSoft. Mike took a shot at it and a draft is below. It has not gone to him yet but we should get him something soon. My comments are that the draft below is very accurate but is too long and detailed for a CEO and the last paragraph, thought factual, will change. Can you please give me your comments so I can get back with Mike and Jay and finish something and send it to Scott? Thanks. GP -----Original Message----- From: Guadarrama, Michael Sent: Wednesday, June 06, 2001 7:31 AM To: Piper, Greg; Webb, Jay Subject: Enron Concerns about JavaSoft To: Scott McNealy. CC: Jonathan Schwartz, Philippe Bibi, Greg Piper, Jay Webb ------------------ Scott, Enron appreciates the time Sun has devoted to us over the recent weeks. We have enjoyed meeting with your personnel and yourself to share with you some of Enron's needs and concerns. EnronOnline and Enron E-Commerce are required to deliver a unique set of capabilities. Our application and organization must support the high velocity (soft real-time) trading behavior of a commodities market, the ever increasing number and complexity of business requirements, the increasing degree of integration between Enron and its trading partners, and the need to do all this as quickly as possible without sacrificing software quality. Each item in itself is not unique, but the combination is. We firmly believe that our only hope for success is to base our application upon a solid technology stack and development methodology. Our view of the technology stack starts at the bottom with networking, server hardware and storage, operating systems, language, language-level specifications, tools, APIs, and containers, language-independent middleware, and enterprise-level specifications and APIs. Through out this stack, we need the ability to tune each level to optimize it for the particular effort at hand. For instance, applications which do not sustain significant load may wish to take advantage of feature rich language-level and enterprise-level APIs; these applications can live with the performance overhead of these APIs. On the other hand, some applications, such as soft-real-time delivery of quotes over the internet, require the highest performance possible and we are willing to sacrifice the convenience of more feature rich and slower APIs. As an application development manager, I embrace the notion of standards-based development. It holds the promise to allow me to focus my development resources on delivering business functionality and not on developing middleware and containers or dealing with enterprise integration. Unfortunately, there are significant deficiencies in the existing set of specifications from JavaSoft, W3C, OMG, and IBM/Microsoft. None of the specs or APIs have any concept of performance. None of the specs or APIs allow for tunability of features to increase performance. Lastly, there is a significant gulf between language-level and enterprise-level specifications. For instance, the J2EE technology suite does not at all address enterprise-level integration. To be fair, IBM/Microsoft Web Services does not at all address language-level development. The fact of the matter is that because of all these deficiencies I have had to continually reduce my use of J2EE technologies. In fact, Enron's most critical systems were developed outside of J2EE. Only our least critical systems use J2EE. In addition, my group spends at least 40% of its development time addressing enterprise-level integration. As the biggest B-to-B site in the world, one can imagine the level of integration we are expected to provide. My primary criticism with Sun is that they approach customers from the bottom of the technology stack working your way up. Customers need someone to start at the top of the technology stack and explain why it then leads to the bottom. For Sun, it appears to be all about selling hardware and operating systems. Enron has moved past those times. We need top-down solutions. Solutions: Create a separate, distinct, and equally influential body in JavaSoft including ONLY large end-user customers (Power Users). A good first list would include Enron, Charles Schwab, GE, and E-Bay. Create an initiative to focus on enterprise-level specifications with input primarily from the Power Users. This should not be influenced by vendors. Ensure all past and future Java specifications and APIs are geared around tunability and performance. Rethink EJBs. If you want to stop Microsoft from conquering the world, you have to do more than shouting to the heavens. Perhaps, you concede the B-to-C, C-to-C, and E-to-E (employee to employer) markets for now. There's some money there but not as much as there is in the B-to-B market. (Besides, if you really want to win in those markets you need to come out with a desktop which has some useful software on it.) My recommendation is to end-run Microsoft in the B-to-B market by coming out with enterprise-level specification which work and ensure that the Java-based implementation of those specifications are the best. Then market share will follow. Regards, Michael Guadarrama Director, E-Commerce Application Development Enron Net Works, LLC.
|