原创2025-01-06小艾老师

TOGAF企业架构师认证知识体系考证须知证书含金量培训大纲 3分钟小视频我要提问

TOGAF 认证是 The Open Group 颁发的架构框架专业认证，是企业在规划、设计、实施和管理 IT 架构时所使用的一种方法和标准。它提供了一个开放的、灵活的、可扩展的方法来构建、部署和管理企业的 IT 架构，帮助企业提高 IT 效率、降低成本、提高业务灵活性和创新能力。

中文名TOGAF企业架构师认证
英文名The Open Group Architecture Framework
英文简称TOGAF
颁证机构The Open Group
证书类别企业架构（业务架构，数据架构，应用架构，技术架构）
同类认证SAFe for Architects、CBA

今天我们来聊聊TOGAF 10中的一个重要概念——业务场景，以及如何创建一个切实可行的业务场景。话不多说，直接开始！

01 业务场景是啥？

很多小伙伴可能一提到“业务场景”，脑袋里就想到了“什么是业务需求”“客户的需求到底是什么”，但实际上，业务场景可不光是“需求”那么简单。它是描述一个特定商业环境下，系统、流程和角色如何交互的一个框架。简单来说，业务场景帮助我们从整体上理解“现在的业务环境是怎样的，未来我们希望它变成什么样”。用《场景革命》中的一句话来说明场景的重要性：产品解决一个问题，场景持续解决问题。

如何用架构的视角来看待“业务场景”？TOGAF 10系列指南中明确指出：业务场景本质上是业务问题的完整描述，包括业务和架构方面的内容，确保各个需求在问题的上下文中关联起来。

02 业务场景的创建过程

创建一个业务场景其实并不是拍脑袋的事，而是需要系统性思考。TOGAF 10的业务场景创建模型由5个部分组成（与TOGAF 9.2的7个步骤稍有不同），这5个部分帮助我们系统性地创建业务场景，确保业务、技术和架构的结合更加紧密。

Problem：识别和记录问题驱动因素

首先，明确问题的来源和性质，并将其文件化和定级。这一步的关键是了解为什么需要这个业务场景，以及它对业务的影响程度。

示例：假设你在一家电商公司，当前的退货流程太复杂，用户不满意，客服投诉率高。这就是一个明确的“问题驱动因素”，需要在业务场景中予以记录。

Environment：识别业务和技术环境

明确业务和技术环境，并在业务场景模型中文件化。这一部分包括与业务场景相关的业务模型、技术模型和操作环境的描述。

示例：继续上面的例子，当前的业务环境是：客户提交退货申请，人工客服手动确认退货信息，耗时长、效率低。目标业务环境可能是：通过App自动提交退货申请，系统自动审核，减少人工介入。

Outcomes：识别并文件化目标（“SMART”）

目标必须是“SMART”的，即具体的（Specific）、可衡量的（Measurable）、可实现的（Achievable）、相关的（Relevant）、有时限的（Time-bound）。

示例：

不具体的目标：提升客户满意度。
具体的SMART目标：在未来3个月内，将退货流程从5天缩短到2天，客户满意度提高10%。

Human Actors：识别人员施动者（参与者）

在业务场景中，明确与业务场景相关的人员及其角色，并描述他们在业务模型中的位置。参与者可能包括客户、员工、管理员、外部合作方等。

示例：在退货业务场景中，人员施动者包括：

客户：提交退货申请，提供反馈。
客服：跟进客户退货请求，提供帮助和支持。
仓库管理员：处理退货的商品验收和入库。

Computer Actors：识别计算机施动者（系统元素）

明确在业务场景中起作用的计算机系统和技术元素，并标明其在技术模型中的位置。这包括应用程序、数据系统、自动化工具等。

示例：

退货管理系统：自动记录和处理客户的退货申请。
客户服务系统：客服使用的客户支持工具，用于查看退货状态。
库存管理系统：用于监控退货商品的入库和处理。

