界面布局设计师（Layout Designer）
许多应用，尤其是那些非常大众化的应用，需要专业的美工和布局设计。绝大部分技术架构师，通过他们自己的手段能够产生功能性Web页面，但那些页面通常丑陋且难于使用。图形界面设计，是技术更是艺术。通常，界面布局设计师主要和业务分析师以及其它的业务方面的代表们一起工作，作出相应的设计。但界面布局设计师也可一和表现层开发者一起创作系统原型。
技术架构师需要负责确认界面设计在技术上的可行性。我见过许多Web 页面的设计众，使用了一些在word中才允许的特效，但这些HTML是不支持的；例如：使用旋转90度的文本。技术架构师应该尽可能早地纠正这些错误。
表现层开发者（Presentation-Tier Developer）
表现层开发者，负责为整个应用编写所有与HTML, Javascript, JSPs, Applet/Swing code, Servlets 等相关的代码。一般来说，任何直接产生用户界面的程序，都是表现层开发者们的职责范围。表现层开发者常常和界面布局设计者合作，由表现层开发者创建原型和最终实现。表现层开发者还与架构师一起确定前端结构和业务导航设计。
技术架构师负责保证所用的设计模式是可维护的，可扩展的。导航问题通常是复杂的容易导致产生难维护的代码。架构师处在很好的位置上，去发现和纠正可维护性问题，以及凸现出的其它方面的技术问题。
业务逻辑开发者（Business Logic Developer）
业务逻辑开发者负责编写应用中所有不可见部分的代码：包括Enterprise bean，Web services，RMI services，CORBA services，业务对象（business objects），以及数据存取对象（data access objects）。也有人把这些不可见部分称为应用的服务器端组件。业务逻辑开发者通常是Java专家，与架构师合作紧密，并且还在需要的时候做性能调整方面的辅助工作。技术架构师给业务逻辑开发者提供指导。通常，技术问题都出现在服务器端组件，毕竟服务器端组件是应用中最复杂的部分。因此，技术架构师常要监督业务逻辑开发者的工作。
数据建模工程师（Data Modeler）
数据建模工程师根据业务逻辑分析的信息，对应用中所有需要存储到数据库的数据进行识别、定义和编目（catalog）。数据建模通常需要将应用的数据用实体联系图（ER diagrams）描述出来。DBA根据实体联系图生成数据库的物理设计。因此，数据建模工程师和DBA常常是同一个家伙。
技术架构师需要负责确认数据建模是适当的。和业务逻辑分析工作一样，期望数据建模工作100％正确是无理的。不过，如果数据模型基本上遵照第三范式完成的话，未来的建模的变化和数据库的变化就会很小了。
数据库管理员（Database Administrator）
数据库管理员负责遵照应用的业务需求设计数据库，并搭建和维护应用所需的数据库和环境。通常，数据库管理员要辅助性能调优，还要帮助业务逻辑开发者诊断应用开发中在数据存取上出现的问题。有时候，数据管理员既是业务逻辑开发者，还充当数据迁移专家。
技术架构师和数据库管理员一起解决有关数据存储的问题。不过，通常情况数据库管理员还是首先和数据建模工程师以及业务逻辑开发者沟通解决问题。
数据迁移专家（Data Migration Specialist）
有些应用，例如哪些涉及到数据仓库的应用，很大程度依赖与从其它来源做数据迁移工作。数据迁移专家书写并管理所有脚本和程序，保证在运行中，将应用所需的数据转移出来。如果一个应用少有或没有数据迁移工作，则这个角色就没有，或者由数据库管理员一并充当了。
系统架构师为数据迁移专家定义数据迁移需求。和数据迁移专家一起解决数据迁移中的问题，则是技术架构师的另一个角色。
配置专家（Infrastructure Specialist）
基础结构专家负责提供全部研发、测试、生产环境和部署方法。正规的研发和部署配置，能节省时间和精力。职责在于容器管理，书写部署脚本，辅助开发者们诊断测试环境的问题。
架构师定义配置需求给配置专家。架构师和配置专家一起决定所需环境的数量、特点以及每个环境所需的支持等级。许多项目至少需要一个开发环境、一个测试环境和一个生产环境。有些组织中将配置专家的角色和技术架构师的角色合而为一。
测试专家（Testing Specialist）
一个测试专家通常是面向细节的，测试专家负责确认软件产品符合规范，并发现那些不该被漏过的bug。一般而言，测试专家至少需要具有软件产品所涉及业务的基础知识。
技术结构师需要和测试人员一起明确配置需求和所需的支持。项目经理和业务逻辑分析师通常需要创建测试计划文档和测试方法。因此，架构师在测试工作方面，通常是提供一些必要的支持。
项目开展方式（Project Life Cycle Approaches）
关于一个J2EE项目周期该如何构化，有着不同派别的方法论。本节描述这些派系的观点和我对于此的看法。本书的指导方针是和所有这些方法论都相融合的。
瀑布式（Waterfall Approach）
项目以瀑布式开展，需要在编写代码和测试之前，完成所有分析和设计工作。This approach was commonly used when most development was mainframe-based 并且仍然是最多公司选择的方式。
基于瀑布式研发的项目，通常比较庞大，且交付时期比较长。因此，也招来更多的风险。这样的项目通常不需要业务逻辑参与者们学习过多的技术术语，并且也能紧紧控制业务端的接口。与其它的方式相比，采用瀑布式开展项目，不能在项目开展的早期及时获得反馈，分发的都是项目比较完善的实现。 瀑布式开展的项目；项目周期倾向于按照预算周期走；这可能是其大行其道的一个原因。因为瀑布式通常需要一个比较长的时间周期，所以业务需求常常会在项目中期改变。项目经理于是会陷入窘境：如果项目不作业务上的变更，会导致项目品质降低；如果因这些业务变化而改变整个项目，则项目所需的时间和资源就会收到负面影响。
迭代式（Iterative Approaches）
迭代式开展的项目，需要努力将项目拆分成小的组件，每个组件需要很少的资源就能完成。因此因此，迭代式与瀑布式有着鲜明的对照。最常见的迭代式方案就是极限式开发（XP）。
极限式开发的核心目标就在于减少技术风险和项目花费，而这些正是瀑布式研发项目中最常被困扰的地方。极限式开发使用下面的假设：
▲ 从长远来看，越早发现错误成本越低。
▲ 降低复杂度，同时也降低了技术风险；从长远看花费也更少。
XP要求你必须将整个问题拆分成一系列小的问题（称为“故事”），一般需要三周以内去实现。每个“故事”由两个程序员使用同一台台机器完成。在每个“故事”的开发过程中，开展有计划的测试以判断功能是否实现并且被添加到了集成测试测试单元中去。
编程人员只关注他们要实现的那个“故事”，其它任何方面的事情都可以不管。配备专门负责业务逻的人随时准备回答任何关于业务逻辑的问题。
使用成对的开发者去实现所有事情，在理论上减少了一个错误被带到部署期的可能性。使用成对的开发者也使代码的事情倾向于简单化，因为需要时间向另一个拍档解释概念。使用的算法或实现越是困难，必然需要花费更多的时间去解释它们。由于强调了降低复杂程度，进而也减少了错误的发生。
对于测试、实现和频繁集中测试的强调和重视，使得错误能够被尽早发现；并且降低了在修改时又引入新bug和带来其它计划外问题的几率。
XP通过尽早反馈的手段来降低风险。一个开发队伍走入歧途，会尽早收到警示尽快修正过来，花费自然也减少了。
RUP（Rational Unified Process）
RUP是一种定型了的开发方法。大多数描述RUP的文献，将它描述成一个迭代式的过程；但这只说正确了一半。RUP 强调在具体实现之前，先对整个工程进行完备的需求收集、需求分析、功能设计工作，包括具体对象和数据模型。从这方面而言，RUP 采用瀑布式进行需求分析和设计，采用迭代式进行实现和发布。
通过鼓励尽早进行需求的收集和分析，RUP 努力寻求项目实现与用户实际期望的统一和同步。RUP通过鼓励先开发简单部分，留下大部分时间去解决和应对真正的问题；从而使得因设计变更带来的返工减少了。
那种方式更流行呢？
这里我并不是想说哪个方式是最好的，它们都有自己的优点和缺点。瀑布式好像是用多最多的；XP很少被单纯使用。这不是一个评判或者建议，紧紧是一个观察的结果。许多公司使用瀑布式进行初始的研发和重大的升级研发。而升级研发更倾向于迭代式而不是瀑布式，但是迭代的单元通常也比极限式研发要求的单元大得多。XP要求两个开发者做一个任务，是一个强行要求。从一个门外汉的视角，XP好像需要更多的人手来完成一件给定的任务。那个多出来的开发者的花费是容易计量出来的，但修正错误所浪费的生产力确很难算清。并且，人们通常喜欢选择从那些显而易见的地方节约开支。
RUP似乎正在逐渐普及。事实上，比起XP，更多公司更倾向于使用RUP。只是，我看到的每一个使用RUP的实现，都偏向其中一方。多数组织通常都是选用RUP中最能给手头的具体项目带来好处的部分，而不是整个RUP方式。
考虑混合模式
这本书从大体上对每种方式进行了比较。因为没有哪种模式具有统治地位，且都有缺点；所以我推荐混合模式。
XP对于测试的重视，具有很大的价值。 我曾经尝试过对我写的每一部分代码配备测试序列代码并且将这些合并到集成测试中去。我还看到一个小组甚至将这些集成测试放在build的过程中，并且做了如果测试不通过则部署失败的强制实现。 我发现，通过这种手段所避免掉的错误节省的代价，要比写这些测试代码和执行测试过程需要的代价多。
XP向复杂性宣战，也是很有价值的。越简单越好嘛。只关注自己的“故事”的确产生了更简单的代码和实现，但是也增加了返工（时髦点说，就是重构）的可能性，因为很多项目缺少整体规划。如果重构没有正确进行或者开发者们面临时间进度的压力，草草了事的代码还是会无端的复杂起来。并且，开发者可能会以过于复杂作为借口驳回一些业务上的正当需求。
RUP对集中进行分析和设计的强调，是非常有价值的。XP让开发者狭隘的关注自己的“Story”而忽视其它的一切。这可能会带来一定量的返工工作。所有开发者还是应该有一个更大的着眼点的。由于RUP 强调在项目开始初期，集中进行分析和设计；它在纯粹的迭代式和纯粹的瀑布式之间需求了一个妥协。控制与最终用户的交流是必须的。XP假定开发团队的每一个成员都可以与最终用户的代表交流。不过，开发者和最终用户有着不同的视角且使用不同的术语。在实践中，许多开发者不太适应非技术术语的交流。他们就是无法将业务逻辑中的术语转化到技术层面的东西，反之亦然。与业务方进行集中的交流还是必不可少的。