TOGAF是工业级的企业架构标准规范，信息系统架构阶段是由数据架构阶段以及应用架构阶段构成，本文主要描述信息系统架构阶段中的应用架构阶段。
如上所示，信息系统架构（Information Systems Architectures）在TOGAF标准规范中处于C阶段。
|--------------------------------------------------------------|
| #### 阶段目标 |
| 开发目标信息系统架构，描述企业的信息系统架构如何赋能业务结构以及架构愿景，解决架构工作组以及利益相关者关注的问题 |
| 识别确认基线信息系统架构以及目标信息系统架构之间的区别以及路线图 |
|---------------------------------------------------------------------------------------------------------|
| #### 架构方法 |
| 信息系统架构阶段，包括数据架构阶段以及应用架构阶段，依据不同系统的需求功能以及使用场景，阶段实现的先后顺序也不相同，有些系统是数据驱动，则先实现数据架构阶段，有些系统是应用驱动，则先实现应用架构阶段 |
应用架构阶段
应用架构阶段的主要内容包括阶段目标、阶段输入、流程步骤、阶段输出、架构方法。
|-------------------------------------------|
| #### 阶段目标 |
| 开发目标应用架构，赋能业务结构以及架构愿景，解决架构工作组以及利益相关者关注的问题 |
| 识别确认基线应用架构以及目标应用架构之间的区别以及路线图 |
|--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| #### 阶段输入 |
| 架构参考资料，企业架构仓库主要存放企业所有架构相关的项目资料，其中，包括项目交付件、可重用资产、对架构工作组以及企业利益相关者的输出 |
| 非架构性输入 * 架构工作或者工作组的要求，主要包括企业组织的赞助者、企业组织使命的声明、业务目标或变化、业务策略计划、时间限制、业务环境的变化、企业组织的约束、预算信息或金融约束、外部约束或业务约束、已有业务系统描述、已有架构或IT系统描述、开发组织的描述、开发组织的可用资源描述 * 能力评估，对企业的总体能力评估，主要包括业务能力评估、IT能力评估、架构能力成熟度评估、业务转型准备度评估 * 沟通计划，企业架构包括大量复杂的、内部互动的信息，需要制订高效的沟通计划，主要包括识别确认利益相关者以及按照沟通需求分组、识别确认与架构愿景相关的关键信息、识别确认沟通机制、识别确认沟通时间 |
| 架构性输入 * 企业架构组织模型，主要包括企业受影响范围、成熟度评估、差距分析、解决方案方法、架构团队的角色与责任、架构工作的约束、预算需求、治理与支持策略 * 已剪裁的架构框架，主要包括已剪裁的架构方法、架构内容（交付件与人工产品）、配置与部署工具 * 应用原则，主要包括技术独立性以及易用性，应用能不依赖于具体的硬件以及操作系统软件、能在不同的平台中运行、其使用的中间件能解耦应用以及具体的软件解决方案，用户专注于业务使用、无需关注潜在的技术、应用具备工程学的特征、用户接口不受到地域语言环境以及其他物理因素的约束 * 架构工作声明，定义工作范围与方法，主要包括声明主题、架构项目的要求与背景、架构项目的描述与范围、架构愿景的总体描述、范围过程的特殊变化、角色责任交付、验收条件与过程、架构项目计划与时间表、声明批准 * 架构愿景，规划架构阶段，主要包括利益相关者的问题描述、有待解决的问题或场景描述、架构工作声明的目标、架构工作要求的总体描述、需求映射关系、引用架构定义文档初始版本 * 架构仓库，主要包括可重用模块、公开可用的参考模型、特定企业组织的参考模型、企业组织标准 * 起草架构定义文档，主要包括详细的基线业务架构版本1.0、详细的目标业务架构版本1.0、基线数据架构版本1.0、目标数据架构版本1.0、基线应用架构版本0.1、目标应用架构版本0.1、基线技术架构版本0.1、目标技术架构版本0.1 * 起草架构需求规格说明书，描述实现项目需要的架构内容，主要包括成功的方法措施、架构需求、业务服务约定、应用服务约定、实现指导、实现规格说明书、实现标准、互操作性标准、IT服务管理需求、约束、假设条件 * 架构路线图，列举工作项，主要包括工作分组描述、功能需求、工作项依赖、业务价值、风险分析、架构域、解决方案、业务转型、关键措施 |
|--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| #### 流程步骤 |
| 选择架构参考模型、架构观点、架构工具 * 应用原则作为架构原则的一部分，评审与验证应用原则，提供运用应用原则的指导 * 基于业务驱动、利益相关的问题以及业务架构，选择应用原则的相关资源，例如，参考模型与架构风格 * 选择相关的应用架构观点，来自应用的利益相关者、与应用的功能点以及个人用户相关，运用架构观点如何解决利益相关者的关注问题 * 识别确认架构工具与技术，用于应用架构的捕获、建模以及分析，例如，建模技术与工具 确定建模过程，技术或方法选型需要支持具体的观点，能解决以及覆盖利益相关者的问题 * 根据基线的应用产品、需求以及业务架构，理解应用以及应用组件的要求 * 通过分解应用成多个应用，实现复杂问题简单化 * 确保应用定义的内部一致性，删除冗余的应用，合并小应用 * 识别确认逻辑应用以及最合适的物理应用 * 开发架构的矩阵关系，主要包括应用与企业组织矩阵关系、角色与应用矩阵关系、应用版本迭代矩阵关系、应用与功能矩阵关系 * 详细描述应用架构的观点，主要包括应用如何提供功能与服务，与集成、迁移、开发、运维相关 识别确认应用建模分类，主要包括应用产品分类以及应用接口分类，应用分解流程由逻辑应用组件、物理应用组件、信息系统服务构成 识别确认矩阵关系，矩阵关系显示相关模型实体的核心关系，需确定应用系列产品与业务架构的业务服务之间的映射关系，由业务服务与数据实体之间的映射关系确定应用产品与数据实体之间的映射关系，主要包括应用与企业组织矩阵关系、角色与应用矩阵关系、应用版本迭代矩阵关系、应用与功能矩阵关系 识别确认图示关系，图示关系可以基于利益相关者的需求，从不同视角体现出应用架构的信息，主要包括应用信息交互图、应用与目标用户图、企业可管理性图、流程与应用实现图、应用迁移图、软件版本分发图、软件工程图、应用用例图 识别确认需求类型，定义目标架构的需求，其中主要包括应用域相关的需求、提供数据架构阶段以及技术架构阶段的需求输入、提供设计与实现的详细指导 |
| 开发基线应用架构描述，用于支持目标应用架构、解决利益相关者的关注问题 |
| 开发目标应用架构描述，用于支持架构愿景、目标业务架构以及目标数据架构，解决利益相关者的关注问题 |
| 执行差距分析，验证架构模型的一致性以及准确性，其中主要包括权衡分析架构模型中的不同观点，验证架构模型支持的原则、目标以及约束，在架构仓库中文档化架构模型的更新变化，测试架构模型对需求的完整性 |
| 定义候选路线图中的系统部件，可应对未来发展的机遇以及解决方案 |
| 分析解决总体架构中的相关影响，其中主要包括应用架构是否对已有的架构造成影响、变化因素是否影响应用架构、应用架构是否有助于企业组织的其他地区、应用架构是否影响其他项目、应用架构是否受其他项目的影响 |
| 执行正式的利益相关者评审，检查应用架构是否符合架构项目的目标以及架构工作的声明，识别确认架构愿景、业务架构、数据架构、应用架构、技术架构之间的变化更新以及相互之间的受影响范围，提供解决方案解决这些问题 |
| 确认完成应用架构工作，其中主要包括以可重用性的角度、从架构仓库的参考模型中、为建模的模块选择对应标准，完全文档化建模的模块，对全部架构的业务需求执行交叉检查以及文档化，文档化需求跟踪报告，文档化架构的映射关系，确认全部工作 |
| 创建架构定义文档，在架构定义文档中提供模块建模的依据，在架构定义文档中提供应用架构部分，用建模工具以报告或者图示的方式描述说明关键的架构观点 |
|------------------------------------------------------------------------------------------------------------------------------------------------|
| #### 阶段输出 |
| 优化更新架构愿景阶段的交付件，其中主要包括架构工作的声明、验证的应用原则 |
| 起草架构定义文档，其中主要包括基线应用架构版本1.0，目标应用架构版本1.0，解决利益相关者的关键问题的观点视图 |
| 起草架构需求规格说明书，其中主要包括差距分析结果、应用可互操作性需求、相关的运用到开发周期的技术需求、技术架构的约束、已更新的业务需求、已更新的数据需求 |
| 架构路线图的应用架构组件，其中主要包括应用产品与应用接口的分类、应用与企业组织的矩阵关系、角色与应用的矩阵关系、应用与功能的矩阵关系、应用版本迭代的矩阵关系、应用信息交互图、应用与目标用户图、企业可管理性图、流程与应用实现图、应用迁移图、软件版本分发图、软件工程图、应用用例图 |
|----------------------------------------------------------------------------------------------------------------------------------------|
| #### 架构方法 |
| 架构仓库，架构工作组需要考虑在架构仓库中提供可用的应用架构资源，例如，与企业组织工业标准相关的业务模型，其中包括标准对象管理工作组的业务模型、标准企业IT治理工作组的应用模型、标准通信工业的应用模型，与通用高级业务功能相关的电子商业应用模型、供应链管理应用模型 |