一个没有赢利计划的电子商务站点就像一辆没有汽油的汽车。它看起来可能会很漂亮。可能会给人留下深刻印象。它可能会让你付出很大的代价。但最终，它哪里也不能去。
去年，人们对这个教训有了深刻的理解。电子企业（EBusiness）一个接一个地破产，但这并不是由于缺少客户，而是由于缺少在这些客户上赢利的计划
在即将到来的一年中，赢利将会像过去一样非常重要。但是，赢利的模式将从基于竞争转变为基于合作。用反话来讲，那就是最具竞争力的公司将是那些不必为竞争担心，而将主要精力集中在协作上的公司。
对于商务而言，橄榄球比喻（“将你的对手压扁！”）已经过去了。未来的商务比喻是交响乐团。整体协作的成功将决定每个单位的成功。
在电子商务中，协作意味着通过合作关系开展销售活动。这意味着利润共享。利润共享迫使我们在协作的每个步骤对盈利模式进行仔细检查。我们需要以最可能低的成本，让技术在协作环境的每个步骤中为电子商务服务。
今天，对于电子企业和电子企业协作有两种技术设想。一种是微软公司的设想，整体称为">.NET平台。另一种是Sun公司的设想，整体称为Java 2企业版( Enterprise Edition，J2EE)。
在该白皮书中，笔者将对.NET平台和J2EE进行比较。笔者将会把重点放在笔者认为在未来的5年内将会对电子企业起推动作用的主要问题：协作与盈利能力上。笔者将讨论这两个平台的技术细节，但只讨论那些影响协作或盈利能力的细节。
需要指出的是，J2EE是一种规范，而不是一种产品。许多开发商在产品中实施了这种规范。最重要的两个J2EE开发商/产品是IBM'公司的WebSphere和BEA公司的WebLogic。根据Cutter Consulting 公司最近的研究报告，这两个开发商占据了J2EE市场59%的份额。Sun公司虽然只占有很小的份额，但却很重要，因为它控制着J2EE规范。
将J2EE的每个实施细节都与微软公司的.NET平台进行比较超出了本白皮书的范围。笔者将对Sun公司（J2EE规范的所有者）定义的整体J2EE设想与微软公司定义的整体.NET平台设想进行比较。为了使得整个讨论更精确，笔者将会把这个问题与一个假想的企业MoneyBroker联系起来，但是虽然这只是一个假想的企业，但所讨论的问题却与任何一个电子企业有关。
关于MoneyBroker
MoneyBroker只是一个用于说明的假想企业。我们假定MoneyBroker的用途是允许进行在线支付。客户可以在一个MoneyBroker帐户内存款，然后在线进行支付帐单。为了吸引客户，MoneyBroker对于未付的存款余额支付利息。
客户可以直接或间接地支付帐单。直接支付在MoneyBroker 网站进行，客户可以登录、安排帐单支付。间接支付通过MoneyBroker合作伙伴进行。MoneyBroker合作伙伴是指那些在客户订购时，可以接受客户的MoneyBroker货币的零售商。当一个客户访问AustinKayaks.com（另一个假想的企业），订购一艘价值500美元的皮艇时，AustinKayaks.com可以提供的一种选择是通过MoneyBroker帐户支付。
MoneyBroker通过将未付的客户存款进行投资赢利。向帐户所有者支付的利率与投资获得的利率的差即为公司的赢利。
电子企业需求
MoneyBroker为了支持电子协作（eCollaboration，electronic collaboration），运行MoneyBroker的计算机系统必须包含一定的能力。在我的经验中，最重要的需求是：
• 互用性 – 系统必须能与协作系统共享信息。
• 可用性 – 系统必须高度可用；第一次由于MoneyBroker 系统停机而导致AustinKayaks失去一次销售机会，它将会很不高兴。第二次，AustinKayaks将会终止合作关系。
• 吞吐量 – 系统必须能支持高事务处理吞吐量，因为支付请求不仅来自于MoneyBroker自己的网站，而且间接地来自其合作伙伴的网站。
为了赢利，总的系统成本必须尽可能地低。在我的经验中，最重要的系统成本的决定因素有：
• 开发成本 - MoneyBroker系统的设计和实施成本。
• 系统管理成本 – 管理MoneyBroker系统的成本。
• 单位生产成本（Unit of Work Costs） - 处理MoneyBroker支付的成本。
• 可伸缩性成本 – 随着客户群的增加，给整个MoneyBroker系统添加吞吐量的成本。
在本白皮书中，这些问题将是笔者重点讨论的主要问题：3个主要的协作需求（互用性，可用性和吞吐量），4个主要的系统成本（开发成本，系统管理成本，单位生产成本和可伸缩性成本）。