03 通过创建业务场景解决工作中的一些常见问题

接下来，我们用一些现实工作中的问题来具体说说怎么创建业务场景。

1.客户抱怨：“我们的业务系统太慢了！”

假设你是负责IT架构的主管，某个部门的同事跟你抱怨：“我们的业务系统太慢了，每天操作一堆数据，要花好几个小时。”这时候，传统的做法可能是急急忙忙开会，讨论怎么加速系统性能。但如果从TOGAF的角度来看，这个问题的背后其实可能隐藏着更深层次的业务需求和痛点。

在TOGAF中，我们可以通过创建一个“业务场景”，明确：这个慢系统是因为数据量大，还是业务流程太复杂？或者是技术架构不匹配？通过梳理出这些场景，我们就能找到根源，而不是简单的“加速”系统。

关键问题：

定义场景背景：系统慢的背景是什么？是因为用户同时操作太多，还是数据存储处理效率低？
描述业务需求：到底是因为快速查询需求，还是是其他操作对性能要求过高？
分析影响因素：是业务流程问题，还是技术架构问题，还是数据管理的问题？

通过这些步骤，你就能建立起一个具体的业务场景，从而为后续的解决方案提供有力支持。

用TOGAF10中的方法创建业务场景：

步骤	详情
识别和记录问题驱动因素	问题：业务系统响应时间过长，操作员需要花费大量时间处理数据，直接影响业务处理效率和客户响应时间。驱动因素：数据量增长过快，系统设计未考虑高并发，查询和处理逻辑不够优化。
识别业务和技术环境	业务环境：客户服务部门的操作员每天需要在系统中录入和查询客户订单信息。技术环境：使用传统的集中式数据库架构，未部署缓存和异步处理机制，前端系统依赖手动查询，未实现批量操作。
识别并文件化目标（SMART 原则）	具体（S）：将系统查询时间从30秒减少到5秒内。可衡量（M）：在2个月内实现操作速度的提升，并通过性能测试验证。可实现（A）：通过数据库索引优化、引入缓存技术等手段实现。相关性（R）：提高系统响应速度，直接改善客户服务效率和客户满意度。时间限制（T）：2个月内上线新方案。
识别人员施动者	操作员：客户服务部门的前台人员需要快速查询客户订单数据。管理者：客户服务部门的主管需要监控操作效率，衡量改进效果。
识别计算机施动者	数据库：传统的关系型数据库，可能需要调整索引或采用更高性能的数据库方案（如NoSQL）。中间件：考虑是否需要使用缓存中间件（如Redis）来加速常用查询的响应时间。前端系统：需要优化前端的查询逻辑，避免不必要的请求，或启用本地缓存。

2.团队成员：我们部门的沟通不畅，很多时候信息共享不到位

再比如，很多公司都有部门间沟通不畅的问题。有时，一个部门根本不知道另一个部门的需求，而另一个部门也不知道自己的需求变化已经影响到了他人。这种信息不对称经常导致重复工作、效率低下。

如果按照TOGAF的思路来做，我们可以通过“业务场景”来理清楚：在不同的部门和职能之间，信息流是如何流动的，哪些环节可能出现瓶颈，哪些环节又没有产生足够的价值？

关键问题：

界定场景范围：这不是一个部门的问题，而是整个公司的流程都没有优化。可以从跨部门合作入手，看看是否有工具可以促进信息的流动。
分析场景影响：如果沟通不畅，部门之间的协作就会受到阻碍，导致业务延误，影响客户体验。
定义解决方案：是否需要一个协作平台，或者一个统一的信息系统？这就是一个TOGAF框架下的具体业务场景，它帮你看清问题所在，并找到解决办法。

用TOGAF10中的方法创建业务场景：

