《IT架构师成长和认证指南》简介及第3章 IT架构思维（二）

作者写了一本关于IT架构师成长和认证的书，希望先通过连载的形式拿出来分享，结合读者的反馈来不断调整完善。本书希望对于那些想成长为架构师，并在架构师职业发展道路上不断进阶的读者们有所借鉴和指导，也欢迎业内专家不吝赐教和斧正。

目前作者在参与信通院企业架构推进中心企业架构相关成熟度模型标准的制定工作中发现，我们目前不少的企业对于企业架构、解决方案架构（或者系统架构）的概念和范围理解上还存在混淆、偏差和不一致的地方，作者也是希望通过个人和相关业内专家的共同努力，推动企业架构和解决方案架构更加系统性、结构化、标准化，并且开放化地发展。

作者一直以为企业架构理论和实践的发展离不开企业（2B）和个人（2C），企业的架构最终还是需要由具备企业架构思维的人才进行架构运用和实践，所以企业乃至整个社会，对于架构师人才梯队的培养也是非常重要的一环。本人是IBM L3 Thought Leader 级别认证架构师，The Open Group的L3认证杰出架构师，也是TOGAF企业架构，OAA开放敏捷企业架构，以及银行业架构网络BIAN认证架构师。曾任The Open Group 架构标准组合本地化联席主席，负责领导了OAA开放敏捷企业架构标准的本地化、推动TOGAF10标准的本地化、翻译和推动BIAN相关标准的本地化工作；也作为全球企业架构师联合会（AEA）架构师执业证规范特邀专家进行了L1~L3企业架构师及各领域架构师的遵从性标准的制定工作。作者本人也是期望结合自身的架构师成长实践，为企业架构和架构师社区尽自己的一点绵薄之力。

《IT架构师成长和认证指南》全书分成两大部分共十二个章节。

第一部分讲了IT架构是什么，以及如何去做IT架构，包括IT架构思维及不同视角、方面的架构模型和方法。

架构视角包括功能视角的组件模型、数据视角的数据模型、运营使用视角的运用模型；架构方面包括关键的非功能性方面工程学，如性能工程、可用性工程和安全架构。

在架构知识体系化的介绍过程中贯穿以实际的案例，并提供了任务级别的架构模型开发方法和相关的架构制品，确保架构方法的可落地性和实践指导性。

另外还介绍了历来不同的架构风格，流行的架构建模语言和工具，方便读者对当今各种架构的来龙去脉有全面深入的理解，并能够熟练运用各种架构语言进行架构制品的产出，方便在架构社区的交流。

第二部分讲了考察一个架构师的角色和素养有哪些，基于此构建出架构师能力六边形模型，并介绍了IT架构师可获得相关认证的一些行动指南。

《IT架构师成长和认证指南》简介和第一章 什么是IT架构

《IT架构师成长和认证指南》简介及第2章 IT架构师角色和素养

《IT架构师成长和认证指南》简介及第3章 IT架构思维（一）

接上一篇 第3章 IT架构思维（一）

前文介绍了IT架构思维需要从三个不同的维度进行思考，满足不同利益相关方的关切，进行架构建模，以支撑起“屋顶”上的功能性需求和非功能性需求。进一步地，我们将架构活动分解成了需求规格化、架构设计、架构验证和架构管理四大部分。本篇介绍了需求规格化相关的架构活动，篇幅所限，本篇是关于功能性需求的规格化，下一篇将介绍对非功能性需求和其他需求和约束描述。

3.5 系统范围和需求视角

一个系统所承担的职责是由系统在整个企业架构中的地位和角色所决定的，相当于房子的功能定位，在一个街区里，这个房子是充当住宅楼还是办公楼，亦或是学校、医院，是由城市规划或区域规划决定的。一个系统需要有明确的角色定位和需求范围，以此为基础才能在系统建设赞助方和实施方间形成明确的工作说明，我们把对系统要实现什么所做的规格化说明称为需求。首先需要从企业架构和系统赞助方的视角明确系统的职能边界，进一步明确系统本身的功能需求和非功能需求。通常我们使用系统上下文图来描述系统的边界，使用用例图来描述系统的功能性需求，使用非功能需求清单来陈述系统对非功能性方面的要求。除了功能性和非功能性需求，解决方案架构还受限于企业特有或项目特有的约束，如员工技能、IT现状、组织架构、企架的专题能力设计、建设预算、建设周期等，此外，在系统架构时还需要考虑系统未来的需求，以确保解决方案架构的灵活性。

3.5.1 系统上下文图

我们使用系统上下文（System Context）图来识别和描述系统的边界，开始时可以把系统当成一个黑盒子，基于企业架构对系统的角色定位，识别出跟系统存在交互关系的参与方，参与方可以是跟系统存在集成关系的其他系统，也可以是系统的最终用户。通常使用椭圆形来表示本系统，通过连线来表示参与方同本系统的主要交互功能关系。

图3-4 系统上下文图（System Context Diagram）示例

