公司信息系统部门的治理可能会形成过度的规则或过度的自由。规则过度的一个例子是只适用于一个厂商的治理指令，这样您的系统在扩展时，或在与潜在的公司合作伙伴集成时就会有问题。假如自由过多，个人或者开发小组就会根据他们来选择技术，这样，假如这些技术高手碰到他们“生疏的”优先认股权这样的话题时，扩展或集成又会变得很困难。开发人员可能会受业务环境不断变化的影响。
努力实现环境平衡
多种环境因素在决定我们的系统必须遵守的的规则。存在于一个业务环境中的系统应有足够长的寿命，以为公司和客户创造价值。持续为一个组织创造长期价值的系统必须能够应付经常的变化。合并、并购、新的治理和市场力量在改变系统的环境，以及通过使用该系统完成业务过程的用户的需求。变化是一个常数，必须将它添加到评估方程式中。当然，我们无法预知未来，但我们可以分析趋势并努力设计我们的系统，使之能够接受大量潜在的变化或系统扩展，同时对组织产生的影响又可以尽可能小。
为了做出正确的决策和评估，我们需要理解支配着环境的规则，以及我们的应用程序在该环境中应具有的自由。要理解的最重要的规则是，我们的系统处在不断发展的组织中，无论是在公司、政府还是教育组织中，都是业务问题支配技术问题。许多体系结构和平台评估都将主要问题漏掉了。他们通常会将两项或多项技术并排放在一起，然后比较技术特性列表。在完成的时候，大多数参与者会达成一致，因为他们不愿与评估小组中嗓门最大、最强硬、势力最大的派别争吵。显然，这不是作出选择的最有效方法。
确定要害业务问题
将业务问题转换为对组织需要的实际评估意味着应该着重考虑以下问题：
组织内的技术力量
不抑制程序员的开发环境
不对应用程序构成限制的运行时环境
运行时环境和开发环境的许可证问题和法律问题（可以说是规则的规则）
可找到有经验的开发人员
能找到收费合理、有见地的咨询服务公司
对组织的客户的影响
对厂商或技术合作伙伴的影响
组织的文化和策略
组织的上级治理联盟
“大亨们”是否在讨论并购或合并
谁是决策者
这些业务问题通常比其他问题（比如采用每个会话一个线程的并发模型还是每个请求一个线程的并发模型）更重要。您可以走进老板的办公室，向他发表足可以充斥一次软件研讨会的技术观点，但是除非您强调了组织的需要，否则您的观点将显得非常空洞。
走近 CORBA
现在让我们用 CORBA 来解决这些问题。CORBA 是一种开放的行业标准，它由参加“对象治理组织 (OMG)”的 600 多家公司支持。这些公司包括硬件或软件公司、电信公司、金融公司、大学、医药研究所和政府机构。OMG 并不实现它们自己的规范；它们依靠厂商的实现，这些实现有助于将竟争导向到功能、性能、价格和令人鼓舞的质量这些方面。OMG 本身是一个布满生气的、活跃的组织，它的许多官员在各种会议上撰写文章并发表演讲。只要留心观察，您就会发现，他们总在关注将会对他们的组织及您的组织造成影响的各种变化。
除上述优势外，CORBA 还提供了高度的交互操作性。这保证了在不同的 CORBA 产品基础之上构建的分布式对象可以相互通信。因此，大型组织不需要让所有开发工作都使用同一 CORBA 产品。OMG 一直都在辛勤工作，以期通过加强 CORBA 规范来提供更高级别的可移植性。要知道，当厂商分化它们的产品以及开发人员添加限制时，他们往往会忘记源代码的可移植性这回事。应当指出，可移植性比以前的版本中有了实质性的提高，并且随着因特网互操作性协议 (IIOP) 形成强大的用户集团和众多联盟，可移植性将越来越好。
我们很快变会转入 Java 技术的讨论，但我们首先应将语言看作一个整体。信息系统有一个确定的规则，那就是不确定性本身。Java 编程语言可能是今天的语言，但谁知道下一种更好的语言哪一天会使它暗然失色呢？应当知道，就在此时此刻，有人正在他们的车库里加紧编写一种更好的语言。因此，CORBA 的语言无关性有助于您长期遵守信息系统环境中的这一法则。CORBA 支持一种经典的、稳定的对象模型，此模型将继续步入未来。它一直在凭借最新的语言不断发展，并将继续向极好的新语言（如 Python）扩展。
进入讨论组讨论。
Java 编程语言及其他
