很多架构师都是从好的开发人员逐步过渡而来的，但并非每个好的开发人员都希望成为架构师，而且他们并不是都适合做架构师。无论您是打算进行职业转型的开发人员，还是寻找能承担体系结构设计责任的合适人选的经理，都务必对此转型过程有个清楚的了解。本文将讨论从实现专家到架构师的过渡过程。
在寻找优秀的指挥的时候，您首先要找的是一名优秀的音乐演奏家。但并非每个音乐演奏家都能成为优秀的指挥。架构师的专业发展方面也与此类似。越来越多的 IT 组织开始认识到良好软件体系结构的重要性，架构师职业正迅速发展为 IT 内一个独立的门类。由于要从相当小的候选范围内招募架构师，因此这就给管理带来了一些新挑战。即使人力资源部门找到了候选者，针对经验进行的筛选也比其他门类更为严格。跨越这些障碍的最快方式是要认识到，大部分好的架构师同时也是好的开发人员，因此寻找架构师人才时可能首先应该从普通开发人员中找起。招聘人员在对候选者(内部或外部)进行详细审查时，应该考虑这个观点。不过，对此资源进行挑选可能比较麻烦，因为只有极少的优秀开发人员具有成为架构师的特征或愿望。
本文列出了开发人员成为架构师要进行的工作。我将从可能考虑进行此转型的开发人员和评估进行此转型的开发人员的经理这两个方面来探讨这一问题。我还将提供一系列在做出这些决策时要考虑的因素。
个人特征
软件开发团队和管理层之间的联系始终是 IT 中的一个关键所在。二者都倾向于以完全不同的方式考虑给定的问题。大部分相关技术都是讨论项目经理应如何跟踪和解释开发人员的进度和问题。但沟通不足的情况仍然非常普遍，而且这是项目失败的首要原因。好的架构师是解决这个问题的最有效办法。架构师的主要责任是提供开发人员和项目经理之间的共用沟通媒体。他们负责让业务规则及需求与工程实践及限制相适应，以确保成功。以下是成功架构师的一些主要特征。
愿意并有能力进行沟通：在开发人员中发现架构师的最有价值标准是有效的沟通。您需要技术娴熟、经验丰富的开发人员，这样的人员需要有就项目中的业务相关问题进行沟通的经历。架构师经常必须对理解方面的差距进行预计，然后才能有所贡献。他们必须愿意克服困难来确保技术和业务观点的融合。他们并不必对意见交换工作进行计划和协调;这仍然主要是项目经理的工作。他们的任务是确定表述系统设计时的最佳工具和构件，以促进有效的意见交换。他们必须能够判断当前方法显得不足而需要采用新方法的情况。写作技能也非常重要，还需要具有制作草图的技能或使用制图软件的能力。
具有处理谈判细节方面的经验：架构师经常需要负责讨论系统开发的技术折衷方案。优先级的冲突可能会带来实践限制、风险规避或可能导致在各个不同业务组之间需求不同。优秀的架构师能够有效地评估技术可能性，并能在不损失项目的主要价值的前提下制订开发计划来处理各种利害关系和限制。这与前面讨论的沟通技能紧密相关，但同时也要体现架构师的技术能力。好的架构师候选者应该是经常帮助对有争议的讨论进行引导的人，能够使讨论得出新的想法，而不会使其在一个位置停滞不前。
自觉主动;积极解决设计问题：架构师的日常工作目标经常并不明确。很多开发人员直接参考功能规范来列出任务清单。架构师通常则是向这些开发人员提供所需结构的人员，以便尽可能提高工作效率。好的候选者不仅进行沟通方面的工作，而且也会预计各种设计问题并加以解决——通常在没有任何具体指示的情况下自觉进行。无论所分配的职责如何，积极参与项目的开发人员都有机会从一起工作的人员中脱颖而出。
抽象思维和分析：架构师必须能够理解表述模糊的概念并将其变成相关各方能够理解的项目构件。他们必须能够理解抽象概念，并以具体的语言对其进行沟通。开发人员中好的候选者经常要求或自己主动解释开发生命周期中容易混淆的问题。他们能迅速评估各种想法并将其纳入后续工作的操作建议中。
开发人员经常具有很强的数学能力，而好的架构师则倾向于表现出更强的口头表达能力。管理人员经常说开发人员具有“工程意识”，而这是一个用于评估架构师的非常有意义的方面。架构师应该具有很强的解决技术问题的能力，但还必须能够准确获知更为全面的人员如何与技术交互的信息。这要求具有某种形式的抽象思维(而不再是代码的细节)，这种思维能力可能较难形成。
有些人认为，某种级别的正式教育是成为优秀开发人员的必备条件之一，我并不同意这种精英论。我遇到了很多高中就辍学的优秀开发人员。不过，对于体系结构设计工作，我的个人经验以及我对所需能力的认识都让我相信，好的架构师通常至少获得了一个有挑战性的学士学位。
跟踪生命周期
好的架构师通常有在具备定义良好的软件开发生命周期(Software Development Life Cycle，SDLC)的组织工作的经验。架构师必须理解在其所属专业内最重要的操作过程。这并不意味着需要有其他前提，例如，并不需要高能力成熟度模型(Capability Maturity Model，CMM)级别的工作经验。好的架构师可能来自使用 SDLC 的多个小型迭代的极限编程(Extreme Programming，XP)方法的组织。务必注意各种传统软件开发操作，如 Michael A. Jackson 的方法：Jackson 结构编程(Jackson Structured Programming，JSP)和 Jackson 系统开发(Jackson System Development，JSD)。Jackson 的研究对架构师职业发展的意义就像 Donald Knuth 的研究对程序员一样重要。架构师可以偏爱任何经典的、经过时间考验的软件系统开发方法。
SDLC 也可以成为评估架构师合适人选的有用机制。每个 SDLC 阶段都具有能提供相关线索的特征。SDLC 包含很多小的变体，但在此部分，我将使用几乎所有方法的公共基础部分。下面的列表详细说明了 SDLC 的各个阶段，并列出了好的架构师候选者在每个阶段表现出来的特征。
- 分析：在分析期间，好的架构师会考虑非技术影响，以便了解需求和将在其中进行开发的环境。架构师可为风险评估任务带来广泛的软件经验供参考。寻找具有丰富经验的开发人员，以帮助业务部门理解技术人员正确解释需求所需的信息。寻找在开发的早期阶段能够预计可能遇到的问题的开发人员。
- 设计：在高级设计期间，好的架构师会收集问题空间的各个抽象元素，并就其进行沟通，以便开发团队草拟将要开发的系统的相关图表。架构师负责将需求谨慎地映射到所得到的系统体系结构的功能。在详细设计期间，他们所扮演的角色并不是核心角色，但为了根据整个系统的规则对特定模块的元素进行审查，仍然需要他们。寻找善于让团队能够预计设计决策对最终系统的影响的开发人员。寻找善于确定一些最佳构件来促进与技术和非技术受众沟通设计问题的开发人员。
- 实现：在实现期间，架构师对项目进行引导，以确保其符合系统体系结构。他们在一线评估技术更改请求，并确定如何对设计进行调整，以最好地处理此类请求。架构师还要密切了解开发人员的进度，特别要跟踪系统中模块间的集成点的状态。寻找经常对讨论进行引导来连接多个子系统的开发人员。寻找项目经理可以依赖其快速地进行与更改和出现的问题相关的风险评估的开发人员。
- 测试：架构师对系统集成和用户接受度测试进行指导，并负责评估进度的正确沟通的持续测试结果。寻找理解错误模式且善于将测试复查结果转换为行动计划的开发人员。
- 维护：在维护期间，架构师将发起关于系统集成的讨论。无论处理 IT 基础设施问题，还是确保部门之间的技术合作，架构师都必须完全理解应用程序，必须快速学习姊妹应用程序的体系结构，而且必须就集成点和风险进行有效沟通。寻找具有系统集成经验且表现出快速掌握全貌的能力的开发人员。系统集成是一项独特的任务。
架构师培养建议
有些组织能比其他组织更有效地进行架构师培养。如果充分考虑到招聘此类新专业人才的困难，努力促成能鼓励开发人员发展为架构师的环境是非常明智的策略。但务必避免对不愿意或不适合走这条路的开发人员进行处罚。组织应该为开发人员制订多条发展路线，包括那些愿意继续担任开发人员的人。对架构师而言，资深开发人员不可或缺。他们可以实现系统中最关键的模块。通过对其他开发人员进行代码检查和测试支持，他们可帮助确保总体软件质量，而如果质量不能保证，即使最好的体系结构也毫无用处。
组织应制订个人评估程序，以鼓励开发人员考虑其职业目标，其中要包含体系结构设计的选项。应该鼓励经理在其下属中寻找体系结构设计人才。应该实现指导计划，让架构师与希望成为架构师的开发人员协作工作。应该鼓励开发人员通过参加各种协会、撰写文章和参加会议，从而参与到专业领域中来。通过这样参与进来，可帮助开发人员从新的角度理解系统，并帮助他们更好地就其认识进行沟通。这样还能培养可提高效率的重要创新想法。
结束语
开发人员一旦迈出了通向体系结构设计专业方向的第一步，就可以利用很多资源来获得帮助，其中包括很多来自 IBM 的资源。有时候，此过程的最困难的部分就是第一步，而本文提供了一些线索和提示，经理和开发人员可以利用其来评估应该鼓励哪些人努力成为架构师。
另外，附加一个作为架构师进行总体技术架构的参考
（例如：项目集群架构，包括一些指导原则、最佳实践和技术标准）
总体技术架构是由技术架构构件（Technology Building Block, TBB）所组成，这些技术架构构件，简要地描述了技术架构的主要组件和功能。此技术架构的制订，参考了业界的标准及相关的模型，以作为设计应用系统时需要遵循的技术原则或标准。
兹将各技术架构构件概述如下：
· 应用TBB
定义应用系统设计、分析与开发所需遵循的标准与规范，并参考业界普遍使用的技术准则，以达成应用系统架构的一致性、扩充性以及延展性，提高应用系统组件的可再利用性。
· 数据TBB
构建一个具有弹性的数据处理平台，提供数据存取、定义、转换、复制等管理功能，以作为企业数据共享之基础。
· 共享应用服务TBB
提供各应用系统所共享之技术功能模块，以及应用系统集成之基础架构，使新系统可以快速而自动的集成现有系统之资源与服务，以提高现有系统的扩展性与可再利用性。
· 接口服务TBB
构建统一的接口服务平台，并制定各渠道系统的业务发展和技术支撑体系，以提高业务支持能力与客户满意度。
· 系统管理TBB
构建一个集中化的、整合的、授权的、安全的系统管理架构，以管控各种的IT资源，在单一的控制平台上，依各管理者所被赋予的管理权限去制定管理的策略，以达成整体IT资源的高可用性、高运作效率、高安全性。
· 安全TBB
定义信息安全战略相关的技术与准则，并构建全行各应用系统或接口的授权和认证机制，提供各应用系统的统一访问接入服务。
· 共享系统服务TBB
主要由操作系统或低层的系统功能提供，为应用系统及软件所共享。
· 网络服务TBB
定义网络服务架构所需遵循的技术规范与准则，以及应用系统设计时应考量的网络相关技术事项。
· 平台服务TBB
定义系统硬件平台所使用之技术架构与准则，必须符合世界潮流，以及高性能、易操作性、可扩展性、高安全性、高可用性等关键要素。
· 系统开发服务TBB
导入完整的应用系统开发方法论，并定义整合性应用系统开发工具所须具备的技术标准与使用规范。
如上图所示，总体技术架构之构件细化与描述如下：
1.3.1.1 指导原则
1. 高内聚（high cohesion）与松耦合（loosely coupled ）的设计原则
2. 高度扩充性与延展性
3. 设计可再利用性高的功能组件
4. 设计跨平台的功能模块
5. 基于标准
6. 能利用已有的核心系统
7. 可快速部署和易于管理
8. 构件化架构的目标是提高业务效率
9. 可共享的构件必须能被任何构件化设计的应用所调用
10. 如果可能，尽量选择购买而不是开发构件
1.3.1.2 技术议题
1. 应用系统设计与开发
最佳实践
· N-tier的面向服务架构设计
· 统一的应用接口
· 由业务单位负责定义业务逻辑
· 不限平台的业务逻辑设计
· 构建各自独立的业务逻辑组件
· 通过业务规则使用数据
· 建立程序撰写标准
技术标准
· 跨平台的程序开发语言，如 C、C++ or Java.
2. 应用框架
最佳实践
· 使用一致的应用框架设计
· 表现层与业务逻辑分离的设计原则
· 重用性高的共享服务构件设计
技术标准
· J2EE
· Struts Framework
· .NET
3. 设计模式（Design Pattern）
最佳实践
· Model-View-Controller（MVC）
· Intercepting Filter
· Front Controller
· Business Delegate
· Data Access Object
· Service Activator
4. 构件重用
最佳实践
· 建立识别和实现构件的方法论
· 建立一个构件审阅组（Component Review Board）以识别通用构件
· 建立一个构件仓库以维护可重用构件的信息
· 每一个构件都必须有一个公开的API
· 构件服务应该可以被任何构件化的应用或其它构件调用
技术标准
· 在基础安全服务层，应不使用供货商所有权的API调用，而使用GSS-API或遵循公共数据安全体系结构（CDSA）的API 调用和产品
· 企业内基础服务平台必须至少遵循公共数据安全体系结构2.0 （CDSA V2.0）
5. 面向对向的构件
最佳实践
· 应用系统开发者应使用基于EJB的面向对向技术开发企业级的构件。而实施前的合适的面向对向的分析和设计是必不可少的
技术标准
· 购买的产品必须遵循 CORBA 2.0 或更高，以及IIOP协议
· 开发或购买的企业解决方案应建立在EJB和Servlet模式上。应用服务器应该遵循EJB 1.1 或更高
· 在企业级或战略级应用中，应避免使用OLE/DCOM 和 Windows DNA
1.3.2.1 指导原则
1. 构建一个具有高度适应性的数据基础架构
2. 在实体上将OLTP与OLAP数据源分别配置
3. 数据架构应该是企业级的，如此才可以提高和促进企业内部的数据共享
1.3.2.2 技术议题
1. 集中化的元数据
最佳实践
· 使用并维护集中化的元数据仓库（CMR，Centralized Metadata Repository），保存集中化的元数据的定义
· 在设计或修改数据库前，通览CMR中的已有标准和数据元素，以确保新设计的数据库是符合CMR标准的
· 利用CMR和元数据审核小组来创建企业级数据定义，鼓励跨部门共享数据
技术标准
· 客户系统必须遵循CMR的数据定义标准
· 支持客户定义数据的COTS（Commercial off-the-shelf）系统必须能满足CMR数据定义标准，否则，供货商应该提供到元数据的转换规则，以实现数据共享
· 当跨部门、跨系统共享数据时，应使用集中化元数据交换标准
1.3.3.1 指导原则
1. 集成的架构强调数据交换、业务流程和终端展现的相互关联
2. 当决定是否采用集成时，方案的生命期是关键考虑因素
3. 集成架构依赖于众多中间服务层，如接入层引擎、数据库网关、信息、集成服务、XML 和第三方工具等
4. 对现有系统的影响应最小化
5. 尽可能地采用通用技术
6. 当集成异类系统时，通过使用中间服务层而提高终端用户功能，从而最大化灵活性
1.3.3.2 技术议题
1. 应用集成
最佳实践
· 连结异质系统中的数据或流程
· 提供新旧系统能同时并存与合作的应用平台
· 使用适配器
· 业务流程管理
· 商业活动监控
技术标准
· Web Services
· JCA
· Message Queue
· CORBA
· BPEL
2. 服务导向的架构设计
最佳实践
· Web Services
技术标准
· SOAP
· WSDL
· UDDI
3. XML
最佳实践
· 透过 XML进行商业协同作业
· 使用 XML管理文件与数据库
技术标准
· IFX
· ebXML
· RosettaNet
· SWIFT
1.3.4.1 指导原则
1. 统一的，可接入门户的应用接口原则
应用系统应使用统一的、易用的、可纳入未来企业门户的接口方式。
2. 统一的接口标准
起草并确认Web和非Web应用系统用户接口设计的标准和原则，这些标准包括：
· 工业标准的选择
· 总体用户接口的原则
· 用户接口设计标准
· 用户接口组体标准
3. 内部用户接口的可用性原则
用户接口应提供可连接相关业务流程的各信息技术应用、数据和服务的、经过整合的统一界面。
4. 统一客户接口
应提供其客户所有产品和服务的直接接口，并以技术上保证界面的标准化、规范化、一致性。这种统一和规范可通过对外企业门户和渠道整合来实现。同时这种接口服务应保证客户信息和产品及服务的安全性。
5. 用户接口的集成性原则
用户的接口设计应考虑相关业务的整体性和应用与应用之间的关联及集成。
1.3.4.2 技术议题
1. 访问服务
最佳实践
· 门户管理服务
· 安全服务
· 数据访问服务
· 应用集成服务
· 搜索服务
技术标准
· Portlet
· LDAP
· JDBC
2. 渠道整合
最佳实践
· 个性化服务（Personalization）
· 内容管理服务
· 多重协议与编码转换（Transcoding）
1.3.5.1 指导原则
1. 配置和资产管理
应逐步建立企业性的应用。系统软硬件资产及其配置数据库，以统一资产和配置进行管理。
2. 系统性能管理
新的应用系统的设计和实施必须确认并满足系统性能需求。应逐步建立企业性的应用系统的性能跟踪和监测手段，其先决条件是逐步建立企业性的系统、数据运营中心。
3. 软件分发原则
软件的版本及升级应统一管理、决策。软件的分发和升级应自动化，并由企业统一管理。
4. 系统操作
应逐步建立企业统一的系统运营操作支持体系。
5. 问题管理
系统管理应包括统一的流程和方法来实现、报告及解决应用系统的问题。
6. 容量管理
应用系统的硬件容量，包括CPU、内存、I/O、硬盘等，应用系统对并发用户的支持、数据库的容量、网络容量、峰值容量等等必须得到统一的监测并定期报告，以尽早发现问题并提出对策。
7. 变更管理
应用系统的管理应包含变更管理的流程和方法。
8. 可获得性管理
应用系统的管理应提供自动监测系统软、硬件及其网络可用性的工具和方法，以满足系统的可用性需求。
1.3.5.2 技术议题
1. 服务台（Help Desk）
最佳实践
· 必须重新思考与设计服务台机制，以提供集成的支持功能
· 单一联系方式的服务台支持运营体系
· 多层次的服务台支持组织架构
· 所有的问题、事件、请求都应该在这里被记录与追踪
2. 运营管理
最佳实践
· 集中式的系统监控机制，并支持远程之管理需求
· 对所有设备、网络、服务和应用的启动、停止、重启与状态监测
· 可用性管理保证服务和流程达到和客户约定的可用性水准
3. 性能监控与优化
最佳实践
· 容量管理优化以满足一定服务水准所需要的设施容量
· 性能监控有利于发现潜在问题、采取实时反应，从而提高服务质量
4. 服务水平管理
最佳实践
· 确保明确提供的服务类型，就提供的服务水准和客户达成一致
· 尽早鉴别潜在失误
· 减少错误导致的系统中断时间
· 尽早通知客户使其能尽早采取措施
· 尽可能精确的向客户描述服务水准
· 通过主动监控服务进程中关键点的服务指针，确保为客户提供的服务水准，以及早发现和通报客户可能发生的进度延迟
1.3.6.1 指导原则
1. 安全的业务价值评估
信息技术安全应首先宏观地着手于对企业信息资产和业务操作的安全评估：企业资产可能得到的威胁、威胁带来的影响及其威胁可能的发生概率等方面，提出整体安全的技术架构。
2. 对隐私权的考虑
安全架构的设计和实施应符合政府和国际机构对个人（客户和企业员工）隐私权的保护规定。这种隐私权的保护体现在何时、怎样、在多大程度上可以披露有关客户或企业员工的个人信息。
3. 对内、对外网络和业务往来的安全原则
安全架构应确定对外业务网络或通过公共网络进行业务操作的安全基础技术，包括：
· 对外网络连接的安全政策
· 标准安全通信基础技术
· 支持与第三方业务往来的安全架构
4. 安全控制和易用性的关系
综合性的、切切实实的安全控制手段是必要的，但不能以牺牲和影响企业员工的工作效率或业务业绩为代价。严重影响工作效率和业务业绩的安全控制手段必须得到技术上的改善并优先实施。
5. 安全管理
信息技术安全机制必须得到一定程度的安全管理控制能力的支持。这里的安全管理包括：
· 确定和完善企业统一的、一体化的安全管理组织
· 制定和发布统一的安全政策、标准和安全操作流程
· 教育和培训安全意识
· 制订新的安全标准更新流程
· 推广新的安全工具、发布流程及手段
6. 安全架构的实施考虑
在进行安全架构组件的实施过程中，应基于业务价值的评估，充分考虑以下的技术需求：
· 授权需求（Authorization）
· 资产保护（Asset Protection）
· 可稽核性（Accountability）
· 可获得性（Availability）
· 可保证性（Assurance）
· 可管理性（Administration）
这些需求应贯彻于安全实施项目的始终。
7. 安全检测原则
企业应建立定期或不定期的综合性的安全检查机制，以保证公司的安全控制能力、员工意识、安全工具和防范手段的到位，是否存在新的安全漏洞等等。定期检查和评估应用、系统、网络及分支行、网点的安全能力。
1.3.7.1 指导原则
1. 提供良好的输出、输入接口，以及相当方便的执行程序的环境
2. 使硬件资源的使用更有效率
3. 使用共享的存储装置
1.3.8.1 指导原则
1. 重点优先原则
企业的网络必须确保重点应用能优先使用网络资源，能为核心业务和关键应用提供连续性的可靠的网络服务。
2. 高可靠性原则
· 关键设备和模块在数量、性能、容量和链路带宽等方面上要有冗余设计。
· 在新技术和新产品的选择上要尽量采用经过实际检验的可靠技术和产品。
· 设计上坚持简单＝可靠的原则，尽可能减少故障点。
3. 高可用性原则：
· 网络的性能满足未来应用不断增加和业务量高峰的挑战。
· 网络在大负荷、大流量的压力下，能连续、稳定运行，而且不降低整体性能。
· 能让用户体验到网络使用的方便灵活，体现网络为工作和生活方式的改进带来的价值。
4. 可扩展性原则
贯彻“松散耦合”的整体设计思想，建设层次化、模块化、可扩展的网络。
5. 安全性原则
网络的设计和规划、实施应考虑对内、对外连接的安全性，保证用户在权限之内的网络连接和对资源的访问。
6. 开放和标准的原则
网络的设计应充分考虑相应工业标准，应尽可能地利用现有或未来工业标准以支持企业网络连接或对外客户、营运商或供货商的连接。
7. 可管理性原则
网络作为应用基础设施，面对所有的网络用户，网络资源相对于应用需求始终是有限的，网络管理体现对网络资源的有效管理，对用户使用网络有统一的规范；需要有统一的网管平台和网络运维组织机构负责全行的网络运维管理；确保应用的数据特征在网络中可分类、可识别，网络对应用的服务管理通过QOS等技术手段逐步实现端到端的质量保证。
8. 网络核心的高效设计原则
为了保证网络核心的高效性，应用策略控制和网络多重服务尽量在网络边缘来实现。
9. 应用部署的网络成本控制原则
应用的部署会占用网络的成本，应用模式、结构、软件平台、数据分布等方面要体现对网络设备和广域网资源节省占用的原则，如有大流量数据交换的多台服务器要尽量部署在局域网的同一网段内；客户端尽量靠近服务器。
10. 网络投资的有效性原则
二层含义：一是要保护原有的投资，二是要保证后续投资的有效性。
1.3.9.1 指导原则
1. 服务器设计要尽可能以物理的服务器为单位
2. 紧迫任务系统要避免单点失败
3. 所有服务器上的应用、应用套件或一个应用中的层要二进制兼容
4. 尽可能使用开放的、独立于厂商的标准
5. 服务器应允许多任务和多线程
6. 服务器应能升级
另外附加一个关于前端架构师的内容，希望对于客户端编程设计的开发人员转型提供一个参考：
当后端技术伴随.Net, Rails和Java之类的框架发展得越来越抽象和强大，前端技术的潜在发展也日益复杂。在束缚前端技术潜在好处的差劲实现之前， Web需要更多的前端架构师。多亏了诸如跨浏览器支持的先进技术的发展，用户体验、更多有意义的主题比如无障碍都拨云见日，这个世界再也不仅仅就HTML和CSS如此简单，因此，绝大部分的团队都需要一个真正理解和实践涉及到前端的一切的人。
角色
这并不是一个扼要和简单的清单，对于下面的主题／技术，前端架构师也不能仅仅满足于了解一下里里外外而已，而是需要足够的深入研究，并有自己出色的见解。
XHTML
CSS(1, 2, 3)
跨浏览器和跨平台
DOM脚本编程
AJAX
Flash
渐进增强和适度降级
无障碍
可用性
信息架构
界面设计
视觉设计
表现层逻辑（ASPX, Rails视图等）
商业规则和逻辑
作为一个前端架构师，必须拥有这些领域的绝对执行力。例如，前端架构师能够决定某个特性是使用AJAX还是传统的页面刷新。哪个更便于使用？对无障碍的影响如何？改用Flash有意义吗？
拨乱反正
表现，结构，行为和商业逻辑的混杂，导致不必要的复杂，导致难以维护的怪胎解决方案。就如后端需要正确地划分为数据层，商业逻辑，表现逻辑等，前端开发复杂到是时候调整其架构了。编写良好结构或者说避免使用表格布局是远远不够的。这是第一步，前端架构的哆咧咪而已。现在是时候关注DOM脚本编程，AJAX, 无障碍等，该升级了。
非编程不可
主张前端架构师必须懂得真正的编程知识，而这正是很多自封为前端架构师的人所缺乏的。意思不是能够剪切粘贴改进代码就行了，而是能够跟老练的工程师商讨如何能够最好地结合前端。这就是说，前端架构师需要真正理解结构遭遇商业逻辑的问题。如果工程师说某些东西使用ASP.Net DataGrid是不可能实现的，前端架构师必须能够解释如何与为何要使用DataList或Repeater取代，解释为何DataGrid在该情景下是个错误的选择……。这只是个例子，问题还在于仅知道客户端编程也是不够的。能够使用与工程师相同的术语，能够讨论（前后端）关键集成的最佳解决方案，这是绝对必须的。
断线的风筝
我们今天正处在一个不妙的处境中，原因在于几乎没有人能够为前后端的沟壑搭桥。一般工程师不会有兴趣或实践标记，CSS, 或DOM脚本编程，大部分客户端开发者也没有与后端技术协作的经验。几周入门PHP不会成为程序员，几周入门XHTML也不会成为真正的客户端开发者。
罪魁祸首
首先想到的十足例子是，ASP.Net完全漠视Web标准，同样地，web氛围（我们指表格和占位gif）让Web标准郁闷。企业项目的大多数框架输出的标记，即使使用1999年的标准来衡量，都是糟糕无比的。如此巨大和“专业”的产品怎么能才够不忽视，按理说是整个项目最简单的方面？只有静态代码。理由是，基于技术的立场衡量产品，结构，CSS和其他客户端技术都是“事后诸葛亮”。表现逻辑，结构和行为混杂，压根无助于无障碍，Web标准，或者前端技术干净的分离。抬起你的头来，就在2006，这些都成受欢迎的惯例了。
总结
如果这个世界上姿态最鲜明的产品和项目都如此低劣的方式来处理事情，其他的还有什么好说？毫无疑问，我们需要前端架构师，而且就在昨天。归结于归结，我们有一堆相互关联的技术，很少人能够埋头钻研它们之间的关系，这很不幸。正确做事的真正价值在于容易的维护和长期的适应性。虽然在关键时刻，有些方式更容易选择其他的方法和拼凑起另外的东西。对某些人来说，这可能是可接受的做事方式。但是，对我们大部分人来说，这是拙劣的抉择，也非常不专业。