6个降低成本的策略.doc

2004年的6个成本降低策略好的产品经理懂得如何找到平衡。利用无限的时间、预算和人员，任何事都可以做到，但是，我们都知道这是不切实际的假设。每个项目都会伴随着一系列的机会，即预先投资并增加成功几率，或者是以低成本方法获取最好的结果。在这两个端点之间一般会有一个实用的中间区域，在此区域不用花光所有的钱就可以完成项目。本文重点介绍2004年降低成本和风险的几个策略。这些策略基于围绕当今市场上可用的技术和技能的实际业界趋势。1. 智能的人员配置为企业交付应用程序涉及范围广泛的项目和流程，每个项目或流程都需要各自的专业技能架构师、开发经理、系统程序员、业务应用程序员、UI设计员、集成专家、业务分析员、项目经理、QA、系统管理员、技术作者，等等。而且，技术选择可以变化很大，增加了确保成功的专业化需求。对于应用程序开发来说，两个主要的模型是基于J2EE的产品和.NET。虽然这些技术和产品在一些领域里重叠了，但是许多人相信两者必须共存。更确切地说，这些技术需要和人、流程以及已经发展了几十年的体系结构相配合，这些体系结构包括大型机、MQ、UNIX、打包的应用程序和其他技术。过去的几年里，业界对J2EE的关注很多。J2EE是业界见到的最标准化的、灵活的和普遍的编程模型。但是灵活性是和成本分不开的。所有试图精通J2EE API的人都知道，心脏虚弱的人是做不到这点的。在J2EE的世界里，不是说需要一个把两个东西固定在一起的螺丝，而是需要知道螺丝的长度、宽度、螺纹数，以及它是否是一个Philip或规则头。有时候，这是件好事，有时候却不是。.NET从一方面来看被认为是易用的，但同时又伴随着安全性、扩展性和可靠性问题。灵活与复杂之间的矛盾限制了大多数VB、COBOL、CFML和过程化的Java程序员成为成功的J2EE开发人员。企业强度的缺乏使得.NET对许多项目都不适用。使用Weblogic Workshop，VB、COBOL和其他过程化的开发人员在Weblogic上是高效的，这是在企业中经过长期检验证明了的。通过可视的设计器，开发人员可以构建Web应用程序、Web服务、业务流程和门户。这就使得J2EE专家们可以把重点放在更低级的系统上，使得应用程序员对业务作出更实时的响应。最终这个简化使得IT管理在可由较少的专业人员处理的任务上花费更少、把现有的技能集合转移到当前的技术、根据需要扩展补充和外包。关键的成功因素包括：l 重视J2EE技术和开发人员，但要知道应用程序需要利用J2EE API进行多少手工编码。l 使用当前技术而不是极端酬金来吸引并留住开发人员和架构师。l 具有一个开发人员领域分类（spectrum），根据每个开发人员的擅长领域来分配工作（系统和业务）和支付工资（高级和低级）。l 在可由较少的专业人员完成的任务上花费更少。2. 使用应用程序框架加速和简化开发项目灵活性和复杂性之间的相同关系影响每个应用程序所需的开发量。而且，J2EE非常强大，但是非常原始。这就导致开发人员构建大量的应用程序基础结构，而不是把重点放在业务、表示或集成逻辑上。当开发人员利用应用服务器和其他的平台产品来得到预建和打包的基础结构时，每个项目仍然还有许多领域需要重复编码。功能如果可以跨应用程序一般化和重用，那么它在定义上就是基础结构。Struts就是跨Web应用程序使用的一般化的高级基础结构的一个好例子。WebLogic Workshop中的应用程序框架提供了一个更高级的应用程序基础结构，该基础结构当前还没有用到应用服务器、门户或集成产品上。这减轻了开发人员手工编码复杂应用程序子系统的痛苦，使他们把重点放在解决业务问题上。例如，异步处理被看成是构建大规模、高度可靠的应用程序的一个重要的架构元素。J2EE为构建异步应用程序提供了一些重要的功能，比如消息驱动Bean（Message Driven Bean，MDB）和Java消息系统（Java Messaging System，JMS）。但是，如何处理长期运行的对话呢？一般来说，开发人员必须编码一个框架来为每个消息提供一个对话ID，持久存储它，然后关联正在进出的消息，这些过程都是以高性能和容错的方式进行的。当需要一个异步响应时，开发人员也需要构建一个进行回调的系统。这种低级的系统编程费时费力且需要维护。对话的、异步的功能是WebLogic Workshop应用程序框架提供的高级基础结构服务的一个好例子。在Workshop属性编辑器里，开发人员可以将一个方法声明为异步的和对话的，应用程序框架就会关心底层结构。Workshop也合并了Struts。Struts框架的核心是一个灵活的控制层，该控制层基于像Java Servlet、JavaBean、ResourceBundle和XML这样的标准技术。添加到Struts之后，Workshop提供了一个用于Web应用程序布局的图形环境，而不是过去Struts开发人员必须处理的难以使用的配置文件。这些功能显著减少了代码行数，并降低了构建及维护应用程序的复杂性。关键的成功因素包括：l 降低每个应用程序需要编写和维护的代码数目。l 降低对基础结构的关注，增加对业务逻辑和表示逻辑的关注。l 获得以前复杂得难以实现的应用程序体系结构。3. 聚合开发和集成传统上认为开发和集成是两个不同的学科。在巨大而独立的应用程序时代这是对的，但是当今天面向服务的体系结构把更多的前所未有的重视放在了互操作性上。不仅仅是同一个企业里的系统需要彼此对话，Internet、Web服务和XML引导了跨应用程序集成的新浪潮。这一新的范例也驱动了流程驱动的开发趋势。在流程驱动的开发中，新的业务流程设计成涉及多种资源，包括应用程序和人员工作流。这是SOA的优点被极大加速的原因。例如，当构建一个新的订单入口应用程序时，典型的场景是查阅SAP中的库存、访问被开发为EJB的定制的定价逻辑，以及访问一个维护当前销售税率的远程Web服务。如果订了一个订单，这个新的应用程序就需要减量SAP中的库存，然后安排货物的交付。所有的过程都需要通过一个Web应用程序访问，或者对于终端用户是在门户里访问，对于商业伙伴是作为一个Web服务。这个简单的例子中，很显然，该应用程序的开发人员需要访问许多后端的应用程序，这些应用程序会带来许多集成方面的麻烦。例如，他们必须精通JCA（适配器）、JDBC（数据库）、RMI（EJB）、Web服务和其他技术。WebLogic平台通过在单个的开发工具、框架和运行时平台中提供涉及开发和集成的基础结构服务，简化了这样的应用程序的开发。SAP应用程序、定价EJB和税款计算器可以作为控件引用到Workshop开发环境中。这样，开发人员就可以容易地编程，而不用理解底层的API和协议细节。WebLogic集成通过拖放BPM IDE使流程定义变得简单。流程引擎允许开发人员进行数据转换、合并人员工作流和监控业务活动。所有这些都可以通过Web应用程序、在一个portlet里或者暴露为一个Web服务而访问到。关键的成功因素包括：l 开发后用更少的一次性集成产品修补系统。l 增强用于构建和集成应用程序的技能配合。l 增强复合的应用程序和流程的开发。4. 开始转换为面向服务的体系结构实现了基于标准的集成这一梦想之后，增强的重用和快速的复合应用程序开发正在驱动全行业转移到面向服务的体系结构（service-oriented architecture，SOA）。标准的广泛采用使其变为可能，并降低了整个企业（或者更糟的是，跨企业）在底层的实现细节上达成一致的需要。Web服务抽象于硬件、操作系统、编程语言和构成应用程序的其他细节，允许所有与标准兼容的应用程序与其他应用程序互操作。WebLogic平台通过允许现有应用程序暴露为服务和相互组合为新的复合应用程序或业务流程，促进了SOA。开发环境通过控件提供给这些服务一个简单而一致的表示。所有东西都可以很容易地转化为控件Web服务、EJB、适配器，等等。这样，开发人员就可以针对这些远程的、异种的资源来编码，就好像它们是本地Java对象一样。WebLogic提供了其他关键的SOA功能，比如管理应用程序的松散耦合的能力，这种能力是使SOA成为现实所必需的。关键的成功因素包括：l 减少冗余的跨企业应用程序服务（认证、客户描述，等等）。l 增加新的复合应用程序的重用和简化的开发。5. 重新评价硬件平台硬件、Java技术和商业化基础结构产品在过去几年里发展得非常快。对于用户来说，这是一个机会，他们可以升级硬件和软件栈，并且对于同一个许可证实际地得到更多的吞吐量，或者降低维护相同数目的用户或事务所需的服务器和软件许可证的数目。通过将应用程序升级为当前栈，客户会看到大的性能增益，足以降低处理相同数目的用户和事务所需的CPU的数目。这就直接影响了系统的硬件、软件和维护成本，并能很快弥补升级带来的成本。Intel也正在改变企业硬件的经济学。32位和64位的Intel服务器交付相同的或更多的吞吐量时，只花费传统的基于RICS的硬件的一部分成本。在最近的industry standard benchmarks（业界标准基准）可以看到这一点。WebLogic JRockit是为Intel处理器专门优化的唯一的JVM。JRockit已经证明是性能最高的可用的JVM。当WebLogic部署在这些系统上时，应用程序可以扩展到大量的用户或事务。把WebLogic应用程序移动到基于Intel的服务器是非常简单的。基于Java的“一次编写，到处运行”的承诺，运行在WebLogic/Solaris上的应用程序可以不加改变重新部署在Linux、Windows或HP-UX上。一些客户看到，部署到新的平台的成本低于维护传统硬件的成本。关键的成功因素包括：l 降低硬件预算。l 对用于潜在的部署操作系统的Linux和Windows的评价。l 对用于潜在的部署硬件的64位平台的评价。6. 合理化Web蔓延20世纪90年代后期以来，许多企业经历了定制的Web应用程序、遗留大型机的Web前端和客户机-服务器技术，以及各种供应商的门户的大量扩增。通常，这些站点被部署为暴露单个功能或数据源，而对整个企业体系结构缺乏引用。因为每个Web应用程序一般都有一个单独的体系结构、安全框架和用户界面，所以用户要完成业务流程必须访问多个站点即使他们知道如何访问。结果导致Web应用程序很少被用户采用、缺乏企业敏捷性、高的硬件和软件维护成本，并且不能获得客户或业务流程的360度视图。希望降低维护遗留Web应用程序和门户的成本的客户正在WebLogic平台上进行标准化，因为BEA的应用服务器、集成和门户产品从一开始就被设计为工作在一起并共享单个集成的开发环境WebLogic Workshop。使用预集成的应用程序平台套件为客户提供了在定制合适的门户里集成现有系统的灵活性，这个门户包含了一致的主体系结构里的遗留Web应用程序。对于采纳这个合理化策略的客户来说，这样做的目的是创建一个门户框架，该框架将现有的Web应用程序和门户转化为处于面向服务体系结构顶部的主门户里的组件（一般是Web服务）。遗留Web应用程序的资源在门户里作为portlet，而底层的系统通过BEA的集成代理和数据集成引擎相互通