上图的示例显示，我们要建设的系统存在两类用户角色，一类是业务用户，在本系统上进行业务的操作，实现业务能力；另一类是系统管理员，进行系统的策略和参数配置和运维管理。另外还存在两个关联系统，一个是企业级的监控平台，按照客户IT架构要求，所有业务系统都需要统一能在监控运维平台实现监控，按照要求，本系统需要通过监控平台的接口发送系统运行的各项监控指标，另外本系统运行过程产生的日志信息也需要收集到监控平台，进行日志分析；另外一个系统是企业级的数据湖，本系统需要每天将业务数据同步给数据湖，以便进一步地挖掘业务价值，联合其他系统数据生成报表，基于模型形成业务洞察。由于这两个系统是本系统的关联系统，我们在进行本系统的架构设计和项目管理计划时，需要将相关的集成工作考虑进来。

3.5.2 功能性需求

满足功能性需求是系统被成功验收的最基本的要求，因而我们需要全面捕获且准确地描述功能性需求，目前架构实践上还是存在两种类型的项目，传统有明确业务需求的项目和业务探索性敏捷产品。适合不同的项目，对需求的捕获和描述也存在一定的差异。对于传统具有明确需求的项目，进行需求规格化描述时力求精确详细，而对于探索性需求的产品，需求规格相对从客户角度，更强调用户通过同系统的交互所获得的好处或价值产出，描述不再力求精确详细。

3.5.2.1 用例模型

用例（Use Case）是从参与方的视角来描述系统特定的功能行为。一个用例包括参与方（Actor）和特定行为（Use Case）。

图3-5 用例图（Use Case Diagram）示例

一般用例的参与方（Actor）可以有两种类型，一种是跟系统交互的人，一种是跟系统交互的其他系统，一般用人形来表示。一个功能用例（Use Case）是系统参与方同系统之间的交互行为，一般使用椭圆形表示一个用例，采用动词+名词的形式来命名，如“支付订单”。除了直观上使用一个或一组用例图来描述系统的功能，对于每一个用例，作为需求规格化的描述，需要进行更详细的用例描述。

表3-1用例详细描述

一个用例需要详细地描述出交互过程和系统处理逻辑，除了正常的处理流程，还需要详细描述出异常情况下系统的处理过程。包括用例模型和用例详细描述在内的需求规格说明书往往要作为赞助方业务用户签收的依据，也会作为后续编写用户测试案例的基础。特殊需求中可以描述用例的非功能性需求，如对性能的要求。

为了形式化地描述用例的状态变化，特别是存在非常复杂的情形时，可以结合使用UML（统一建模语言）的状态图对用例进行形式化描述。

3.5.2.2 用户故事地图

一个用户故事通常没有用例描述的精确，只是对产品特性的一个意向性描述，通常代表了最终用户的视角来看待产品特性。一般用户故事会以用户故事卡片形式存在，卡片的正面通常会描述用户故事，通常以“作为一个<用户角色>, 我想要<做什么事情>, 这样我可以<获得什么价值>。”的形式进行描述，而卡片的背面则给出进一步的业务逻辑细节，以及列出了该用户故事可被验收的条件。将相关联的用户故事组织成经典敏捷意义上的史诗（Epic），并按照用户活动和发布顺序进行组织，就形成了用户故事地图。

图3-6 用户故事地图（User Story Mapping）示例

用户故事地图横向表示用户的价值流活动，纵向表示用户故事的实现优先级排序。横向又进一步分解为四部分，分别是用户活动（User Activities）、用户任务（User Tasks），史诗（Epics）和用户故事（User Stories）。用户价值流活动是从用户视角出发揭示产品为用户创造价值产出过程，包括了一组用户活动或产品特性。用户活动由用户或业务事件触发，为实现用户特定业务目的，用户及相关方同产品进行交互的过程。用户任务由单一角色（用户或相关方）执行，在连续的时间里完成，由具备明确业务目的的一组步骤构成。

用户任务进一步分解成为可执行需求史诗（Epics），而一个史诗Epic又包括一组相关的用户故事（User Stories）。不同的故事可能优先级不同，按照产品的规划，对用户故事在纵向进行分组，按照产品特性的优先级顺序，确定用户故事所处的不同的发布周期。

一个用户故事就是一个最详细的用户交互功能陈述，例如可以陈述为“作为一个消费者用户, 我想要根据关键词快速检索到我想要的商品, 这样我可以快速下单购买它”。用户故事还需要有能被验收的标准，比如“支持模糊检索”，“检索结果按照同检索词的相关性排序”，“保留用户的历史检索关键词，以便用户快速再次使用”。

图3-7 用户故事模板

就像用例描述一样，我们可以遵循用户故事模板，对实际的用户故事进行相对全面的陈述。一个用户故事包括以用户为中心的期望陈述：“作为一个<用户角色>, 我想要<做什么事情>, 这样我可以<获得什么价值>”，还包括一些额外的细节便于软件开发工程师清楚地理解用户故事，以及最后通过验收的标准，软件开发工程师清楚工作完成到什么程度，该用户故事可以通过验收。

用户故事其实并没有用例描述得那样详尽，其描述是用户为中心，产出结果导向的，这给予了软件开发工程师一定的空间去实现这些功能。当然我们也可以把这两种功能需求定义工具结合使用，比如明确了用户故事地图和用户地图卡片后，需要将功能开发外包，则可以进一步通过用例对一个用户故事进行具体的设计描述，细节到事件流的每一个步骤。