前言
EA将企业视为一个系统。
此表定义了一些一般的系统理论概念，并说明了它们在业务架构方法中的应用。
它区分结构和行为，区分抽象结构和具体结构。
系统论 |
BIZBOK®的 业务架构 |
TOGAF®里的业务架构 |
|
抽象结构节点 |
分组 所需的行为/动作 |
能力 |
功能, 角色 |
具体的结构节点 |
被指派执行行为/行动 |
组织单元， 演员/行动者 |
|
抽象行为 |
序列需要的行为/行动 |
价值流: 价值创造/交付的步骤 |
场景、流程:服务创建/交付中的步骤 |
抽象行动 |
是一个原子行为 |
流程步骤 |
|
抽象系统结构 |
节点相互作用的网络 |
能力/产出网络: 能力之间的流动。 |
节点连接图: 节点之间流动 |
TOGAF所说的“功能”是什么意思
简而言之，功能是一个逻辑业务组件，一个业务能力的逻辑单元，需要实现物理的组织资源。
银行的核心职能包括市场营销、销售、分行管理、银行卡支付以及人力资源等支持职能。
功能通常安排在一个层次结构，一个逻辑组织图。
TOGAF所说 |
TOGAF是什么意思 |
“功能描述所有粒度级别上的业务能力单元” |
功能描述业务能力的单元，无论适合于架构工作的粒度级别是什么。 |
“任何有界的业务功能单元都应该被描述为一个功能。” |
任何业务能力的有界单元都应该被描述为一个功能。 |
“功能受服务约束” |
一个功能是由它提供的服务(它的服务组合)限定和定义的。 业务服务向服务请求者提供有价值的材料和/或信息。 |
“业务功能由明确定义边界的业务服务支持，并将由业务流程支持和实现。” |
业务功能受到它们相互提供的服务和向外部实体提供的服务的限制。 每个业务服务都由服务契约定义。 契约定义了向服务请求者提供哪些有价值的材料和/或信息。 业务服务由一个或多个业务流程实现。 这些流程可以全部包含在一个功能中。 否则，该功能可能会向其他功能请求服务。 |
业务功能是由组织单位来执行的。 “结构化分析:确定架构范围内的关键业务功能，并将这些功能映射到业务内的组织单元。” |
在“功能组织结构”中，功能-组织单元关系可能是一对一的。 但通常(因为两者都可以组合和分解)，关系是多对多的。 结构化分析还定义了流程如何在功能层次结构中交叉和连接底层功能。 |
功能分解图的目的是在单个页面上显示与架构相关的组织能力。 通过从功能的角度检查组织的能力，有可能快速地开发组织所做的事情的模型，而不被拖入关于组织如何做的广泛辩论中。 一旦基本的功能分解图被开发出来，就有可能在这个图的上面分层热图来显示范围和决策。 例如，在一个改变计划的不同阶段所要实现的能力。” |
功能分解: ·是一个逻辑业务结构，其他架构实体可以映射到该逻辑业务结构。 ·按照层次结构安排业务功能/能力。 ·组织业务所做的事情，在层次结构的每一层逐步细化。 ·使人们能够从广泛的讨论开始，然后在需要的地方深入到更多的细节。 ·使用功能/能力名称来定义，这些名称有助于建立跨业务的公共词汇表。 ·通过分析确定需要改进的功能/能力——通常用颜色标记为“热度”图。 ·比业务流程和组织管理结构更稳定。 |
在TOGAF中的功能和能力
TOGAF 9.1中基于能力的计划章节很少涉及到TOGAF产品和技术，并且是模糊的。
但是，下表中的引号表明TOGAF将功能和能力视为同义词。
TOGAF是怎么说功能的 |
TOGAF是怎么说能力的 |
|
“业务服务/功能目录可以用于识别组织的能力。” |
“业务能力可以看作是宏观级业务功能的同义词。” 一种组织、个人或系统所拥有的能力。 |
|
规范 |
“任何有界的业务功能单元都应该被描述为一个功能。” “业务功能由明确定义边界的业务服务支持，并将由业务流程支持和实现。” “功能受服务(应该是服务)的约束。” |
“通常用通用和高级术语表达” |
例子 |
电子商务、供应链管理等 |
市场营销、客户联络或对外电话营销。 “金融能力” |
通过组织实现 |
业务功能是由组织单元来执行的。 “结构化分析:确定架构范围内的关键业务功能，并将这些功能映射到业务内的组织单元。” |
“通常需要组织、人员、流程和技术的结合来实现。” |
组织结构的独立性 |
“业务交互矩阵的目的是描述企业组织和业务功能之间的关系交互。” “联邦企业架构业务参考模型是一个功能驱动的框架，用于描述联邦政府的业务操作，而不依赖于执行这些操作的机构。” |
“业务能力评估是用来定义一个组织需要什么能力来实现其业务目标和业务驱动因素。 |
其他资料中“功能”的含义
此表列出了功能在不同来源中的含义。
In this source |
功能 |
E.g. |
结构化分析 |
抽象活动结构元素——逻辑组合结构中的组件 |
市场营销，客户管理，产品管理 |
TOGAF 9.1 |
同上. |
同上 |
IT4IT |
同上 (“功能组件”). |
同上 |
ArchiMate 3.0 |
同上，但错误地将其描述为行为元素 |
同上 |
DoDAF |
没有定义，因为它使用能力代替 |
同上 |
VDML 1.0 |
没有定义，因为它使用能力代替 |
同上 |
Ackoff |
理想、目标或目的以及/或实现这些目标的行为。 |
为了生存，为了繁殖，为了赢得这场游戏 |
UML 2.4.1 |
一种行为元素——一种原始的刺激-反应过程 |
给定半径，以面积响应 |
在数学中，函数是一种将输入与输出联系起来的过程;它将一个集合的每个元素与另一个集合(可能是同一个集合)的一个元素精确地联系起来。
在UML中，函数是一种基本的过程，它将一组输入值转换为一组输出值，而不参考系统状态。
在这两种情况下，函数只使用输入值来计算输出值;它不维护已存储的数据，也没有其他影响或副作用。
功能性（Functionality ）是一个丑陋的词，通常可以用“行为”或“功能”来代替，而且没有失去意义。
例如，UML标准使用“功能”来表示在接口中发现的一组服务/流程。
ArchiMate的“功能”是什么意思
ArchiMate使用术语“功能”定义了三个应用程序体系结构元素。
并使用术语“行为”来定义第四种功能(“应用程序功能”)。
ArchiMate 应用域 |
行为视角 |
结构视角 |
外部视角 |
Application Service an “externally visible unit of functionality” which “exposes the functionality of components” |
Application Interface “describes the functionality of a component |
内部视角 |
Application Functions “describes internal behaviour”. |
Application Components “self-contained unit of functionality” |
ArchiMate使用术语业务功能的结构意义与TOGAF相同(不同于业务流程)。
但是它的应用程序功能似乎是一个流程，由应用程序服务(可以称为用例)封装。
令人困惑的是，ArchiMate用“业务功能”一词来指代行为元素。
“应用程序行为”的标准ArchiMate示例显示了从触发器到结果运行的顺序流程中排列的功能——在这个过程中，每个功能似乎都是子流程。
看来，ArchiMate图中的“功能”符号可以表示流程(使用流程图文档化)或逻辑组件(作为参与者/组件定义文档化)。
功能(如角色)可以由其执行的流程在内部定义。
有一段时间，我将功能定位在通用元模型中。
TOGAF’s 业务域 |
行为视角 |
结构视角 |
外部视角 |
业务服务. |
??? |
内部视角 |
业务流程 |
业务功能 |
功能(如角色)也可以由它所提供的服务在外部定义。
在与Marc Lankhorst长时间的讨论后，我得出的结论是，这样放置职能会更好。
TOGAF’s 业务域 |
行为视角 |
结构视角 |
外部视角 |
业务服务. |
业务功能 |
内部视角 |
业务流程 |
业务参与者 |
最终，在对齐TOGAF和ArchiMate时，我总结出元模型将因此得到更好的扩展。
TOGAF’s业务域 |
行为视角 |
逻辑结构视角 |
物理结构视角 |
外部视角 |
业务服务 |
业务功能 |
组织单位 |
内部视角 |
业务流程 |
业务角色 |
业务参与者 |
结论
业务功能是抽象的活动结构元素。
它们是从实际组织单元中提取的逻辑抽象，如果由提供的服务定义，则可以视为接口定义。
业务功能对应于业务功能。
但“能力”一词往往意味着功能+目标+实现功能所需的人力和其他资源。
也就是说，一个能力就是一个业务系统。
