级别： 中级 Anthony (Joey) Bernal (abernal@us.ibm.com), 高级门户架构师, IBM
Ian Uriarte (iuriarte@us.ibm.com), 软件工程师, IBM
2005 年 8 月 10 日 本文描述了团队在启动用 IBM® WebSphere® Portal 实现门户的新项目时通常采取的第一步。它还提供了一些基本工具，可以帮助您完成这第一步。它讨论了团队在启动新的门户项目时通常面临的问题，并且推荐了一些解决这些问题的方法。它描述了各种类型的门户，以及所选择的门户类型如何影响计划流程。最后，它介绍了一些工具，您可以使用这些工具来计划和建立自己的门户。本文是这个由多个部分组成的系列创建新的门户的第 1 部分。
引言
这一系列文章旨在提供一些工具和指导来帮助您完成所选择的 Web 开发项目流程。它没有规定一种具体的方法，而是假定您有某种方法来指导整个开发过程。附录 A. 实用方法讨论我们在实际工作中遇到的一些流程。如果您没有准备好任何正式的方法，请遵循本文列出的流程和常规阶段，这对于您的团队而言应该足够了。然而，如果您已经建立好了流程，则这里提供的信息和工具可以帮助您完成该流程，或者使其适合门户项目。
这一系列文章是由实践经验丰富的门户专家和架构师撰写的，他们已经成功地交付了许多项目。虽然技术和产品方面的经验可能比定义良好的流程更重要，但是最好的解决方案应该将这两者都融入其中。然而，如果您不了解相关问题、风险和可能的选择，则所有这些实用工具和流程都可能难以发挥作用。
在多年研究门户和其他 Web 项目（有时产生令人不安的结果）之后，撰写本系列的作者们承认，有许多关于运行成功的门户项目的问题仍有待探讨。项目的成功和失败在很大程度上取决于组织的项目方法，包括项目遵循的步骤以及项目所采取的特定步骤背后的考虑。
回答下列问题有助于理解什么是成功的方法：
- 项目将经历哪些阶段？
- 一个项目何时完成，另一个项目何时开始？
- 在每一阶段中，可交付的产品和工作产品是什么？
- 如果某个阶段赶不上进度，导致下一个阶段不能按时启动，会发生什么情况？
尽管本系列要做的是解决这些问题中的一部分，而不是为您回答所有这些问题，但是我们希望您在计划项目时牢记这些重要的问题。当您阅读关于这一主题的书籍或文章时，相关的讨论常常基于所推荐的已定义流程。虽然我们可能不选择正在提倡的流程，但是我们仍阅读一些新的关于这一主题的资料，希望吸取一些新的思想，以用于未来的项目。我们发现，了解新的方法可以帮助我们学习新的处理特定问题的技术、调整子流程，或者从新工具中获得一些启发。
有经验的专业人员几乎总有一些预先形成的关于他们的努力方向的想法。这些预先形成的假设有时可能导致项目失败。那么您如何做？在经历过许多门户项目之后，我们希望未来的专业人员在着手新项目时，不管采用什么方法（或者缺少合适的方法）都可以避免我们曾经有过的教训。
这一系列文章提供：
- 一组“实用的”工作产品或工具，可以在几乎任何门户项目中使用，帮助您收集、跟踪、设计和部署成功的门户。即使您没有完全采用我们提供的文档和模板，您也可以从中获得对应该执行的许多任务的新的理解。
- 门户架构师和专家通过几十个项目收集了大量的最佳实践，您可以将它们应用到自己的工作中。
这些讨论中的大部分很有可能是“我没有想到”之类的信息，将帮助您在项目计划上注释另一个行式项目，毕竟，更好的项目计划基于更明智的决策。
定义门户需求
有许多收集需求的方法。大多数项目有专门的需求分析阶段，在这一阶段中，业务分析人员和顾问与最终用户和企业所有者一起探讨他们想要或需要系统做什么。对于敏捷方法，例如极限编程 (Extreme Programming)，收集需求（用户案例）往往几个小时或几天就完成了。有关敏捷开发和极限编程的信息，请参阅参考资料。
在更正式的环境中，在全部完成的需求分析之前，可能需要花几个星期的时间召开用户会议才能获得有用的信息。一般来说，在收集了这些需求并确定了其优先级之后，就需要确定完成的工作的范围及所需的资源和时间。
然而，实际情况并非总是如此。在许多项目中，正式的需求毕竟是事后产生的想法。即使在比较注重需求的项目中，它们的形式也常常不可用。在研究项目的过程中请反复地问自己，“需求是什么？”或许给定的需求与您正在做的事情没有任何关系。
重要的不是进行指责，而是提供对正在进行的工作中的任何不足的思考。在后续的文章中，我们将向您演示如何记录对特定组件的需求，而不管是否已经正式地收集它们。在任何情况下，一收集到需求，就应该立即将其提供给项目团队。把时间花在收集诸如“系统将用多种语言显示信息”这样的常规需求上对任何人都没有好处。相反，应该进行更具体的表述，例如“系统将处理以下六种语言，用户可以随时切换语言”，这样团队就可以理解需求的范围以及如何满足需求。
需求分析方法
在项目的某个阶段，您需要收集需求，您如何看待项目的这个方面将决定您在多大程度上可以满足客户对成功的期待。
一种方法是将需求分析看作是在整个项目中进行的工作，跨整个项目生命周期。在项目的概念阶段收集高级需求。在设计的过程中，团队理解这些需求，并讨论实现的灵活性与特性或功能将带给用户的实际好处之间的矛盾所产生的问题。在项目最后的测试阶段，这些需求将以测试用例或测试场景的形式带回到项目会议。在这种方法中，需求是构建成功的门户项目的基础部分。在不同的阶段，需求是不变的，并且将随着时间的推移而适当地加以采用。
对于门户项目的需求收集，重要的是明确地定义项目的范围，因为这将在很大程度上影响所选择的用户群体。只要在项目的范围中明确地定义了对象和目标（通过选择将成为门户的主要用户目标的用户群体），定义门户的特性和功能集就水到渠成了。
需求模型
门户项目中影响需求的四个主要方面是：
- 功能需求
- 非功能需求
- 内容需求
- 用户群体
图 1 展示了开头的三个元素如何组成核心需求。用户群体是收集这些需求的目的。
通过清晰地确定主要用户群体，您可以定义谁将是门户的受益者。为此，您可以定义一些目标群体并选择将使这些群体受益的特性。
图 1 - 用户群体和需求
需求和项目范围
在多年实现门户的过程中，我们看到许多开发门户项目的团队混淆了需求与项目范围的性质。
- 需求以后应该成为所选择的用户群体需要的特性和功能的细目清单。当然，这应该受到业务主管单位提供的约束条件和指导原则的限制，并且通过所选择的技术进行实现。
- 项目范围是项目团队与支持的群体和业务主管单位之间的合约，承诺在给定的时间内根据一组明确声明的具体假定提供所选择的特性。
项目范围以项目需求为基础，通过选择要实现的具体需求加以确定。关于这些需求的协议是根据业务对象和目标以及项目资源的限制制订的。
门户类型
我们有一种对门户进行分类的方法，我们认为这种方法非常有用。在最近的文章“Developing an On Demand Workplace, Part 4: The business value of WebSphere Portal”中，概述了五种可能门户类型。我们鼓励您阅读这篇文章，以帮助确定您要启动的门户项目的类型；然而，为了方便起见，我们已经将其归纳为三种普通的门户类型。
所谓的内容门户，即其主要目的在于共享知识或信息的门户。这些门户自然以信息为主。内容或信息可以传播到整个企业，也可以传播到企业之外。这些内容可以从完全不同的系统中聚合，也可以从集中的内容储备库提取。用户将门户作为主要的通道来访问内容。
所谓的事务门户，即其主要目的在于为用户提供执行事务或接收其他用户执行的事务的更新的门户。这种类型的门户可能包括应用程序内或门户内的工作流。事务门户通常是两个或更多完全不同的系统的集成，例如企业资源规划 (ERP) 系统、客户关系管理 (CRM) 系统或供应链实现。
协作门户为以各种方式在一起工作的人员提供工具。它们可以包括使用 Sametime® 或其他即时消息传递系统的的实时通信支持、使用消息板的异步通信，以及文档协作功能。
为什么定义门户类型如此重要呢？其原因在于，确定将构件的门户的类型有助于您定义实现的大部分工作项，并且影响您在项目中分配资源的方式。
内容门户
内容门户需要在查找内容、定义内容生命周期和集成创建这些内容的流程方面做更多的工作。此外，还需要花大量的精力设置内容的格式，以适应特定的品牌形象和企业指导原则。必须通过发布内容的门户支持培训用户群体的流程，以便他们能够创建、更新、维护和拥有门户上的这些内容。
图 2 展示了内容门户的典型实现。
图 2 - 内容门户
事务门户
在另一方面，实现事务门户要求更多地理解选择与门户集成的每个系统。这样的集成是具有挑战性的独立项目，例如准实时系统集成。这种类型的集成强制您将资源和精力更多地投入到明确地定义每个集成点，花大量的时间和精力定义要包括在门户中的每个系统的连接文档。
协作门户
实现协作门户涉及另两种类型的门户的某些方面。通常很好地混合了消息传递系统、基于事务的系统的集成以及需要集成的相当数量的内容。大量所谓的知识门户适合这种类别的门户部署。这些协作门户要求对每一种技术您都有经验丰富的团队，因为不可能每一件事都顺利地进行。所以在计划协作门户部署时，您的团队中需要内容门户实现方面的专家以及系统集成专家。
使门户如此有吸引力的是其对集成的承诺。不过，人们对集成的宣传常常夸大其词，其实，作为满足客户的用户群体的实际需要的解决方案，集成显得过于简单。作为这种解决方案的实现人员，您当然要面临努力在给定的商业、政治、技术和时间的约束下将数十个完全不同的系统连接在一起的现实。从集成的观点来看，门户确实提供了一种完美的框架，使企业能够在要求苛刻的用户群体面前展示统一的形象。
如果门户包括这三种类型的门户的各个方面——或许还有一些此处没有定义的功能——难度甚至可能变得更大。如果需要将关键资源分散到许多不相关的方面，甚至可能因此而葬送最佳定义的项目。对于第一次门户发布，您反反复复听到的主题就是从小处着眼。不要试图包括用户希望列出的每一项功能，即便他们真的需要。强硬一点——您的声誉可能维系于此。如果项目确实有许多主要的功能，就计划一系列发布好了，一定不要一次发布全部内容。
定义目标对象
定义目标用户群体是构建成功的门户最重要的部分。对于目标明确的门户，例如代理中心或呼叫中心门户，确定用户群体可能是一项简单的工作；然而，对于多用户门户，这项任务所涉及的工作可能比您想像的多得多。一个门户实现可以满足许多用户群体的需求。例如，作为简单的 B2E 门户或动态 Workplace 启动的项目可以包括组织中许多不同类型的用户。您需要识别访问门户的不同用户，并对其进行分类。
定义目标群体有助于定义特性、内容和系统集成要求。为了将需求压缩成一组非常有用的特性和内容，目标群体是关键。在另一方面，有时不同的用户群体会带来完全对立的需求。这可能让项目团队感到不安。取决于目标对象，在对需求进行分类和确定需求的优先级时，用户群体应该是计划不可或缺的一部分。
虽然我们没有提供特定的工作产品来帮助您完成这一任务，但我们建议：
- 留出时间确定和讨论谁需要访问该门户。
- 定义门户的宗旨，帮助您根据项目构建的范围坚持目标。
- 用简单的列表或电子表格列出不同的用户类型、不同的用户群体和他们需要通过门户完成的活动。
在本文后面，您将看到如何定义这些信息中的一部分，从而使之成为更正式的文档。
门户管理
门户管理是许多项目常常忽略的一个方面，特别是当项目由技术人员推进并且没有很好的业务激励目标时。我们已经注意到，大多数项目未能考虑门户解决方案的这一重要方面，而在项目启动之后，这是最重要的。因此，如果门户管理不是项目早期计划的一部分，则最终的解决方案可能看起来是完整的，但在经过仔细考虑之后，将发现它很难管理，充其量也只能算作部分解决方案。
什么是门户管理？为什么门户管理如此重要？门户管理是一组流程和过程（用于管理门户不断进行的操作）及其相关的流程和技术。它由拥有门户解决方案的组织定义，是核心门户解决方案的一部分。
单凭技术无法解决我们尝试通过实现门户处理的问题。我们的解决方案也很有可能涉及人和组织。因此，您需要一些流程和技术，以保持在物理、政治和组织的限制下解决方案能够在假定的框架中正常地工作。
情况当然并非总是如此。在许多较小的门户中，有简化的流程和小型的团队，他们相互协作，很好地管理和提前准备系统的功能和使用。多次发布、争用资源和时间压力都可能给环境和组织带来其他问题。理解如何使用、管理和增强门户可以减少将来可能出现的许多问题。本系列后面的部分将对这些问题进行更详细的讨论。但是我们现在需要考虑如下问题：
- 门户中将有多少不同的提供者？来自不同业务单位的不同团队是争相把他们的信息放到门户中，还是每条信息都由单个源或部门驱动？
- 如何建立门户的基础设施？是用一个门户服务器来发布所有的信息，还是设置多个不同的门户环境，以便用户根据自己的不同需要进行切换。
在这一系列文章中，我们将继续讨论该主题。
确定门户的范围
确定门户（或 Portlet）的范围不像听起来的那么难。确定门户的范围其实就是分析需求，弄清楚您需要门户做什么。（请参阅定义需求的方法部分中对范围的定义。）
门户其实就是一个人员、内容和应用程序的窗口。需求有助于定义这些窗口以及每个窗口中的内容或数据。您需要做的就是将需求、设计和信息体系结构融合在一起，来有效地启动确定范围的流程。大多数项目都知道它们需要拥有 Portlet A，该 Portlet 将从特定的源显示信息。它们甚至可能定义要消失的信息，以及信息的格式下面是确定范围需要做的工作——定义 Portlet 并提供一些关于该 Portlet 后面的数据源的细节。
可以使用一些用于确定范围的电子表格，但是它们也可能引起混乱。在这一阶段，我们不需要将过多的信息放入一个 Portlet 或多个 Portlet 的设计中。此时，大多数团队对门户框架的了解都还不够，无论用什么方法都难以形成良好的设计决策。关于 Portlet 消息传递这样的主题的决策应该留待每个 Portlet 的全面设计会议研究。
在这一阶段，只有少数其他方面的事项需要考虑。对于每个 Portlet 或一组 Portlet，需要考虑以下事项：
- 确定 Portlet 或应用程序的作用和主要功能。
例如：显示程序中性能最高的前十位的列表。
- 确定 Portlet 将从中检索、添加和编辑数据的数据源。
例如：Portlet 将查询当前程序的数据库，并显示名称、地理位置列表，以及分值最高的前十位的得分。
- 模拟 Portlet 的外观显示。
一下子讲清楚这个问题是不可能的。信息体系结构（Information Architecture，IA）是一个比我们在本文中介绍的还要大的主题，不过，在这一系列文章后面的部分中，我们将介绍设计和 IA 问题。
- 考虑谁可以与此 Portlet 交互——谁可以查看数据列表，以及谁可以更改和编辑 Portlet 配置。
开始把用户分成各种角色，这样以后就可以将他们映射到 LDAP 组中。这包括用户以及企业内的不同管理员（如有必要）。
图 3 展示了一个示例电子表格，您可以使用这个表格来开始概括页面和 Portlet 的初始流程。
图 3 - 确定门户中的 Portlet 的范围
如果在召开门户研讨会之前获取了所有这些信息，则您有了一个良好的开头。作为参加过很多这样的研讨会的顾问，我们希望第一个上午从评审门户将提供的功能以及功能的某些白板图开始。如果首先介绍这些信息，架构师可以从一开始就把注意力集中在您的特定需求上，并且帮助您制订初始设计计划。
工具或工作产品
可以使用许多工具或工作产品来帮助您着手定义门户的基本需求。这些构件可以向您提供掌握项目的方法要点或当前“最受欢迎的”技术的方法。我们认为选择的这些工具或工作产品非常合理，而且相当简单，足以帮助您详细记录门户需求，以为下一步做好准备。
针对门户需求的初始工作产品集包括以下内容：
- 内容库存
- 内容分类（请不要与门户分类混淆）
- 页面和 Portlet 矩阵
- 门户分类和导航（也称为信息体系结构或 IA）
- 应用程序和服务库存
- 内容和服务地图
这些工作产品中有一些是简单的电子表格，您可以在其中确定并记录关于门户的主要决策要点。下面让我们对工作产品进行更深入的讨论。
内容库存
如果您要设计基于内容的门户，则内容库存极其重要（尤其是当门户将替换现有的 Web 站点或 Intranet 组时）。内容库存可向您提供要迁移到门户的内容的数量，以及用来计算迁移需要多少工作的数据。
对于不使用现有内容的新门户（通常情况并非如此），内容库存可以帮助参与者着手考虑将为门户生成的内容类型。该工作产品是内容分类的开始，有助于组织关于门户内容的想法。
对于事务门户和协作门户，该工作产品没有那么重要，但仍是有待开发的良好实践。它可以帮助您确定内容的需求，无论需求多么不重要，您都仍需要考虑它们。对于这两类门户，要获得收集实用需求的帮助，请参阅服务库存和地图工作产品。
内容库存工作产品的主要目的是创建所有现有内容的准确数量，并获取统计数据，该统计数据包括页面数目以及需要迁移到门户的内容类型。另外，该文档可帮助您确定谁拥有内容的每种类型、以及谁负责生成每种类型的内容。因此，当您准备执行迁移时，您知道应该参与到此过程的内容所有者。在重新安排信息的格式或用途时，内容所有者还是重要的参与者。
表 1 展示了一个内容库存摘要的示例，用来帮助评估将内容从一组 Web 站点迁移到门户项目要用的时间。
表 1. 内容库存
| 项 | AMERICAS-总计 | ASIA-总计 | EMEA-总计 | 总计 |
|---|
| 库存中列出的 URL 的数目 | 558 | 169 | 221 | 897 | | 考虑迁移到 WIN 门户的 web 应用程序的数目 | 69 | 25 | 28 | 98 | | 目前不是通过 Intranet 分布的内容项的数目（部门可能需要将其在 Intranet 上发布） | 84 | 4 | 10 | 95 | | 总计 | 711 | 198 | 259 | 1168 |
这个库存示例演示了三个不同的地理位置：美洲、亚洲和欧洲 (EMEA)。从美洲迁移的 Web 内容项的数目在数量上超过了其他两个地理位置（限度大小相当）。这可能意味着随着时间的推移逐步将内容迁移到新的门户。取决于首次向不同目标对象推出门户的时间以及他们可能期望看到的内容，可能需要花费大量的时间来迁移现有的美洲信息，然后才能进行其他地理位置的信息的迁移。在建立内容库存时可以发现这种类型的信息，在以后计划和确定项目的范围时，将证明这非常有用。
内容库存是“活”文档。当它完成时就变得过时了，而在临近发布门户时，它将继续改变。因此，您需要在项目的早期定义维护流程，以便更新库存，并使其能够与对门户预计要替换的站点进行的任何更改保持同步。建立内容库存维护流程有助于创建过渡策略，过渡策略让内容所有者负责报告内容发布活动，并且提供关于内容的重要信息。对于成功地迁移到门户中的正式 Web 内容管理系统而言，这种过渡策略至关重要。
内容库存应该包括每个内容项的以下属性中的大部分：
- 位置，例如 URL、网络上共享驱动器的路径或内容储备库的位置。
- 内容所有者或创建者的名称。此人负责更新和归档或删除内容项。
- 内容所有者的联系信息。
- 内容的目标对象，例如部分、分部或组内的角色。
- 内容项的名称和描述。
- 撰写内容项的一种语言或多种语言。有不同语言的几份文档副本。
- 迁移的优先级。优先级有助于确定是否将某项内容迁移到门户内容储备库。还可以使用此信息来确定迁移工作量的大小。
保护内容
需要考虑的一个基本方面是门户的不同组件的安全性。安全性提供了一些手段，可以确保内容或应用程序只对经过授权的用户可用。与自定义不同，我们将立即讨论安全性。安全性是由系统管理员创建的，用于执行企业或部门定义的访问控制。用户无权选择何时执行安全性。在大多数内容或访问实现中，安全性是以二进制的方式设置的——用户要么能够看到内容要么不能看到内容。在大多数情况下，没有中间状态。
门户安全性控制所有门户资源（包括内容）的访问级别。对于大多数资源，安全性是根据组成员身份和用户属性应用的。如果对于要迁移到门户的内容安全性是一个问题，现在就是开始研究在新的环境中处理这个问题的时间。许多实现延迟了这一工作，并且在其更好地理解门户框架的功能和限制之前，只允许将公共或“内部公共”信息发布到门户。然而，在某些情况下，目标内容和个性化内容是新门户的核心，因而也成为工作的主要内容。
除了内容之外，门户资源还包括选项卡、导航菜单、Portlet、Portlet 外观和门户主题。对所有这些资源的访问都是基于角色和组成员身份进行的。如果用户是特定组的成员，则可以给组分配一个角色，该角色有权访问安全性策略允许的资源。
内容和门户分类
根据《American Heritage Stedman's Medical Dictionary》的定义，分类是“划分有序系统中组织的类别，以指示自然关系。”这种定义对内容或门户分类非常合适。我们还需要区分门户分类和内容分类，尽管它们是密切相关的，但毕竟有所不同。
门户信息分类（或导航分类，通常是在信息体系结构领域内定义的）是按照一定的顺序划分用于导航门户的内容的类别。这包括所有类型的导航，例如选项卡、页面和 Portlet，在某些情况下还包括一些重要 Portlet 内部的永久性内容链接（如在书签 Portlet 中创建的链接）。这种定义是基于使用正式含义的术语或隐含术语的自然关系进行的。换句话说，在设计门户分类时，考虑到了门户最终用户。请了解如何为需要用于创建信息分类的一些基本概念创建有效的分类。
另一方面，内容分类也是用在内容管理系统中的内部分类，用于根据内容创建者和内容所有者的特定需要来区分内容的类别。
为了简化内容和模板的创建过程，请在启动开发工作之前确定分类指导原则。您需要为将定义的每种内容类型的元数据打下基础，并且确定如何根据自然关系组织内容。另外，即使还没有定义好所有的内容，也要尝试尽可能地开发一个初始高级分类。
图 4 展示了一个示例内容分类，它遵循地理方法。它仅使用三种级别，这是保持结构灵活性的最佳实践。
图 4 - 内容分类
页面和 Portlet 矩阵
页面矩阵是创建用来记录门户将使用的所有页面和 Portlet 的工作产品或构件。这种工作产品是在信息架构师定义了门户分类之后创建的。它利用分类来安排哪些元素作为页面、以及哪些元素作为选项卡或子页面。它还向架构师展示了如何在页面级实现分类，从而有助于完成设计。
图 5 中的页面矩阵非常类似于我们在确定门户的范围时开始创建的。在完成了矩阵之后，我们可以立即开始添加在需求分析和设计阶段十分有用的信息。业务主管可以将这种矩阵作为门户需求的一部分，用于验证每个页面或某些 Portlet 信息的安全和权限。
图 5 - 页面和 Portlet 矩阵——已修改
Portlet 矩阵是作为将在门户项目中实现的每个 Portlet 实例的参数显示的构件。它包含一个 Portlet 及其相关属性列表，例如安全需求、每个 Portlet 的个性化和自定义需求，以及每个 Portlet 需要的视图类型。
图 6 展示了 Portlet 矩阵中通常收集的 Portlet 属性或特性列表。
图 6 - Portlet 特性
内容地图
对于基于内容的门户，在收集了关于页面和 Portlet 矩阵的需求，并且还编制了内容库存的文档之后，您需要映射将在新门户中的特定页面和 Portlet 上显示的内容。在一个拥有数以十万计用户的大型组织中，这项任务可能会使人不堪重负。我们对这项任务的建议（正如在本文的前面所述）可以概括为四个字：增量发布。
实现门户已经成为一项复杂的任务，涉及编排系统集成、简化业务流程，以及管理内部策略。因此，如果内容库存类似于数以万计的内容项，我们建议您以增量的方式发布内容。我们知道您可能会在这个问题上面对极其强烈的反对；然而，此时您项目的安全确实处于危险的境地。内容映射任务包括重新安排内容的用途和格式，有时还需要向内容发布审批添加新的工作流。这不是一件可以轻而易举地完成的事情。在大型组织中，它需要得到许多部门的支持，并在企业的多个场所进行。
要生成内容地图，需要内容库存、内容分类、完全开发的 Portlet 和页面矩阵，以及经过完全审批的门户 IA（或者导航分类）。最终工作产品通常不是一个文档，而是一系列文档，说明如何通过门户导航模式将现有内容和新的内容部署到不同的 Portlet 和页面。如果个性化和自定义是项目范围的一部分，则最终工作产品还包括用于个性化和自定义的规则。
服务库存和地图
服务库存和地图是一个工作产品，可以帮助您定义将交付给用户群体的服务（或应用程序）列表。服务是任意大小的应用程序，用户可以通过服务来执行事务，这些事务既可以如查询数据库一样简单，也可以涉及在后端系统（如 ERP 或 CRM 系统）执行数千条记录更新的批处理过程。这些服务可以是远程应用程序，例如需要与门户集成的远程 Web 服务。这些应用程序不需要全部存在，但对于存在的应用程序，您需要定义集成所需的全部元素。
对于作为新功能开发的服务，该工作产品可帮助您收集关于目标对象的基本需求（目标对象稍后将转换为用户组），以及最终用户无缝访问这些服务所需的集成点。
该工作产品的三个主要用途是：
- 定义这些服务所需的全部属性，以便集成到门户或发展成门户
- 确定这些候选应用程序的业务和技术所有者，以实现门户集成
- 确定门户提供的候选服务的目标对象
图 7 中的服务地图显示了典型服务和应用程序库存，它具有为记录集成的技术需求而收集的一些典型属性。所收集的功能需求将受到这些应用程序的功能以及门户可提供的其他功能的总数的限制。
图 7 - 服务地图
个性化和自定义
个性化和自定义相似，许多最终用户无法区分。然而，这两者之间具有明显的区别。
自定义在日常生活中随处可见。例如，在餐馆里，请求更换菜肴是很常见的。我们根据个人喜好请求这些更改并调整菜单。换句话说，我们“自定义”了菜肴。与此类似，Web 方面的自定义包括用户根据他（她）的特殊喜好更改“缺省”用户界面、布局，以及要呈现的内容。
从另一方面来说，个性化更偏向于与用户匹配内容。例如，去看病时，护士首先要确认您是谁。她通过询问一些问题来确定您就是您说的那位病人。她可能还会问您的身份证号码、ID 或者家庭住址。如果您生病了，则医生可能会接着问您一些个人问题，例如您看病的原因和身体上出现的任何症状。然后，医生采用这些信息，并将其添加到您的个人“文件”。该文件包含您的健康状况的信息。它向内科医师提供这些信息，以使他能够向您提供非常“个性化的”治疗。内科医师需要确保他开的药物不会使您过敏，药物不会对您产生副作用，等等。这是在匹配对用户的服务标准。这与 Web 门户上的个性化如何工作非常类似。根据用户的概要信息，个性化通过规则来将“服务”或内容与特定用户匹配。
在一定程度上，可以按照如下方式考虑这两者：自定义是由最终用户处理的，而个性化不是。当然，实际的个性化通常基于您在门户环境中的角色或职务。
理解用户视图
用户在门户中看到的内容是由不同的确定范围的机制集成决定的，我们已经在本文中对此进行了描述。图 8 演示了如何将过滤器应用于完成的“单个用户视图”。
内容和门户管理员必须使用内容属性和元数据（包括用于安全策略的内容属性和元数据）标识所有内容。还可以为特定的目标对象标识内容。其中的每一个属性都可帮助确定向哪个用户提供哪些内容。
- 安全性视图。该过滤器显示整个领域的可用门户内容之外的内容，用户有权访问这些内容。此视图是由内容和门户管理员创建并实施的（在内容所有者提供的内容内）。
- 个性化视图。通过应用业务部门创建的个性化规则，此视图进一步过滤最终用户可看到的内容数量。此视图是业务部门通过定义应用于每一个 Portlet 的个性化规则创建的。
- 自定义视图。该视图应用最终用户的个人偏好，以进一步过滤要显示的内容。该视图由最终用户创建，方法是更改用户的概要信息，并编辑对内容通道的 Portlet 订阅。
图 8 - 用户视图
结束语
没有什么比艰难地完成一个项目，但是最后却发现该项目有问题更糟糕的了。如果因为站点通不过测试或不堪最终用户的使用而不能发布，则不仅您的精神要倍受煎熬，而且您的职业发展也将受到极大的影响。而最糟糕的情况是，站点虽然发布了，但是却在第一天因为测试不充分而崩溃，或者它是由缺乏相关经验的人员在没有主题专家的指导下设计和创建的。在许多情况下，不得不“重新回到制图板”，并且给费用高昂的专家打电话，寻求协助解决某个在项目早期稍微勤快一点就可以轻松避免的问题。
本系列旨在让您正确地迈出第一步。通过遵循本系列中提出的建议以及在开发过程的早期邀请某些专家给予指导，您可以避免其他的团队遇到的许多问题。您有望从中得到教训，并且通过了解构建门户需要做的工作以及获得成功的方式，力求避免走入并不少见的极端情况。
在后续的文章中，我们将沿着项目流程定义范围，设置门户，直到最后实现和发布门户。我们不期望每个项目都将使用一个工作产品或遵循一条建议。有时您需要做的相当简单，但是您可以在自己的门户构建之旅中利用这些想法的一部分。请继续关注关于门户开发的文章。
附录 A. 实用方法
讨论方法与讨论咨询方面的其他主题一样，有时可能导致最激烈的争论。有经验的专业人员常常都有自己喜爱的方法——通常是知名的流程的变体，他们通过自己无数次的实践对其加以改进。然而，情况并非总是如此。很多时候没有适当的流程，或者至少没有一个流程可以实际支持项目。
我们中的大多数人都相信，必须有某种类型的方法或流程才能使项目成功。这通常是事实，不过对于小型项目，即使流程打扰您的时候比帮助您的时候还多，但是由于项目的大小和范围，您也可以获得成功。有一些通用的方法非常好，并且已证明有效，您可以从这些方法中进行选择，许多组织已经采用了其中的一种或多种。然而，团队在实现或执行流程方面通常达不到预期的效果。由于缺乏培训、没有专家指导或补充新的团队成员，因此即使是最佳定义的流程，其有效性也可能降低。
所以我们都是在门户项目中使用某种方法的坚定支持者。然而，在这一领域与客户一起工作的时候，我们发现在方法的实现方面有许多地方不合常规。我们已经尝试对其进行分类，以便您可以识别（有望在项目的早期）项目可能在什么地方出现，以及您可以相应地采取哪些纠正措施。
方法类别 1：临时方法或没有方法。团队除了主意和期限之外什么也没有。虽然没有注定会完全失败，但在此项目的生命周期中肯定有许多失误和沟通问题。团队漫不经心地谈论需求和设计，不过每个成员或子团队通常都清楚自己需要做什么、应该何时做，以及要交付（或不交付）什么工作产品。一般来说，文档是后来添加的（如果真的考虑过文档的话）。
方法类别 2：石偶方法。团队高度推崇他们的组织内的方法和流程，但是团队中没有一个人真正知道或理解。许多这样的团队拥有知名流程的行业标准证书或高级排名，但是当组织发生改变，培训减少，以及有经验和领导能力的人离开时，他们就不能理解或遵循自己的组织内部的一套标准。对于许多团队，“流程”仅仅由一些必须定期填写的固定表格组成。
方法类别 3：采用最近流行的方法。从项目一开始，团队就尝试采用知名的方法。有时，过分热心的经理指示团队采用或遵循一些知名的流程。虽然这是很好的长期策略，但是在时间和预算都非常紧张的项目中，这种策略从未实际发挥作用。有时，流程中的一些工作会因缺少适当的培训或经验而达不到目标。时间和预算限制常常使团队采取急功近利的做法，而方法也会因此而失去作用。
方法类别 4：墨守成规的方法。这种方法很少见，通常只是在大型组织中看到。团队有定义良好的流程，在团队前进时，这些流程对其加以限制。模板、表格、委员会和评审团甚至可以使最热切的团队慢下来。团队成员通常都经过了良好的培训且经验丰富，了解流程的工作方式，知道在不同的时间需要做的工作。有时需要做一些工作来修改流程或工作产品，以适合门户项目。作为一名新的团队成员，通常有许多关于流程的内容需要学习。这种方法几乎总会使项目慢下来。
在读完了这些描述之后，您可能认识到自己的组织或项目中的一些特点。更有可能出现的情况是，您难以在解决所有的流程问题的同时，仍然按时交付项目。然而，在为您提供了一些知识和支持之后，不管您属于哪一种类别，您都能获得项目的成功。
即使团队不属于上面的类别，也可能有问题。在一个项目中，团队成员通常是从不同的领域和地方抽调过来的，临时组成一个团队。在外部顾问团队以及内部人员团队中都可能出现这种情况。当配备一个项目的人员或者制订集合资源的计划时，在技术和业务方面的经验和专业知识是最重要的。然而，从来都不会有人在会谈期间询问或讨论特定方法方面的经验或做法。
即使团队或组织的每个人在定义好的流程的特定方面都得到了良好的培训，但是个人的经验并不总是让人很好地融合到一个新集体中。换句话说，团队的不同成员使用的流程可能是相同的，但遵循的方法却是不同的，这充其量会引起混淆，但是更有可能造成混乱。
解决上面提到的部分问题的一个建议方法是使用“方法采用研讨会”。您可以使用这种方法来确保团队成员或不同的团队之间达成某些一致。需要给所有的团队成员提供适当的培训时间，并且在关键产品干得热火朝天的时候不要忘了在开始时进行几个小时的培训。对于所采用的任何方法，不管是组织级的还是项目级的，情况都是如此。
参考资料 学习
获得产品和技术
讨论
作者简介  | 
| | Anthony (Joey) Bernal 是 IBM Software Services for WebSphere (ISSW) 的一名高级门户架构师。从最初的 1.1 版开始他就从事 WebSphere Portal 方面的工作，在设计和开发门户应用程序方面有着丰富的经验，他已经用 IBM 的 WebSphere Portal 实施了许多项目。Joey 还是一位杰出的作家、演说家以及关于 WebSphere Portal 及其相关技术方面的讲师。他是《Programming Portlets》一书的合著者。 |
| 
| | Ian Uriarte 是 IBM Software Groupis 的顾问兼软件工程师，主要致力于 Lotus Workplace Industry Solutions 方面的研究。他是一名实践经验非常丰富的解决方案架构师，组织能力和技术水平都非常高。他使用过各种 IBM 技术，自 IBM WebSphere Portal 开发之初就一直参与它的研究。他还喜欢弹吉它，而且把大部分业余时间花在社区开发非营利组织的志愿活动方面。 |
对本文的评价
| 