步骤	详情
识别和记录问题驱动因素	问题：不同部门之间的信息共享不及时，造成项目延迟和客户投诉增加。驱动因素：各部门依赖独立的沟通工具（如邮件、微信群等），缺乏统一的协作平台，导致信息流不通畅，信息滞后和冗余问题频发。
识别业务和技术环境	业务环境：市场部、销售部和产品开发部门需要协同工作，频繁共享客户需求、销售反馈和产品开发进度。技术环境：部门依赖独立的工具（如邮件和Excel）共享信息，缺乏统一的协作平台和工作流工具。
识别并文件化目标（SMART 原则）	具体（S）：在1个月内上线一个统一的协作平台，取代各部门的分散工具。可衡量（M）：协作平台的使用率达到80%，并减少20%的邮件流量和延迟响应时间。可实现（A）：通过引入如Worktile、腾讯TAPD、PingCode等现成的SaaS协作工具来实现。相关性（R）：提高信息共享的速度和准确性，减少项目延迟，提升客户满意度。时间限制（T）：在1个月内完成部署和员工培训，2个月内实现全面使用。
识别人员施动者	业务用户：市场部、销售部和产品开发团队的成员是关键用户，需要接受新平台的培训并使用平台。管理者：各部门的主管需要推动员工采用新平台，并监控使用率和效果。
识别计算机施动者	协作平台：如Worktile、腾讯TAPD、PingCode等工具，提供跨部门的沟通和协作支持。移动设备和桌面设备：确保平台支持手机端和桌面端的使用，方便随时随地访问信息。

3.IT部门和业务部门“脱节”了

另一个常见的问题是，IT部门和业务部门的需求常常无法对接。IT部门认为自己的技术能力很强，业务部门却总是觉得IT无法理解他们的实际需求。这个脱节看似是沟通问题，但深入一看，往往是两者在目标和视角上的差异。

在TOGAF中，业务场景帮助我们明确，IT和业务之间的差异不仅仅是语言不通，而是两者从不同的角度看待问题。IT往往聚焦于技术细节，而业务则更多关注“这个技术能解决什么实际问题”。

关键问题：

定义目标和需求：明确IT部门和业务部门各自的目标。比如IT关注系统稳定性和安全性，而业务关注如何提升用户体验和加速市场反应。
识别关键问题：这个场景里，业务和IT之间_大的鸿沟是什么？是不是业务对技术要求不够清晰，还是IT没有提前与业务讨论需求？
寻找连接点：通过业务场景的创建，可以发现双方的共同目标，比如提升客户满意度，缩短开发周期等，从而帮助双方对齐目标。

用TOGAF10中的方法创建业务场景：

步骤	详情
识别和记录问题驱动因素	问题：IT部门与业务部门的目标不一致，导致IT交付的系统未满足业务需求。驱动因素：业务需求未明确定义，IT部门的关注点偏向技术实现，忽略了业务目标。
识别业务和技术环境	业务环境：业务部门希望推出一款新产品，并要求快速上线，但IT部门的系统交付周期较长，导致新产品上市延迟。技术环境：IT团队采用敏捷开发方式，但未与业务部门对接优先级和关键需求，需求不断变更。
识别并文件化目标（SMART 原则）	具体（S）：建立业务和IT的联合项目组，以确保业务需求的传达和优先级的确定。可衡量（M）：在3个月内实现需求的透明化，减少50%的需求变更次数，并缩短项目交付时间20%。可实现（A）：通过Scrum仪式中的"需求澄清会"，确保IT与业务的对齐。相关性（R）：IT和业务目标一致有助于确保项目交付的成功率，避免项目延误或失败。时间限制（T）：3个月内实施联合项目组的机制，并开始跟踪需求变更次数。
识别人员施动者	业务用户：市场部的业务分析师需要明确定义业务需求，并参与Scrum会议。 IT开发人员：开发团队的架构师和开发人员需要定期参与与业务的沟通，确保需求明确。
识别计算机施动者	项目管理工具：如Jira、Trello或其他敏捷项目管理平台，确保业务和IT能够在一个平台上透明化沟通和管理需求变更。开发工具：如GitHub和CI/CD工具，支持IT团队的敏捷开发。