什么是商业价值实现？

这个术语在以前没有使用过的领域中出现的频率越来越高。

几个来源将价值实现定义为：

“随着时间的推移从流程或项目中提取的价值”

企业的需求是组织从现有产品、流程和客户中产生更多“增值”的能力。
过去，不同的学科使用不同的语言来表示以一种或另一种方式实现的价值。这可以看出包括学习和发展中的“评估”一词，资本方面的投资回报率。当然，纯粹主义者会争辩说它们都是不同的东西。在很多方面他们都是。但我想强调的是，价值实现的概念并不新鲜。但它不太常见。它确实需要整个商业思维才能成功。

虽然价值实现可以应用于组织的所有部分，但它是 IT 系统的世界，特别是围绕 ERP 的环境，最强烈地采用了“价值实现”这个术语。

从本质上讲，价值实现是关于展示 IT 系统或改进的有形或实际业务价值。例如，变更前在门户网站上转换了 x 个客户。改进的价值实现产生了 y 客户转化，导致每月/或交易等花费 $$+。通常这被引用为每个客户生命周期的额外收入。

有时这称为业务价值实现 BVR 或程序价值实现 PVR

测量价值

为了衡量价值实现，我们需要在任何变化或过渡发生之前建立明确的 KPI。这些 KPI 可能包括以下因素：

• 每笔交易花费，
• 每月/每年的客户终身收入等

需要获得关键措施的基线。随着解决方案或变更过程的发展，可以进行分阶段测量。

价值实现的优势

由于需要有基线，这也意味着需要在整个业务中保持内部透明度。业务利益相关者需要接受价值，并被视为支持过渡和预期结果。陈述的结果必须是现实的。
通常，IT 和其他业务流程需要适应和改变，以启用措施和新流程。进行此类变革的组织所犯的主要错误之一是未与所有利益相关者合作。无论人们认为他们的赌注有多么小。

不要只关注更大的利益相关者

在那些寻求增加价值的过渡性项目中，一个常见的错误是更大的利益相关者参与其中。但较小的留在边线上。不幸的是，太多的变革项目意识到为时已晚，使过渡成功的差异往往是。
因为较小的利益相关者拥有钥匙。它们通常是启用或禁用价值实现的因素。

IT 项目不仅适用于极客

IT 人员被锁在房间里，通常远离“正常”员工的日子正在迅速消失。几乎业务中的每个功能都取决于 IT 实施的成功或失败。
“看大局”的能力。越来越多地能够从一个地方获取数据并在另一个地方使用它是一种竞争优势。
在世界各地的许多 MBA 课程中展示了麦当劳的成功和“你想变大”的运动，是对一个人的数据分析的结果。数据显示，一家餐厅的一名工人的平均销售额比世界上任何人都高！他们去观察那名工作人员，发现了他们的神奇问题。那一条数据被用来产生数百万的额外利润。企业需要意识到重要性，并培训人们在全球范围内倾听和实施。

几年前，一位员工使用了这样的短语：“你想吃那个炸薯条吗？” （交叉销售），也被使用。
使用数据为现有市场或客户增加价值很重要。

数据和业务世界成功的变化

过去，价值实现等活动是在引入系统和系统升级后实施的单独流程。部分由于 IT 在业务运营中的集成度更高，因此价值实现是任何变更或开发项目的关键部分。
我最近参与了一个大型全球项目，该项目将价值实现置于转型和实施的业务驱动因素的前面。

在线忠诚度计划

许多在线零售商使用游戏化作为提高保留率的一种方式。增加站点或商店的退货频率。通过此类系统收集的数据有助于影响并确实增加企业的价值实现。使用 VIP 或忠诚度计划只是一个开始。

实现价值的挑战

最大的挑战之一是让所有利益相关者接受所提议的“附加价值”。有时这些附加价值会降低一个领域的成本，只会增加其他领域的工作量。最终结果应该是整个组织的改进。对于所涉及的变革推动者来说，这可能很难卖。
从 IT 供应商手中实现价值
看看主要的 IT 供应商； SAP、微软或主要咨询公司、埃森哲、普华永道
你会看到他们都“专攻”它。为了使价值实现真正发挥作用，它需要成为任何业务中的协作方法。它需要真正的跨功能。它需要满足业务的战略需求，而不是一个功能王国的需求。
成功实现业务价值实现的真正关键需要：

• 合作
• 专注于技术之前的业务
• 明确的业务发展战略和运营方式
• 沟通，沟通，沟通！

我希望对商业价值实现的介绍能引起一些兴趣。开始你的学习之旅。要知道，没有保证成功的灵丹妙药或公式。通过一个共同的目标，为企业利益而进行的组织范围内的协作将成功实施！

 

原文：https://www.linkedin.com/pulse/what-value-realization-mike-michael-morr…

本文：https://jiagoushi.pro/node/2122

事件风暴是一种快速，轻量级且未得到充分认可的群体建模技术，它对于加速开发团队而言非常强大，有趣且有用。作为Alberto Brandolini的心血结晶，它是Gamestorming和领域驱动设计（DDD）原则的综合学习实践。该技术不限于软件开发。您可以将其应用于几乎任何技术或业务领域，尤其是那些大型，复杂或两者兼而有之的领域。

事件风暴催化并加速小组学习，通常在几小时或几天内实现更传统的建模技术从未做过的事情 - 对软件必须运行的领域的共同理解。

要了解事件风暴，您首先需要了解两个关键术语。域事件是域专家感兴趣的任何事件。域专家对数据库，Web套接字或设计模式不感兴趣，但对业务领域感兴趣。域事件以不指定特定实现的方式捕获这些事实。

事件风暴如何运作

您运行一个辅助研讨会进行一个活动风暴会议。每个人都参与其中，并且协调人使团队保持专注和参与，指导进展到完整的域模型。该小组从域事件开始，向前和向后遍历模型以确保所有内容都被覆盖。然后，该组添加导致事件的命令或触发器，并考虑所有命令源，包括用户，外部系统甚至时间。

该组识别接受命令和完成事件的聚合，并开始将聚合分组到有界上下文中。在此过程中，识别关键测试场景，用户和目标并将其合并到模型中。最后，添加有界上下文之间的关系以创建上下文映射。然后用代码对所得模型进行挑战，以验证组学习并验证模型。

虽然DDD社区的事件风暴正在增长，但在该专业之外几乎不为人知。这是一种耻辱，因为只有主持人必须是DDD从业者才能指导小组走向完整的模型。包括非技术产品所有者在内的每个人都可以参与对域的理解和建模。整个团队了解域越好，软件实施越有可能反映域，这是DDD的主要目的。

走得更快

如果你可以完成这个项目，你刚刚重新完成了，同一个团队，知道你现在知道什么，你能够更快地完成它吗？

是的，因为你已经学会了成功所需要的知识。小组学习速度慢是软件开发过程中的主要制约因素。正如Brandolini所说，“软件开发是一个学习过程;工作代码是一个副作用。”

域事件有助于构建域模型;它们起到了骨骼的作用。这不是设计，它是关于域的模型 - 一个视角。您使用域事件来推动建模，因为技术人员和领域专家都很容易理解。域事件几乎没有关于设计的说明，也没有关于实现的内容，这正是你想要的一个好的域模型。

一种不同的建模方法

更传统的DDD建模工作通常由小组或个人开发人员完成，有时在与产品所有者就数据，对象或行为进行几次对话之后。不幸的是，这开始建模的程度太接近实现域，而不是局限于业务领域。如果您从数据建模开始，您的思考和对话将很快转移到模式，事务和其他与业务领域无关的事情。如果从行为建模开始，当您将行为分解为任务并将其链接到流程时，您会分心。

这些是实现概念，而不是业务领域概念。虽然有很多选择来表示数据和实现行为，但域事件没有其他选择。由于域事件表示域的事实，因此这些事件仅在基础业务发生更改时才会发生显着变化。因此，域事件是您模型的更稳定和更具弹性的脚手架。

但是这种方法有一个更令人信服的理由：将初始讨论限制在域事件中会迫使每个人，特别是开发人员，专注于域的无处不在的语言。他们必须学习它，定义它，改进它，并在有关模型的对话中专门使用它。

虽然以域事件为中心的模型可能会自然地导致事件驱动的系统设计(EDA)，例如事件源或命令查询责任隔离(CQRS)，但这是一种选择，而不是义务。实现模型的软件不必是事件驱动的，甚至不是面向对象的（尽管这些通常是很好的选择）。

加速小组学习

想想你完成的最后一个项目。开发人员必须做些什么才能理解域模型并构建系统？在发挥故事的过程中，开发人员可能会在域专家，解决方案架构师，测试用户和其他团队成员之间穿梭。虽然这个过程可能会导致所有团队成员对整个域的共同理解，但这不太可能。转移的领域知识过于稀疏，过于分离，过于孤立，而且过于分散，无法在任何单个开发人员的脑海中产生完整的模型，更不用说整个团队理解的常见模型。

相反，这些对话可以在事件风暴会话期间发生。通常这些对话是按顺序发生的，但是在事件发生时，它们都会立即发生。通过这种方式，您可以解决域中任何部分的任何冲突或不连续性，同时所涉及的每个人都在场并参与其中。

DDD的最大障碍是开发人员倾向于专注于他们非常了解的事物 - 软件开发概念 - 而不是业务领域。当非技术人员（例如产品所有者或用户拥护者）与开发人员会面并开始用编程术语而不是商业术语描述系统时，可以看到这种情况的一个症状。如果开发人员不了解域，则无法正确建模。

何时何地使用事件风暴

使用事件风暴最明显的时间是在项目开始时，因此团队可以从对域模型的共同理解开始。使用事件风暴的另一个高回报时间是项目结束的一部分，用于捕获和分享团队在构建软件过程中学到的知识。这很重要，因为没有任何一个开发人员可能因为偶然的发现，修改以及对其他区域的有限暴露而了解整个域。使用较小规模的事件风暴也是有利的，例如当您考虑改变某些事物，开始新故事或制定不同的场景或替代方案时。

尝试一下

事件风暴旨在创建和分享对域模型的共同理解;它不是设计文档，流程图，UML图，部署计划，体系结构图或与实现相关的任何其他内容的替代品。可以将其视为低保真，临时信息辐射器，用于与其他人共享和确认域模型。

尝试一下暴力事件，你将获得多种好处。使用协作组学习，您将实现快速的域驱动建模，而无需每个人都必须成为DDD专家，您的团队和术语将与业务领域专家的一致。这个过程非正式且价格低廉 - 您只需要纸张，便签和笔，您就可以很好地加快团队的工作效率。

今天，我想写一个简单可靠的方法来实现域事件。

域事件：在提交之前调度

我相信是Udi Dahan首先介绍了域驱动设计特有的域事件概念。这个想法很简单：如果您想指出对您的域有重要意义的事件，请明确地引发此事件，并让域模型中的其他类订阅并对其做出反应。

所以基本上做到以下几点。创建域事件：

然后引入一个静态类，允许订阅事件并提升它们：

现在，当您拥有此基础架构时，您可以开始使用它。这是域事件生成器的外观：

这是消费者的一个例子。它收集所有已提交订单的统计信息并将其保存到数据库：

在提交之前，我将这种经典方法称为域事件调度。这是因为它允许您在提交业务事务之前引发事件并做出反应。

这种方法存在一些问题。它有时很有用，但是当处理域事件的副作用跨越多个事务时，它就会失败。

让我解释一下我的意思。例如，假设您要将另一个使用者添加到上述域事件中。此消费者会向提交订单的用户发送通知电子邮件：

现在，发送电子邮件的行为又为表格带来了一笔交易。在此之前，域事件的生产者和它的使用者都生成了存储在同一数据库中的副作用。生产者的副作用是Order类实例，消费者的副作用是更改了stats信息。您可以创建一个总体数据库事务，以便如果系统由于某种原因无法保持订单，则订单统计信息的更改也不会保留。

添加OrderNotification类后，情况就不再如此。发送电子邮件在其自己的事务边界内工作，您无法将其与数据库绑定。通过在确保数据库事务完成之前发送通知电子邮件，您将打开应用程序以查找潜在的不一致问题。现在可以在不保留订单的情况下发送电子邮件。例如，如果数据库在保存该订单时出现故障，则可能发生这种情况。

有些人认为，当然，这种方法在这种情况下不起作用，但是当没有涉及外部系统时，你仍然能够使用它。换句话说，如果所有使用者都在相同的数据库事务范围内运行，例如OrderStats。

这是一个不好的论点。如果事件的所有使用者都驻留在同一数据库事务中，则域事件几乎不会增加值。如果所有协作方都在同一个数据库上运行，那么最好使域逻辑流明确，并避免处理域事件。域事件以间接的形式带来了显着的复杂性开销。如果你能够避免这种开销，我主张你这样做。

因此，如果OrderStats是OrderSubmitted事件的唯一消费者，您可以将上面的示例重写为以下内容：

并完全摆脱域事件基础设施。此程序流程可以更好地了解请求期间发生的情况。这里明确概述了所有步骤。

这就是我不建议使用“提交前发送”方法的原因。如果消费者产生超出数据库事务范围的副作用，则不能使用它。对于所有其他类型的副作用，最好不要使用域事件。

当谈到域事件的主题时，一般规则就是：当你需要产生超出数据库范围的副作用时，只使用它们进行应用程序间通信。对于内部应用程序通信，让您的程序流程直观明确。使用常规技术，例如返回操作的结果并将其传递给下一个方法。

Jimmy Bogard在几年前写了另一篇关于域名事件的文章。 Udi和Jimmy的方法之间的区别在于后者建议将包含提升域事件的两个步骤分开：创建和调度。它使事件更易于测试，但实质上，它是相同的“提交前调度”方法：在提交数据库事务之前调度域事件。

域事件：在调度之前提交

几年前，我也在我的领域驱动设计实践培训课程中写过关于域事件的文章。由于缺乏更好的名称，我称我的实施“更好”。但是现在我想在发送之前重命名它。

正如您已经从名称中猜到的那样，此方法涉及提交数据库事务，并且仅在调度域事件之后。基本思想类似于Jimmy Bogard在他的博客文章中描述的内容：您不应该立即发送事件，而是需要跟踪它们，直到您准备好提交数据库事务。这里的主要区别是您在提交事务之后而不是之前调度这些事件。

以下是该活动的制作人的样子：

请注意，Order不再适用于静态DomainEvents类来分派这些事件。相反，它将它们保存到内部集合中。顺便说一句，这样就有机会将事件合并为一个事件或取消之前的事件。以前的方法是不可能的，因为事件是立即发送的。

为了调度事件，我使用了NHibernate的事件监听器。特别是，提交数据库事务后触发的事件（从此处获取）：

这可确保仅在数据持久化后才执行调度。请注意上面代码中的OnPostUpdateCollection侦听器。它允许您分派事件，即使实体本身尚未更改。例如，当您向订单添加一行但保持订单本身不变时。花了我很长时间才弄清楚如何处理这些用例?

“调度前提交”方法比“提交前调度”方法有了很大改进。现在，您可以在域事件使用者中产生任何副作用，无论是发送电子邮件，在总线上发送消息，调用第三方API等等。当数据库事务失败时，您将不再遇到这种情况但确认电子邮件已发送给客户。

域事件：简单可靠的解决方案

然而，即使有了这种改进，该解决方案仍有两个缺点：

1. 您需要一个ORM来实现它。而不仅仅是任何ORM，而是支持更新后，删除等事件的ORM。 NHibernate很棒，但也许你不能出于某种原因使用它。
2. 你仍然可能遇到不一致。它们没有你在提交之前遇到的那些严重，但它们仍然可能发生。如果您的电子邮件网格无法接受通知电子邮件，您将收到提交的订单但没有确认电子邮件。您无法使域事件的分派与提交数据库事务100％一致。

我说这种不一致并不严重，因为它很容易减轻它们。在外部，可能有故障的呼叫之上的可靠队列有很大帮助。它显着降低了遇到不一致的可能性（但当然不能完全消除它，因为可靠的队列也可能会崩溃）。

那么简单可靠的解决方案是什么，没有所有这些缺点？

它与域对象一起持久化域事件。您需要做的是向数据库添加一个表：

域事件：简单可靠的解决方案

并将事件像常规域对象一样持久化。然后，让一个单独的工作人员逐个选择这些事件并处理它们。在大多数情况下，处理将涉及在总线上推送消息，然后可以将消息传递给适当的订户。但是你也可以提出自己的pub-sub机制。

这种方法的好处是，您现在可以在域事件基础架构中100％确定。持久域事件允许您实现这些事件的生产者和使用者之间的完全一致性。生产者只有在它们自己被持久化时才能生成事件（上例中的Order类）。并且消费者有机会实施重试机制，以便没有域事件漏洞。它还有助于消费者居住在一个单独的过程中。

但是，这种方法有一个缺点。与前一个相比，它需要更多的努力来实现。它简单可靠，但并不容易。您需要引入附加表，并且还需要为此目的开发后台作业。

我通常采用“调度前提交”的方法。我的所有活动消费者通常都会在公交车上发消息，这是一个非常可靠的操作。我在制作中没有遇到任何问题。但手动方法也很好，特别是考虑到我上面描述的所有好处。

摘要

 

1. 仅将域事件用于应用程序间通信。对于内部应用程序通信，请改用显式程序流程。
2. 提交之前的调度是在数据库事务完成之前调度事件的时间。避免这种类型的域事件，因为您将无法将其用于应用程序间通信。
3. 调度之前的提交是在数据库事务完成后调度事件时。在大多数情况下，这种方法很好。与此实现不一致的可能性仍然很小。
4. 如果您需要100％一致性且无法使用ORM，请将域事件与域对象一起保留。这种方法需要更多的工作。

原文：https://enterprisecraftsmanship.com/2017/10/03/domain-events-simple-and-reliable-solution/

本文：http://pub.intelligentx.net/node/555

讨论：请加入知识星球或者小红圈【首席架构师圈】

战略家，架构师，流程专家，软件开发人员，数据管理员和其他参与改变企业的专业人员经常投入大量精力来创建各种有用的设计模型。在许多情况下，此类业务模型，企业架构模型，业务流程模型，软件模型，数据模型等仅用于指定某些设计，即描述应构建的内容。但是，通过使用强大的分析技术创造新的见解，这些模型还有更多的价值。在我即将发布的博客文章中，我将介绍其中的7个分析，向您展示BiZZdesign Enterprise Studio如何支持它们，并以这种方式讨论您可以支持的业务成果。

7种强大的分析技术，创造商业价值

 

1. 影响分析遍历模型结构，以评估应用程序的业务重要性，变更计划对战略目标的贡献，或企业范围内的变更影响。
2. 探索架构元素之间一致性的依赖性分析。您的架构的关键要素是什么，您在哪里运行风险，哪些是瓶颈？
3. 查看业务流程效率的流程分析。您的流程中的关键路径是什么？如何提高吞吐量？
4. 生命周期分析，以解决您的企业随时间的演变。您如何规划变更计划并控制体系结构中元素的生命周期，从而处理不同项目，它们实现或更改的流程和系统以及所需业务成果之间的依赖关系？
5. 应用程序组合管理的业务价值和技术价值分析。应用程序对您的组织有多重要，以及它如何完成工作？
6. 财务分析，例如应用程序成本计算或项目组合管理。您在哪里花钱并且这与您的业务目标一致？
7. 风险，安全和合规性分析，例如在法规遵从性，隐私和网络安全的背景下。

当然，您也可以组合使用这些技术，我也将展示这些示例。

使用影响分析提供有关IT环境健康状况的业务重点信息

为了开始这个系列，让我们从最常见的分析类型之一开始：影响分析。 Enterprise Studio支持您以非常易于使用的方式遍历模型中的关系：只需将Navigator从一个元素遍历到另一个元素，可能跨越多个关系甚至不同类型的互连模型。当您到达您要查找的元素时，请使用上下文菜单选择颜色或标签视图。

例如，请参见下面的屏幕截图。在这里，我们通过两者之间的业务流程和功能，从功能导航到底层应用程序。生成的颜色视图显示了企业的功能如何依赖于这些应用程序的支持。这可用于查找哪些功能依赖于哪些应用程序，以查看替换应用程序的影响可能在哪里。当然，在创建这些类型的分析时，您需要密切关注您遍历的不同类型的关系。这也是ArchiMate和其他建模语言的强大功能所在：由于不同关系类型的特定含义，您可以在使用简单的框和线创建图片时完全不可能执行这些分析例如微软幻灯片软件。

下载我们的VIVAT客户案例，了解VIVAT如何合理化其应用领域并降低成本。

Analysis Techniques – Impact Analysis

可以轻松扩展此类分析以解决更高级的问题。首先，请注意，在创建颜色视图时，它在视点浏览器中显示为未保存的视点（此处位于屏幕截图的左下角）。这实际上是Enterprise Studio内置脚本语言中的一个脚本，可以通过多种方式进行编辑和扩充，并作为模型的一部分保存。使用这些脚本，您可以充分利用Enterprise Studio支持的建模语言的语义。

其中一些和其他分析可以组合在多级度量标准中，这些度量标准提供有关IT环境的构成和运行状况的以业务为中心的信息。这对于应用程序和项目组合管理以及优先级和规划必要更改非常有用。在本系列的后面部分，我将更详细地介绍投资组合管理中的这种分析用法。

当然，还有更多方法可以使用这种分析。请让我知道你是如何使用它的，并请继续关注本系列的下一部分！

原文：https://bizzdesign.com/blog/7-powerful-analysis-techniques-to-get-more-business-value-from-your-models/

本文:

讨论：加入知识星球【首席架构师圈】

 

在之前的文章中，我们介绍了Business Model Canvas™并讨论了优缺点。我们看到专业人士远远超过缺点，所提到的许多缺点相对容易弥补。但在什么场合你可以应用画布？在BiZZdesign，我们帮助组织解决他们在业务设计和变革领域的问题。为了回答以下问题，Business Model Canvas已被证明是一个非常有用的工具：

1. “我们拥有世界上最好的主意！至少......我们认为这很不错......下一步是什么？“
2. “会议室的幻想从我们真正意味着什么？”
3. “我们需要新的经营方式。我们有什么选择？“
4. “我们有很多项目，但不能同时完成所有项目。什么是最重要的，什么序列有意义？“
5. “当然，我们拥有所有必需的架构视图和流程模型，但为什么人们不使用它们呢？”
6. “专注于做正确的事情是伟大的，但我们不需要考虑做正确的事情吗？”
7. “我们发现自己一遍又一遍地讨论同样的事情。有没有办法构建讨论？“

1.启动和服务设计

“我们拥有世界上最好的主意！至少......我们认为这很不错......下一步是什么？“

一个伟大的产品或服务理念不会立即带给您成功。大多数想法往往来自公司内部，您和您的同事感觉，看到和体验您的团队非常擅长做某项工作。首先要做的是考虑价值主张和潜在客户。我们解决了哪个问题？这是谁的问题？客户是否愿意支付，或者我们是否需要其他收入模式？ Business Model Canvas的结构可帮助您添加将您的想法转变为可实现的业务模型所需的其他相关元素。您必须检查事实和数据，与潜在客户取得联系并制定计划以创建必要的基础架构。考虑一下自己在绿地环境中工作的幸福！所有选项都是开放的。

2.战略影响评估

“董事会的幻想从我们这里真正意味着什么？”

在大型组织中，定期发布新版本的策略。有时候因为组织环境中的要素发生了变化，而且往往是在领导层发生变化之后。对于组织的其他部分，可能难以解释策略，因为它处于相当高的抽象级别。战略与为实施该战略而启动的项目之间存在差距。通过评估所做出的战略选择，您可以指出业务模型中受策略影响的位置。首先，它可以帮助您评估完整性，并促进负责创建策略的人员和负责执行策略的人员之间的讨论。此执行可能会导致企业开展业务和/或构建方式发生变化。深入了解策略对业务模型的影响有助于您将资源分配到业务中的正确位置。

3.创新 - 寻找新方向

“我们需要新的方式来开展业务。我们有什么选择？“

商业模式画布有助于深入了解您当前的商业模式，但在应用于创新时处于最佳状态。一种有效的方法称为“epicentric-approach”，其中您使用一个块作为起点，看看您可以提出哪些替代方案。任何更改都需要更改其他块。例如，在以客户为导向的业务模式创新的情况下，针对新的客户群。这将导致价值主张，交付渠道，基础设施等方面的必要变更。特别是在准备好并完成跨职能团队的过程中，组织中人员的变化和创造力将会让您感到震惊。在选择最佳创意之后，人们被邀请提出他们的想法，就像在商业模型画布中所做的那样。观众将提供改进想法的提示。

在创新过程的后期阶段，可以使用场景技术更好地了解与各种替代业务模型选项相关的收益和风险。

我们看到产品成为服务（服务化）和服务成为产品（产品化）的趋势！在未来的博客文章中，我们将回到这个主题。

4.投资组合评估

“我们有很多项目，但不能同时完成所有项目。 什么是最重要的，什么序列有意义？“

使用画布作为项目的背景。 它们对您的业务模式有何影响？ 空白点怎么样？ 我们如何处理重叠？ 这里最重要的是将其与您在战略影响评估中所做的工作联系起来。 通过使用Business Model Canvas作为模型将策略连接到项目组合，您可以深入了解项目的战略匹配。 当您在一个更大的组织中定位时，从业务模型，企业架构到项目组合都是有意义的。

第二步可能是让所有项目负责人为他们的项目创建一个画布！这需要一些时间，但在项目的生命周期中真正为项目指明方向！

5.在业务相关的环境中传达更详细的模型

“当然，我们拥有所有必需的架构视图和流程模型，但为什么人们不使用它们呢？”

其中一些可能与视图的表示对您的受众没有意义的事实有关（请记住IEEE1471？）。或者他们只需要一些指导，以便在他们不太熟悉的世界中感到舒适，从他们理解的环境开始。一旦您的利益相关者习惯于考虑商业模式画布（发生得非常快！），您就可以开始使用它作为您已经创建的更详细模型的基础。这有助于架构师和分析师更好地了解业务管理和营销人员。

6.精益和六西格玛项目的起点

“专注于做正确的事情是伟大的，但我们不需要考虑做正确的事情吗？”

那里肯定有一些非常精简的CD盒工厂。但是这些天谁仍然购买CD呢？精益旅程通常会以提高流程绩效来节省成本为目标。通过应用Business Model Canvas作为起点，人们可以更好地理解其流程的上下文。该协作有助于在任务的最初几天创建团队体验。在某些实践中，我们已经看到它促进了选择并实际上立即停止了一些活动。对价值主张的共同理解是评估活动和讨论其附加价值的良好参考。

7.聪明......或者至少假装是！

“我们发现自己一遍又一遍地讨论同样的事情。有什么东西可以构建讨论吗？“

现在很多人都在使用画布。无论是在与同事聊天时在纸上画草图，还是询问预期的客户体验，都能让人们走出不断持久的渠道组合讨论。搜索完整性，写下您的假设，并从画布右侧（客户）通过中心（值）到您自己的关键活动。并随意提出需要提出的问题......即使这会让其他人感到有点不舒服。

最后的想法

业务建模技术的知识非常强大，并且在许多不同的情况下都很有用。我可以在商业模式中有更多的思考应用......我很想知道你的经历。如果您想了解更多关于商业模型画布的信息，请随时下载我们的白皮书商业模式 - 调整业务战略和企业架构，或者请求演示我们的软件工具BiZZdesign Enterprise Studio。

原文：https://bizzdesign.com/blog/7-applications-of-the-business-model-canvas/

本文：http://pub.intelligentx.net/node/410

讨论:加入知识星球【首席架构师圈】

在这一系列博客中，我们描述了在实践中使用新的ArchiMate 3.0标准。 我们使用一个虚构但实际的示例公司ArchiSurance，ArchiMate的用户熟知，因为这是The Open Group提供的标准案例研究中的公司。

保险公司在具有挑战性的情 金融市场的超低利率使他们很难履行其财务义务，数字中断威胁到他们的商业模式和市场份额。 更重要的是，利润率正在下降，市场份额正在萎缩。

我们的示例公司ArchiSurance也在处理这些问题。 它是如何赚取足够的资金在短期内生存并长期维持业务的？ 该公司对其提高回报的主要方式进行了战略分析，如下图所示。

为了维持盈利能力，公司需要增加收入，这需要更高的客户保留率和/或增加市场份额。为此，它希望提高客户满意度并提高竞争力。

基于此分析，ArchiSurance看到了两种不同的战略选择来解决这些问题。第一种选择是通过降低成本，增加自助服务选项以及简化和标准化其产品组合来最大限度地提高运营效率。

ArchiSurance认为技术创新的快速发展既是挑战，也是机遇。这导致它确定了基于“数字客户亲密度”的第二个战略选择，该选择采用大数据和物联网（IoT）的组合。根据这一策略，他们打算使用更详细的客户数据来改善客户互动和满意度，并确定定制的保险费。

能力图

在此战略分析旁边，创建组织的能力图以成功转变公司也很重要。下图使用ArchiMate 3.0的新功能概念概述了ArchiSurance的当前功能。

数字客户亲密策略

在其数字客户亲密战略中，ArchiSurance采取双管齐下的方法。首先，它希望通过各种社交媒体渠道更密切地与客户互动。其次，它旨在使用各种外部数据。对于在消费者市场上销售的保险产品，这需要来自智能互联设备的数据，例如健身追踪器，车辆中的黑匣子或家庭自动化网关;在各种b2b市场中，它希望使用来自车队管理，能源网络，店内RFID设备或智能建筑传感器等来源的数据。最终，这可能会产生实时保险产品，客户可以获得有关其行为的财务后果的直接反馈，并建议调整此行为以降低其保险费。

下图显示了实现此战略所需的主要新功能，它们与当前功能的关系，以及它们如何为ArchiSurance希望实现的业务成果做出贡献。

 

您的策略的这些元素也可以链接到，例如，业务模型画布中的更高级别描述，您的功能可能被视为关键活动。 BiZZdesign Enterprise Studio完全支持这种集成方法。

在接下来的几篇博客中，我们将进一步探讨ArchiSurance如何实现其战略目标。 我们还将解决功能和业务功能之间的差异，以及如何创建有用的分析以支持基于功能的规划。 请继续关注更多！

下一篇博客文章：ArchiMate®3.0 - 功能映射

原文：https://bizzdesign.com/blog/archimate-3-0-strategy-concepts-and-capability-based-planning/

本文：

讨论：请加入知识星球或者小红圈【首席架构师圈】

在我们之前的博客中，我们概述了业务战略与能力之间的关系。但是，我们还没有就如何创建您的能力的良好概述提供任何指导。在本博客中，我们将了解为什么识别功能对于组织很重要，如何定义它们，如何对它们进行分类以及如何将它们包含在功能映射中。

能力定义了组织需要做的事情，以便成功实现定义为公司战略一部分的结果。它们是业务的关键组成部分，彼此独特且独立，并且随着时间的推移趋于稳定。

为帮助您定义业务功能，以下指南可能会有所帮助：

1. 功能定义了业务的功能或功能，而不是业务的执行方式或执行方式。它们与业务流程，功能，服务，组织单位或IT系统不同，尽管这些都可能有助于提高能力。可以以不同方式实现相同的能力，例如，手动，IT支持或完全自动化。
2. 功能由业务拥有，并以业务术语命名和定义。对于所有涉及的业务专业人员，他们的定义应该易于理解。他们的名字是名词（例如“产品创新”），而不是商业流程，用动词命名（例如“购买材料”）。
3. 功能独特而稳定。它们仅为整个企业定义一次，并且很少改变，除非，例如，企业承担全新的业务或剥离其当前业务的一部分。
4. 能力可以是复合的，由子能力组成。功能也可以使用其他功能。
5. 可以在功能图中组织功能，该功能图提供整个企业的概述。
6. 可以跨不同维度评估能力的成熟度，例如人员，流程，技术，资产或信息。这些是基于能力的计划的基础。

能力图是企业的地图，可以显示其在特定状态下的功能，例如当前功能及其当前成熟度级别，或未来状态下所需的功能。通过分解可以使每个关键功能更具体。从自上而下的角度来看，能力来自组织的战略方向。从自下而上的角度来看，组件和资产（例如应用程序）可以链接到它们支持的功能，从而提供这些组件和资产与战略方向的间接链接。通过这种方式，能力可以用作资产组合定义的起点。

能力也可以进一步分类，例如：

• 核心与非核心
• 战略与运营与支持
• 面向客户与内部
• 创新与差异化与商品化

这种分类方案有助于投资和采购决策：

• 差异化，面向客户的能力是核心，很少外包。
• 战略性，创新能力对于企业的长期未来非常重要，并且通常会分配单独的预算，以避免“创新挤压”，核心运营能力会耗尽所有预算。
• 非核心，商品或支持能力是外包给以这些为核心，差异化能力的合作伙伴的良好候选者。

回到上一篇博客的示例，我们来看看ArchiSurance的Capability图（图1）。您将注意到的第一件事是此功能图中的所有功能都被命名为名词（例如：“产品管理”）。此外，有七个主要功能（例如“索赔管理”，“资产管理”等），它们已被进一步分解为更具体的能力（例如“索赔结算”，“合同管理”等）。此外，他们的能力图分为战略，运营和支持能力。

能力图是组织可用于执行高级性能评估的基本组件。 我们将在即将发布的博客中讨论功能分析，使用热图和蜘蛛图以及其他主题，如功能实现。 请继续关注更多！

下一篇博文：ArchiMate®3.0 - 能力分析

原文：https://bizzdesign.com/blog/archimate-3-0-capability-mapping/

本文：

讨论：请加入知识星球或者小红圈【首席架构师圈】

业务流程模型和符号(BPMN)是一种图形表示，它使公司能够更容易、更清晰地理解其内部业务流程。图形表示由不同种类的符号组成，以表示业务流程中涉及的业务活动。在Visual Paradigm中，我们有绘制业务流程图(BPD)所需的BPMN工具，在本教程中，我们将使用休假申请流程的BPMN示例来演示业务流程图如何有效地演示流程。

BPMN的组件

实际上，除了事件、网关和活动之类的流元素之外，其他一些元素对于组成BPMN也很重要。它们是泳道、游泳池和泳道。一般来说，泳道充当了在流程图中组织不同活动的机制，它包含另外两个组件，pool和lane。池表示进程中的参与者，而lane是池中的子分区。

在本例中，BPMN有一个代表参与者ABC公司的池。在池中，有多个通道，其中每个通道由公司的一个参与者组成。这家ABC公司共有三名员工，员工、经理和人力资源部。

休假申请流程示例

为了启动这个过程，必须发生一些事情，也就是说，这家公司的一名员工想要休假。因此，在图表中，开始事件符号被绘制在标有Employee的lane上，以指示开始。然后，将一个实箭头从开始事件符号链接到任务符号，以指示流程流方向，并显示员工需要做的第一件事是填写请假申请表。之后，他必须把表格交给经理批准。

从这里开始，经理负责流程，因此，我们将任务提交休假申请批准链接到经理通道上的另一个任务事件评估休假申请。经理收到申请后，会进行评估，以决定是否批准休假申请。此时，由于有两种可能的结果，要么批准，要么拒绝，所以在图上绘制一个网关符号，将流程分成两个端点。也就是说，如果申请被拒绝，经理需要通知员工，申请过程终止。因此，任务通知员工请求被拒绝连接到一个结束事件符号。另一方面，如果申请被接受，经理会通知员工，申请流程会继续跟进到HR需要管理申请的区域。

最后，在这个过程中剩下的就是让员工离开。结束事件符号连接到最后一个任务，告假表示整个过程结束。

Resources

1. Design Patterns.vpp
2. The-Leave-Application-Process.vpp

---

Related Links

• Introduction to BPMN Part I
• Introduction to BPMN Part II - Swimlanes
• Introduction to BPMN Part III - Flow and Connecting Objects
• Introduction to BPMN Part IV - Data and Artifacts

---

Readers of this tutorial also read

• What is Data Flow Diagram (DFD)? How to Draw DFD?
• How to Write Effective Use Cases?
• Data Flow Diagram: Examples - Food Ordering System
• How to Model Relational Database Design with ERD?
• How to Develop As-Is and To-Be Business Process?

 

原文：https://www.visual-paradigm.com/tutorials/bpmn-tutorial-with-example.jsp

本文：

讨论：请加入知识星球【首席架构师圈】或者飞聊小组【首席架构师智库】

BPMN允许我们以清晰一致的方式捕获和记录组织的业务流程，从而确保流程所有者和业务用户等相关利益相关者参与到流程中。因此，团队可以更有效地对流程中发现的任何问题做出响应。BPMN提供了全面而丰富的符号，可以很容易地被技术和非技术涉众理解。

以下是BPMN提供的好处列表：

• 由OMG财团（一个非盈利性行业组织）制定的行业标准
• 为企业提供通过业务流程图定义和理解其过程的能力
• 提供一个所有业务涉众都容易理解的标准表示法
• 弥补业务流程设计和实现之间经常出现的沟通鸿沟
• 简单易学，但足以描述业务流程的潜在复杂性
• 供应商中立，工具支持广泛

本文分为四个部分，旨在介绍业务流程模型和符号（BPMN）。本文将描述BPMN表示法的基础知识，即组成该符号的图形对象的类型以及它们如何作为业务流程图的一部分一起工作。它还说明了如何使用可视化范式创建和绘制BPMN图。

基本构造

BPMN元素有五个基本类别。它们都代表了业务流程的一个独特方面。

泳道

泳道是表示流程参与者的图形容器。游泳池和泳道是两种泳道，我们将在本教程的第二部分详细讨论它们。

流元件

流元素是相互连接以形成业务工作流的元素。流元素是定义流程行为的主要元素。有三种流元素：事件、活动和网关。我们将在本教程的第三部分讨论它们。

连接对象

流对象不是孤立的，而是为了形成流而连接起来的。连接流对象的连接器称为连接对象。有四种连接对象：序列流、消息流、关联和数据关联。我们将在本教程的第三部分讨论它们。

数据主要是执行业务流程时需要或产生的信息。有四种类型的数据：数据对象、数据输入、数据输出和数据存储。我们将在本教程的第四部分讨论它们。

人工产品

工件提供有关业务流程的附加信息。在本教程的第四部分中，我们将讨论这两种工件、组和文本注释。

BPMN简介的其他部分

• 游泳池第二部分
• 第三部分-流动和连接对象
• 第四部分-数据和工件

本教程的读者也阅读

• 什么是数据流图（DFD）？如何绘制DFD？
• 如何编写有效的用例？
• 数据流图：示例-食品订购系统
• 如何用ERD建模关系数据库设计？
• 如何按现状和未来发展业务流程？

原文：https://www.visual-paradigm.com/tutorials/bpmn1.jsp

本文：http://jiagoushi.pro/node/1080

讨论：请加入知识星球【首席架构师圈】或者加小号【jiagoushi_pro】

流程要素是指连接在一起形成完整流程的要素。连接流元素的连接器称为连接对象。BPD的读者可以通过元素流来了解业务流程是如何执行和完成的。

虽然有四种流元素：活动（任务和子流程）、事件和网关，但主要有两种连接对象：序列流和消息流。

活动

活动是在业务流程中执行的工作。它们以圆角矩形显示，并用名称描述要执行的工作。

有两种类型的活动：任务和子流程。当我们想为一个无法进一步分解或这样做毫无意义的原子工作建模时，我们使用一个任务。

另一方面，当我们要为一个非原子的、复杂的工作建模时，我们使用一个子过程。子流程可以分解为另一个级别的详细信息。由于这个原因，一个子流程通常包含另一个BPD对其细节进行建模。

请注意，选择任务或子流程不仅要考虑工作的复杂程度，还要考虑您需要了解工作的详细程度。如果您是客户，您可能不想知道您的付款是如何处理的。但是，如果你是商店，如何处理顾客的付款就变得很重要了。

事件

事件是发生的事情，可能会对业务流程产生影响。事件可以是外部事件，也可以是内部事件。只要它们能影响被建模的过程，它们就应该被建模。事件显示为圆形。在某些情况下，圆圈内有代表事件触发器类型的图标。

事件有三种类型：开始事件、中间事件和结束事件。可以为每个触发器指定触发器，以指示在什么条件下触发事件。

每个流程都应该有一个start事件来显示业务流程的开始。它允许读者在BPD中找到流程开始的位置。此外，结束事件用于指示业务流程在何处完成，中间事件负责根据其指定的事件驱动业务流。中间事件可以附加到某个活动，以便对该活动执行过程中可能发生的事件进行建模，也可以通过连接对象将其连接起来，以便对之前执行流元素之后可能发生的事件进行建模。我们将在本教程后面更详细地讨论。

看看下面的例子。它会给你一些关于事件如何运作的想法。基本上，图表是说当我们收到订单时，我们开始处理它。如果且仅当没有剩余的信用额度时，我们检查问题。当订单已处理或问题已确定时，流程结束。

网关

网关负责控制业务流程的流动方式。它们以菱形显示。在一个过程中，所要做的工作和输出可能因外部或内部条件的不同而有所不同。例如，折扣只提供给VIP买家，而不提供给其他任何人。网关是评估条件并作出决定的地方。

以下是一些典型的网关类型：

基于数据的独占网关，也称为独占网关，用于根据给定的流程数据控制流程。从网关连接的每个传出流都对应于一个条件。遍历满足条件的流。将只遍历一个流。

可使用Inclusive Gateway创建并行路径。对所有流出流的条件进行了评估。将遍历所有结果为正的流。因此，如果满足多个条件，则可能导致执行多个流。

并行网关用于模拟并行流的执行，而不需要检查任何条件。换句话说，所有传出流必须同时执行。

基于事件的网关用于对基于事件的可选路径进行建模。例如，要等待某人的答复，需要Yes或No来确定要遍历的路径。因此，网关后面是两个带消息触发器的连接的中间事件，其中一个表示是消息，另一个表示否。当任何一个事件被触发时，将采用该事件之后的流。所有其他事件及其后续流将不再有效。

序列流

序列流用于连接流动元件。它以带箭头的实线显示。它显示了流动元素的顺序。

只能使用序列流连接同一池中的流元素：在同一池/车道内，或在同一池中跨车道。如果要跨池连接元素，则不能使用序列流，而是使用消息流。

消息流

在BPMN中，池之间的通信是通过消息来实现的。消息流用于显示池之间的消息流或池之间的流元素。消息流以带有箭头的虚线显示。一些在池之间流动的消息示例：传真、电话、电子邮件、信件、通知、命令。

案例研究-True Aqua蒸馏水公司（续）

在本教程的第二部分中，您已经开始为True Aqua蒸馏水公司绘制BPD。您已经创建了几个游泳池和泳道。现在，我们将绘制流程图。如果您错过了第二部分，您可以点击本页底部的超链接打开它。

 

原文：https://www.visual-paradigm.com/tutorials/bpmn3.jsp

本文：http://jiagoushi.pro/node/1081

讨论：请加入知识星球【首席架构师圈】或者加小号【jiagoushi_pro】

传统建模技术的一个共同特点是允许在流程执行期间创建、读取和更新数据的建模。典型的例子是数据流图（DFD）。尽管BPMN主要不是为数据建模而设计的，但是仍然有一组符号可以让您对业务流程中涉及的数据进行建模。

BPMN还为modeler提供了几个工件符号，以更详细地描述业务流程。例如，分组相关活动的组对象和详细解释流对象的文本注释对象。

数据

通常，在执行业务流程时，可能会在流程期间或结束后生成数据。例如，成功执行下单任务将产生采购订单、发票、收据等数据。在BPMN中，数据可以由几种类型的“数据”对象建模，例如数据对象、数据输入、数据输出和数据存储。有一种定义良好的方法来管理数据的状态，比如实例化、完成、删除等。

组

组是带有虚线边框的框，为建模者提供了一种按不同类别对形状进行分组的机制。

文本批注

文本注释可用于向BPD中的流对象添加额外的细节。它不影响流，但提供流中对象的详细信息。

案例研究-True Aqua蒸馏水公司（续）

在本教程的第三部分中，您已经为True Aqua蒸馏水公司建模了蒸馏水订购流程的流程。现在，我们将添加数据和注释来进一步描述流。如果您错过了第一部分到第三部分，您可以点击本页底部的超链接打开它们。

蒸馏水订购流程的执行将产生采购订单。让我们对采购订单的创建和操作进行建模。我们知道，采购订单是在客户服务助理收到客户的订单请求时创建的，该请求由任务Verify customer Identity建模。因此，我们将从任务创建采购订单数据验证客户身份。将鼠标指针放在它上面，并拖出右上角的资源目录图标。

释放鼠标按钮并从资源目录中选择数据对象。

命名数据采购订单。

采购订单在流程中有其生命周期，从创建到完成。我们可以通过定义状态来建模。右键单击采购订单并选择状态>创建。。。从弹出菜单。

在输入窗口中，输入【Create】作为state的名称，然后单击OK。

Create标记被添加到采购订单的名称中。正如我所说的，采购订单有它的生命周期。当客户服务助理完成任务转发订单后，采购订单将等待物流部门的分配。我们可以通过在改变状态的情况下重复使用同一数据段来对此进行建模。从任务转发顺序中，按下并拖动资源目录图标。

释放鼠标按钮并从资源目录中选择数据对象。

输入采购订单作为数据的名称。注意这一步。必须输入“采购订单”作为“名称”，才能重新使用之前创建的“采购订单”数据对象。确认编辑时，系统将提示您是否希望数据对象引用现有的数据对象。选择“是”。

右键单击与远期订单关联的采购订单数据，然后选择“状态”>“创建…”。。。从弹出菜单。

输入【被指定】状态并确认。到目前为止，相同的采购订单数据在流程中显示两次，状态不同。

当物流部经理完成安排交货任务后，采购订单将分配给一名工人，等待交货。应用上述技巧。添加采购订单数据并定义【要交付】的状态。

最后，当交货完成时，采购订单即告完成。试着在图表中建模。

在结束本教程之前，让我们创建一个文本注释。请看任务放置顺序。根据从True Aqua蒸馏水公司收集的信息，我们知道虽然有些订单请求是通过电话提出的，但有些是通过电子邮件提出的。让我们用文本注释来描述这个额外的细节。使用资源目录从任务放置顺序创建文本批注。

输入正文注释：超过90%的请求是通过电话提出的，10%是通过电子邮件提出的。

确认编辑并调整文本批注的大小以使文本显示在多行中。以下是最终的BPD：

BPMN简介的其他部分

• 第一部分-BPMN简介
• 第二部分-泳道
• 第三部分-流动和连接对象

资源

• The True Aqua Distilled Water Company - Part IV.vpp (with this part completed)

 

原文：https://www.visual-paradigm.com/tutorials/bpmn4.jsp

本文：http://jiagoushi.pro/node/1082

讨论：请加入知识星球【首席架构师圈】或者小号【jiagoushi_pro】

业务架构

业务架构一方面是企业业务模型和企业战略之间的桥梁，另一方面是企业业务功能之间的桥梁。

定义–“与公司业务相关的企业架构的一部分，以及描述该业务架构结构的文档和图表。”

EBA不是什么

• 1] EBA不仅仅是一个流程视图-业务流程正在发展以支持信息分析、社交网络和协作/团队。这意味着，通常理解良好、文档齐全且受支持的自动化流程将变得更加复杂和动态，需要在整个EA环境中的集成视图。这意味着，EBA必须平等地考虑人员、财务、流程和组织结构，而不仅仅是主要的流程，当然也不是孤立的流程。
• 2] EBA并不是唯一的业务链接-虽然EBA和企业业务架构师将链接到业务，但这不是EBA的唯一或主要角色。此外，EA要求所有的视点（业务、信息、技术和解决方案）都需要与关键业务领域直接连接和协作。

EBA维度

EBA的四个主要维度（人员、财务、流程和组织结构）都在业务上下文定义的业务功能中。（图1）需要注意的是，业务功能和子功能可以由完整和部分流程、人员和/或组织实体的集合来支持。业务流程、人员、财务和组织结构通常跨业务职能。在大多数情况下，业务功能或子功能与任何特定流程、人员或组织实体之间不存在一一对应关系。

• 人员-这个维度关注对您的业务有直接影响的人员，特别是由EA范围定义的业务部分。这些人可能是内部员工、承包商、外包合作伙伴、供应商和顾问。
•  财务——欧洲银行业管理局的财务维度着眼于企业如何管理其财务资源以支持未来的状态。
• 组织-这个维度指的是组织的正式和非正式结构-正式的是正式的报告组织结构，非正式的是虚拟团队、文化层级和社会网络
• 流程-这是将系统从一个状态转换到另一个状态的活动的集合。有不同类型的过程，包括：操作过程、管理过程、支持过程、元过程、过程的过程和IT过程。

图1

影响因素

一些关键影响因素可能包括：

1. 合规性——不同的业务职能（因此包括人员、组织、财务和流程）受特定法规合规性要求影响的程度。
2. 生态系统——一个组织通过与外部业务伙伴、供应商和云资源合作，努力创造增长和机会的程度。
3. 文化和政治-在某些情况下，这是一个很难分析的因素，因为通常存在一个由组织内的领导和人员定义的整体企业文化。此外，一个组织内的文化和政治可能因群体、角色、部门和地区而大不相同，特别是在合并和收购的情况下。
4. 行业-这个维度反映了你的业务所关注的行业。这一因素强化了这样一种观点，即在所有行业和企业中，都没有单一的EBA方法。
5. 地区/位置-这一因素集中在地区和位置差异上。随着人们越来越关注全球化（包括内部和外部），了解地区差异对于欧洲银行业管理局以及整个欧洲银行业管理局都至关重要。
6. 创新-了解在组织和/或业务的不同部分鼓励（或不鼓励）创新的程度对人们的角色和态度、组织结构的动态性、技术如何得到支持、正在进行的投资类型、团队如何，衡量团队和人员，以及动态过程可能如何。
7.  行为-个人用户并不等待IT或业务领导人支持他们的工作风格、行为和完成工作的需要。这些行为因人而异。感知、理解和响应人们不断变化的需求、技能和行为可能对EBA维度产生巨大影响。
8. 时间-时间是一个不寻常的因素-就其本身而言，它不会“做”任何事情。时间作为一个因素提醒我们，EBA和EA并不是一个永远“完成”的“项目”，宏观问题是，随着人、市场和创新的变化，时间反映了一个不断发展的业务。其中一些变化是在定义明确的进化周期中发生的，而另一些则没有。

定义企业上下文

企业架构（Enterprise architecture）是将业务愿景和战略转化为有效的企业变革的过程。要做到这一点，EA实践者必须根据他们的企业环境定义并驱动他们的EA工作。企业环境是：

• 识别内部和外部环境趋势
• 阐明经营战略
• 确定需求
• 创造原则
• 开发业务的锚模型

企业上下文覆盖并通知所有的EA工作和观点（图2）[企业技术架构（ETA），企业信息架构（EIA），企业解决方案体系结构（ESA）和企业业务体系结构（EBA），以确保与业务的有效战略集成和工作的重点方向。

图2

业务上下文与业务架构

企业架构的业务上下文是业务策略及其含义、外部“环境”趋势和高级未来状态远景的表达。业务上下文覆盖并通知所有EA工作和观点，即ETA、企业信息体系结构（EIA）、企业解决方案体系结构（ESA）和EBA，以确保与业务有效的战略一致性和工作的重点方向。

企业业务架构（enterprise business architecture）是EA的观点之一，与ETA、EIA和ESA一起，它们应该利用业务上下文。定义EBA的目标是确保业务功能、流程、财务、人员和组织结构的更改和增强以及信息和技术得到充分优化，以支持业务战略

原文：https://sites.google.com/site/aniketsaoblog/home/emerging-business-architecture/business-architecture-layer

本文：http://jiagoushi.pro/node/1067

讨论：请加入知识星球【首席架构师圈】或者微信小号【jiagoushi_pro】

开发业务架构

EA过程模型可以表示为一系列七个步骤，在支持任何架构（architecture）观点的过程中都可以遵循这些步骤，以及进行中的管理、治理和通信工作。这必须以迭代的方式完成：架构师必须根据业务上下文的变化（例如新的业务策略）继续在深度和广度上发展。EA开发“步骤”是可以重叠和混合的活动。一步可以在另一步结束之前开始。它不需要遵循严格的瀑布式方法。

图1

构建业务架构是一个迭代过程，在开发EBA时，相同的EA过程也可以应用。

1] 定义和范围

为了开始使用EBA，EA团队应该：

• 建立一个明确的EBA定义，包括EBA工作的总体目标。
• 为这个特定的迭代创建一个范围声明，以及一个超出范围的声明。
• 制定一份相关假设的声明（如业务主题专家[SME]的可用性）。
• 确定每个迭代的总体业务发起人和业务发起人。
• 确定EBA活动与其他视点活动、依赖项和关系之间的关系。
• 就与整个EA过程的关系制定一份声明。
• 确定关键约束（合规性、扩展的企业生态系统、组织文化和政治、行业和区域要求）。

2] 组织

确定并组织团队完成迭代的工作。对于任何EA领域，这意味着详细说明关键领导和成员角色，并确保他们从其选区领导正式参与。此外，收集必要的（以及可用的）支持信息、模型和工件。

任何EBA团队都应具备以下条件：

• 基于目标和宗旨的明确章程
• 明确的角色和职责

3] 未来状态

第三步是通过定义需求、原则和模型来确定未来状态的EA远景，这些需求、原则和模型描述了要改变的长期目标，以及如何成功地走向该目标状态。未来的第一个状态任务是定义EBA更改的上下文，了解业务上下文如何应用于EBA迭代

4] 当前状态

这个过程的第四步是建立当前状态的基线。目标是了解EA和EBA工作范围内当前业务维度的状态。为了解决这一问题，当前国家文件的范围和详细程度应反映未来国家的文件，因为这项任务的目标是为下一步做好准备——确定你现在的位置和你想要的位置之间的差距。

5] 差距分析

当EBA团队达到这一步时，当前状态和未来状态之间的差距应该相当明显。这一步骤的目标是明确记录这些差距。

6] 迁移计划

EA路线图可以作为有价值的规划工具，帮助组织定义一组清晰的提议变更项目，将企业从当前状态转移到未来状态。

EBA团队应：

• ·建议对EBA维度（人员、流程、组织和财务）进行更改
• ·确定相关ETA、EIA和ESA架构的变更
• ·确定调整决策（组织变更、重新定义项目和项目启动）
• ·确定投资决策（技能、人员和技术）
• ·确定可能受内部和外部因素（合规性、文化和政治、行业和地区）变化影响的EBA维度-为关键领域制定情景。

7] 迭代和优化

随着组织不断向未来发展，EBA团队应根据需要考虑更深入的迭代，特别是加强对其他架构（architecture）视点的依赖性；这样做将允许更好的相关性分析和更好的影响分析，从而提高敏捷性。

运营模式

运营模式是一个组织如何、在何处以及与谁一起运营的抽象表示，包括每天做出决策，以实现其使命和战略目标，同时为其目标客户提供价值

经营模式和商业模式的衔接是收紧公司执行模式的一个关键组成部分，以便以更低的成本提供更多的价值。对于业务架构师来说，存在着巨大的机会，他们可以定义操作模型，从而为他们的公司创造重要的价值（图2）

图2

创建有效运营模式的五大核心要素

五个要素对于定义运营模式至关重要：

• 领导
• 治理
• 组织模式
• 能力
• 服务

关注这些要素的清晰性和一致性的业务架构师将支持公司战略的成功。

原文：https://sites.google.com/site/aniketsaoblog/home/emerging-business-architecture/best-practices-for-business-architecture

本文：http://jiagoushi.pro/node/1069

讨论：请加入知识星球【首席架构师圈】或者微信小号【jiagoushi_pro】

业务能力建模是一种创建业务锚模型的技术，该模型表示一个组织的不同和差异化的业务能力，独立于该组织的结构、系统、流程、人员或域。

组织正在利用业务能力建模来表达和探索“我们做什么”，以便他们能够就“我们如何做”做出决策。利用业务能力建模应该在与业务领导人密切合作和协作的情况下完成，理想情况下由业务部门而不是it部门驱动。

下面是一个消费品和服务公司的业务能力模型示例

图1

将业务流程模型与业务能力模型连接起来

业务流程主管和业务流程架构师应将其高级流程视图链接到业务功能中，以支持跨相互依赖关系的影响分析。最明显的方法是将最高级别的流程区域映射到至少一个目标业务功能中。EA还将把每个业务能力与流程之外的其他视图（如信息和应用系统以及其他技术）联系起来，而BP架构师也可以利用这种更广泛的联系。

图2

业务能力建模方法

1] 向管理层推销业务能力建模的概念-

关于业务能力建模的第一个市场-

• 通过定义功能建模将做什么以及它将为业务解决什么挑战来总结该建议
• 解释这项技术是如何工作的，并举例说明拟采用的方法
• 描述了使用此方法的预期好处

然后通过以下方式描述业务能力建模方法：

• 为知识共享、协作和决策提供一致的模型。
• 识别相互依赖和重叠，消除业务能力、流程、信息和技术的筒仓。
• 为业务/技术的一致性提供完整和连贯的信息，并为业务和IT通信提供通用语言

最后解释如下好处：

• 通过为领导和变革管理提供方向性的愿景，帮助多个服务线的实施者遵循统一的战略计划。
• 为企业技术规划提供从业务到技术的清晰视线。
• 使用可扩展、可重复的方法确定和利用跨服务线的协同效应

2] 业务能力模型开发过程

• 该流程首先确定有关服务线的相关细节，包括业务战略、原则和目标、措施和好处；它们的能力和关键流程的细节。
• 在详细了解流程级别之后，深入了解人员、信息、应用程序和系统，即涉及的各方——服务线领导、EA资源、业务能力“所有者”和IT资源。
• 创建访谈问题和模板
• 创建模型

3] 业务和IT采用能力模型

业务能力模型可用于业务的多种实际用途：

• 跨职能业务规划
• 资源规划（角色和职责）和资源共享
• 设施设计和部门邻近规划
• 确定业务关键要素之间的关系
• 工艺流程设计
• 支持项目管理
• 业务技术需求的沟通和规划

从能力建模工作中开发一系列诊断可交付成果，使IT组织能够预见新业务的样子，以便更好地支持转换

 

原文：https://sites.google.com/site/aniketsaoblog/home/emerging-business-architecture/business-capability-modeling

本文：http://jiagoushi.pro/business-capability-modeling

讨论：请加入知识星球【首席架构师圈】或者微信小号【jiagoushi_pro】

业务能力是组织执行核心功能所需的能力、材料和专业知识的表达或发声。 企业架构师使用业务能力来说明业务的总体需求，以便更好地制定满足这些业务需求的 IT 解决方案。

捷径

• 介绍
• 业务能力建模
• 您可以通过业务能力映射实现什么？
• 并购管理
• IT风险管理
• 创新管理
• 业务能力优势
• 通过 4 个步骤创建您自己的业务能力模型
• 结论

介绍

在数字时代，技术的作用从支持业务战略的流程转变为战略执行本身的关键工厂。 信息技术帮助客户在第二天收到他们在网上订购的衬衫，帮助他们在通勤途中在 iPad 上阅读报纸，并且这些服务的发票可以顺利处理。 因此，如何弥合 IT 战略和执行之间的差距的挑战变得更加紧迫。

这种差距通常是由使用多种语言的组织造成的。 他们谈到使命、战略、目标、流程和项目。 首席执行官谈到“将移动优先作为优先事项”，营销“增加千禧一代的钱包份额”和“负载平衡 Linux 服务器集群”的 IT。 哪一种是正确的语言？ 业务能力有可能成为这种通用语言。

业务能力建模

你需要知道的
业务能力建模是一种表示组织的业务锚模型的技术，该模型独立于组织的结构、流程、人员或领域。

作为企业架构师的工具，业务能力模型可以讨论战略投资或撤资。 业务能力可以作为发现 IT 冗余的结构化元素。

麦肯锡估计发现 IT 冗余可节省 15 - 20%。

业务能力映射使公司能够清楚地看到企业为实现其目标所做的工作。 业务能力建模是 IT 领导者的基本视图。 业务需求应该塑造您的 IT 架构。 随着公司的变化、创新和为数字化转型做准备，流程、需求和目标也会发生变化。 在经历了复杂而众多的变化之后，配套技术也应该重新审视。

您可以通过业务能力映射实现什么？

 

• 封装企业现在正在做什么以及需要做什么来应对当前和未来的挑战。
• 定义企业“做什么”，而不是“如何”做
• 为讨论和计划提供一个共同的基础
• 从战略到执行的清晰链接
• 让定义战略的适当利益相关者参与进来
• 进行有组织的并购
• 准确定义业务中的角色
• 管理合并、评估风险并为创新努力做好准备。

并购管理

由于业务能力根据其活动构建公司，因此能力图是建立高度战略性并购的关键工具。即使两家公司的组织结构和流程彼此非常不同，能力图也为双方提供了以有益方式构建合并的基础。

能力图将应用程序分配给用户组和业务能力。这种对应用程序的总体视图以及 SaaS 发现及其业务价值使得评估 IT 支持在两个维度（功能性和可用性）方面的冗余和差距成为可能。

 

想象一下最近收购了当地保险公司的跨国保险公司。在并购过程中，两个团队都会坐下来评估他们的支持申请。团队必须决定哪些应用程序可以在未来使用，哪些应该被淘汰。熟悉他们的潜在应用程序，并受其先前组织结构的影响，团队如何客观地选择最适合新公司前进的应用程序？

与其迷失在不确定性中，“这个应用程序以前为我们工作，所以它应该继续工作”，团队可以坐下来用业务能力图来构建整个合并后的集成。

业务能力模型有助于讨论战略投资或撤资领域。业务能力可以作为发现 IT 冗余的结构化元素。麦肯锡估计发现 IT 冗余可节省 15 - 20%。

LeanIX Customer Helvetia 在与瑞士再保险的合并中能够减少冗余并实现大量节省。在其半年报告中，Helvetia 将 IT 列为这些节省的重要贡献者。建立透明度是实现这一目标的关键第一步。如今，已建立的 LeanIX 清单已成为战略 IT 管理决策所依据的单一事实来源。

IT风险管理

通过将业务能力链接到应用程序，并将这些应用程序链接到技术组件，CIO 可以浏览业务能力图并执行快速的战略风险评估。有了正确的信息，首席信息官可以发表如下声明：“我们不能接受服务器集群报废的风险，因为它为我们的在线预订系统提供了基础设施，这对我们直接销售给顾客。

由于其财务影响，直接向客户销售具有最高的战略优先级。”清楚地了解哪些技术组件依赖于其他技术组件是一个强有力的观点，尤其是在高安全漏洞期间。

创新管理

业务能力对于构建有关如何转变业务和 IT 的想法也有很大帮助。在这个数字时代，公司需要调查和思考创新的新方法，能力逐个能力。 SaaS 提供商可能会被列入名单，考虑转换和更新其能力的方法。

再看一眼“管理定价”功能，并确定更新方法。过去，公司可能遵循简单的标准定价模型表。现在，SaaS 公司可以根据更新的数据进行定价。

业务能力优势

业务能力视图带来了许多好处。

1. 将执行与战略联系起来，将哪些能力支持战略支柱，将资金与核心能力保持一致，并分配、衡量和监控关键绩效指标。
2. 专注于核心能力可为您的公司带来竞争优势，使您能够标准化上下文能力并将商品能力外包。
3. 拥有 360 度的企业视图可以让您对业务动机、能力、流程、数据和资源有一个连贯而全面的视图，并让您能够理解相互关联、重叠和协同作用。
4. 业务能力建立了一种通用语言，为业务和 IT 提供了可操作的框架。
5. 从业务能力的概述来看，IT 和业务领导者能够在没有业务和技术术语的情况下跨组织交流应该完成的任务。
6. 业务能力允许更明确的架构定义，因为能力有助于提供更好的业务定义，从而产生有效和高效的技术解决方案。一旦组织起来，IT 资产就可以被多次利用和重复使用，从而节省成本并减少不必要的软硬件采购。
7. 业务能力有助于打破 IT 和业务方面的孤岛。从以能力为中心的组织设计运营可加快上市时间。

麦肯锡报告称，业务能力可以帮助发现冗余——节省的潜力通常在 15% 到 20% 之间。能力驱动的思维帮助组织更好地理解和降低技术风险，节省超过 59 万美元——这是单个 IT 事件的成本。

本质上，业务能力应该位于业务架构的顶层。业务能力具有三个主要特征。

• 它们是规划组织最稳定的参考，
• 它们使战略更加切实，
• 如果定义得当，它们可以帮助克服组织孤岛

业务能力描述了企业为响应已定义的战略而做什么和需要做什么。 它们有助于缩小战略与执行之间的差距。

如果一个业务能力说“招聘优秀的员工”，它涉及到各种各样的人——HR团队，流程——吸引、筛选、面试、录用，以及所需的技术——在线评估中心、数字人事档案等，成为一个能力。 该组织。

业务能力构成了伟大 IT 战略的关键部分，因为它们指明了通往胜利的道路，并指出了 IT 和业务在此过程中的必要步骤。

通过 4 个步骤创建您自己的业务能力模型

1 - 了解需求

“了解贵公司的发展方向以及 IT 可以如何提供帮助。”

如果 IT 部门不知道业务的发展方向，就不可能做出支持性决策。因此，审查公司的战略和目标文件是一个好的开始，或者更好地让定义战略的人参与进来，比如战略或公司发展部门。

2 – 定义您的业务能力

“业务能力语法：如有疑问，请寻求广度而不是深度。”

想想您的企业需要运营的主要能力。在第一级（1 级）应该只有几个关键的。对前 100 个 LeanIX 工作空间的分析表明，公司通常在最高级别使用大约 7 到 10 个功能。您可以通过自上而下（公司想要实现什么目标）和自下而上（组织、流程和人员到位）思考来构建它们

3 - 评估你的能力

“就客户价值和财务影响而言，并非所有业务能力都是平等的。”

并非所有能力都同等重要。根据定义的标准评估能力，作为以后分析和计划的基础。

4 - 将功能链接到应用程序

“业务能力和应用程序之间的联系在业务和 IT 之间架起了一座桥梁。”

在最后但同样重要的一步中，将您的功能链接到您的应用程序。与 IT 组件不同，应用程序始终可以链接到特定的业务目的。业务用户与他们合作以创造价值。因此，应用程序是业务架构和技术架构之间的完美过渡。

获得完整概览的一个好方法是将业务能力描述为包含分配的应用程序的嵌套框。

The 4 steps to creating a Business Capability model

综上所述

业务能力有可能成为业务和 IT 之间的通用语言。 正确定义的业务能力可以帮助节省资金、降低风险并促进增长。 最佳实践表明，具有精益理念的公司的业务能力模型具有大约 10 个顶级能力和两个深度级别。

生成的模型可用于支持分析，以使 IT 投资与战略保持一致、绘制技术风险图并整合 IT 应用程序。

 

原文：https://www.leanix.net/en/wiki/ea/business-capability

本文：https://jiagoushi.pro/node/1949

前言

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 Domain	行为视角	结构视角
外部视角	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 业务域	行为视角	逻辑结构视角	物理结构视角
外部视角	业务服务	业务功能	组织单位
内部视角	业务流程	业务角色	业务参与者

结论

业务功能是抽象的活动结构元素。

它们是从实际组织单元中提取的逻辑抽象，如果由提供的服务定义，则可以视为接口定义。

业务功能对应于业务功能。

但“能力”一词往往意味着功能+目标+实现功能所需的人力和其他资源。

也就是说，一个能力就是一个业务系统。

原文：http://grahamberrisford.com/00EAframeworks/01Fundamentals/Business%20functions%20in%20TOGAF%20and%20ArchiMate.htm

本文：http://jiagoushi.pro/node/1232

讨论：请加入知识星球【首席架构师圈】或者小号【jiagoushi_pro】或者QQ群【11107777】

 

目标/目标/服务图的目的是定义服务对实现业务远景或战略的贡献方式。

服务与它们所支持的驱动因素、目标、目标和度量相关联，允许企业了解哪些服务对业务绩效的类似方面有贡献。目标/目标/服务图还提供定性输入，说明什么是特定服务的高性能。

 

UML/BPMN EAP Profile

Goal/Objective/Service diagram

Show/Hide legend

Business service: Represents a service provided by the business, which may then be realized by one or more IS services.

Goal: This is a goal or objective of the enterprise.

General purpose traceability link: Determines that the origin of the trace has been founded on the trace destination during its definition.

 

Archimate

原文：https://www.togaf-modeling.org/models/business-architecture/goal-objective-service-diagrams.html

本文：

讨论：请加入知识星球【首席架构师圈】或者小号【jiagoushi_pro】或者QQ群【11107777】

业务足迹图描述了业务目标、组织单元、业务功能和服务之间的联系，并将这些功能映射到提供所需功能的技术组件上。

业务足迹图在技术组件和它所满足的业务目标之间提供了清晰的可跟踪性，同时也证明了所识别服务的所有权。

业务足迹图只展示了将组织单元功能与交付服务联系起来的关键事实，并被用作高级（CxO）涉众的交流平台。它必须专注于当前的业务兴趣：根据关注点的不同，它可以专注于一个或多个应用程序组件（需要改进）或一个或多个业务功能。

UML/BPMN+ EAP Profile

Archimate

原文：https://www.togaf-modeling.org/models/business-architecture/business-footprint-diagrams.html

本文：

讨论：请加入知识星球【首席架构师圈】或者小号【jiagoushi_pro】或者QQ群【11107777】

也称为“流程图”。 事件图的目的是描述事件和流程之间的关系。某些事件，如某些信息的到达（例如，客户提交销售订单）或某个时间点（例如，财政季度末）会导致工作，并需要在企业内部采取某些行动。这些事件通常被称为业务事件或简单的事件，并被视为流程的触发器。需要注意的是，事件必须触发流程并生成业务响应或结果。 事件图提供流程的概述，这有助于它们的映射。事件图提供了流程、触发事件、发送事件、参与角色或组织单元以及接收或发送产品的一般视图。在这个宏观层面上，流程之间没有顺序，即使我们能够看到一个过程发送的产品可以被另一个过程重用。

UML/BPMN+EAP Profile

 

External actor: An actor that is external to the enterprise.

Internal actor: An actor that belongs to the enterprise.

Organization unit: Describes one unit that breaks down the organization of the enterprise. This can be, for example, a department.

Business process: As presented in process maps (event diagrams). The business process is detailed in flow diagrams.

Product: A product is produced or consumed by business processes.

Business event: A business event triggers a business process or is generated by a business process.

Information flow: Defines the flow of any kind of information (business entity, event, product, informal, etc) between active entities of the enterprise.

Participates in link: Describes in which part or activity of the enterprise a participant intervenes.

Initiator of link: The origin participant initiates the designated process. It starts the process by realizing a task or activity in it.

Archimate

原文：https://www.togaf-modeling.org/models/business-architecture/event-diagrams.html

本文：http://jiagoushi.pro/node/1235

讨论：请加入知识星球【首席架构师圈】或者小号【jiagoushi_pro】或者QQ群【11107777】

 

功能分解图的目的是在一个页面上显示与架构（architecture）考虑相关的组织能力。通过从功能的角度考察一个组织的能力，就可以快速地开发出组织做什么的模型，而不必被拖入关于组织如何做的广泛辩论中。一旦一个基本的功能分解图被开发出来，就有可能在这个图的上面分层显示范围和决策。例如，在变更计划的不同阶段要实现的能力。

可以使用指向模型其他部分的链接来丰富此图，例如，指示哪个应用程序支持哪个功能，哪个角色使用哪个功能，等等。

UML/BPMN EAP Profile 

Main functions of the DiscountTravel company

Function: Describes one function of the organization.

Archimate

原文：https://www.togaf-modeling.org/models/business-architecture/functional-decomposition-diagrams.html

本文：

讨论：请加入知识星球【首席架构师圈】或者小号【jiagoushi_pro】或者QQ群【11107777】

业务流程建模是使用流程图进行的。

流程图的目的是描述与流程相关的所有模型和映射。过程流图显示了活动之间的顺序控制流，可以利用泳道技术来表示过程步骤的所有权和实现。例如，支持流程步骤的应用程序可以显示为泳道。除了显示活动序列外，流程流还可用于详细说明应用于流程的控制、流程完成时触发或导致的事件，以及流程执行过程中生成的产品。过程流程图在与主题专家一起详细说明体系结构时非常有用，因为它们使专家能够描述特定功能的工作是如何完成的。通过这个过程，每个过程步骤都可以成为一个更细粒度的功能，然后又可以被细化为一个过程。

流程图描述了流程的内部功能。它们用BPMN标准表示，描述了任务的顺序、负责这些任务的实体以及交换的信息。

请注意，在这个图中，我们可以找到先前定义的角色（客户），它们对应于线（任务的责任）、业务单元（销售部门、管理部门）和业务实体（订单）。因此，业务流程完成角色或部门的属性。

业务流程可以在多个级别进行描述。

 

UML/BPMN EAP profile

Model of the Reserve Trip BPMN process

Elements represented: See the BPMN standard.

Archimate 

 

原文：https://www.togaf-modeling.org/models/business-architecture/process-flow-diagrams.html

本文：http://jiagoushi.pro/node/1239

讨论：请加入知识星球【首席架构师圈】或者小号【jiagoushi_pro】或者QQ群【11107777】

组织分解图描述了组织树中参与者、角色和位置之间的链接。组织图应该提供组织中所有者和决策者的指挥链。虽然组织分解图的目的不是将目标与组织联系起来，但是应该可以从组织分解图直观地将目标与涉众联系起来。

这个图表还可以描述参与者的定义和他们的职责。组织是指参与者之间的联系，或者是参与者和组织单位之间的联系，表现出等级关系、沟通和责任。

通过展示企业主要参与者之间的主要信息流，还可以突出组织内的任务和责任。这显示了组织中由谁接收、处理或发出哪些信息，从而说明了组织元素的责任。

组织分解图还用于定义参与者承担的不同角色。

位置、角色和参与者

在图1所示的示例中，表示了位置、角色和参与者。总部设在巴黎，在南特、图卢兹和里昂有三家分公司。组织单位已分配到不同的地点。大部分服务集中在巴黎。IT部门设在图卢兹。每个分支机构都有销售部。通过其职责链接（角色到角色或组织单元），角色的地理位置通常是隐含的。

UML/BPMN EAP  Profile

Figure 1 - Roles, actors, locations and organization units are represented in organization decomposition diagrams

Show/Hide legend

Internal actor: An actor that belongs to the enterprise.

Headquarter location: Geographically defines where the elements of the enterprise are deployed (organization units, hardware devices, actors, etc).

Site location: Geographically defines where the elements of the enterprise are deployed (organization units, hardware devices, actors, etc). Generally, an enterprise has one headquarter and several sites.

Organization unit: Describes one unit that breaks down the organization of the enterprise. This can be, for example, a department.

Localization link: Localization link of an element of an enterprise (actor, business unit, hardware device, etc) in a location. Alternatively, the localized element can be embedded into the location.

Archimate

角色及其职责的定义

如图2所示，角色及其职责的定义是以一般方式展示企业功能的一种好方法。企业的参与者及其交互提供了对组织的概述。

一个企业内的几个演员可以代表几个人。某些演员代表一群人或演员，例如“董事会”：这是一个将不同部门的董事聚集在一起的例子。但和其他演员一样，它也有责任和决策权。

企业外部的参与者有助于展示他们对组织本身的定位：谁与他们互动。

存在的元素：

• 描述层级的责任链接
• 责任链接到组织单位，表明谁负责哪个组织单位
• 沟通链接，表明谁与谁沟通
• 构图环节，展示复合演员的构成。
• 内部行动者，即参与企业运作的行动者
• 外部参与者，他们是企业外部的参与者，但与企业互动（此处：客户和合作伙伴）

UML/BPMN EAP Profile

Figure 2 - This model provides the organization chart, enriched by information on responsibilities and communication

Show/Hide legend

Organization unit: Describes one unit that breaks down the organization of the enterprise. This can be, for example, a department.

Internal actor: An actor that belongs to the enterprise.

External actor: An actor that is external to the enterprise.

Communicates with link: Indicates that two roles or actors communicate together to realize their work.

Composed of link: Indicates that a role is composite, and is made up of other roles.

Responsible for link: Indicates hierarchical responsibilities between roles or actors, and responsibilities of organization units.

Archimate 

 

Figure 2 - This model provides the organization chart, enriched by information on responsibilities and communication

Business Actor.

Meaning.

企业内部流通的主要信息流

图3显示了在企业内部流通的主要信息流。它们是从行动者和/或组织单位接收或发送给它们的。此示例集中于从外部参与者发出/发送到外部参与者的流，以及参与处理的主要组织单元。

UML/BPMN EAP Profile 

Figure 3 - Main information flows within the enterprise

Elements used:
•    Actors
•    Business Units
•    Information flows: Information can be related to business entities to express that these are the exchanged data (Bill and Order in this example).

Show/Hide legend

Organization unit: Describes one unit that breaks down the organization of the enterprise. This can be, for example, a department.

External actor: An actor that is external to the enterprise.

Information flow: Defines the flow of any kind of information (business entity, event, product, informal, etc) between active entities of the enterprise.

 

Archimate

Figure 3 - Main information flows within the enterprise

Show/Hide legend

Business Actor.

Business Object.

Flow.

参与者承担的角色

图4显示了由参与者承担的角色。演员扮演一个角色来执行任务。演员通常或预期的功能，或某人或某物在某一特定动作或事件中所扮演的角色，在这里进行了建模。

UML/BPMN EAP Profile

Figure 4 - Roles assumed by actors

Elements used:
•    Actors
•    Roles
•    "assumes" dependencies

Show/Hide legend

Internal actor: An actor that belongs to the enterprise.

External actor: An actor that is external to the enterprise.

Internal role: Role played by an internal actor during a given action (task).

External role: Role played by an external actor during a given action (task).

Archimate 

Figure 4 - Roles assumed by actors

Show/Hide legend

Business Actor.

Business Role.

Assignment.

详细参与者承担的角色

图5显示了相同类型的模型，但是显示了一个非常详细的层次，集中在一个参与者上。这种每个参与者的详细模型提供了每个参与者的详细定义，显示了其任务、责任和权利。此图显示了分配给销售总监的目标、他/她的职责（业务部门、管理的参与者）、他/她拥有的业务流程、他/她的位置、假定的角色、他/她使用的应用程序组件、他/她与之交互的其他参与者，以及他/她有权访问的企业实体。

UML/BPMN  EAP Profile 

 

Figure 5 - Detailed model of actors, focused on Sales director

Show/Hide legend

Goal: This is a goal or objective of the enterprise.

Internal actor: An actor that belongs to the enterprise.

Headquarter location: Geographically defines where the elements of the enterprise are deployed (organization units, hardware devices, actors, etc).

Organization unit: Describes one unit that breaks down the organization of the enterprise. This can be, for example, a department.

Business macro process.

Composed of link: Indicates that a role is composite, and is made up of other roles.

Responsible of link: Indicates hierarchical responsibilities between roles or actors, and responsibilities of organization units.

Owner of link.

Assigned link: Assignment of a goal to an element of the enterprise, typically an actor, an organization unit or a business process.

Localization link: Localization link of an element of an enterprise (actor, business unit, hardware device, etc) in a location. Alternatively, the localized element can be embedded into the location.

Archimate 

Figure 5 - Detailed model of actors, focused on Sales director

Show/Hide legend

Business Actor.

Location.

Business Process.

Assignment link.

Influence link.

Goal.

Association link.

Aggregation link.

 

原文：https://www.togaf-modeling.org/models/business-architecture/organization-decomposition-diagrams.html

本文：

讨论：请加入知识星球【首席架构师圈】或者小号【jiagoushi_pro】或者QQ群【11107777】

 

TOGAF 9.1元模型在图的中心有一个称为“业务服务”的框。经常有人问我:我们所说的“业务服务”是什么意思?查看规范和定义，我们发现以下定义:“通过显式定义的接口支持业务能力，并由组织显式治理。”

是的，我们知道业务能力可以帮助我们确定业务在一定粒度级别上需要哪些服务，以实现业务敏捷性，并由IT实现，但它并没有真正解释它的真正含义以及如何识别它们。业务能力完全符合这样一种概念:在面向服务体系结构(SOA)的意义上，服务是一个黑盒，其实现被封装在标准接口之后。

在规范的SOA部分，您还可以发现:

服务是具有指定产出的可重复业务活动的逻辑表示(例如，核对客户信用、提供天气数据、合并钻井报告等)，以及:

• 是独立的
• 可由其他业务服务组成
• 是服务消费者的“黑箱”

问题仍然存在……这些业务服务到底是什么，我们如何识别它们，正确的粒度级别是什么?

在ArchiMate 2.1中，我们也有一个可能更详细的定义:“业务流程、业务功能或业务交互可能用于实现业务服务”，但这并没有回答我们的问题:业务服务到底是什么?

潜在客户管理系统可能会实现许多业务服务(例如线索识别服务、潜在客户识别服务等)，这些业务服务将由销售人员访问(作为销售流程的一部分)。要访问面向服务的体系结构中的功能，只需要知道服务集(而不是底层应用程序/系统)。

业务服务的表示方式也更有利于业务。业务服务以“业务活动”的形式表征了独特的“业务行为元素”，由“特定角色”承担，共同支持特定的“业务目标”。

现在，TOGAF中的业务服务与ArchiMate和SOA服务中的业务服务相似吗?

从业务流程开始

作为起点，我们可以从由核心和非核心功能组成的流程景观来关注业务流程。这些流程通常可以在流程模型中称为流程级别的各种抽象级别上表示(例如，描述性、分析性/操作性和可执行性)。

然后可以使用自顶向下的方法从这些级别识别和提取业务服务。较高的抽象级别为组合业务服务提供输入，而较低的级别为细粒度的候选服务提供输入。这种对流程和业务服务候选者的关注还将有助于确定整个企业的功能冗余。

然而，这种方法的结果可能因组织的不同而有所不同。

业务服务以“业务活动”中独特的“业务行为元素”为特征，由“特定角色”承担，共同支持特定的“业务目标”。下面是一些业务服务的示例。两个是保险公司的，一个是银行的:

示例1保险

• ►业务能力
  • 客户合同管理
• ►业务目标
  • 确保优质客户合同
• ►业务活动
  • 创建客户契约
• ►业务功能
  • 合同管理
• ►业务流程
  • 合同管理流程
• ►业务角色
  • 合同专家
• ►业务服务
  • 客户合同创建

所有这些概念都可以链接到TOGAF元模型中描述的单个实体(方框)。

业务服务“客户契约创建”支持业务功能“契约管理”(并且是业务功能“客户契约管理”的一个组成部分，图中没有显示)。

在本例中，客户是内部的，因为“合同管理”功能是一个支持业务功能，它可能向保险公司的几个业务部门提供“客户合同创建”业务服务。有时，业务功能的客户可能是内部和外部的;它们可以被认为是共享的业务服务。业务服务与流程、信息、功能和人员相关。

例2保险公司

• ►业务能力
• 保险索赔管理
• ►业务目标
• 遵守保险单
• ►业务活动
• 接受保险索赔
• ►业务功能
• 索赔管理
• ►业务流程
• 索赔管理过程
• ►作用
• 保险索赔受体
• ►业务服务
• 保险索赔接受

与示例1一样，业务服务“保险索赔接受”支持业务功能“索赔管理”

示例3银行业务服务(与银行产品关联)

• ►银行产品
• 经常账户
• ■储蓄账户
• 透支账户
• ■信用卡账户
• 使用:
• ►业务服务
• 现金支取/存款

根据客户使用的银行通道，可能需要多个应用程序/系统组件:自动柜员机、Kiosk、网上银行、移动银行、分行银行

我在这三个示例中标识了以下业务服务:

客户合同创建

保险索赔接受

现金支取/存款

然而，这些合适吗?他们是正确的吗?这是正确的粒度级别吗?

服务模型

即使您选择的体系结构样式不是SOA，如果不考虑服务模型，您也无法真正地面对正确识别正确级别的业务服务的挑战。在过去的几年里，我们看到越来越多的业务服务实现为SOA服务，它们与软件功能直接相关。必须指出的是，其他社区，比如那些关注It服务管理(ITIL)的社区，也在寻求额外的清晰度。

该服务模型应该将业务服务与TOGAF的应用程序体系结构中的信息系统服务联系起来，然后与SOA和ITIL服务联系起来。

业务服务和SOA-ITIL服务是相关的，但是间接的。

SOA服务并不完全是业务服务，因为它通常是开发人员编写的一系列软件模式，用于提供信息、转换数据或进行一些计算。它是一个提供服务的组件，该服务公开隐藏内部实现技术的接口。它由三部分组成;实现要提供的服务的服务类、承载服务的主机环境以及客户机将连接到的一个或多个端点。

TOGAF定义的信息系统(IS)服务的解释是:“业务服务的自动化元素。信息系统服务可以交付或支持一个或多个业务服务的部分或全部“。一种可能的解释是，SOA服务继承自IS服务，SOA服务可以被归类为提供一个或多个结果(流程、访问、应用、信息、服务等等)。SOA参考体系结构可能是有益的，也应该加以考虑。

另一个要考虑的方面是ITIL服务;“IT服务是由信息技术、人员和流程组合而成的。面向客户的IT服务直接支持一个或多个客户的业务流程，应该在服务水平协议中定义其服务水平目标。其他IT服务(称为支持服务)不是由业务直接使用的，而是由服务提供者交付面向客户的服务所必需的”。我们还可以想象ITIL IT服务从相同的IS服务继承而来。

下面的模型说明了一种扩展TOGAF元模型的方法，以显示功能、流程、产品、业务服务、IS服务、SOA和ITIL服务之间的依赖关系。业务服务为特定流程组合人员、产品以及流程和技术资源。

SOA服务由部署的软件提供。ITIL(或IT)服务也由软件提供，这就是为什么我们还可以在不同级别的服务之下添加TOGAF体系结构域。

回到例1

• ►业务服务
  • 客户合同创建

我现在可以想象一个更完整的描述，包括:

• ►ITIL服务
  • 服务名称:合同管理服务(包括合同创建)
  • 服务描述:该服务向供应商(如承运人、港口、仓库等)提供报价和协议条件;管理采购和销售合同、知识产权许可证、内部协议等;自动化并加速整个契约生命周期，等等……
  • 支持时间：一至周五07:00 - 19:00
  • 可用性目标:99%
  • 备份
  • 服务所有者
  • 服务代表
  • 服务的重要程度
  • 等。
• ►SOA服务
  • 合同创建服务

SOA服务将是一个基于数据-应用-技术体系结构(最终)的软件，使用参考体系结构。这就是TOGAF架构域被添加到服务层次结构之下的原因。

ITIL IT服务属于一般类型，而不是SOA类型的服务。在IT服务和过多的SOA服务之间也可能存在关系。

从企业架构或ITSM的角度来看，业务服务被交付给客户，支持他们的需求，有时通过支持业务流程或直接支持交付给最终客户的服务或产品。

业务功能可以交付由一个或多个ITIL IT服务支持的业务服务，这些服务本身可能由SOA服务实现，也可能不实现(取决于对SOA体系结构的选择)。

这是一种有助于阐明如何集成这些不同类型的服务的方法(当然还有其他方法)，特别是对于TOGAF从业者。

感谢Ed Harrington复习了课文。

 

原文：http://sergethorn.blogspot.com/2014/08/business-services-what-are-they-really.html

本文：http://jiagoushi.pro/node/1231

讨论：请加入知识星球【首席架构师圈】或者小号【jiagoushi_pro】或者QQ群【11107777】

业务架构是最主要的架构；所有其他架构都可以从业务架构中派生出来，并且应该可以追溯到业务架构。

尽管任何模型都是对某些现实的抽象，但业务架构应该是业务术语中对现实最有形的表示。它为构建所有其他架构提供了业务规则和要求。该架构层维护与企业战略的联系，并使整个企业保持专注；通过这种方式，它为额外的业务改进和建立竞争优势的机会提供了极好的反馈机制。

业务架构定义了企业价值链（或流程流）及其与所有企业和外部业务实体的关系。它定义了企业必须生产什么以及如何生产以满足客户、在市场中竞争、与供应商打交道、维持运营和照顾员工。

这种业务架构可以用三个关键模型来描述；这三个模型通常可以互换使用来描述业务架构，但实际上却大不相同。它们提供了对业务的不同观点，有时相互重叠：

• 商业模式描述了企业业务的运作方式；它更关注公司、合作伙伴和客户之间的外部关系和互动
• 业务运营模型描述了业务中以及公司所有内部和组件之间的业务流程集成和数据标准化的必要水平；它更侧重于公司部门之间的内部关系和互动以及它们如何合作经营业务
• 能力模型描述了实施业务和运营模型所需的能力

公司的业务模型是其业务逻辑的简化表示，这意味着它描述了组织如何创造、交付和获取价值的基本原理；它定义了企业向客户交付价值、吸引客户为价值付费并将这些付款转化为利润的方式。

即使该术语用于广泛的描述以代表业务的核心方面（包括目的、产品、市场、客户……），但业务模型的本质是它描述了公司为客户提供的服务，它如何为客户提供服务。接触他们并与他们互动，通过哪些资源、活动和合作伙伴来实现这一目标，最后，它如何赚钱。

在业务模型的早期历史中，定义业务模型类型是非常典型的，但是，这些类型通常只描述业务的一个方面，通常只描述收入模型。因此，最近关于商业模式的文献集中于描述作为一个整体的商业模式而不是一个元素。受“商业模式画布”框架的启发，商业模式设计应包括对以下关键要素的描述：

• “目标客户群”元素定义了企业旨在接触和服务的不同人群或组织
• “价值主张”元素描述了为特定客户群创造价值的产品和服务包
• “分销渠道”元素描述了公司如何与客户群沟通并接触其客户群以提供价值主张
• “客户关系”元素描述了公司与特定客户细分价值配置建立的关系类型
• “关键资源”元素描述了使商业模式发挥作用所需的最重要的资产
• “关键活动”元素描述了公司必须做的最重要的事情才能使其商业模式发挥作用
• “关键合作伙伴”元素描述了使商业模式发挥作用的供应商和合作伙伴网络
• “收入流”元素代表公司从每个客户群中产生的现金
• “成本结构”元素描述了运营商业模式所产生的所有成本

商业模型的所有这些元素都应该在价值流或价值链中混合在一起，这些价值流或价值链描述了组织中允许创造价值的步骤序列，这部分将在运营模型中进行描述。

运营模型描述了您希望您的业务在内部如何运行； 它定义了实施业务模型所需的主要运营要素； 以及它们中的每一个如何根据子组件进行链接和进一步设计。 从这个意义上说，运营模式通常是由商业模式通知和派生的； 然而，在某些情况下，运营模式可以成为竞争优势的来源，并可以为商业模式提供信息。

运营模型将公司组织分解为其逻辑组件并描述组织如何开展业务，它说明了组织结构的关键领域、运营单位和贸易伙伴之间的关系，并为业务架构提供了一套指导方针 和技术基础设施，使公司能够发展其业务。

运营模式应该回答一些关于公司内部运营的运营问题，例如“组织结构是什么？”或“组织使用什么流程？”以及“角色和职责是什么？”试图突出运营模型框架的主要组成部分和关系，它们是：

• 人员组成部分，包括结构、组织、技能、知识文化、治理、奖励、采购和位置
• 支持基础设施和设施组件，包括物理资产、设施和位置、信息和数据资产、技术基础设施和应用程序（部分已在 IT 架构中进行了更详细的描述）
• 流程组件包括整体流程、输入、输出、问责制（谁做什么）、在哪里、如何、什么度量以及什么级别的一致性

能力建模是一种表示组织业务内部方面的技术，独立于组织的结构、流程、人员或领域；它描述了组织执行其业务模型或完成其使命所需的全套能力。

能力是公司为实现特定目的或结果而必须具备的特定能力或能力。从这个意义上说，能力将组织与人员及其与给定业务功能相关的角色、流程、程序和技术抽象并封装到一个简单的块中。

能力模型中的能力不同于操作模型中的流程；能力是企业为达到预期结果所做的“什么”，而流程描述的是“如何”完成。好处是能力模型随着时间的推移更加稳定，并且在同一部门内的业务之间也更加静态，因此更适合将 IT 架构固定在其上的业务设计组件。

区分能力模型和运营模型的业务能力的关键特征如下：

• 每项功能都是独一无二的且可重复使用。它是组织的基本要素，因此与其他能力明显不同。一种能力可能会应用于整个组织，并可能以不同的方式应用来影响不同的结果，但它仍然是一种单一的能力。
• 能力稳定。明确定义的能力很少改变；与项目、流程、应用程序甚至战略相比，它们提供了更稳定的组织视图。只有当潜在的商业模式或使命发生重大转变时，能力才会发生变化，这可能通过业务转型计划或与合并或收购相结合而发生。
• 能力是从组织模型中抽象出来的。能力模型不仅仅是企业组织模型的简单重述。它们在组织上是中立的，这意味着组织结构的变化不需要能力模型的变化。在简单的组织中，能力模型可能看起来类似于公司的组织结构，因为组织通常围绕通用技能构建，但更复杂的组织具有出现在多个职能组中的相同能力。
• 业务能力不会对如何通过 IT 系统或人工操作实现它施加任何限制。
• 能力模型是多层次的，但层次的数量因组织而异，这取决于模型的应用方式。几乎所有人都至少有两个级别，很少有超过五个级别，包含一些能力，在较低级别，范围从 10-50。

图 19 – 业务能力模型

在高层（从第 1 层到第 2 层），能力模型代表组织的 5-10 个主要通用能力，它们通常与高层过程模型重叠或与高层产品组重叠。 层次结构第 3 级以下的功能主要用于将模型连接到流程和技术。

从我的电子书中阅读有关此主题的更多信息……或继续关注新帖子。

原文：https://frankitecture.wordpress.com/2014/01/06/business-architecture-as…

本文：https://jiagoushi.pro/node/1760

近年来，我们看到业务架构的受众和关注度稳步提升。业务体系结构在其生态系统中提供了面向业务的企业抽象，这有助于组织进行决策和方向设置。这种业务架构学科的成熟使得基于模型的设计，分析和决策支持的作用也变得越来越重要。在本系列文章中，我们将向您介绍业务架构建模的有用技术以及BiZZdesign Enterprise Studio如何支持它们。

对业务架构的看法

业务架构学科已经开发了自己的方法和知识体系，例如Business ArchitectureGuild®和开放式业务架构（O-BA）标准中的“业务架构知识体系指南”（BIZBOK®指南）。目前正由The Open Group开发。

我们认为业务架构是企业架构更广泛范围内的重要领域。在ArchiMate语言的最新版本3.0中包含业务架构概念（如功能，结果和行动方案），以用于企业架构建模，也可以看到这一点。其他人则采用更加面向IT的企业架构视图，将其视为企业级IT架构，并将业务架构置于其旁边，作为一个单独的学科。第三组将业务和企业架构视为同义词。

但无论您在本次辩论中的立场如何，该领域中使用的技术都是您可以在设计和管理企业时使用的工具箱的重要补充。这种独立于实现和技术的视图提供了战略与实现之间的关键联系：它将组织战略和业务模型的常常相当高级，粗粒度的描述与EA中更多以细节和技术为导向的其他域相关联。范围，例如业务流程，应用程序和基础架构体系结构。

业务架构域

业务体系结构所关注的典型域或方面如下图所示。该中心包含一组四个“核心”域，代表业务的相对稳定的方面，以及其他一些更不稳定的方面。基本上，所有这些都可以在Enterprise Studio中直接或间接表示。

该图未显示所有这些域以各种方式相互关联。 BIZBOK®指南通过代表企业某些方面的蓝图（“交叉映射”）将它们联系起来。我们更喜欢使用形式语义在一个方面的每个实例之间建立直接关系。这是ArchiMate可以提供帮助的地方。要做到这一点，BIZBOK®概念和ArchiMate概念之间需要一个映射元模型。稍后在本系列博客中，我们将讨论如何创建这样的元模型。

业务架构和其他领域

业务架构的关键输入是组织的战略和业务模型。例如，投资组合管理，风险分析和基于能力的计划支持业务架构中的分析和决策。

商业架构中的其他常用设计技术包括描述其价值网络和价值流，开发和改进客户旅程以及创建服务蓝图等。

9种有用的业务架构技术

BIZBOK®描述了一组常用且有用的业务架构建模技术。在之前的博客中，我们已经展示了如何在Enterprise Studio中创建其中的一些。对于其他人，我们将在本系列的未来博客中提供示例：

• 业务战略映射：请参阅以前有关业务模型画布和策略建模的博客
• 能力映射：参见以前关于能力映射，分析和实现的博客
• 价值映射：请参阅我们关于建模价值网络和价值流的博客
• 组织映射
• 信息映射
• 倡议制图
• 产品图谱
• 利益相关者映射
• 策略映射

在接下来的几周内，我们将向您展示如何创建其他业务架构图并使用这些模型为您的企业指明方向。我们还将重新审视ArchiMate 3.0中关于价值流建模的想法，并讨论我们如何认为语言可以发展以为此提供最佳支持。

如果您迫不及待地想了解更多有关BIZBOK®及其实际用途的信息，您可以随时注册我们的实践业务架构课程，并成为认证业务架构师®！

敬请关注！

原文：https://bizzdesign.com/blog/the-business-architects-toolbox-an-introduction/

本文：http://pub.intelligentx.net/business-architecture-business-architects-toolbox-introduction

讨论:请加入知识星球【首席架构师圈】

 

我不止一次被告知，企业架构 (EA) 是在浪费时间。老板、客户、同事和开发人员都告诉过我。我可以理解有些人不了解架构在公司中所扮演的角色——尤其是商务人士。但是，当 CTO 或 CIO 告诉您这一点时，您不得不想知道他们是如何成为他们的职位的？他们是主人的侄女还是侄子？他们对 CEO 保密吗？也许他们只是看起来的一部分。他们显然不是从他们的智慧和能力中得到的。

EA 是大规模的批判性思维。这是连接战略和战术细节之间的点的做法。它是通过技术为企业定义未来之路的艺术。

许多 IT C 级人员不了解 EA 是什么。他们将其视为企业级的解决方案架构——当您查看专注于提供解决方案的企业架构师的职位发布时，这一点很明显。 EA 的角色实际上比这更广泛，并且具有更显着的影响。 EA 做的是平凡的事，例如记录和维护架构状态。 EA 做了必要的事情，例如围绕技术建立协议和治理。 EA 做的很强大，比如将技术的执行与公司战略保持一致。

遵循开放组架构框架 (TOGAF)，EA 拥有多个领域，包括业务、应用程序（包括数据）和技术（服务器、网络和其他可部署项目）。其中，应用程序和技术架构是最著名的。然而，业务架构通常没有在许多组织中实施。这是一种耻辱，因为它是 EA 的重要组成部分——它使技术得以实施以实施企业战略。

TOGAF 及其架构开发方法 (ADM) 从业务架构开始。这是您定义业务架构的地方，从组织模型到角色再到业务流程。有人可能会说这是业务领域，而不是 IT。这并没有错。可能 EA 不应该完全是 IT 的一部分，而是向 CEO 或 COO 报告。 EA 是一种协作努力。它可能没有定义组织结构或业务流程的责任，但它需要记录组织及其流程。它还可能带来可用于帮助定义业务架构的结构化方法。 EA 可以为业务架构带来的一些特定服务包括：

• 维护企业架构存储库 (EAR) — EAR 是跨架构域的所有 EA 数据的中央存储库。理想情况下，这是一个以数据为中心的存储库，而不是以文档为中心。这允许查询存储库的能力，允许可追溯性和报告。
• 提供战略调整服务——战略调整可以通过多种方式实现。它可以包括执行战略分析或采用已定义的战略和定义能力路线图。能力是企业拥有或渴望的已定义能力。它被规划为战略。例如，一种能力可能是在定义的时间段内快速实现新店面的投资回报 (ROI)。它是通过将其放入时间线来绘制的，通常不超过未来 18 到 24 个月。
• 定义和记录业务流程——业务流程应该从对业务流程进行编目开始，然后继续详细说明业务流程。一种众所周知且广泛使用的格式是业务流程模型和表示法 (BPMN)。该符号应标识业务流程中的步骤、流程中涉及的角色以及流程中涉及的应用程序。理想情况下，BPMN 可以作为数据存储在 EAR 中（而不是作为文档）。

这些前面的项目是 EA 主要规划工具的输入：

• 制定技术路线图——技术路线图为 IT 组织提供了前进的道路。它定义了 IT 需要在何时何地采取行动以执行该战略。

该服务提供了业务和技术之间的关键链接。如前所述，三个输入包括 EAR、业务流程定义和战略调整服务。 EAR 提供了当前的架构状态——没有它你不知道需要改变什么。业务流程定义定义了需要进行的战术更改——当前和未来状态定义，其中包括定义角色的更改以及业务流程中涉及的系统。

在战略协调功能中，利用能力路线图，将战略带入画面，确保战略与技术执行之间的协调。 EA 制定技术路线图，确保技术到位以实现功能。例如，利用上面定义的能力示例，计算投资回报率的数据需要可用。这包括开发 BI 系统、数据集成和其他技术来报告投资回报。

基于能力路线图开发技术路线图还解决了组织中的另一个常见问题：对战术特性的关注。开发资源是有限的。产品团队与业务部门合作，他们通常对业务需求做出反应。一些产品组织实施精益价值树或其他可以将特性与战略相关联的方法。但是能力和技术路线图为分析增加了一层时间，这对于战略的执行至关重要。精益价值树还依赖于“赌注”以及使命和战略目标。赌注依赖于质量可能参差不齐的假设。虽然这很有价值，但我发现这种分析方法缺乏知识纪律。

Alignment of business strategy and technical execution through roadmaps.

 

另一方面，能力和技术路线图的方法更加严格。战略映射到能力路线图，这映射到技术路线图。然而，能力路线图一旦被定义就不是静态的。技术路线图调整并向能力路线图提供反馈。例如，在制定技术路线图时，可能会发现一项技术需要 18 个月才能到位，而能力被定义为在 12 个月内到位。能力需要调整。这可能就像将功能推出六个月一样简单，也可能将功能分解为更小的组件。

还有其他输入——预算、组织模型、业务合作伙伴能力、技术之间的依赖关系和关系都是路线图中的元素。另一个重要因素是战略本身。 EA 可以在制定策略中发挥作用，尽管这并不常见。 EA 有执行战略开发的工具，特别是我喜欢 Archimate 3.1 战略和动机元素，它映射资源（资产）、能力、价值流和行动方案。这是另一篇文章的主题。

最终，企业架构在与业务相关时提供了最大的价值。但是当它嵌入到 IT 中时，它是如何做到的呢？在我看来，有两条路。一是提拔EA向CEO或COO汇报。在具有强大层次结构的企业中，这可能是有益的，但在更敏捷的组织中，这可能无济于事。在这种情况下，第二种方法可能会更好。将 EA 定义为跨组织实体可能是更好的方法。业务架构师不需要放置在 IT 内部。他们可以在产品管理、各个业务部门、向 C 级甚至财务部门报告。我相信后一种方法是 EA 的未来。它更符合协作、敏捷的方法。

与解决方案架构不同，E​​A 的范围更广，并且在支持业务和技术领域的战略执行方面提供了巨大的价值。许多技术主管没有看到其中的价值，因为他们喜欢做主。他们自己的狂妄自大影响了他们对结构化分析价值的认识——他们继续使用启发式和其他非结构化决策工具，这些工具既能带来好处，也能带来好处。

企业架构带来了结构和组织，在战略和执行之间划出了清晰的界线。战略和执行都很重要，尽管战略执行将两者联系起来对于成功至关重要。这并不总是万无一失的——事情会发生变化（例如 Covid-19 大流行等商业环境发生无法控制的变化）。但是，结构化的方法比靠猜测和愚蠢的方法更有效。 EA 职能将战略与执行的映射作为首要关注点，并通过这些努力为组织提供重要价值。

原文：https://www.naviger.com/business-architecture-the-missing-art-science-o…

本文：https://jiagoushi.pro/business-architecture-missing-artscience-path-str…

 

什么是业务能力热图?

业务能力热图是创建引人注目和丰富多彩的视图的重要工件，它在突出显示和向高级管理人员展示有关业务能力和上下文的基本考虑方面是有价值的工件。在基础级别上，业务能力热图是一个具有X和Y轴以及填充分数的行和列的交点的二维图表。有时，人们可能使用三或四维—例如，气泡图，它可能包括传统的X和Y轴，然后气泡的大小来表示体积尺寸，颜色来表示状态或状态。

热图与业务架构领域有什么关系?

如果你是一名业务架构师、业务分析师或企业架构师，那么你理应创建并展示业务能力热图。大多数业务架构师确实开发了几个热点图。

业务架构热图包括对不同的信息实体和资产进行并列，以分析覆盖范围、足迹、影响和指标。

但是，什么是热图?

所以，先做重要的事。科马克·金尼在机构证券交易中创造了“热图”这个术语。

Wikipedia将热图定义为数据的图形表示，其中矩阵中包含的单个值用颜色表示。分形图和树形图通常都使用类似的颜色编码系统来描述层次结构中变量所取的值。

什么是业务能力热图?

首先，为了确定，让我们就什么是业务能力的定义达成一致。能力就是企业所做的事情。业务能力热图是使用业务能力的地方，业务能力被分解成粒度级的细节，以捕获业务所做的本质，并将它们与各种评估参数并置，生成一个视觉工件，显示一系列的值，通常用不同的颜色表示。这里有一篇概念/理论论文供有学术倾向的同学参考。

是否有业务功能热图列表?

一个人可以生成什么样的业务能力类型的热图是没有限制的。下面只是几个例子。

能力评估热图:

人们可以从多个维度评估能力，例如战略重要性、成熟度、技术支持、资源充分性等。

示例能力热图:能力到策略的映射

大多数公司都在努力使执行与战略保持一致，而能力是弥合战略与执行之间差距的好方法。

基于能力的供应商评估热图:

当您考虑系统实现时(购买或构建;替换的或初始的)，您可以使用您在系统中需要的功能，将其分解到较低的粒度级别，并让您考虑的供应商创建一个热图。评估参数可以是功能、可用性、部署选项等，并对供应商进行规模评估，从而创建供应商评估热图。

基于能力的供应商评估样本热图:

基于能力的合并分析热图:

显示收购方和被收购方之间的各种能力状态的热图

首先，两个组织都应该有详细的业务能力图，并且不仅要对能力成熟度、重要性和相关因素进行评估，还要评估底层的过程和系统/应用程序。

一旦个人能力和相关实体评估完成，接下来就是能力和底层过程和应用程序的相对评分。

因此，举例来说，在客户关系管理方面，两家公司的客户关系管理能力可能排名相对接近。但是，如果其中一个CRM系统在架构上优于另一个系统——一个多云SAAS CRM(软件即服务客户关系管理)平台——那么它可能会使天平偏向更高级的平台。

另一个例子是，特定能力的目标状态可以根据其发展和满足未来需求的能力来决定选择哪个能力和相关资产。

基于能力的分析和热点图在合并前的目标分析以及合并后的整合和能力合理化中是有用的。

基于能力的影响评估和优先级划分热图:

如果你将业务能力和铁砧上的项目的状态三角化，并根据它们弥补差距和发展能力的能力进行评分，它将使你的支出与优先级保持一致。

应用程序/IT服务功能热图:

功能是一个抽象，由功能、数据和应用程序/系统实现。将功能与各种应用程序/系统联系起来的热图将有助于分析内存占用、碎片和重叠。

要创建此热图，您将需要业务功能的清单和底层功能的概要。然后，您将需要一个SOA服务或应用程序或微服务(如果您有一个混合的IT景观，则可以是它们的组合)及其支持的功能列表。

有了这两组信息之后，在行中并列功能，在列中并列服务/应用程序，并并列功能占用空间。您可以使用诸如“实质性的”“适度的”“部分的”“可以忽略的”这样的术语来表示每个服务/应用程序对功能的支持水平。

如何构建热图?

创建全面的热图超出了本文的范围，但是这里有一些构建热图的优秀资源。

一些业务能力热图是基于特定的环境触发的——例如并购事件或供应商评估。其他许多热图可能是周期性的，最好是年度的，这样就有连续性，并允许用户生成一个连续的年比分析。

如何构建业务能力热图?

首先，我们假设您有一个经过良好构思和验证的能力模型。根据您想要生成的热图类型，编译一个类别、参数和评分值的列表。分配不同的颜色来表示评分值。然后是实际的评分——不管是使用德尔菲(Delphi)方法进行一次评分并达成一致意见，还是多个评估者对相同的能力进行评分并得出相同的或加权的平均值——来生成热图。

谁是业务能力热图的受众?

也许，应该首先问这个问题，并且业务能力热图应该针对所述的受众进行剪裁。执行观众将对概要概述、累计评分值、前10名和后10名类型表示感兴趣。操作层的人员——业务架构师、企业架构师、解决方案架构师、IT经理、产品所有者——希望了解细节，比如相互关系、个人评分和进行假设分析的能力。

Capstera如何帮助业务能力热图?

Capstera提供了一个名为lens的电子表格类型界面。注册用户可以利用现有的功能模型和预生成的模板来创建业务功能热图。当然，用户还可以创造新的镜片。用户可以定义或自定义类别、参数、评分值和显示方法。最后但并非最不重要的是，这些可以导出到Excel进行进一步的分析。

• CUNY has detailed tutorials on heat maps in Excel
• Lynda.com offers a tutorial. (Note: It may involve registration)
• Chandoo.org provides a free tutorial.

原文：https://www.capstera.com/business-capability-heatmaps/

本文：http://jiagoushi.pro/node/1230

讨论：请加入知识星球【首席架构师圈】或者小号【jiagoushi_pro】或者QQ群【11107777】

• 应用业务功能的第一个也是最常见的用例是提供一个通用的、易于理解的和整体的组织视图，可用于将 IT 组件（例如应用程序、数据或技术）映射到它。了解应用层、数据层和技术层的现状和未来前景是企业架构管理的核心。业务能力可以是位于业务层中的链接元素，IT 可以将组件映射到该元素，并且该业务能够轻松理解。

在开始景观评估之前，清楚地了解您在收集数据后想要对数据做什么（以及您实际想要详细评估的内容）、您希望如何存储、共享它以及如何它应该随着时间的推移进行管理和更新。

• 此用例要求项目确定它们支持的业务能力，并在需求和项目组合流程开始之前集中收集结果。这还要求为整个组织制定业务能力图，并指示每个能力的战略相关性。这可以通过分解现有的业务策略并了解这些策略的实际含义来完成。

考虑这个例子：如果您的公司想要增加数字销售，您的电子商务能力可能具有很高的战略相关性。如果您的组织为此用例收集数据，它将能够基于基础项目显示业务能力的战略重要性——这取决于它们启用的功能。由此产生的分析可能有助于决定是否应该资助一个项目。

• 一个非常流行的用例是支持组织的需求管理流程。不幸的是，它也是最难实施的一种。为了在能力的帮助下为需求管理流程增加价值，您需要有一个详细的能力图，以及映射到它的环境的非常好的原样透明度。您的 As-Is 环境可能包括应用程序及其功能、系统和支持的技术，甚至是现成的解决方案包。

如果您收集所有这些信息，您可以将传入的需求（例如业务绘制的用户旅程）映射到业务能力，并确定您是否已经在地图中拥有该能力。如果它已经存在，您可以分析映射到它的 IT 组件。您还可以评估它们是否适合满足所描述的需求，或者您是否真的需要开发新的东西。此练习的结果很可能会减少一组功能，因此需要从头开始开发或购买的功能，同时您可以最大限度地重用现有 IT 组件，从而降低成本和所需资源，通过以下方式增强稳定性经过测试的组件，并缩短上市时间。

然而，这种方法通常停留在理论上，因为它不能应用于大型应用程序的领域，不能分离成它的单一功能。因此，他们不允许将其中的单个部分用于新的需求。此外，对现状的描述通常不够详细，无法采用这种方法，因此需要大量的前期工作。

一些组织有数千个应用程序。根据他们启用的业务能力应用业务能力对它们进行集群，这使得优化应用程序环境变得更加容易。目标是拥有这样一个细粒度的业务能力映射，不超过 5 到 10 个应用程序映射到一个业务能力。

这允许每个业务能力集群相互独立地分析应用程序。例如，这可以通过应用时间分析来完成，该分析评估每个应用程序的业务匹配度和 IT 匹配度，并将其分配到矩阵中。业务匹配可能是业务增值、业务关键性、用户数量、部门、使用应用程序的国家或分配收入的结果。 IT 契合度可能是底层技术支持、应用程序安全性、源代码可用性、响应时间、问题等的结果。您可以考虑许多指标，您应该评估您的组织可以评估哪些指标并且对你的目标很有帮助。

如果您将业务适合度放在 x 轴上，将 IT 适合度放在 y 轴上，您将创建以下象限：

• 左上角，容忍：这些应用程序的业务契合度较低，但它们的 IT 契合度很高。因此，您可以将它们保留在您的组织中，因为它们不会造成任何伤害。
• 右上，投资：这些应用程序具有高度的业务适合度和高度的 IT 适合度。您应该进一步加强它们并进一步投资它们，因为它们是您应用程序的最佳类别。
• 右下角，迁移：这些应用程序具有很高的业务适合度，但 IT 适合度较低。您可能需要它们的功能，但底层技术并不是最优的。您应该考虑更换提供商、迁移到新服务器或做其他事情来增强他们的 IT 匹配度。
• 左下角，消除：这些应用程序的业务契合度和 IT 契合度都较低。您不需要这些应用程序，它们也没有合适的 IT 基础。对它们而言，最好的选择是消除它们以减少应用程序的数量并降低成本。

原文：https://digitalroadmap-management.medium.com/top-5-use-cases-for-busine…

本文：https://jiagoushi.pro/top-5-use-cases-business-capabilities-transform-o…

为什么我们需要为价值实现而烦恼？

实现您决定投资新功能和支持它们的技术所依据的业务案例不会自动发生。商业案例、您的愿景和期望的结果是制定投资策略的关键输入。通常，组织从获得赞助和阐明最终目标的正确意图开始。这将移交给项目团队以实施解决方案。项目团队的主要关注点是按照商定的进度、成本和质量交付功能，而不是交付收益和业务成果。有许多共同的挑战和风险导致无法实现愿景和商业利益。一些例子包括：

1. 组织没有计划有效的业务变革活动，导致运营准备不足，无法采用新的工作方式；
2. 最终用户通常不会采用新流程；使用变通方法而不是接受新的工具/方法；
3. 治理、沟通和控制不力会影响价值的采用和实现；
4. 未利用解决方案能力时无法实现运营效率；流程、角色和解决方案错位；
5. 缺乏与解决方案提供商的合作以利用他们的经验和良好实践。

为确保您的项目实现业务案例中概述的更多收益和价值，您需要坚定地关注价值实现。既然您知道为什么价值实现对您的技术投资的成功至关重要，本博客将探讨在您的公司实现更大价值的“内容”和“方式”。

需要做些什么来支持实现您的投资价值？

如您所知，管理与您的技术投资相一致的目标的实现将取决于几个关键要素以获得成功：定义具有明确目标的成功标准、针对明确定义的方法的具体和有意识的执行、衡量的方法成就，监测结果，并采取适当的措施来解决偏差。这必须通过有效的治理结构来加强，该结构将促进和协调利益相关者，以支持与共同业务目标的一致性。

有效治理的关键方面是做出正确决策并在需要时上报的能力。这需要有一个绩效管理系统来支持收益的衡量和监控。毕竟，如果你不能衡量，你就无法管理，如果你不管理，你就不会实现。

您的绩效管理方法需要灵活，以根据利益相关者分组解决不同的收益结果。在运营层面，重点应放在所提供服务的效率上。在业务层面，重点应该放在有效性上。在战略层面，重点应该支持不断变化的业务优先级。也就是说，以下是对企业需要考虑的重要指标示例：

• 效率（Efficiency）。这将衡量生产力。这是关于用更少的资源做同样的事情，从而使多余的资源可以释放或转移到其他增值活动中。
• 效力（Effectiveness）。这将衡量服务质量和用户体验。它是关于通过做得比以前更好的工作来使资源更有效。
• 战略（Strategic）。这将衡量机会和敏捷性的增长和利用以及支持不断变化的业务优先级的灵活性。

以下是支持组织所有层级的结果管理和报告所需的决策示例。

Figure 1: Performance Management is informed by the decisions around the questions represented in the above figure.

既然已经清楚了价值实现的内容和信息以及衡量重要的不同级别的指标，接下来让我们来看看如何将其整合到价值实现和关键成果的计划中。

我们如何规划价值和成果的实现？

管理价值的实现需要全面和整体的方法。 这应该包括规划您的投资以及管理和实施新功能，以持续监控和验证您的目标成果和价值的实现情况。 确保投资的可持续性同样重要，这意味着管理未来的需求并推动持续的服务改进活动。 下面的图 2 概述了 BMC 帮助客户实现其投资决策的目标和目的的方法。

Figure 2: BMC’s value realization and business change activities alignment

BMC 实现价值的综合方法有助于管理业务变化，并与技术能力的支持相结合。这需要确定实现目标和实现愿景的关键成功因素。这些通常基于三个重要标准：提高生产力、提供更优质的服务和增强用户体验。要开始在这些重要标准上取得进展，首先确定受影响的利益相关者并制定管理期望和采用的沟通策略。接下来，确定并纳入将成为整体项目计划一部分的业务变革活动。例如，这些可能与流程优化、增强员工能力或加强治理和控制有关。此外，您将需要概述收益、指标、基线数据、收益所有者、目标和依赖关系，并将它们与计划时间表保持一致。最后，您将需要衡量和监控结果以及识别偏差。当发现偏差时，采取行动定义必要的缓解步骤以解决未实现目标结果的潜在风险至关重要。

这些活动必须得到有效的绩效管理系统的支持，该系统可以报告结果、监控绩效并管理未能实现和实现投资价值和结果的风险。这需要实施一个流程来管理需求和持续改进服务，以确保业务一致性。所有这一切都必须以有效的治理和控制制度为基础，协调各种利益相关者，以应对变革的潜在阻力并实现预期的结果和价值。

正如您从上述原因、内容和方式中所看到的那样，价值实现需要有效的治理、绩效管理以及对进展和缓解措施的一致沟通，以保持在正轨上。随着您的技术投资的收益和成果的成功实现及其对实现业务优先级的贡献，这将增加业务社区对 IT 的信心和可信度。此外，它将在正确的治理和监督水平下真正实现的目标方面提供对投资决策的更好理解和证明。价值实现活动将增加解决方案的采用和开发。它还将最大限度地减少定制需求，从而采用可降低拥有成本并更好地与技术供应商的产品路线图保持一致的良好实践。此外，上述价值实现活动将支持关键的 ITIL 4 原则，以支持服务价值系统 (SVS)，该系统包含通过产品和服务创造价值的端到端生态系统，并包含支持灵活的运营结构。

如果您在开发与您的技术投资相一致的价值实现方法方面需要帮助，请填写我们的表格，BMC 客户成功专家将与您联系以开始使用。

原文：https://www.bmc.com/blogs/why-what-how-to-realize-value-from-your-techn…

本文：https://jiagoushi.pro/node/2124

BPMN允许我们以清晰和一致的方式捕获和记录组织的业务流程，从而确保相关的涉众，例如流程所有者和业务用户参与到流程中。因此，团队可以更有效地响应流程中确定的任何问题。BPMN提供了全面而丰富的表示法，这些表示法很容易被技术和非技术涉众理解。

以下是BPMN提供的好处:

• 一个由OMG联盟(一个非盈利的行业组织)开发的行业标准
• 通过业务流程图为业务提供定义和理解其过程的能力
• 提供一个容易被所有业务涉众理解的标准符号
• 弥补业务流程设计和实现之间经常出现的沟通鸿沟
• 简单易学，但功能强大，足以描述业务流程的潜在复杂性
• 供应商中立与广泛的工具支持

本文分为四个部分，旨在介绍业务流程模型和符号(BPMN)。将描述BPMN符号的基础——即组成符号的图形对象的类型，以及它们作为业务流程图的一部分如何一起工作。它还演示了如何使用可视化范例创建和绘制BPMN图。

基本构造

BPMN元素有五个基本类别。它们中的每一个都代表了业务流程的一个独特方面。

泳道

泳道是表示流程参与者的图形化容器。游泳池和泳道是两种泳道，我们将在本教程的第二部分详细讨论它们。

流元素

流元素是相互连接以形成业务工作流的元素。流元素是定义流程行为的主要元素。有三种流元素:事件、活动和网关。我们将在本教程的第三部分中讨论它们。

连接对象

流对象不是孤立的，而是为了形成流而连接的。连接流对象的连接器称为连接对象。有四种类型的连接对象:序列流、消息流、关联和数据关联。我们将在本教程的第三部分中讨论它们。

数据

数据主要是在执行业务流程时需要或产生的信息。数据有四种:数据对象、数据输入、数据输出和数据存储。我们将在本教程的第四部分讨论它们。

工件

构件提供关于业务流程的附加信息。我们将在本教程的第四部分讨论两种工件，组和文本注释。

介绍BPMN的其他部分

• 第二部分-泳道
• 第三部分-流程和连接对象
• 第四部分—数据和工件

本教程的读者也可以阅读

• 什么是数据流程图(DFD)?如何绘制DFD?
• 如何编写有效的用例?
• 数据流程图:实例-订餐系统
• 如何使用ERD对关系数据库设计建模?
• 如何开发现有的和将来的业务流程?

 

原文：https://www.visual-paradigm.com/tutorials/bpmn1.jsp

本文：http://jiagoushi.pro/node/865

讨论：请加入知识星球【首席架构师群】或者飞聊小组【首席架构师智库】

游泳池里有专门为游泳者设计的泳道。游泳的人有自己的泳道，不用穿过另一条泳道。泳道的概念也存在于BPMN中。

BPMN中的泳道对象(也称为泳道)是表示业务流程参与者的矩形框。泳道可能包含由该泳道(参与者)执行的流对象，除了必须有一个空体的黑盒子(我们将在本教程的后面讨论黑盒子)。泳道可以水平排列，也可以垂直排列。它们在语义上是相同的，只是表示不同。对于水平泳道，流程从左到右流动，而垂直泳道中的流程从上到下流动。泳道的例子包括客户、客户部门、支付网关和开发团队。

有两种泳道:游泳池和泳道。

池（Pools）

池代表业务流程中的参与者。它可以是一个特定的实体(如部门)或一个角色(如助理经理、医生、学生、供应商)。

在池中，有流元素。它们表示在建模的流程下池需要执行的工作。但是，有一种池根本没有内容。它被称为黑箱池。黑盒池通常用于对业务流程外部的实体进行建模。由于它是外部的，它的内部流对所建模的流程没有任何影响，因此可以跳过它，从而产生一个黑盒。下面的BPD(业务流程图)给出了一个黑盒池的示例。客户是一个黑箱。由于这个过程关注的是厨师如何准备一顿饭，顾客做什么与这个过程无关。黑盒的使用取决于进程所采用的透视图。如果您需要对客户如何下订单的流程建模，那么将对客户流程建模，从而使Chef pool成为一个黑箱。

游道（Lanes）

lane是池的子分区。例如，当您有一个池部门时，您可以将部门主管和普通职员作为泳道。与池一样，您可以使用lane来表示流程中涉及的特定实体或角色。

当需要时，泳道可以包含其他泳道以形成嵌套结构。然而，BPMN主要帮助您对业务流程进行建模。不要仅仅为了对组织的结构建模而构建嵌套的通道。如果您想对组织结构建模，那么可以使用组织结构图。

案例研究-真正的水蒸馏水公司

真正的水蒸馏水公司是一个年轻的蒸馏水供应商在城市。他们出售蒸馏水供商业和家庭使用。现在，True Aqua蒸馏水公司希望在未来的12-18个月内将他们的市场份额从5%提高到10%。为了实现这一目标，他们正在努力寻找提高运营效率和满足更高水平的客户满意度的方法。

因此，True Aqua蒸馏水公司决定改进他们的蒸馏水订购流程。现在，您是负责这项任务的业务分析师。在与True Aqua蒸馏水公司会面后，您已经收集了以下关于订购过程的信息。让我们来看看。

客户可以拨打订购热线，也可以通过电子邮件订购蒸馏水。目前，90%的订单来自电话，10%来自电子邮件。接收订单的客户服务助理将检查客户是现有客户还是新客户。如果客户以前从未下过订单，客户服务助理将在处理订单之前为他或她创建一个客户帐户。

蒸馏水的运送每周一次，每周三进行。所以，每周三上午，客服助理都会将订单转发给物流部门进行配送。当物流部经理收到订单后，他会安排送货，安排工人管理不同的订单，打印和邮寄时间表。工人接电话，然后把水送到客户那里。

现在，您需要使用BPMN在BPD中对流程建模。在本节中，将指导您完成在BPD中创建必要泳道的步骤。本教程的下一部分将描述流程流的建模。

• 通过从应用程序工具栏中选择project > new来创建一个新项目。在“新建项目”窗口中，单击“创建空白项目”。
• 从应用程序工具栏中选择diagram > new，创建一个新的业务流程图。
• 在New Diagram窗口中，选择Business Process Diagram并单击Next。

• 输入蒸馏水订单流程作为图表名称，然后单击OK以创建图表。您将看到下面的窗口。

以下是用户界面不同部分的描述:

Application toolbar	The application toolbar provides you with accesses to various operations in Visual Paradigm.
2	Diagram Editor	The area where you edit your diagram.

• 通过阅读从用户收集的订购流程的细节,你理解了客户和真正的Aqua蒸馏水公司之间的合作,需要能够识别以下实体建模的桶,它们参与流程:客户、客户服务助理,物流部门经理(物流部)和工人(物流部)。您应该使用BPMN池和泳道对它们进行建模。让我们首先创建客户池。在关系图工具栏中选择水平池。

• 单击BPD(在关系图编辑器中)来创建一个池。输入Customer作为池名称，然后按Enter确认。

注意，一个池水平地扩展了整个图表的长度。

• 您可以为客户服务助理和物流部门创建单独的池。但是为了突出他们是在同一家公司下的事实，最好是为真正的Aqua蒸馏水公司建一个游泳池，让客服助理和后勤部门成为游泳池的泳道。在Customer下面创建一个池。将这个游泳池命名为“真正的Aqua蒸馏水公司”。

• 让我们创建车道。右击池中真正的Aqua蒸馏水公司，并从弹出菜单中选择Add Lane。

• 输入客户服务助理的姓名。按回车确认。
• 创建客户服务助理通道下面的物流部门通道。右击客户服务助理并从弹出菜单中选择后插入通道。

• 输入物流部门的名称。按回车确认。
• 车道太宽了。让我们调整。按下lane边框并向上拖动以调整lane客户服务助理的大小。若要调整第二条泳道的大小，请按下池底的边框并向上拖动。

• 到目前为止，图表应该是这样的:

• 在物流部门内部，有两个实体参与这个过程。他们是经理和工人。由于这个原因，您应该在lane物流部门内部创建它们作为嵌套的lane。右键单击lane后勤部门并从弹出菜单中选择Add Child lane。

• 输入Manager作为名称。按回车确认。
• 右击lane Manager并从弹出菜单中选择Insert lane After。
• 输入Worker作为名称。按回车确认。到目前为止，你的BPD应该是这样的:

介绍BPMN的其他部分

• 第一部分—BPMN简介
• 第三部分-流程和连接对象
• 第四部分—数据和工件

资源

• 真正的水蒸馏水公司-第二部分。vpp(此部分已完成)
• 本教程的读者也可以阅读
• 什么是数据流程图(DFD)?如何绘制DFD?
• 如何编写有效的用例?
• 数据流程图:实例-订餐系统
• 如何使用ERD对关系数据库设计建模?
• 如何开发现有的和将来的业务流程?

 

原文：https://www.visual-paradigm.com/tutorials/bpmn2.jsp

本文：http://jiagoushi.pro/node/866

讨论：请加入知识星球【首席架构师圈】或者飞聊小组【首席架构师智库】

作为销售和营销人员，“价值主张”的概念已成为我们在市场和客户中定位的基础。显然，价值主张的概念可以追溯到麦肯锡 1988 年的一篇论文，以及诺顿和卡普兰在 90 年代初的工作（我对此感到惊讶，我认为这个概念比这早了几年。）

但价值主张几乎已成为我们在推销产品和公司时谈论的另一个特征。花点时间，搜索您的网站和您的竞争对手的网站。不可避免地，您会发现“价值主张”与您的产品的所有其他功能和优势一起被吹捧。它会自豪地展示在你的产品页面上，它会在你的公司页面上大肆宣传，它可能是主页上的标题。

几年前，我被要求做一个关于价值主张的主题演讲。我的第一张幻灯片是来自客户网站的价值主张。他们都为自己的定位鼓掌欢呼。接下来的几张幻灯片是他们的前 5 名竞争对手的价值主张。他们都一样——每个人都解决了客户问题，每个人都为客户推动增长和差异化，每个人都降低了成本并提高了盈利能力，每个人都比竞争对手好得多，与众不同——每个人都是一样的…………。 .

嗯，我认为价值主张应该是差异化的......

另一件事是他们全都关注公司、他们的产品、服务以及他们有多棒。他们只是与客户间接相关。

那没有改变……

随着时间的推移，我们开始围绕价值扩展我们的概念。我们开始意识到“价值在旁观者的眼中”。我们开始谈论价值定位，即：“您可以期望得到这些结果(results )和结果(outcomes)……” 价值定位是客户在实施解决方案时可以期望的定量和定性结果的组合。它成为证明解决方案合理性的商业案例。

在价值定位方面，我们采用标准的“亲爱的居住者或当前居民”价值主张，并开始根据客户的具体情况对其进行定制。我们进行发现以了解我们可以在哪些方面提供帮助、具体影响可能是什么，并将其呈现给客户。

在某些情况下，我们也开始将我们的价值定位与价值实现联系起来。这是事后评估，“你真的得到了我们承诺的结果吗？”可悲的是，我们并不经常这样做，而且通常只有在客户推动或我们试图追加销售或续订时才这样做。

价值定位和价值实现在我们的参与和客户发展战略中非常强大和重要。

但我们必须思考。他们真的有区别吗？他们真的让我们有别于其他人吗？他们是否帮助客户做出选择并对他们的决定充满信心？

现实情况是，我们的价值定位可能正在成为赌注。这对客户很重要，但是当他们查看他们的短名单时，替代方案可能并没有太大的不同。他们都解决了客户的问题。他们每个人都帮助客户实现他们的目标。有一些差异，可能更多的细微差别。一种方法可能在某些领域更强大，另一种方法在其他领域可能更强。

不要误会我的意思，价值定位在我们与客户的合作中至关重要。如果我们赢了，价值实现在此基础上至关重要。但我们的定位可能不是我们获胜的原因。

那么是什么让我们获胜呢？

我们必须扩展我们的价值理念，更加专注于价值创造！

价值创造是我们与客户一起完成他们的机会/问题解决和购买旅程的工作。这是我们和客户一起学习的东西——关于他们的面子和他们可能实现的目标。这是我们相互了解的。它是如何通过协作开始以不同的方式思考，考虑新事物，重新构建我们对未来的看法。

价值创造不是我们可以在我们的网站上大肆宣传的东西。我们不能制造“我们的产品创造独特价值……”的头条新闻

这是因为价值创造是在当下创造的。这是我们与客户的互动。每一次互动都是不同的，每一次都是短暂的。我们无法将其标准化为剧本和战斗卡。

价值创造是非常个人化的，我们每个人、客户和销售人员都有彼此的共同经历。我们正在学习新的东西，我们正在辩论新的想法，我们正在质疑我们的前提和偏见。我们一起计划，想象一个新的未来，并弄清楚如何到达那里，如何管理风险。

我们不能遵循围绕价值创造的脚本，但我们可以装备自己成为价值创造者。心态是关键——开放/成长导向的心态。好奇心很重要，它可以帮助我们以不同的方式看待事物。深入倾听、批判性思维和协作解决问题都是帮助客户前进的基础。而关怀是创造价值的基础。

价值创造与我们产品的特性/功能/优势/馈送/速度/能力无关。这完全是关于我们的客户、人员，而不是公司和我们，以及我们如何共同看待和管理变化。

价值创造是最终的差异化因素。它不仅限于客户的购买旅程，而是我们在关系生命周期中的共同经历。在我们见面之前，这是他们对我们公司的体验，也是我们对他们的体验。这是我们在第一次转瞬即逝的讨论中创造的价值——即使我们/他们甚至可能没有关注。这是每次互动中的体验，因为他们决定他们应该改变（也许是因为我们已经煽动了它），它会在他们的购买过程中以及在他们购买并寻求实现/实现价值之后继续。

价值定位和价值实现仍然至关重要。而且，一般来说，我们还有很大的改进空间——太多的销售人员仅限于鹦鹉学舌标准的价值主张。我们必须在这方面做得更好，但这是赌注。

价值创造是我们与其他人的不同之处，它是我们与客户一起创造并终生打造的体验。最终，这就是为什么客户选择我们而不是替代品的原因。

未来呢？

我们的价值概念是从 1988 年引入价值主张开始演变而来的。

我怀疑，我们会在未来几年看到一些新事物的出现。

• 我们将认识到，需要创造的价值不是一刀切的方法，因此我们必须适应。有些决策并不复杂，风险不高，可能是交易性的。我们为这些创造的价值与复杂复杂的场景截然不同。
• 价值创造将越来越多地转向激励组织变革。
• 意义建构和决策信心对于价值创造已经很重要，并且随着人们与复杂性作斗争将变得越来越重要。
• 我们将看到需要敏捷的价值创造网络——多个组织​​和人员之间的协作努力。我们已经在巨大的社会变革中看到了这一点，但随着组织寻求成长和创造更多价值，我们将看到我们需要新的和不同类型的关系。因此，这将不再是我们吸引客户的方式，而是我们如何吸引对实现我们共同目标至关重要的人。
• 我们将认识到多样性——在所有意义上——对价值创造至关重要。我们不能有相同的想法，我们必须有不同的想法。因此，我们将寻找日益多样化的群体，例如可能蜂拥而至的群体，以帮助完成这一旅程。因此敏捷性、敏捷性和灵活性变得至关重要。
• 我们还将了解到这些原则对于在我们自己的组织内推动变革至关重要，它们将成为我们如何领导、如何发展、如何赋权、参与和调整员工的基础。 “大辞职”是一个危险信号，告诉我们需要改变我们在组织内创造的体验（这进一步使我们在与客户和其他人创造价值方面更有影响力）。

你都有些什么想法呢？

原文：https://customerthink.com/value-realization-value-positioning-value-cre…

本文：https://jiagoushi.pro/node/2123

你公司的竞争优势是什么？价值主张有助于企业识别出它与竞争对手的区别。但你如何判断你的商业活动是否为客户创造了最大的价值和巨大的利润率呢？

什么是价值链？

价值链用于描述从开始到结束创建产品所需的所有业务活动（如设计、生产、分销等）。价值链分析为企业提供了这些活动的可视化模型。

通过此分析，您可以采取步骤来创建竞争优势、提高效率和增加利润率。让我们深入了解价值链分析，并学习如何分析业务活动。

 

什么是价值链分析？

价值链分析是企业分析其为创造产品而进行的活动的一种方法。一旦对活动进行了分析，企业就可以利用结果来评估提高竞争优势的方法。

竞争优势

竞争优势是使你的企业与众不同的因素。为了发展优势，你需要清楚地了解你的目标市场，你的产品给目标市场带来的好处，以及对你的竞争对手和他们的产品有一个坚实的了解。

企业可以在下列领域中获得竞争优势。

1.成本领先

成本领先战略的目标是成为行业或市场中成本最低的供应商。擅长低成本战略的公司具有极高的运营效率，使用低成本的材料和资源来降低产品或服务的整体价格。

成本领先的例子：麦当劳和沃尔玛

2.差异化

通过差异化战略，通过提供独特或高度专业化的产品或服务获得竞争优势。企业需要投入时间和资源进行创新、研究和开发。成功的差异化战略允许企业为其产品或服务设定溢价。

差异化示例：星巴克和苹果

最好选择一个竞争优势来集中精力。根据您选择的竞争战略，您的价值链分析的目标将是降低成本或差异化以提高利润率。然后，你会清楚地知道你的业务目标，你计划如何提供价值，并且它缩小了可能需要进行的改变的范围，以提高效率。

波特价值链分析

哈佛商学院（Harvard Business School）教授迈克尔•波特（Michael Porter）在其著作《竞争优势》（Competitive Advantage）中介绍了一种简单的价值链模型。他开发了执行价值链分析的步骤，并将业务活动分为两类：主要和支持。

价值链分析步骤

价值链分析需要研究，需要时间来发展。以下是创建价值链分析所需的一般步骤：

1.确定业务的主要和支持活动。

主要活动和支持活动共同构成了价值链。它们包括产品或服务开发过程中所需的每一个动作，从原材料到最终产品。

2.分析活动的价值和成本。

负责创建价值链分析的团队应集思广益，讨论每项活动如何为客户和整个业务提供价值。将活动与您试图实现的竞争优势（成本领先或差异化）进行比较，看看它是否支持目标。

完成价值分析后，查看活动的成本。这项活动是劳动密集型的吗？X原材料要多少钱？提出类似的问题将有助于确定哪些活动具有成本效益，哪些不具有成本效益。这是可以确定需要改进的地方。

3.找出获得竞争优势的机会。

价值链分析完成后，业务中的主要利益相关者可以看到业务在哪些方面表现优异以及在哪些方面可以在操作上进行改进的概述。

先从需要小的改变并提供高影响结果的改进开始。在简单的胜利被确定并付诸行动之后，你和你的团队可以应对可能阻碍效率的更大挑战。

价值链分析让企业清楚地知道如何调整自己的行为和流程，为目标市场提供最大价值，并为公司增加利润率。

主要和支持活动

确定主要和支持活动是创建价值链分析的第一步。这些是企业用来开发产品或服务的关键流程和系统。

主要活动

有五个主要活动，其中包括创建业务“产品”所需的所有操作。

1.入境物流

这就是在开发最终产品或服务之前从供应商那里获得材料和资源的方式。

2.操作

操作是材料和资源的生产方式，最终产生产品或服务。

3.外部后勤

产品或服务一旦完成，就需要分发。出站物流描述了这个交付过程。

4.市场营销

这就是你的产品或服务如何呈现并销售到你理想的目标市场。

5.服务

这是企业为客户提供的支持，包括对产品的支持和培训、保证和保证。

支持活动

支持活动有助于主要活动创造优于竞争对手的优势，这些活动包括：

1.坚实的基础设施

这需要一个企业所拥有的所有管理、财务和法律系统来做出业务决策和有效地管理资源。

2.人力资源管理

人力资源管理包括管理员工和雇佣新员工所涉及的所有流程和系统。这对于提供当面服务的公司尤其重要，优秀的员工可以成为竞争优势。

3.技术开发

技术发展有助于企业创新。技术可以应用于价值链的各个环节，通过提高效率或降低生产成本来获得相对于竞争对手的优势。

4.采购

这就是如何为产品提供资源和材料，并找到供应商。我们的目标是找到符合企业预算的优质供应。

价值链分析实例

价值链分析使企业能够审视自己的活动并发现竞争机会。例如，麦当劳的使命就是为顾客提供低价食品。这项分析有助于麦当劳确定需要改进的领域，以及为其产品、服务或活动增加价值的活动。

下面是麦当劳及其成本领先战略的价值链分析示例。

1.入境物流

麦当劳已经为其食品和饮料的原材料预先选定了低成本的供应商。它为蔬菜、肉类和咖啡等商品寻找供应商。

2.经营

这家公司拥有特许经营权，每家麦当劳的营业地点都由特许经营人拥有。麦当劳在全球有37000多家分店。

3.外部后勤

麦当劳没有正式的坐式餐厅，而是有快速休闲餐厅，专注于柜台服务、自助服务和直达服务。

4.市场营销

其营销策略主要集中在媒体和平面广告，包括社交媒体帖子、杂志广告、广告牌等。

5.服务

麦当劳努力实现高质量的客户服务。它还为成千上万的员工提供深入的培训和福利，使他们能够最好地帮助客户。

价值链分析模板

以下是一些来自Edraw的价值链分析模板，可以帮助您开发自己的价值链分析模板。

1.波特价值链分析模型

波特的价值链分析模板提供了业务活动的一般概述。

2.成本利润率模板

如果您正在分析主要和支持活动的成本与预期利润率，则此模板适用于您。

3.教育机构模板

该模型不分析创建产品或服务的活动，而是着眼于开发学术研究所涉及的价值链。

4.产品模板

使用此模板分析从原材料到成品创建产品所需的活动。

5.金融收购模板

你最近有没有收购或合并另一家公司？如果是，请使用此模板分析转换中的步骤。

您的价值链分析将帮助您确定需要改进的领域以及为客户和整个企业提供最大价值的活动。消除低效的商业活动可以加快生产，提高竞争优势，增加利润率。

 

本文：http://jiagoushi.pro/node/975

讨论：请加入知识星球【首席架构师圈】

价值是企业成功的关键。

 

为客户提供价值 = 增加获取、保留和宣传，并为业务提供价值 = 更高的利润和更高的盈利能力。

了解您的业务在何处以及如何提供价值可以提高运营效率并确定竞争优势的机会。

 
什么是价值链分析？

价值链分析是分析企业为向客户提供有价值的产品或服务而进行的活动的过程。分析价值链可以确定每项活动为客户提供的价值是否大于为企业开展活动的成本。

 

价值链中的活动是什么？

由迈克尔波特于 1985 年提出，组织的价值链由九种影响利润率的增值活动组成。这些可以分为两种类型：主要和支持。

五项主要活动是与生产和销售产品或服务直接相关的活动，包括：

• 入库物流——接收和储存来自外部供应商的材料
• 运营——将材料转化为产品/服务
• Outbound Logistics – 处理订单并分发给客户
• 营销和销售——向买家推广产品和服务并促进他们的购买
• 服务——确保产品或服务在购买后继续为客户提供价值

支持活动是支持主要活动的活动，包括：

• 采购——负责协商所有五项主要活动的采购成本
• 技术开发——负责组织内用于管理和处理信息的系统
• 人力资源管理——负责招聘、培训和留住具备交付产品/服务所需技能的人员
• 企业基础设施——与允许企业维持日常运营的功能有关，例如金融

价值链分析和竞争优势

在做出购买决定时，客户会被宠坏了。吸引他们的注意力并赢得业务意味着提供比市场上其他选择具有更高感知价值的产品，从而获得竞争优势。竞争优势可以通过两种策略获得：成本优势和差异化优势。

• 成本优势战略的目标是创造一种有价值的产品，以最低的成本为企业和客户带来最大的价值。分析价值链使组织能够识别每项活动的成本驱动因素并找到降低成本的方法，从而降低生产成本并提高利润率。
• 差异化战略旨在通过向竞争对手提供独特或卓越的产品来创造价值。识别产品/服务的独特方面使其与市场上的其他产品区分开来会增加感知价值，因此可以要求更高的价格。

 
如何分三步进行价值链分析

1. 识别价值链中的活动

确定提供产品或服务所需的主要活动和支持活动。例如，在银行业，主要活动之一是营销团队开展广告活动以吸引新客户，这得到了负责业务技术的团队的支持，使客户能够通过数字渠道快速轻松地创建新账户他们已经习惯了诸如手机银行之类的应用程序。

2. 确定每项活动的成本和价值

计算每项活动的成本以及它为企业和/或客户增加的价值。在银行示例中，团队将分析营销活动是否在客户获取方面提供了良好的投资回报，以及企业的技术是否为内部和外部客户提供了价值。

3. 识别竞争优势机会

确定哪些活动提供了获得成本或差异化竞争优势的最大机会。例如，营销团队是否可以与他们用于广告活动的代理机构协商更好的交易，或者进行比竞争对手提供的更能吸引客户的促销活动？

原文：https://www.bizagi.com/en/blog/value-chain-analysis-increasing-customer…

本文：https://jiagoushi.pro/node/2120

正如我们在上一篇博客中看到的，ArchiSurance希望建立一些新的能力来支持其“数字客户亲密度”战略，如数字客户管理、数据驱动保险、数据采集和数据分析。在其当前功能的上下文中定位这些功能会导致下图，使用Enterprise Studio的“highlight”功能来强调这些新元素。

Figure 1. New capabilities for Digital Customer Intimacy.

能力与业务功能

请注意，业务功能不同于功能。能力代表一个组织的当前或期望的能力，由其人员、流程、信息和技术实现。它们专注于特定的业务成果，并用于战略规划目的。相反，业务功能描述了组织实际完成的工作；它们通常是显式管理的，并且与组织结构更紧密地结合在一起。每个功能在功能图中只出现一次，而在企业的功能分解中，相同的子功能可以出现多次。

在描述基线业务架构时，能力图的价值主要在于分析当前与期望的能力水平，并揭示组织已经拥有但未明确识别或管理的能力。目标业务体系结构中的能力和能力级别为更改提供了高层指导。这是基于能力的规划的核心。

当然，当你绘制出组织当前能力的地图时，它当前的业务功能往往会占据显著位置，因为你今天实际做的事情本质上也必须是你能够做的事情。多个业务功能（连同其他元素）可能有助于实现一种能力。

下图显示了上图中ArchiSurance的一些主要能力与其当前业务功能之间的一些关系。上图中的新子功能是此图中两个绿色功能的一部分。这些可以通过扩展现有的业务功能（以及其中的流程）来实现，但它们也可能需要新的功能和资源。例如，数据驱动的保险能力及其子能力可能需要建立组织的一个全新部分，精算、索赔和承保业务职能可能会发生重大变化。

Figure 2. Capability realization.

 

这些能力需要适当的资源支持，包括具备数字时代适当知识和技能的人员、用于数据采集的智能设备以及客户数据本身。

这些资源本身由企业架构核心实现。这可能导致的一小部分结果也显示出来了。注意，这并不是描述实现这些资源所需的所有元素，而是一个代表性的示例。在实践中，通常会创建单独的视图来显示如何实现单个功能和资源。

通过将所有这些放在一起，我们可以看到从您的不同资产到它们支持的能力，以及我们在上一篇博客中概述的战略、目标和结果。您甚至可以更进一步，通过将更详细的模型（例如，BPMN中的流程或UML中的数据）连接到ArchiMate中的架构模型，只需在Enterprise Studio中将这些模型链接在一起。这样，您可以深入了解战略决策的影响，反之亦然，发现您所使用的资源提供的新选择和创新。在整个企业中规划、执行和控制变革从来就不是那么容易！

原文：https://bizzdesign.com/blog/archimate-3.0-capability-realization/

本文：http://jiagoushi.pro/node/1012

讨论：请加入知识星球或者微信圈子【首席架构师圈】

业务模型画布是一个战略管理和精益创业模板，用于开发新的或记录现有的业务模型。它是一个可视化的图表，其中的元素描述了一个公司或产品的价值主张、基础设施、客户和财务状况。它帮助企业调整他们的活动，通过说明潜在的权衡。

业务模型画布最初是由Alexander Osterwalder[4]在其早期业务模型本体工作的基础上提出的。自2008年前后Osterwalder的作品发布以来，[5]已经出现了针对特定利基的新画布。

描述

业务的正式描述成为其活动的基础。存在许多不同的业务概念化;Osterwalder在2010年的著作[3]和2004年的论文[5]中提出了一个单一的参考模型，该模型基于广泛的业务模型概念化的相似性。通过业务模型设计模板，企业可以轻松地描述其业务模型。奥斯特瓦德的画布上有九个箱子;每一个的名字在下面的粗体部分给出。

基础设施

1. 关键活动:执行公司价值主张中最重要的活动。笔制造商Bic的一个例子是，创建一个有效的供应链以降低成本。
2. 关键资源:为客户创造价值所必需的资源。它们被认为是公司维持和支持业务所需的资产。这些资源可以是人力、财力、体力和智力。
3. 合作伙伴网络:为了优化运营和降低商业模式的风险，组织通常会培养买方和供应商之间的关系，这样他们就可以专注于自己的核心活动。互补的商业联盟也可以考虑通过合资企业或竞争对手或非竞争对手之间的战略联盟。

提供

• 价值主张:企业为满足顾客需求而提供的产品和服务的集合。Osterwalder(2004)认为，公司的价值定位是其区别于竞争对手的地方。价值主张通过各种元素提供价值，例如新奇、性能、定制、“完成工作”、设计、品牌/状态、价格、成本降低、风险降低、可访问性和便利/可用性。
  • 价值主张可能是:
    • 数量-价格和效率
    • 定性——客户的整体体验和结果

客户

客户细分:

为了建立一个有效的商业模式，公司必须确定它试图服务哪些客户。根据客户的不同需求和属性，可以对不同的客户群体进行细分，从而保证企业战略的适当实施，以满足所选择的客户群体的特点。不同类型的客户细分包括:

1. 大众市场:对于一个遵循大众市场元素的公司来说，并没有特定的细分市场，因为该组织展示了潜在客户的广泛视野。例如汽车
2. 利基市场:根据客户的特殊需求和特点对客户进行细分。如劳力士
3. 细分:公司在现有的客户细分中应用额外的细分。在细分的情况下，企业可以根据性别、年龄和/或收入进一步区分客户。
4. 多样化:企业服务于具有不同需求和特征的多个客户群。
5. 多边化的平台/市场:为了日常业务的顺利运作，一些公司会服务相互依赖的客户群体。信用卡公司将为信用卡持有者提供服务，同时帮助接受信用卡的商家。

渠道:

公司可以通过不同的渠道向目标客户传递其价值主张。有效的渠道将以快速、高效、低成本的方式分配公司的价值主张。组织可以通过自己的渠道(店面)、合作伙伴渠道(主要分销商)或两者的结合来接触客户。

客户关系:

为了确保任何业务的生存和成功，公司必须确定他们想要与客户建立的关系类型。各种形式的客户关系包括:

1. 个人协助:以雇员-顾客互动的形式提供协助。这种协助是在销售期间和/或销售后进行的。
2. 专门的个人帮助:最亲密和亲自动手的个人帮助，销售代表被指派处理所有的需要和问题的特殊客户。
3. 自助服务:指公司与客户之间的间接互动转化而成的一种关系。在这里，组织为客户提供所需的工具，以方便和有效地为自己服务。
4. 自动化服务:类似于自助服务的系统，但更加个性化，因为它能够识别单个客户及其偏好。亚马逊网站就是一个很好的例子，它会根据你以前买过的书的特点给你推荐一些书。
5. 社区:创建社区允许不同客户和公司之间的直接交互。社区平台产生了一个场景，在这个场景中，不同的客户端可以共享知识并解决问题。
6. 共同创造:通过客户对公司产品/服务的直接投入，建立个人关系。

财务状况

成本结构:

这描述了在不同商业模式下运营时最重要的货币后果。公司的医生。

业务结构类别:

1. 成本驱动——这种商业模式注重于最小化所有成本，没有多余的东西。例如低成本航空公司
2. 价值驱动型——不太关注成本，这种商业模式专注于为产品和服务创造价值。路易威登，劳力士

成本结构特点:

1. 固定成本——成本在不同的应用中是不变的。如工资、租金
2. 可变成本-成本的变化取决于产品或服务的生产数量。例如音乐节日
3. 规模经济成本随着订购或生产的商品数量的减少而降低。
4. 范围经济-由于合并了与原始产品直接相关的其他业务，成本下降。

收入来源:

公司从每个细分客户中获取收入的方式。产生收入流的几种方法:

1. 资产出售(最常见的类型)出售实物商品的所有权。例如,零售企业
2. 使用费-使用特定服务产生的费用。例如UPS
3. 订阅费——通过出售连续服务的访问权而产生的收入。例如Netflix
4. 贷款/租赁/租赁-给予特定时期内资产的专有权。租一辆车
5. 许可——对使用受保护的知识产权收取费用而产生的收入。
6. 经纪费-由双方中间服务产生的收入。经纪人出售房子以赚取佣金
7. 广告—产品广告的收费收入。

应用程序

业务模型画布可以打印在一个大的表面上，这样一群人可以共同开始草图，并讨论业务模型元素与便利贴笔记或板标记。它是一种实践工具，可以促进理解、讨论、创造力和分析。它是根据来自strategy yzer AG的知识共享协议[8]发布的，可以在没有任何限制的情况下用于商业建模。

业务模型画布也以基于web的软件格式提供。

不同形式

参见:精益创业§商业模式模板

业务模型画布已经被使用并进行了调整，以适应特定的业务场景和应用程序。[9][10][11]的例子包括:

1. 产品/市场配合
2. 供应链
3. 现金流
4. 内部沟通
5. 精益创业§精益画布

批评

业务模型画布被描述为静态的，因为它不捕获策略的变化或模型的演化。模板的一些限制在于它关注组织及其与环境的概念隔离，无论是与行业结构[13]还是与利益相关者，如社会和自然环境

另请参阅

1. 业务流程建模
2. 商业计划
3. 业务参考模型
4. 产品/市场配合

 

原文：https://en.wikipedia.org/wiki/Business_Model_Canvas

本文：https://pub.intelligentx.net/node/827

讨论：请加入知识星球【首席架构师圈】或者飞聊小组【首席架构师智库】

由于业务功能直接源自企业战略计划，并被设计为满足企业的业务战略、目标和目标，因此它们为创建企业架构路线图提供了良好的基础。

什么是业务能力?

业务能力表示一个组织执行产生价值结果的活动的能力。业务功能尽可能用那些业务结果和价值来表示。据我所知，这个概念起源于MODAF，后来被TOGAF采用。参见http://en.wikipedia.org/wiki/Capability_management_in_business

许多企业架构师和组织没有真正地使用它们，但实际上它们正在慢慢地成为通用的EA可交付产品和开发目标操作模型视图的方法。

它们越来越受欢迎的关键在于，业务功能是用业务结果和价值来表达的，而不是纯功能或IT术语(即，不仅仅是业务单元需求或IT解决方案)，从而确保IT与业务保持一致。用结果和价值来表达还意味着业务能力是与客户旅程和战略场景的外部视角相联系的，而不是由内而外的视角。

一本好书读到在外面的角度来看是“在外面:实力的客户业务的中心”曼宁哈利等人http://www.amazon.co.uk/Outside-In-Putting-Customers-Business/dp/147780… +。

为了让一个组织执行一项活动，组织的许多部分需要参与。因此，业务能力被建模为其他EA概念的分组，包括以下内容:

• 人
• 组织单位
• 功能
• 流程
• 业务服务
• 信息和数据
• 应用程序服务
• 应用程序
• 基础设施服务
• 基础设施

通过这种方式，业务能力可以被看作是典型企业架构模型的横切部分。

业务能力用于管理战略性业务变化的单位，并为计划和项目组合提供授权。随后，项目将开发一个解决方案，该解决方案将创建一个全新的业务功能，或者通过实现功能增量来更新业务功能。

因此，业务功能和功能增量为EA路线图的开发提供了基础。

业务能力模型

图1:示例业务能力模型来源:UK Government Reference Architecture (UKRA) v1.0

此图说明了业务能力模型的起点。这是一个基于IBM组件业务模型（Component Business Model）风格的静态视图。这是一个非常流行的样式图。

整个矩阵代表了组织执行的所有业务能力。每个单元都是一个业务功能。

这些列通常反映了组织的高水平价值链，或者是对业务有意义的业务能力的主要分组。

这些行反映了业务能力的基本用途，通常有三行:

Row	Aligned to the Viable System Model (VSM) system type
Direct (or Strategy)	System 5 and system 4
Control (or Management)	System 3, system 3* and system 2
Execute (or Operate)	System 1

有关VSM的详细信息，可以参考http://en.wikipedia.org/wiki/Viable_System_Model和我以前的博客文章。

业务能力之间也有依赖关系。也就是说，在实现另一个业务能力之前，必须先有一个业务能力。

实现业务策略需要新的或改变的业务能力，但在大多数情况下，我们只是改变了业务能力的某些方面，而不是引入全新的功能。这就是能力增量。

图2:显示业务功能来源的图:TOGAF

上面的图表显示了业务能力和能力增量之间的关系，并且还与企业架构开发方法阶段以及计划和项目组合的工作包的定义相关。

能力增量记录了实现业务或IT策略所需的每个业务功能的变更。

每个业务能力被分解为一个或多个能力增量，这些增量通常在不同的时间点和不同的转换体系结构中实现。每个能力增量代表一个变更单元。

能力增量之间也有依赖性。例如，在实现另一个能力增量之前，必须先实现一个能力增量。

图3:能力依赖模型

上面的图表显示了业务能力之间以及能力增量之间的依赖关系。

可以重新安排能力增量，以显示需要应用它们的依赖顺序。这个序列构成了EA路线图的基础。

图4:EA路线图结构

通常，在EA路线图中表示几个轨道可能是有用的(和策略)。例如，可以为战略变更、业务变更和IT变更引入跟踪，因为可以以一种可以并行实现的方式识别能力增量。

能力增量可以分组到转换架构中。过渡架构于当前状态和未来(目标)状态企业架构模型之间的中间架构模型。转换架构通常与实现中的中间和临时阶段保持一致。

一个或多个功能增量的组将为项目中开发的解决方案或服务提供强制要求。

业务能力模型应该是所有企业架构模型的核心。

通常，架构远景模型或核心模型作为业务能力模型产生，以提供战略视图，帮助组织中的所有涉众对需要做什么和需要更改什么形成共同的理解。

(感谢Lee Hepplewhite在这方面的贡献)

原文：https://ingenia.wordpress.com/2013/06/16/business-capability-based-ea-roadmap/

本文：http://jiagoushi.pro/node/1229

讨论：请加入知识星球【首席架构师圈】或者小号【jiagoushi_pro】或者QQ群【11107777】

在BPMN术语中，“泳道”代表两个主要分组BPMN元素-池和泳道。

池

池是设置业务流程边界的基本BPMN元素。池最多包含一个业务流程。这意味着两个流程程必须在两个不同的池中建模。池可以以将要执行的流程的形式具有可见的内部详细信息（称为“白盒池”），或者池可能没有可见的内部详细信息（称为“黑盒池”）。应该使用的池类型取决于所需的详细程度和特定的上下文。

“白盒”池通常以相应的业务流程（如“需求管理流程”、“帮助台流程”或“服务交付流程”）命名，而“黑盒”池通常以相应的组织、人员或系统（如“供应商”）命名，“客户”或“内容管理系统”）。

泳道

Lane是池中的子分区，用于组织和分类流程的活动。最常见的是，lane代表一个组织角色（例如开发人员、分析师和经理）。但是，泳道也可用于其他目的（例如第一阶段、第二阶段和第三阶段）

常见误解

游泳池和泳道的含义和语义常被误解。例如，一组池可能被错误地视为单个池中的一组泳道，反之亦然。这会导致语法和语义上错误的流程模型。

由于池和通道之间的语义差异，BPMN流元素（活动、网关和事件）的连接方式不同，这取决于它们是在池中使用还是在池之间使用。在池中，BPMN流元素以以下方式与序列流连接，如图2所示。

“池之间”通信时只能使用消息流。消息流表示两个池或流程之间的消息交换，包括它们的同步。可以按照图3中的定义使用消息流：

请注意，在这两种情况下，只允许元素之间的连接，如前两幅图所示。基于这些误解，在建模BPMN时，以下三个错误是常见的：

错误1：缺少序列流

问题。在对多个池进行建模时（例如，在业务对业务的情况下，两个或多个流程交互），一个常见的错误是池中的活动没有连接到序列流。

这种错误最常见的原因是建模者可能将多个池视为单个流程，并错误地将消息流解释为指示活动序列的方式。这种流程模型是无效的，因为没有明确定义活动的顺序。

解决方案。建模者应该始终对单个池进行建模和验证，并记住一个池不能包含多个流程。这意味着池中的所有流元素都应该使用图2和图3中定义的序列流进行连接。

错误2：序列流的错误使用

问题。建模多个池时的另一个常见问题是，建模者可能会将一组池视为具有多个通道的单个池。在这种情况下，建模者使用池之间的序列流。最终结果将是一个不正确的模型（参见图2），该模型散布在池的边界上。

解决方案。此问题最常见的解决方案是在单个模型中使用泳道交换池，如下所示。如果需要使用多个池（可能存在多个独立流程时），则应使用错误1的解决方案。

错误三：泳道使用不当

问题。有时，建模者可能会错误地将一个通道视为一个池，从而在单独的通道中表示各个流程。这是错误的，因为通道只是一种“活动分类机制”。下图显示了这个错误。

解决方案。这个问题最常见的解决方案与前一个类似；在两个流程中定义一个（如图9所示）。这意味着冗余的开始和结束事件将从模型中删除。如果实际需要多个池（存在多个独立流程），则应使用错误1的解决方案。

尽管如此，重要的是要指出，如果一个流程有两个开始或两个结束事件，在语法上并不是错误的！例如，几个不同的事件可以在不同的地方启动一个流程，例如，通过消息触发器异步启动一个流程，或者每天早上定期启动一个流程。另一方面，一个流程通常以不同的结束状态结束（例如“成功治疗”或“不成功治疗”）。

结论

本文介绍了BPMN“泳道”的概念，它可以用“池子”和“泳道”来建模。乍一看，这两个元素看起来非常相似，但是它们有完全不同的含义！

池是单个流程的容器，而通道充当“活动分类机制”。基于这些差异，BPMN流元素的关联方式完全不同。在池间交互的情况下，只能使用消息流。另一方面，只有顺序流可以在池内和泳道之间使用。

原文：https://blog.goodelearning.com/subject-areas/bpmn/common-bpmn-modeling-mistakes-swimlanes/

本文：http://jiagoushi.pro/node/1084

讨论：请加入知识星球【首席架构师圈】或者小号【jiagoushi_pro】

 

您的产品开发策略不仅应受业务目标的影响。 使用客户价值链可视化您的产品如何帮助或阻碍人们的日常生活。

您可能声称对您的产品开发策略采用客户至上的方法——但事实真的如此吗？虽然许多组织表示他们坚持客户至上的理念，但销售目标往往占上风。

您的客户至上方法应该专注于围绕用户需求构建解决方案，而不是围绕竞争对手正在做什么或可能最有利可图的事情。

那么这对产品开发有何影响？成功的产品开发战略与了解客户价值链密切相关。这允许产品团队建立直觉并识别产品中的差距。

了解客户价值链的重要性

客户价值链包含客户需求、他们如何使用您的产品以及如何让他们更容易使用您的产品。从本质上讲，客户价值链让您全面了解您的产品如何为客户的生活增加价值。它可以帮助人们可视化客户需求以及您的产品如何映射回这些需求，并将所有内容链接或链接在一起。

当您更好地了解您的客户以及他们如何与您的产品互动时，您就有能力做出更好的决策。

客户价值链始终始于客户。这与您的业务目标、销售配额、产品创意无关——它纯粹与您的客户有关。

因此，当您评估自己的客户价值链时，最好的起点是您的用户。您可能会问以下一些问题：

• 我们用户的痛点是什么？
• 他们用我们的产品做什么容易？
• 他们对我们的产品有什么困难？
• 他们想要什么？

基于这些见解和其他产品分析，您可以使用更客观和数据驱动的方法针对客户价值链评估产品、功能和想法。

专注于客户访谈

请记住，客户价值链始于客户。如果您从不与他们互动，您将无法了解您的客户。没有比直接问他们问题更好的方法来深入客户的头脑了。

大多数产品经理在构建之前、之中和之后的每个阶段收集客户反馈。但只有 7% 的人使用客户访谈。

虽然调查和分析很重要，但客户访谈会更深入，并为您提供出色的定性反馈。他们让受访者有机会了解客户以及他们如何使用您的产品，这在现在和以后都会派上用场。

在 Amplitude，我们会在面试中提前与人们交谈，以了解他们的要求。有时，我们也会展示模型和设计以获得反馈。这有助于我们随着时间的推移熟悉客户，并建立我们在做出日常决策时可以依靠的直觉。我们还确保批判性地问：“有人真的想要这个吗？”在构建它之前。

这些访谈是确定客户价值链以及他们的需求、愿望、挑战和愿望是什么的起点。

将反馈因素纳入您的产品开发策略

收集反馈很容易，而且什么也不做。但是客户至上的产品团队会不断地将反馈纳入他们的产品开发策略中。

我们使用 Productboard 来收集、组织和分析客户反馈。项目经理仔细研究所有笔记，以直观地了解当前客户的感受，然后相应地优先考虑输入。他们依靠在客户访谈中和团队经验中形成的直觉。这意味着他们不需要每一步都进行采访和调查，而是可以依靠他们通过之前的客户互动获得的知识。

我们产品团队的另一个战略优势是能够利用我们的客户合作伙伴作为 beta 测试人员来获得早期反馈。只有不到 10% 的组织实际上拥有 beta 测试计划，我们发现我们的计划非常有价值。我们使用功能标志在目标用户的雷达上获得新的发布，并陆续收集反馈。

我们的 beta 测试分阶段进行。我们将发布客户合作伙伴版本，然后向大约 10% 的客户进行部分发布，然后向更大的测试组中的每个人发布。在那之后，我们去掉了 beta 标签。这使我们能够轻松地迭代和实施客户反馈，每轮发布一个改进版本。

用一页纸合成信息

听说过分析瘫痪吗？当您拥有如此丰富的定量和定性数据时，这是一个真正的挑战——您不知道从哪里开始或优先考虑哪些信息。这种数据过载可能导致无所作为。

为了避免这种分析瘫痪，我们为 Amplitude 的整个产品团队综合了信息。我们构建单页文件，列出产品要求、客户问题以及来自采访的见解以进行验证。

产品开发团队编写一页纸来封装他们试图解决的问题。这些单页纸在整个产品开发过程中派上用场，因为它们被分发给从事该项目的整个团队。结果是进行了有针对性的采访，因为产品团队可能会接触并征求使用过用户相关功能或我们正在改进的功能的客户的反馈。我们可能会展示模型甚至设计，并根据来自单页纸的信息评估客户反馈。

尽管单页纸可能会暗示解决方案，但它并不意味着解决方案。相反，这些单页纸总结了客户挑战，因此产品团队可以产生想法并围绕它构建新的解决方案。他们还确保我们的想法始终贴近客户价值链，使团队保持一致并朝着手头的目标前进。

灵活制定产品开发策略

尽管您可能拥有与客户价值链紧密集成的强大产品开发流程，但保持一定程度的灵活性仍然很重要。松散的强有力的计划是我们的口头禅。我们的团队明白，在此过程中，一切都可能随时发生变化，因此我们能够并且愿意更快地转向，因为我们不害怕随时返回并重新开始。

原文：https://amplitude.com/blog/product-development-strategy

本文：https://jiagoushi.pro/node/2121

 

波特五力分析模型最早出现在哈佛商学院教授迈克尔·E·波特1979年发表在《哈佛商业评论》上的文章中。这篇论文的发表在历史上改变了企业、组织甚至国家对战略的理解。自《哈佛商业评论》创刊以来，它被评为十大最具影响力的论文之一。

五力分析可以帮助公司评估行业吸引力，趋势如何影响行业竞争，公司应该在哪些行业竞争，以及公司如何定位自己以获得成功。

五力分析是一种战略工具，旨在提供全局概览，而不是详细的业务分析技术。它基于五种关键力量，帮助评估市场地位的优势。因此，五力在观察整个市场部门时最有效，而不是你自己的业务和一些竞争对手。

什么是五力模型?

该模型的主要思想是企业获得竞争优势的关键在于所在行业的盈利能力(行业吸引力)和企业在行业中的相对竞争地位。因此，战略管理的首要任务是通过分析供应商、购买者、当前竞争对手、替代产品和潜在进入者五个因素来选择潜在的高利润行业。企业在选择产业后，应根据自身的优势和五种力量的比较，从低成本、生产异化或集中化三种战略中选择一种作为竞争战略。

波特五力分析模型对企业战略的制定具有全球性和深远的影响。将其应用于竞争战略分析，可以有效地分析客户的竞争环境。其应用范围从最初的制造业逐渐覆盖几乎所有的行业，如金融服务、高科技等。

波特五力模型在一个简单的模型中汇集了大量不同的因素来分析一个行业的基本竞争格局。波特五力模型确定了五个主要的竞争来源，即:

• 供应商议价能力
• 买方议价能力
• 新进入者的威胁
• 替代品的威胁
• 行业内现有竞争者的竞争

(A)供应商的议价能力

当供应商所提供的投入要素占买方产品总成本的比例较大时，供应商的潜在议价能力就会大大提高。一般而言，符合以下条件的供应商议价能力较强。

• 供给侧行业是指市场地位相对稳定，市场竞争不激烈的行业。
• 供给侧产品有一定的特点，购买者难以转换，或者转换成本过高
• 供应商促进了前向集成，否则将增加生产过程的成本

(B)买方的议价能力

购买者主要通过降低价格的能力和提供更高的产品或服务质量的要求来影响行业中现有公司的盈利能力。一般来说，符合以下条件的买家议价能力较强:

• 买家的总数很少，每个买家都购买了大量的商品，占了卖家销售额的很大比例
• 卖方行业由大量相对较小的公司组成
• 购买者购买一个标准化的产品，同时从多个供应商购买该产品在经济上是可行的。
• 供应商促进向前集成，而买方发现很难合并或向后集成。

(C)新进入者的威胁

新进入者在为该行业带来新产能和新资源的同时，希望在已经被现有公司瓜分的市场中赢得一席之地。这可能会导致与现有公司在原材料和市场份额上的竞争，从而导致现有行业的出现。企业利润水平下降，甚至威胁生存。

竞争进入威胁的严重程度取决于两个因素:进入新领域的壁垒规模，以及现有企业对进入者的预期反应。

进入壁垒主要包括以下几个因素:

规模经济

随着企业规模的扩大，行业单位产品成本下降的特点，行业最低有效规模越高，进入壁垒越大。

分化程度

差异化是指产品和服务对客户需求的独特定位。差异越大，进入壁垒越大。

转换成本

客户或买方的转换成本是指客户为更换供应商而必须支付的额外成本。

技术障碍

包括专利技术、专有技术和学习曲线。

销售渠道控制

公司自建分销渠道，良好的合作伙伴关系，以及声誉、品牌等。

政策和法律

国家政策保护某些行业，如金融业。

(D)替代品的威胁

不同行业的两家公司可能会产生竞争产品，因为他们生产的产品是替代产品。

• 现有产品的销售价格和盈利能力的提高将受到限制，因为存在用户容易接受的替代产品。
• 由于替代品的入侵，现有的公司必须提高产品质量或降低成本。
• 来自替代产品生产者的竞争强度受到产品购买者转换成本的影响。

(E)业内现有竞争者之间的竞争

大多数行业的企业都与彼此的利益息息相关。作为他们整体战略的一部分，他们的目标是让自己的公司比竞争对手更具竞争力。有冲突和对抗，往往表现在价格，广告，产品介绍，售后服务。

波特五力工具的特点

Porter Five Forces提供了深入分析公司所在行业的工具，帮助公司了解竞争环境，正确把握公司面临的五种竞争力量，制定有利于公司竞争地位的战略。总的来说，波特五力模型具有以下特点:

• 竞争导向
• 研究现有产业
• 关注行业的利润潜力

如何应用五力模型?

波特五力分析模型是企业进行环境分析，尤其是行业分析的有力工具，但并不是企业战略的全部。企业应用波特五力模型也需要内外平衡。

• 在波特五力分析的基础上，考察了其资源与产业的匹配程度。在市场竞争加剧的条件下，任何企业进入陌生领域都存在一定的风险。企业是否要抓住这些机遇，必须考虑自身的核心能力和优势。
• 基于波特五力分析模型，分析了市场趋势和战略柔性程度。没有一成不变的市场，也没有一劳永逸的战略。战略制定是一个不断反馈、不断调整的动态过程。保持一定程度的战略灵活性是必要的。
• 即使有好的战略，也需要好的战略落地能力。人在当今企业中的作用越来越重要。激励已成为企业可持续发展的最重要因素，如何设计一套有效的、多元化的激励机制体系对不同层次的员工尤为重要。

五力分析实例

这五种力量分别是:新市场主体的威胁、替代产品的威胁、顾客的力量、供应商的力量、决定市场竞争强度和吸引力的行业竞争。

在Visual Paradigm中执行五力分析

让我们看看如何在可视化范例中执行五力分析。我们将在这里使用一个简单的五力分析示例。完成本教程后，您可以展开示例。

• 从主菜单中选择Diagram > New。
• 在New Diagram窗口中，选择Five Forces Analysis并单击Next。

• 您可以从一个空的图开始，或者从一个五力分析模板或者提供的五力分析示例开始。让我们从一个空白的图开始。选择Blank并单击Next。

• 输入五力分析模型的名称并单击OK。
• 从关系图工具栏中拖动五力分析形状并将其拖放到关系图上。

 

• 五力分析模型的编辑是通过InfoArt形状完成的。点击五力分析形状来显示信息艺术形状。

• 开始在信息艺术中输入内容。

 

 

原文：https://www.visual-paradigm.com/tutorials/five-forces-analysis-tutorial/

本文：http://jiagoushi.pro/node/861

讨论：请加入知识星球【首席架构师圈】或者飞聊小组【首席架构师智库】

我假设本文的读者已经初步了解什么是业务能力。 如果不是这种情况，请先阅读这篇文章，了解您需要了解的业务能力。

许多组织从业务功能开始，因为有人想以某种方式使用它们。 业务能力仍然是一个相对较新的概念，在概念理论方面几乎没有共识和公认的文献，特别是在定义、开发方法、用例和标准方面。

一些组织已尝试建立标准，但其标准的范围仅限于其组织的边界。 结果是可用的指导很少，开发结果不同，成功案例很少，并且许多持怀疑态度的利益相关者。

为了支持努力发展业务能力的组织，我总结了我在过去几年中学到的最重要的 12 个经验教训：

1. 了解确切的用例

了解您的用例以确定您到底需要什么。业务能力可以支持许多不同的用例，例如业务和 IT 的一致性，跨合并的公司，或者用于未来预算和项目的战略规划。但是，不要以为所有人都可以使用一张业务能力图！事实上，不同用例所需的业务能力在数量、详细程度、层次数量以及应映射的信息和组件方面会有很大差异。

• - 例如，应用程序环境的合理化方法可能只需要一些业务功能和映射信息。这些可能是应用程序、成本信息、底层技术的生命周期以及总体结果的业务满意度。
• - 相反，需求管理方法可能需要大量详细的功能。对于这样的用例，可以将 20 多种业务能力映射到一个需求。目标是确定现有解决方案已经涵盖了其中的多少。然后，要映射的信息可能是可扩展性、相互依赖性等。
• - 对于合并，您不需要任何详细的能力，因为您必须保持在各公司之间仍然具有可比性的水平。

2. 了解所有利益相关者

确定特定业务能力领域的所有相关利益相关者。如果您只与一个部门合作来确定特定领域的业务能力，则不要期望得到一个整体的业务能力图。以定价为例。它不仅由营销部门完成，而且还受到业务中更多领域的影响。以下领域也会对其产生影响：

• - 开发和生产成本，
• - 战略部的战略方面，
• - 最终必须考虑运输、进口、税收、临时和当地折扣等的当地销售商店。

同样，合同管理不仅在客户购买产品或服务时需要，而且与供应商、业务合作伙伴等也需要。您的组织最终可能会出现在不同的市场中，并且有不同的部门，这些部门都有点不同，使用不同的应用程序，并遵循不同的流程。但是，它们都使用相同的业务能力堆栈，最终代表您公司的业务能力图。

3. 理解和解释流程的差异

准备好与“流程人员”进行激烈的讨论。许多组织在为其组织开发详细而复杂的过程描述方面付出了巨大的努力。此外，流程描述通常比业务能力更成熟，因此总会有一些流程的坚定支持者不将业务能力视为可行的替代方案——一开始。强调业务能力优于流程的优势是业务能力成功的关键因素之一，这就是为什么我将在这里简要提及它们的原因：

• 首先，业务能力总是尽可能地被定义和命名，以便最大限度地从各种利益相关者那里获得理解。例如，它不得包括公司细节，例如技术或特定流程步骤。相反，两个不同公司之间的流程可能会有很大差异，即使它们的名称相同，实际内容也可能会大不相同。
• 其次，业务能力始终具有三个组成部分，即流程、人员和技术。作为多个组件的结果，使得业务能力随着时间的推移比其单个组件（例如流程）更稳定。
• 第三，业务能力的目的是提供公司的详尽视图，而不会重叠。它们是一个理论概念，被选择用于最小化两种不同能力之间的相互依赖关系。这使得单独分析它们成为可能。相比之下，流程反映了公司的实际行为，并且没有针对独立分析进行优化。

有了这些优势，还必须了解业务能力的巨大劣势，这是它们的理论性质。为了从能力中受益，组织需要为自己理解和定义概念——如果没有良好的现有指导方针，这是具有挑战性的。这将我们带到要考虑的第四课。

4. 一遍又一遍地传达这个概念

准备好向组织成员解释业务能力的概念 1000 次甚至更多次——在所有不同的层面上。我花了无数时间来介绍和讨论业务能力的概念。一个主要的收获是共享和能够重用内容应该具有非常高的优先级。
一般来说，准备好回答以下问题：为什么是能力？它对我们目前的情况有何帮助？为什么它比我们尝试的最后两个概念更好？我们为什么要使用它们？你会怎么做？你期待什么结果？行政级别的内容是什么？商业用途？给我？有无穷无尽的问题。

五、严格指导发展

就您期望的业务能力的外观制定和传达非常清晰的指导。如果您已经搜索过其他组织的业务能力图，您会注意到，根据来源，结果可能会有很大差异。同样，这是由于缺少标准化，因为即使是新的 TOGAF 9.2 也在努力新的数字主题，例如仅在非常高的水平上的业务能力
（更新：TOGAF 试图通过其系列指南：业务能力——它确实提供了迄今为止最好的摘要之一，为业务能力主题提供了一些标准化）。
如果没有集中接受的指导，每个利益相关者将创建在细节、维度、考虑的组件和措辞方面不同的业务能力。所有这些方面都使得以后协调和比较结果变得具有挑战性。
根据我的经验，解释不够详细，不足以以人们独立得出相同结果的方式充分定义业务能力。相反，我更愿意提供一些小例子来说明业务能力图最终应该是什么样子。这样，细节级别、语法、组件、范围等属性变得清晰并立即被捕获。

6. 重用和利用现有输入

尽可能多地重用现有资源——内部和外部。第一个业务能力草案通常比理论所暗示的更接近现状。这一点都不错，因为它有助于组织慢慢地将其思维方式转变为基于能力的观点。了解业务能力图的第一个版本作为您的组织可以使用的起点。在下一步中，进一步整合，确定更多属于一起的能力。此外，确定映射中是否还有一个或另一个进程可以转换。
当涉及到内部资源时，请考虑战略文件、流程描述、组织结构图或应用程序的功能。当涉及到外部资源时，请考虑来自 APQC 或 FrameworX 的全球流程标准。但是，请注意，这些输入源都不是完美的，并且每个都有其优点和缺点。
如何开始对业务能力进行建模以及采取哪些输入是重要的一步。

7.意识到这个概念的缺点

来源的缺点之一是会偏向业务能力的组成部分之一：人员、流程或技术。偏见的类型将取决于您决定的来源。显然，如果您使用流程描述来开发第一个业务能力地图草案，那么结果将在某种程度上相似。将不再有泳道、负责或重复的详细流程步骤。然而，它将明确指出，例如人力资源是从雇佣到解雇的，或者研发具有从研究到专利生命周期管理的能力。
另一方面，如果您开始研究应用程序的功能并在逻辑上对它们进行集群，也会存在偏差。结果很可能存在技术偏差，因为您一个接一个地检查系统并考虑每个技术细节。
最后，如果您从组织结构图开始，您可能很快就会掌握您的第一个业务能力级别。这样的能力图将包括营销、生产和采购等能力。但是，如果您在地图中捕获了太多您不希望出现的组织细节（即人员组成部分），例如部门或区域组织，则存在很高的风险。

8. 着眼长远——不要期待短期结果

准备好无法快速交付结果或快速增加价值。业务能力长期成功的最大风险在于它们是非常理论化的。它们是一个需要时间来为组织增加价值的概念。作为企业架构的大多数领域，这些概念需要被组织内的许多人接受。因此，需要收集、分析数据，并且需要传达并再次接受其影响。
这一切都需要时间，如果关键利益相关者不支持这个想法，附加值可能会很快变为零。此外，高层管理人员必须明白，真正的利益将在长期内实现。短期内甚至可能根本没有正面影响！
因此，尽可能展示业务能力的附加值非常重要，尤其是在讨论该概念的价值时。

9. 寻找每一个试点和展示的机会

这对你来说意味着你必须对机会敏感。您的目标应该是通过试点或展示展示业务能力的价值。如果您不断寻找机会，就会有足够的机会。对那些对你的工作比其他人更感兴趣的利益相关者保持敏感。他们可能只是想法相似，并了解背后的真正潜力。留意早期项目，这些项目可能无法协调一部分景观，或者无法清楚地展示其战略前进方向。所有这些情况都可能为您提供一个很好的机会来展示您草拟的业务能力图的某些价值。

10. 管理期望

在您所做的一切中，不要期望获得 100% 准确的最终结果。企业架构师，尤其是业务架构师，知道他们的工作永远不会提供明确的答案。但是，企业可能不习惯这一点。业务架构师用于提供建议、指导或几个选项。相比之下，业务通常会查看业务案例的确定数量。
由于业务能力是一个企业架构概念，它们被概念化以针对广泛的问题提供建议。他们不是为了提供明确的答案，因为他们总是缺乏一些信息。缺乏信息可能是：

• - 更详细的业务能力级别，
• - 该概念未考虑的相互依赖关系，
• - 未捕获用于分析或在此期间发生变化的信息，
• - 以及来自未参与的领域或解决方案架构师的隐性知识。

11. 根据目标状态和运营模式选择合适的工具

获得工具支持以管理您将拥有的大量数据的更新。有不同的选项，从 Excel 列表、SharePoint 解决方案和各种专业的 EA 工具开始，从精益到高度复杂。最后，该工具也必须适合您的目的。但是，请注意，开发业务功能并将信息映射到它们，以及使用它们并显示结果是一项迭代活动，通常需要比最初预期更多的时间。
因此，从一开始就明智地思考：您需要管理多少数据集？应该有多少人有权查看和编辑数据？你期待什么样的视觉表现？您希望多久允许一次更新或新版本？数据需要什么安全级别？根据您对这些问题的回答，您可以初步了解您需要什么样的工具支持。

12.了解你需要的能力类型

在本文中，我谈到了业务能力。但是，许多人会混淆具有相似概念的人。例如，IT（或技术）能力更侧重于技术和解决方案，这些技术和解决方案可以跨越许多不同的业务能力，因此不能显示在同一个能力图中。例如，识别主数据中的拼写错误和重复数据条目并执行数据清理活动的能力。
另一种越来越流行并经常与业务能力混淆的能力是数字能力。数字能力地图的主要区别在于，它们的目标不是描述公司的所有方面，而是只关注数字化感兴趣的方面。因为它们的用例不同于业务能力的用例，所以它们通常更详细，并且只用一个级别进行描述。
如果您想了解业务能力的用例以及它们如何帮助组织转型，请阅读我的文章“业务能力转型组织的 5 大用例”。

原文：https://digitalroadmap-management.medium.com/12-must-dos-to-get-busines…

本文：https://jiagoushi.pro/node/1885

我假设本文的读者已经初步了解什么是业务能力。 如果不是这种情况，请先阅读这篇文章，了解您需要了解的业务能力。

许多组织从业务功能开始，因为有人想以某种方式使用它们。 业务能力仍然是一个相对较新的概念，在概念理论方面几乎没有共识和公认的文献，特别是在定义、开发方法、用例和标准方面。

一些组织已尝试建立标准，但其标准的范围仅限于其组织的边界。 结果是可用的指导很少，开发结果不同，成功案例很少，并且许多持怀疑态度的利益相关者。

为了支持努力发展业务能力的组织，我总结了我在过去几年中学到的最重要的 12 个经验教训：

1. 了解确切的用例

了解您的用例以确定您到底需要什么。业务能力可以支持许多不同的用例，例如业务和 IT 的一致性，跨合并的公司，或者用于未来预算和项目的战略规划。但是，不要以为所有人都可以使用一张业务能力图！事实上，不同用例所需的业务能力在数量、详细程度、层次数量以及应映射的信息和组件方面会有很大差异。

- 例如，应用程序环境的合理化方法可能只需要一些业务功能和映射信息。这些可能是应用程序、成本信息、底层技术的生命周期以及总体结果的业务满意度。

- 相反，需求管理方法可能需要大量详细的功能。对于这样的用例，可以将 20 多种业务能力映射到一个需求。目标是确定现有解决方案已经涵盖了其中的多少。然后，要映射的信息可能是可扩展性、相互依赖性等。

- 对于合并，您不需要任何详细的能力，因为您必须保持在各公司之间仍然具有可比性的水平。

2. 了解所有利益相关者

确定特定业务能力领域的所有相关利益相关者。如果您只与一个部门合作来确定特定领域的业务能力，则不要期望得到一个整体的业务能力图。以定价为例。它不仅由营销部门完成，而且还受到业务中更多领域的影响。以下领域也会对其产生影响：

• - 开发和生产成本，
• - 战略部的战略方面，
• - 最终必须考虑运输、进口、税收、临时和当地折扣等的当地销售商店。

同样，合同管理不仅在客户购买产品或服务时需要，而且与供应商、业务合作伙伴等也需要。您的组织最终可能会出现在不同的市场中，并且有不同的部门，这些部门都有点不同，使用不同的应用程序，并遵循不同的流程。但是，它们都使用相同的业务能力堆栈，最终代表您公司的业务能力图。

3. 理解和解释流程的差异

准备好与“流程人员”进行激烈的讨论。许多组织在为其组织开发详细而复杂的过程描述方面付出了巨大的努力。此外，流程描述通常比业务能力更成熟，因此总会有一些流程的坚定支持者不将业务能力视为可行的替代方案——一开始。强调业务能力优于流程的优势是业务能力成功的关键因素之一，这就是为什么我将在这里简要提及它们的原因：

首先，业务能力总是尽可能地被定义和命名，以便最大限度地从各种利益相关者那里获得理解。例如，它不得包括公司细节，例如技术或特定流程步骤。相反，两个不同公司之间的流程可能会有很大差异，即使它们的名称相同，实际内容也可能会大不相同。

其次，业务能力始终具有三个组成部分，即流程、人员和技术。作为多个组件的结果，使得业务能力随着时间的推移比其单个组件（例如流程）更稳定。

第三，业务能力的目的是提供公司的详尽视图，而不会重叠。它们是一个理论概念，被选择用于最小化两种不同能力之间的相互依赖关系。这使得单独分析它们成为可能。相比之下，流程反映了公司的实际行为，并且没有针对独立分析进行优化。

有了这些优势，还必须了解业务能力的巨大劣势，这是它们的理论性质。为了从能力中受益，组织需要为自己理解和定义概念——如果没有良好的现有指导方针，这是具有挑战性的。这将我们带到要考虑的第四课。

4. 一遍又一遍地传达这个概念

准备好向组织成员解释业务能力的概念 1000 次甚至更多次——在所有不同的层面上。我花了无数时间来介绍和讨论业务能力的概念。一个主要的收获是共享和能够重用内容应该具有非常高的优先级。

一般来说，准备好回答以下问题：为什么是能力？它对我们目前的情况有何帮助？为什么它比我们尝试的最后两个概念更好？我们为什么要使用它们？你会怎么做？你期待什么结果？行政级别的内容是什么？商业用途？为了我？有无穷无尽的问题。

五、严格指导发展

就您期望的业务能力的外观制定和传达非常清晰的指导。如果您已经搜索过其他组织的业务能力图，您会注意到，根据来源，结果可能会有很大差异。同样，这是由于缺少标准化，因为即使是新的 TOGAF 9.2 也在努力新的数字主题，例如仅在非常高的水平上的业务能力

（更新：TOGAF 试图通过其系列指南：业务能力——它确实提供了迄今为止最好的摘要之一，为业务能力主题提供了一些标准化）。

如果没有集中接受的指导，每个利益相关者将创建在细节、维度、考虑的组件和措辞方面不同的业务能力。所有这些方面都使得以后协调和比较结果变得具有挑战性。

根据我的经验，解释不够详细，不足以以人们独立得出相同结果的方式充分定义业务能力。相反，我更愿意提供一些小例子来说明业务能力图最终应该是什么样子。这样，细节级别、语法、组件、范围等属性变得清晰并立即被捕获。

6. 重用和利用现有输入

尽可能多地重用现有资源——内部和外部。第一个业务能力草案通常比理论所暗示的更接近现状。这一点都不错，因为它有助于组织慢慢地将其思维方式转变为基于能力的观点。了解业务能力图的第一个版本作为您的组织可以使用的起点。在下一步中，进一步整合，确定更多属于一起的能力。此外，确定映射中是否还有一个或另一个进程可以转换。

当涉及到内部资源时，请考虑战略文件、流程描述、组织结构图或应用程序的功能。当涉及到外部资源时，请考虑来自 APQC 或 FrameworX 的全球流程标准。但是，请注意，这些输入源都不是完美的，并且每个都有其优点和缺点。

如何开始对业务能力进行建模以及采取哪些输入是重要的一步。

7.意识到这个概念的缺点

来源的缺点之一是会偏向业务能力的组成部分之一：人员、流程或技术。偏见的类型将取决于您决定的来源。显然，如果您使用流程描述来开发第一个业务能力地图草案，那么结果将在某种程度上相似。将不再有泳道、负责或重复的详细流程步骤。然而，它将明确指出，例如人力资源是从雇佣到解雇的，或者研发具有从研究到专利生命周期管理的能力。

另一方面，如果您开始研究应用程序的功能并在逻辑上对它们进行集群，也会存在偏差。结果很可能存在技术偏差，因为您一个接一个地检查系统并考虑每个技术细节。

最后，如果您从组织结构图开始，您可能很快就会掌握您的第一个业务能力级别。这样的能力图将包括营销、生产和采购等能力。但是，如果您在地图中捕获了太多您不希望出现的组织细节（即人员组成部分），例如部门或区域组织，则存在很高的风险。

8. 着眼长远——不要期待短期结果

准备好无法快速交付结果或快速增加价值。业务能力长期成功的最大风险在于它们是非常理论化的。它们是一个需要时间来为组织增加价值的概念。作为企业架构的大多数领域，这些概念需要被组织内的许多人接受。因此，需要收集、分析数据，并且需要传达并再次接受其影响。

这一切都需要时间，如果关键利益相关者不支持这个想法，附加值可能会很快变为零。此外，高层管理人员必须明白，真正的利益将在长期内实现。短期内甚至可能根本没有正面影响！

因此，尽可能展示业务能力的附加值非常重要，尤其是在讨论该概念的价值时。

9. 寻找每一个试点和展示的机会

这对你来说意味着你必须对机会敏感。您的目标应该是通过试点或展示展示业务能力的价值。如果您不断寻找机会，就会有足够的机会。对那些对你的工作比其他人更感兴趣的利益相关者保持敏感。他们可能只是想法相似，并了解背后的真正潜力。留意早期项目，这些项目可能无法协调一部分景观，或者无法清楚地展示其战略前进方向。所有这些情况都可能为您提供一个很好的机会来展示您草拟的业务能力图的某些价值。

10. 管理期望

在您所做的一切中，不要期望获得 100% 准确的最终结果。企业架构师，尤其是业务架构师，知道他们的工作永远不会提供明确的答案。但是，企业可能不习惯这一点。业务架构师用于提供建议、指导或几个选项。相比之下，业务通常会查看业务案例的确定数量。

由于业务能力是一个企业架构概念，它们被概念化以针对广泛的问题提供建议。他们不是为了提供明确的答案，因为他们总是缺乏一些信息。缺乏信息可能是：

• - 更详细的业务能力级别，
• - 该概念未考虑的相互依赖关系，
• - 未捕获用于分析或在此期间发生变化的信息，
• - 以及来自未参与的领域或解决方案架构师的隐性知识。

11. 根据目标状态和运营模式选择合适的工具

获得工具支持以管理您将拥有的大量数据的更新。有不同的选项，从 Excel 列表、SharePoint 解决方案和各种专业的 EA 工具开始，从精益到高度复杂。最后，该工具也必须适合您的目的。但是，请注意，开发业务功能并将信息映射到它们，以及使用它们并显示结果是一项迭代活动，通常需要比最初预期更多的时间。

因此，从一开始就明智地思考：您需要管理多少数据集？应该有多少人有权查看和编辑数据？你期待什么样的视觉表现？您希望多久允许一次更新或新版本？数据需要什么安全级别？根据您对这些问题的回答，您可以初步了解您需要什么样的工具支持。

12.了解你需要的能力类型

在本文中，我谈到了业务能力。但是，许多人会混淆具有相似概念的人。例如，IT（或技术）能力更侧重于技术和解决方案，这些技术和解决方案可以跨越许多不同的业务能力，因此不能显示在同一个能力图中。例如，识别主数据中的拼写错误和重复数据条目并执行数据清理活动的能力。
另一种越来越流行并经常与业务能力混淆的能力是数字能力。数字能力地图的主要区别在于，它们的目标不是描述公司的所有方面，而是只关注数字化感兴趣的方面。因为它们的用例不同于业务能力的用例，所以它们通常更详细，并且只用一个级别进行描述。

如果您想了解业务能力的用例以及它们如何帮助组织转型，请阅读我的文章“业务能力转型组织的 5 大用例”。

原文：https://digitalroadmap-management.medium.com/12-must-dos-to-get-busines…

本文：

德勤平台工程已经积累了提供跨组织领域的复杂解决方案的经验和知识。这些大规模的跨域解决方案为交付带来了更多复杂性。我们的经验表明，通过对问题采取不同的观点，您可以提供的不仅仅是技术成果。

应用平台架构方法不仅会改变这些大型解决方案的架构方式，还会改变组织查看和管理技术的方式。平台架构方法可以在整个解决方案体系结构中提供优势，还可以提高业务灵活性和IT经济性。

在我们深入研究平台方法如何实现这一点之前，我们必须首先回答两个关键问题：平台是什么意思？什么是平台架构？

平台这个词有几个含义，来自传统：

“平坦，凸起的区域或结构”，但在业务环境中，平台意味着：“一系列服务和功能，为业务价值链提供服务”

平台体系结构使业务和技术体系结构与业务域平台保持一致。在此模型下，平台架构意味着：

“将业务构建为领域拥有的技术平台，通过领域拥有和管理的平台服务在领域内提供业务价值。”

以下是如何构建平台体系结构的示例：

采用平台架构方法可以实现几个重要的好处。

业务领域可以拥有所使用的IT应用程序和系统，从而允许域直接管理其技术投资路线图，而不受来自中央IT功能的传统约束。

平台方法有助于使域明确定义关键的“平台服务”，然后通过服务集成模式公开这些服务，以供业务的其他部分使用，也可能用于外部第三方。这还可以使已启用的第三方能够利用它们实现增值，从而实现关键服务的商业化。例如亚马逊，Paypal等

例如，在上图中，第三方可以使用仓库和交付平台服务来形成市场，其中物流和快递公司可以通过平台服务竞标交付。即使是公司使用的IT服务也可以构建为支持IT平台。

将业务划分为平台还可提供结构和变更独立性。平台功能的实现可以独立于其他业务平台发展。这要求通过服务层提供平台服务，将服务接口与实现分离。

虽然这个平台模型有许多好处，但它并不是免费的，需要考虑很多因素。

每个业务平台都需要技能和专业知识来管理，运营和开发自己的技术应用程序。这需要更改业务和IT预算流程。业务领域预算现在需要包括平台IT成本。这也是一个促成因素，因为IT预算成为每个业务领域的责任，而不是与业务分开拥有和分配的中央IT预算。

其平台的域名所有权带来的另一个关键变化是运营和支持平台的新职责，因为它现在充当其他业务部门和其他第三方的服务提供商。

考虑到这些方面需要了解和理解改变平台架构的整体经济性。从表面上看，这似乎是在每个业务领域内建立定制的IT功能，并且需要重复成本和费用。但是，如果从中央资源模型转移到平台资源模型的角度考虑这一点，那么这可以提供更好的资源平衡。通常，中央模型需要携带过多的资源来满足峰值或并发需求。

平台架构通过域自治和独立性提供优势，以发展，适应并向市场提供新服务。实施平台架构和提供平台服务需要跨架构，技术集成和工程学科的技能。如果没有这样的经验和洞察力，不同的平台可能会转变为功能失调的技术领域，阻碍结果而不是赋予它权力。

 

原文：https://platform.deloitte.com.au/articles/2018/platform-architecture/

本文：http://jiagoushi.pro/node/283/edit

讨论：请加入星球【首席架构师圈】或者小号【jiagoushi_pro】

过去的架构师往往把他们的注意力集中在一个静态的物体上。我认为动态变化更重要:人的动态变化，他们与空间和环境条件的互动。

                                                                 --------小约翰·c·波特曼(1924-2017)

摘要

在本文中，我们将业务模型看作是为创造、交付和获取价值而组织的复杂交易活动系统。与其他一些观点不同，我们强调系统组件和它们之间的相互联系。商业活动是由一个利用资源网络的行动者网络来进行的，个别公司寻求配置这些交叉的网络以增强其竞争地位。商业模式文献指的是先行活动在提供环境中的重要性——企业决定追求的机会、采用的战略和必要的能力。在此基础上，我们提出了一种构建业务模型上下文的方法。利用信息系统文献，我们确定了一个工具包促进活动系统架构设计。我们建议这如何引出业务模型的潜在复杂性，并说明视图的多样性如何有意义。

介绍

Chesbrough(2010)认为，与不合适的商业模式结合在一起的好点子比与伟大的商业模式结合在一起的普通点子更不成功。事实上，已经观察到，进行业务的创新方法可以成为竞争优势的来源(例如，Teece, 2010)，导致越来越重视商业模式创新(Foss & Saebi, 2017)。因此，关于从哪里开始，如何创新，以及创新什么的问题引发了一个正在进行的研究议程。可持续发展的业务依赖于收入的产生和其他形式的支持，可能表现为具有特定架构的复杂活动系统(例如，Amit & Zott, 2015;Zott & Amit, 2010)，其发展需要多种观点合理化才能有效。什么是价值主张/交易，为什么它有意义?提供互惠互利的交易在何时何地进行谈判?价值是如何传递的，由谁传递的?一个公司的商业模式如何与其战略和可获得能力相关联(例如，DaSilva & Trkman, 2014;蒂斯,2010)?

企业商业模式不是孤立存在的;它与更广泛的商业生态系统相联系，新的概念从一个并行的创新生态系统中涌现出来(例如，Dougherty & Dunne, 2011)。反思上下文和概念框架被视为寻找满足客户需求的新方法的重要实践(例如，Souto, 2015)。

该文献提供了一些建议，包括如何利用已建立的实践作为模板来设计商业模式(例如，Gassmann et al.， 2014)、如何适应当前的商业模式，以及如何映射现状和未来情况(例如，Osterwalder et al.， 2014)。然而，正如Osterwalder和Pigneur(2013)所指出的那样，“如今许多组织面临的核心问题是，缺乏一个流程，让他们能够提出全新的、可行的商业模式替代方案来进行选择。”

本文通过采用系统设计的观点来考虑以下问题来解决这个问题:什么工具可以帮助我们设计特定于企业的业务模型?我们从构建系统架构设计实践的三个文献流中收集了观察结果:一些面向业务模型，一些面向企业架构，还有一些面向设计思维。然后，我们开发一个可用于支持业务模型架构设计的工具包，并讨论其实用性和与现有文献观察结果的一致性。我们从考虑上下文、表示复杂实体的方法和设计生命周期的问题开始。

背景

在业务模型、企业架构和系统设计文献流中引用了许多文章。在这里，为了简洁起见，我们一般只参考回顾文章和当前观点，因为这些也包含了以前的研究。

商业模式的上下文

虽然商业模型概括了公司的价值创造、获取和交付机制，这是一个普遍的共识，但是有各种各样的定义。其中一种观点认为，“商业模式是组织结构的设计，以实现商业机会”(George & Bock, 2011);另一个指出，“每当建立一个商业企业时，它或显式或隐式地使用一个特定的业务模型，该模型描述了它所使用的价值创造、交付和捕获机制的设计或架构”(Teece, 2010)。Mitchell和Coles(2003)代表了从业者的观点，指出“商业模式包含了‘谁’、‘什么’、‘何时’、‘为什么’、‘在哪里’、‘如何’和‘在多大程度上’为客户和终端用户提供产品和服务的组合元素”。

Massa、Tucci和Afuah(2017)对之前的商业模式研究进行了批判性评估，并确定了构成商业模式的三种观点:1)描述业务的认知/语言模式和相互理解;2)业务模型通用组件的形式化表示/描述;3)关注真正的公司具有的竞争优势和卓越表现。他们思考了为什么会有多种观点，以及商业模式和战略之间的关系，并指出价值创造和获取的传统理论偏向于供应方。客户-提供者价值共同创造的概念是当前需求侧的一个积极讨论的话题(例如，Gronroos & Voima, 2013)。Spieth和合著者(2014)在商业模式创新的背景下也做了类似的观察:首先，解释业务以支持战略发展;其次，代表企业的经营模式，追求效率;第三，通过探索新的机会和可持续竞争优势的来源来发展企业。

DaSilva和Trkman(2013)认为，业务模型代表了一种特定的资源组合(企业的资源基础理论)，通过交易(企业的交易成本经济理论)为客户和企业创造价值。他们将业务模型看作是执行企业战略所需的动态能力的操作配置。Wirtz和合著者(2016)评估了600多篇文章中的研究重点领域、商业模型定义和组件，从而给出了概念的定义，并从战略、客户和市场以及价值创造组件的角度对集成框架的组件进行了描述。与大多数商业模式不同，他们在考虑财务价值产生和获取时，在收入和成本因素中加入了融资和资本模式。

Allee(2000)指出，在知识经济中，尽管传统的价值创造观点认为是供应链及其支持基础设施，但这种观点正在被价值网络的观点所取代。Aversa和合著者(2015)反映了这一观点，根据交互价值创造、捕获和交付结构定义了业务模型的模块化组件。而且，尽管传统的供应链可能侧重于实物产品的流动，但无形产品(如软件)和智力资本都可能是重要的贸易资产。马龙和合著者(2006)在考虑数千家美国企业的相对财务业绩时，采用了商业模式作为分析单元，因为这比使用商业部门过滤器绘制的结果更加连贯。它们以交易资产(金融的、有形的、无形的或智力的;(我们的适应)和交易过程(创造的或获得的资产的所有权转移，作为业主或经纪人提供获得资产的途径)(见表1)，代表了企业所选择的战略选择。有人指出，一些公司建立了不同的运营单位，拥有不同的业务模式，我们注意到一些公司将这些业务结合起来提供独特的价值主张(例如，喷气发动机制造商提供租赁/维修套餐)。在实践中，尽管一个公司可能会选择一个特定的表1模型类型，一个相关的关于特定市场细分的决策集将被制定，以利用公司的动态能力并使商业有意义:框架交易、资源和价值结构(例如，George & Bock, 2011)。这些结构可以根据通用的子层构建块进行阐述，例如使用Osterwalder和Pigneur(2009)的业务模型画布。稍后，我们将进一步讨论这个级别的分析。

Foss和Saebi(2017)回顾了150篇关于商业模式创新的文章，认为存在四个研究空白。第一个与构造有关:定义分析单元加上作为变化范围(业务模型架构级别或模块级别变化)和新颖性程度(对公司或行业来说是新的)的交集的创新本质。第二个与一致性有关:识别先行活动，如战略发展和寻求的创新成果的性质。第三个与权变和调节变量有关，包括组织能力和领导能力、学习和实验的作用、认知和灵活性。第四个与边界条件有关:与其他观点(企业家精神、可持续性、服务化)和公司外部世界的联系。

表1。我们是做什么生意的?十六种核心商业模式类型(改编自马龙等，2006年)

交易的角色	所涉资产类型
	金融	物理	无形的	知识
供应商	企业家	制造商	发明家	教育家
经销商	金融交易员	批发商/零售商	知识产权交易	合作者
房东	金融的房东	物理的房东	知识的房东	承包商
代理	财务代理	物理代理	IP 代理	HR 代理

图1展示了我们从上面得到的信息，它首先表明，一个合适的业务模型的设计受到五个上下文元素的影响。我们观察到，这些元素为公司与更广泛的商业生态系统之间提供了桥梁。其次，这些因素之间有相互作用，独立但与商业模式相联系，例如，匹配市场机会和公司的目标。最后，这些元素中的每一个都可能是一个单独的研究领域。举例说明:我们选择建立什么样的业务(见表1)，它的目标是什么?价值架构是与经济、社会或环境利益的交付相关，还是与它们的某种组合相关(例如，Dembek等人，2018)?

图1所示。影响确定合适商业模式概念的环境因素

复杂系统的表示和设计

我们在此的出发点借鉴了Cilliers(2001)对理解复杂实体方法的回顾。首先，他指出，在描述一个特定的复杂系统时，人们会划定边界，这意味着这个系统嵌入到一个更广泛的复杂系统中。在商业模式研究中，边界通常是单个企业，但在合作企业中，边界可能是半自治企业的集合。其次，有一种形成等级的自然倾向(见Simon, 1962)。这反映在大多数组织结构和建模复杂系统的方法中。最后，复杂操作可以看作是相互连接的节点/模块组成的网络，重点关注它们之间连接的性质。在这里，我们注意到业务模型文献倾向于关注节点(组件)，而较少关注它们之间的连接。

基于市场参与的观点，一些研究人员将商业生态系统网络划分为三种类型的子网络:相互作用的参与者和参与者的纽带、必要的活动和活动的纽带、必要的资源和资源的纽带。公司和商业生态系统之间的个体相互作用(Hakanson & Ford, 2002)和管理实践的本质(Ritter et al.， 2004)被考虑在内。在业务模型结构和之前的观察中，建议采用以下对齐方式:

• 演员债券共同创造和传递价值，包括公司的服务实体、客户和公司内外的价值网络贡献者。
• 活动链接与涉及资产所有权交换或协商资产访问的功能性交互结构相关联。
• 资源债券包括财务、物质(产品、基础设施)、无形(软件、品牌)和智力(信息、知识)组成部分

以这种方式查看业务活动引入了这样一种思想，即业务模型结构可以表示为功能活动的相互连接的网络。

许多研究人员已经利用系统工程工具来帮助表现和优化商业模式:

• 探索将系统动力学建模(仿真)工具用于支持商业模型设计的方法(Cosenz, 2017)
• 考虑企业运营的业务模型和企业架构视图之间的相互作用(Fritscher & Pigneur, 2013)
• 利用Zachman(2003)企业架构框架作为工具，帮助企业架构与业务目标保持一致(Nogueira等人，2013)
• 在业务模型设计的背景下探索系统模块化的思想(Aversa等，2015)

可以看到，映射业务模型组件及其交互是必要的，信息流支持价值、交互和资源结构的链接，利用企业架构工具可以洞察操作活动系统，可能需要适应多个粒度级别。

架构的设计

这里我们的出发点是考虑系统设计过程，包括对预期的系统角色和必要的功能的考虑，以及显示功能组件如何组合在一起的架构描述。Jones和Gregor(2007)回顾了信息系统设计理论的经验，并从产品设计实践中初步学习了其他人所认同的设计过程观点。他们确定了八个需要考虑的演进阶段，其中包含潜在的迭代，这与文献中要求考虑不同业务模型的演进和性能的呼吁产生了共鸣。

在之前关于设计思维在业务模型设计中的应用的研究中，我们在概念、需求和分析的实现级别上比较了传统设计和(提出的)业务模型观点。图2展示了这一点，以及基于组件(模块化)的业务模型设计视图(Aversa等人，2015)。本文前面的讨论建议我们需要包括一个总体上下文级别，并且在实现的模型和需求级别之间需要有一个子组件定义级别，与Zachman(2003)企业架构框架中采用的多个视点一致。设计流程视图如图2所示。

 

 

 

图2。多个设计观点

研究方法

我们正在探索的研究问题是:什么工具可以帮助我们设计特定于企业的业务模型?作者在不同的商业过程建模应用和国防工业系统设计/操作方面有经验，我们编制了用于这些目的的工具列表(例如Mo & Beckett, 2018)，可以用于帮助回答研究问题。

我们首先将业务模型视为具有底层架构的复杂活动系统(Zott & Amit, 2010)。其次，我们效仿Osterwalder和Pigneur(2013)的做法，考虑信息系统工具在支持商业模型设计中的效用。我们最初的目标是支持系统架构描述的开发，为此我们借鉴了国际标准ISO/IEC 42010:2007 (ISO, 2007)。在许多研究者和从业者的贡献下，这个标准已经发展了好几年。这个标准的元素反映了在前面的商业模型设计讨论中所做的观察，例如，需要多视点。该标准的核心——将利益相关者、多种观点和相关的基本原理聚集在一起——被认为与利益相关者理论的应用是一致的(例如，Jensen, 2010)。其中一位作者有超过五年使用该标准的经验，这表明使用设计结构矩阵可以极大地促进多视点之间的交互映射(Browning, 2016)。简单的矩阵，如波士顿咨询集团(BCG)的市场增长份额矩阵，其中一个变量对应另一个变量，长期以来被证明对探索业务场景很有帮助。表1给出了此类矩阵的一个示例。另一种形式的矩阵，关系矩阵，显示哪些系统实体是连接的，并可以描述每个连接的某些属性。我们已经在探索不同业务模型组件之间的交互时使用了它。

发现

开发一个复杂的系统架构描述

ISO/EIC 42010架构描述框架(ISO, 2007)的调整概述如图3所示。框架的一些元素被显示为表示业务模型前因。核心系统体系结构描述表示了一组详细的需求，并通过来自涉众的输入和多个视点(这些视点代表了基于先前经验和模型的知识库)、体系结构的一般形式和选择特定设计的基本原理来提供信息。

我们认为后一组活动代表了从业者使用Osterwalder和Pigneur(2009)业务模型画布来映射公司当前业务模型元素所采用的方法。通常情况下，跨部门的涉众在便利的研讨会环境中工作，提供关于业务模型画布的每个组件的具体的公司信息的多种观点。

图3。业务模型架构描述框架的ISO/EIC 42010:2007表示(ISO, 2007)

与活动理论相联系的商业模式观点

我们遵循Zott和Amit(2010)的指引，将业务模型架构元素表示为基于活动理论的六组件模型，该理论也考虑了元素之间的交互(Engestrom, 2000;琼斯和霍尔特出版社，2008年)。活动理论框架的一些属性是:

• 所有六个部分都是相互关联的，有15个二元的双向联系，这些联系中的紧张关系可以指向创新的机会。例如，买家想要最小化价格，而卖家想要最大化价格。
• 每一个二元环节都可以受到第三个调节成分的影响。例如，可能存在调节主题(服务实体)-对象(价值主张)活动的规则。
• 六组件框架可以作为一种思维方式，并以递归的方式使用。例如，一个单独的对象可以开发新的动态功能，但是谁来做这个工作，可以使用什么工具，对高级活动的潜在影响是什么?

此框架在业务模型上下文中的表示如图4所示。交易活动是核心，服务实体的角色是及时刺激和支持这类活动。达成交易的事件不是连续的，每一个都可能有一些独特的特点。术语服务实体被用来表示活动理论的主体，因为它可能是一个人、一个团队或一个智能代理。谈判交易的性质和交易达成过程可能需要与其他四个要素的互动:市场、公司的动态能力、价值网络和利益/成本架构(例如，以什么成本可以提供什么)。如果我们以这种方式查看所有15个交互，我们将有60个主题需要考虑，这反映了潜在的复杂性。

 

 

图4。业务模型组件及其交互。图中是活动理论框架(Engestrom, 2000)和Zachman(2003)企业架构框架疑问词的组合，括号中显示为(活动理论/ Zachman实体/ Zachman问题)。

我们建议使用Zachman(2003)框架作为映射系统架构的工具。它支持与设计阶段观点一致的多层次粒度描述(如图2)，六个疑问词可以与活动理论元素对齐，如表2所示。

表2。调整业务模型概念:Zachman(2003)架构框架疑问与活动理论(Engestrom, 2000)

商业模式的概念	Zachman架构 框架的疑问词	活动理论业务模型表示
价值结构: 到底是怎么回事?	为什么?(支持动机)	目标:一个互惠互利的价值主张
	什么?(商业交易模式)	规则:收入、收益/成本权衡和监管合同条件
交易结构: 价值/交易谈判	在哪里?(市场活动网络)	社区:市场及其动态
	什么时候?(时间，事件——让它发生)	主题:服务实体(组织交易活动)
资源结构: 价值/交易交付	谁?(人——创造和传递价值)	劳动分工:公司的价值网络
	如何?(功能---驱动流程)	工具:动态功能(可交易和基础设施资产)

 

考虑“什么时候?”观点介绍了一个在商业模式文献中没有很好体现的话题。不同类型的企业有完全不同的参与动力和机制。一个大型的以项目为基础的公司可能一年只谈判几次合同或者每几年一次，而一个销售消耗品的公司可能每几分钟就谈判一次交易。每一种都需要不同类型的服务实体。

映射业务模型组件之间的交互

在研究交互的详细组合时，我们广泛地结合使用了设计结构矩阵工具和其他工具。例如，我们使用四种类型的资产加上四种类型的交易来扩展表1，以创建一个8x8矩阵。一个象限代表了表1中的视图，它可以被解读为给定一个特定的交易模式，我们主要提供什么样的资产。互补的观点表明，鉴于某种特定资产类别的优势，我们的交易选择是什么?资产/资产象限提出了基于资源的观点:如果我们交易的是一种特定类型的资产(例如，无形的，如软件)，那么需要什么其他资产来支持这一点(财务的，物理的，智力的或其他无形的资产)?交易模式/交易模式组合可以说明:我们可以组合什么样的交易模式来作为一种独特商业模式的基础?举个例子，Uber出租车服务模式可以看作是经纪人/房东的结合。这些对话可能有助于设计创新的商业模式概念

结论

本文的引言提出了三个与创新业务模型体系结构设计相关的问题，以及什么类型的工具可以支持这一点。我们做出了最初的贡献，调整了一组工具的使用，这些工具以前应用于不同的专业设置，但以前可能没有在业务模型架构设计上下文中使用过。

第一个问题:从哪里开始?

我们的建议考虑了商业模式文献中作为商业模式设计前提的背景和概念。一个先行模型如图1所示。公司的使命、建立和运作基础是什么?它的运行环境有什么特点?公司有哪些动态能力?我们将动态能力视为可交易资产(可能是产品或提供服务)和基础设施资产的组合，这些资产有助于市场参与、价值创造和价值交付。

第二个问题:如何创新?

设计文献建议遵循一个循序渐进的过程(例如，图2)，在这个过程中，各个阶段之间可能会有迭代。我们的建议是提出关于作为活动系统的商业模式的关键问题。利用一组工具，包括ISO/IEC 42010体系结构描述标准(图3)、考虑业务模型组件之间交互的六组件通用业务模型体系结构(图4)和对Zachman(2003)企业体系结构框架的适应，该框架将具有不同粒度级别的多个观点结合在一起。Zachman框架的一个潜在优势是，它还可以用于在业务模型表示上建立一致的信息系统和技术资源覆盖。这三种工具都具有递归属性，可以应用于全局系统或子系统/组件级别。

第三个问题:创新什么?

我们的建议是遵循自由/开源软件和Saebi(2017)的建议:在组件级创新(例如，增强动态能力)，或者在架构级创新，关注组件之间的交互(例如，改变与客户的关系(参见Osterwalder et al.， 2014)。无论选择哪一个，使用设计系统矩阵来映射在创新过程中可能需要改变的东西。

Amit和Zott(2015)建议在商业模型设计中考虑治理、架构和内容等问题。我们建议，所有受影响的行动者需要被视为利益相关者，并利用活动理论模型(图4)，操作治理可能与跨越内部和外部活动的劳动分工/价值网络安排相关联。

我们通过说明，虽然许多研究者可能寻求商业模式的单一定义，并认为文献在这方面缺乏连贯性，但将商业模式视为一个复杂的活动系统实际上需要多种观点的融合，从而进一步促进了理论的发展。

宏观视图将一种模型类型与企业上下文联系起来(图1和表1)。在这个级别上，一个简单的描述符(如零售商或制造商)传达了对特定业务上下文的某种程度的理解。在这个层面上，商业模式的创新可以通过从一种商业模式转变为另一种商业模式，或者通过考虑特定的组合(例如，制造商加零售商)来促进。在中观层面，重点是通过交易结构和资源结构的组合来实现价值创造和价值捕获(Massa等，2017)。表2演示了企业架构模型的应用程序，该应用程序将这个视点与六个较低级的通用组件链接起来。图4显示了这些组件以及它们之间的交互。这种表述借鉴了活动理论(Engestrom, 2000)，其中提出创新的机会可以在联系之间的紧张关系中找到。其他研究人员可能利用更多的组件，引入更细的粒度级别。我们认为，无论功能体系结构如何表示，都有必要再次以更细的粒度级别描述每个业务模型实例，以来自多个涉众的贡献为基础，以获得可用的表示。此实践在广泛使用的业务模型画布的应用程序中得到了演示，在该画布中建立了便利的讲习班，以填充与每个组件关联的细节。

引入一个交互结构属性映射兑Zachman(2003)体系结构框架是考虑时间因素——查看事务交易事件的事件或集由一个服务管理实体(表2)。这共鸣文献服务主流逻辑,这是未来研究的一个主题。

从从业者的角度来看，正如业务模型画布(或者图4)充当组件级分析的边界对象一样，我们认为ISO/IEC 42010模型(图3)在描述整个系统时也可以起到类似的作用。这种说法是基于与寻求为创新的公私伙伴关系服务的国防工业从业者使用it的直接经验。一组wiki页面取代了画布，每个wiki页面表示模型的一个元素并包含提示，用于支持虚拟团队开发体系结构描述。设计结构矩阵用来表示它们之间的关系。在这个例子中，创新的机会是通过考虑业务上下文中的宏观层面的变化场景来确定的，特别是参照操作环境。

 

References

Allee, V. 2000. Reconfiguring the Value Network. Journal of Business Strategy, 21(4): 36–39.
https://doi.org/10.1108/eb040103

Amit, R., & Zott, C. 2015. Crafting Business Architecture: The Antecedents of Business Model Design. Strategic Entrepreneurship Journal, 9(4): 331–350.
https://doi.org/10.1002/sej.1200

Aversa, P., Haefliger, S., Rossi, A., & Baden-Fuller, C. 2015. From Business Model to Business Modelling: Modularity and Manipulation. In Business Models and Modelling: 151–185. Bingley, UK: Emerald Group Publishing Limited.

Browning, T. R. 2016. Design Structure Matrix Extensions and Innovations: A Survey and New Opportunities. IEEE Transactions on Engineering Management, 63(1): 27–52.
https://doi.org/10.1109/TEM.2015.2491283

Chesbrough, H. 2010. Business Model Innovation: Opportunities and Barriers. Long Range Planning, 43(2-3): 354–363.
https://doi.org/10.1016/j.lrp.2009.07.010

Cilliers, P. 2001. Boundaries, Hierarchies and Networks in Complex Systems. International Journal of Innovation Management, 5(02): 135–147.
https://doi.org/10.1142/S1363919601000312

Cosenz, F. 2017. Supporting Start-Up Business Model Design through System Dynamics Modelling. Management Decision, 55(1): 57–80.
https://doi.org/10.1108/MD-06-2016-0395

DaSilva, C. M., & Trkman, P. 2014. Business Model: What It Is and What It Is Not. Long Range Planning, 47(6): 379–389.
https://doi.org/10.1016/j.lrp.2013.08.004

Dembek, K., York, J., & Singh, P. J. 2018. Creating Value for Multiple Stakeholders: Sustainable Business Models at the Base of the Pyramid. Journal of Cleaner Production, 196: 1600–1612.
https://doi.org/10.1016/j.jclepro.2018.06.046

Dougherty, D., & Dunne, D. D. 2011. Organizing Ecologies of Complex Innovation. Organization Science, 22(5): 1214–1223.
https://doi.org/10.1287/orsc.1100.0605

Engeström, Y. 2000. Activity Theory as a Framework for Analyzing and Redesigning Work. Ergonomics, 43(7): 960–974.
https://doi.org/10.1080/001401300409143

Foss, N. J., & Saebi, T. 2017. Fifteen Years of Research on Business Model Innovation: How Far Have We Come, and Where Should We Go? Journal of Management, 43(1): 200–227.
https://doi.org/10.1177/0149206316675927

Fritscher, B., & Pigneur, Y. 2014. Visualizing Business Model Evolution with the Business Model Canvas: Concept and Tool. In Proceedings of the 16th IEEE Conference on Business Informatics (CBI): 151–158).
https://doi.org/10.1109/CBI.2014.9

Gassmann, O., Frankenberger, K., & Csik, M. 2014. The Business Model Navigator: 55 Models that Will Revolutionise Your Business. London: Pearson UK.

George, G., & Bock, A. J. 2011. The Business Model in Practice and Its Implications for Entrepreneurship Research. Entrepreneurship Theory and Practice, 35(1): 83–111.
https://doi.org/10.1111/j.1540-6520.2010.00424.x

Grönroos, C., & Voima, P. 2013. Critical Service Logic: Making Sense of Value Creation and Co-Creation. Journal of the Academy of Marketing Science, 41(2): 133–150.
https://doi.org/10.1007/s11747-012-0308-3

Håkansson, H., & Ford, D. 2002. How Should Companies Interact in Business Networks? Journal of Business Research, 55(2): 133–139.
https://doi.org/10.1016/S0148-2963(00)00148-X

ISO. 2007. ISO IEC 42010:2007 Systems and Software Engineering -- Recommended Practice for Architectural Description of Software-Intensive Systems. Geneva: International Organization for Standardization (ISO).
https://www.iso.org/standard/45991.html

Jensen, M. C. 2010. Value Maximization, Stakeholder Theory, and the Corporate Objective Function. Journal of Applied Corporate Finance, 22(1): 32–42.
https://doi.org/10.1111/j.1745-6622.2001.tb00434.x

Jones, D., & Gregor, S. & 2007. The Anatomy of a Design Theory. Journal of the Association for Information Systems, 8(5): Article 19.

Jones, O., & Holt, R. 2008. The Creation and Evolution of New Business Ventures: An Activity Theory Perspective. Journal of Small Business and Enterprise Development, 15(1): 51–73.
https://doi.org/10.1108/14626000810850847

Malone, T. W., Weill, P., Lai, R. K., D’Urso, V. T., Herman, G., Apel, T. G., & Woerner, S. 2006. Do Some Business Models Perform Better than Others? MIT Sloan Working Paper 4615-06. Cambridge, MA: MIT Sloan School of Management.

Massa, L., Tucci, C. L., & Afuah, A. 2017. A Critical Assessment of Business Model Research. Academy of Management Annals, 11(1): 73–104.
https://doi.org/10.5465/annals.2014.0072

McGrath, R. G. 2010. Business Models: A Discovery Driven Approach. Long Range Planning, 43(2-3): 247–261.
https://doi.org/10.1016/j.lrp.2009.07.005

Mitchell, D., & Coles, C. 2003. The Ultimate Competitive Advantage of Continuing Business Model Innovation. Journal of Business Strategy, 24(5): 15–21.
https://doi.org/10.1016/j.lrp.2009.07.005

Mo, J. P. T., & Beckett, R. C. 2018. Engineering and Operation of Systems of Systems. Boca Raton, FL: CRC Press.
https://doi.org/10.1201/9781315206684

Morris, M., Schindehutte, M., & Allen, J. 2005. The Entrepreneur’s Business Model: Toward a Unified Perspective. Journal of Business Research, 58(6): 726–735.
https://doi.org/10.1016/j.jbusres.2003.11.001

Nogueira, J. M., Romero, D., Espadas, J., & Molina, A. 2013. Leveraging the Zachman Framework Implementation using Action – Research Methodology – A Case Study: Aligning the Enterprise Architecture and the Business Goals. Enterprise Information Systems, 7(1): 100–132.
https://doi.org/10.1080/17517575.2012.678387

Osterwalder, A., & Pigneur, Y. 2009. Business Model Generation. Hoboken, NJ: John Wiley & Sons.

Osterwalder, A., & Pigneur, Y. 2013. Designing Business Models and Similar Strategic Objects: The Contribution of IS. Journal of the Association for Information Systems, 14(5): Article 3.

Osterwalder, A., Pigneur, Y., Bernarda, G., & Smith, A. 2014. Value Proposition Design: How to Create Products and Services Customers Want. Hoboken, NJ: John Wiley & Sons.

Ritter, T., Wilkinson, I. F., & Johnston, W. J. 2004. Managing in Complex Business Networks. Industrial Marketing Management, 33(3): 175–183.
https://doi.org/10.1016/j.indmarman.2003.10.016

Simon, H. A. 1962. The Architecture of Complexity. Proceedings of the American Philosophical Society, 106(6): 467–482.
https://www.jstor.org/stable/985254

Souto, J. E. 2015. Business Model Innovation and Business Concept Innovation as the Context of Incremental Innovation and Radical Innovation. Tourism Management, 51: 142–155.
https://doi.org/10.1016/j.tourman.2015.05.017

Spieth, P., Schneckenberg, D., & Ricart, J. E. 2014. Business Model Innovation – State of the Art and Future Challenges for the Field. R&D Management, 44(3): 237–247.
https://doi.org/10.1111/radm.12071

Teece, D. J. 2007. Explicating Dynamic Capabilities: The Nature and Microfoundations of (Sustainable) Enterprise Performance. Strategic Management Journal, 28(13): 1319–1350.
https://doi.org/10.1002/smj.640

Teece, D. J. 2010. Business Models, Business Strategy and Innovation. Long Range Planning, 43(2-3): 172–194.
https://doi.org/10.1016/j.lrp.2009.07.003

Wirtz, B. W., Pistoia, A., Ullrich, S., & Göttel, V. 2016. Business Models: Origin, Development and Future Research Perspectives. Long Range Planning, 49(1): 36–54.
https://doi.org/10.1016/j.lrp.2015.04.001

Zachman, J. A. 1987. A Framework for Information Systems Architecture. IBM Systems Journal, 26(3): 276–292.
https://doi.org/10.1147/sj.263.0276

Zachman, J. A. 2003. The Zachman Framework: A Primer for Enterprise Engineering and Manufacturing. Zachman International, Accessed November 2018:
http://www.zachmaninternational.com

Zott, C., & Amit, R. 2010. Business Model Design: An Activity System Perspective. Long Range Planning, 43(2): 216–226.
https://doi.org/10.1016/j.lrp.2009.07.004

Zott, C., Amit, R., & Massa, L. 2011. The Business Model: Recent Developments and Future Research. Journal of Management, 37(4): 1019–1042.
https://doi.org/10.1177/0149206311406265

 

原文：https://timreview.ca/article/1252

本文：http://jiagoushi.pro/node/1109

讨论：请加入知识星球【首席架构师圈】或者小号【jiafoushi_pro】

活动风暴是一种快速探索复杂业务领域的研讨会形式。研讨会重点关注在业务流程或业务应用程序的上下文中生成的域事件。域事件是在域中发生的有意义的事情。研讨会侧重于产品所有者，领域专家和开发人员之间的沟通。

事件风暴方法由Alberto Brandolini在介绍EventStorming中介绍和公布。这种方法在领域驱动设计社区中被认为是一种快速捕获解决方案设计并提高团队对设计的理解的技术。 EventStorming的这种变体包含对事件驱动架构设计有用的改进和扩展。扩展方法通过添加有关未来可能事件的预测性见解，增加了识别和捕获价值的洞察力。通过使用数据科学分析，数据模型，人工智能（AI）或机器学习生成预测性见解。

对于实际研讨会的详细输出，该研讨会应用事件风暴和洞察力冲击全球集装箱运输，请参阅集装箱运输分析。

举办活动和洞察力风暴研讨会

在您举办活动风暴研讨会之前，请完成企业设计思维研讨会，您可以在其中开发人物角色和移情地图，并定义业务难点和目标。事件风暴研讨会为流程的每个步骤中发生的事件，微服务的自然环境以及指导系统操作的预测性见解添加了更具体的设计。

通过这种方法，包含业务所有者和利益相关者的团队可以为解决方案定义最小可行产品（MVP）。最终的设计被组织为松散耦合的微服务的集合，这些微服务通过事件驱动的体系结构和一个或多个事件主干链接。这种设计风格可以部署到多云执行环境中，并允许扩展和敏捷部署。

完成这些任务以准备活动风暴研讨会：

• 找一个足够容纳至少6到8人的房间，并且有足够的墙面空间来张贴大纸张。您需要墙面空间来定义模型。
• 收集不同颜色的粘滞便笺，黑色标记或笔，以及蓝色画家的胶带。
• 不鼓励在会议期间使用开放式笔记本电脑。
• 限制椅子的数量，以便团队保持专注和连接以及对话流程。

概念

在活动风暴研讨会期间使用的许多概念都是在域驱动设计方法中定义的。 下图显示了分析过程中使用的元素。 第一个图显示了该过程中使用的初始概念集。

域事件也称为业务事件。 事件是在特定时间在系统中发生的操作。

事件风暴过程的第一步包括以下操作：

• 识别域中的所有相关事件以及您正在分析的特定过程
• 在便利贴上写下每个事件的简短描述
• 在时间轴上按顺序放置所有事件便签

编写事件描述的行为通常会导致需要稍后解决的问题或有关需要记录的定义的讨论，以确保每个人都同意基本的域概念。

域事件的时间线是事件风暴过程中第一步的关键输出。 时间表使每个人都能够了解事件何时发生在彼此之间。 您仍然需要采用这种初始理解水平并将其转向实施。 在进行该步骤时，请扩展您的思路以包含命令的概念，该命令是启动触发事件的处理的操作。 作为理解命令角色的一部分，您想知道谁启动命令（actor）以及允许命令运行所需的信息。 此图显示了这些分析元素如何链接在一起：

• Actor通过用户界面消费数据，并通过发出命令与系统交互。 AI代理也可以替换演员。
• 命令是用户决策或策略的结果。它们作用于CQRS模式中的Read模型的相关数据。
• 策略是在事件发生后发生的反应逻辑。在此示例中，策略由浅紫色便签指示。策略会触发其他命令。策略总是以“when ...”开头。策略可以是人类遵循的手动步骤，例如文档化的过程或指导，或者它们可以是自动化的。应用敏捷业务规则开发方法时，策略将映射到决策模型表示法中的决策。
• 外部系统产生事件。
• 数据可以在用户界面中呈现给用户或由系统修改。

事件可以通过命令或外部系统创建，包括物联网（IoT）设备。事件可以通过处理其他事件或经过一段时间来触发。当事件重复或按计划定期发生时，在该事件的便签的角落绘制时钟或日历图标。

当您识别事件并将它们放入时间线时，您可能会发现独立的后续事件彼此不直接耦合并且代表系统的不同视角，但这些事件发生在重叠的时间段内。您可以将这些并行事件流放入单独的泳道中，这些泳道由水平蓝色画家的磁带识别。

当您将事件组织到时间线中时（可能使用泳道），您可以识别关键事件。关键事件表明域中的主要变化，并且经常形成系统的一个阶段与另一个阶段之间的边界。它们通常在域驱动设计术语中分离，或者是有界的上下文。关键事件由垂直蓝色画家的磁带识别，穿过所有泳道。

此示例显示已完成事件时间轴的一部分，其中包含关键事件和泳道：

举办研讨会

研讨会的目标是更好地了解未来应用程序要解决的业务问题。该方法还可以应用于找到瓶颈或应用程序中的其他问题的解决方案。该研讨会通过在业务流程生命周期内构建域事件的时间表，帮助团队了解解决方案的总体情况。

避免在研讨会期间记录处理步骤。您没有尝试指定特定的实现。相反，在研讨会的初始阶段，重点是识别和排序解决方案中发生的事件。事件时间表是整个步骤的有用表示。它传达必须发生的事情，但允许许多可能的实现方法。

第1步：域事件发现

首先在粘滞便笺上写下每个域事件，并用过去时的几个单词和一个动词。在此示例中，使用橙色便签。描述发生的事情。首先，通过让每个域专家生成单独的域事件列表来“暴乱”事件。最初，您可能不需要将事件放在有序时间轴上。这些事件必须以对域专家和业务利益相关者有意义的方式措辞。您正在解释业务术语中发生的事情，而不是系统实施中发生的事情。

您无需描述域中的所有事件，但必须涵盖您有兴趣从头到尾探索的过程。确保您识别开始和结束事件，并将它们放在墙的开头和结尾的时间轴上。将您在这两个端点之间确定的其他事件放在团队可以按顺序达成一致的最接近的近似值中。不要担心重叠，因为您稍后会解决它们。

第2步：讲述故事

在这一步中，您将通过讨论如何将事件与角色相关联来重述故事。团队成员采用域中角色的视角，并询问哪些事件跟随哪些事件。这个团队成员通常是推动者，但其他人也可以扮演这个角色。

例如，辅导员可以采用想要将小部件发送给客户的制造商的观点。从该角色的互动开始，然后问：“接下来会发生什么？”拿起并重新排列团队风暴的事件。如果您发现重复的事件，请将重复的事件从墙上取下。如果事件的顺序错误，请将它们按正确的顺序移动。

如果某些部分不清楚，请使用不同颜色的便签添加问题或评论。在此示例中，使用红色便签。这些粘滞便笺表明团队需要跟进并在以后澄清问题。同样，使用这段时间来记录定义粘滞便笺的假设。在您浏览故事时，步骤2也是重新定义事件的好时机。有时，您需要通过将动词置于过去时或者将用于与其他已识别事件清楚地关联的术语进行调整来重新定义事件描述。

在此步骤中，您将专注于主线“快乐”的端到端路径，以避免在异常和错误处理的细节中迷失。以后可以添加例外。

第3步：找到边界

此过程的下一步是通过查看事件来查找系统的边界。可以出现两种类型的边界。第一种边界是时间边界。通常，特定的关键事件表明从系统的一个方面到另一个方面的变化。这种变化可以在从一个人到另一个人的交接中发生，但也可以在地理，法律或其他类型边界的变化时发生。如果您注意到事件便签上的术语在这些边界处发生了变化，那么您将看到域驱动设计术语中的“有界上下文”。通过将蓝色画家的磁带垂直放在事件后面突出显示关键事件。

第二种类型的边界是主题边界。您可以通过查找以下条件来检测主题边界：

• 您有多个同时发生的一系列事件，这些事件只会在以后汇集
• 在一系列事件的事件描述中使用相同的术语。
• 当您重播时，您可以从不同角色的角度“阅读”一系列事件。

通过水平应用蓝色画家的胶带，将墙分成不同的泳道，指示这些不同的同时事件流集。

此图是一组有序域事件的示例，其中指示了关键事件和主题泳道。此示例来自将事件风暴应用于集装箱运输领域，并在“集装箱运输分析”示例中进行了更详细的讨论。

 

第4步：找到命令

在此步骤中，您将从域分析转移到系统设计的第一阶段。到目前为止，您试图了解域中的事件如何相互关联，这就是域专家参与至关重要的原因。要构建一个实现您感兴趣的业务流程的系统，您必须继续讨论这些事件是如何发生的。

命令是用于创建事件的最常用机制。查找命令的关键是询问“为什么会发生此事件？”在此步骤中，流程的重点将转移到导致事件的操作序列。您的目标是找到事件记录效果的原因。预期事件触发器类型的示例如下：

• 人类操作员做出决定并发出命令。
• 外部系统或传感器提供刺激。
• 事件由策略产生，通常是前体事件的自动处理。
• 完成一段确定的经过时间。

在此示例中，触发命令在蓝色粘滞便笺上标识。此命令可以在以后的实现中成为微服务API。发出命令的人物角色在黄色便条上标识。在步骤5的图表中，制造商演员请求在集装箱中交付货物的报价。当报价到达时，制造商使用发货订单命令来创建装运订单放置事件。

您可以链接事件和命令，如“概念”部分中的分析图所示。

第5步：描述数据

如果不了解命令运行以生成事件所需的数据，则无法真正定义命令。您可以在此步骤中识别多种类型的数据。首先，用户（角色）需要来自用户界面的数据才能在运行命令之前做出决策。该数据构成CQRS实现中的读取模型的一部分。对于每个命令和事件对，您添加了做出此类决策所需的预期属性和数据元素的数据描述。下图显示了从装运订单操作的位置创建的装运订单放置事件的简单示例。

在此步骤中，您还可以更全面地描述可以触发从上一个事件或一组事件生成事件的策略。

第一级数据定义可帮助您评估微服务范围和责任，因为您开始看​​到从几个相关事件中使用的数据中出现的共性。这些概念在下一步中变得更加明显。

第6步：确定聚合

在域驱动设计中，实体和值对象可以独立存在，但通常关系是实体或值对象没有其上下文时没有值。聚合通过构成一个或多个实体的根和通过生命周期链接在一起的值对象来提供该上下文。在事件风暴中，聚合通过对相关事件和命令进行分组而在整个过程中出现。此分组不仅包含相关数据（实体和值对象），还包含由该聚合的生命周期连接的相关操作（命令）。最终，聚合建议微服务边界。

在此容器装运示例中，您可以对命令和事件对及其关联数据进行分组，这些数据与运输订单的生命周期相关。

第7步：定义业务环境

在此步骤中，您可以使用在明确边界内有效的明确含义来定义术语和概念。术语定义可以在为应用程序开发的业务单元之外进行更改。

第8步：展望未来

在事件驱动架构解决方案的风暴中，包括额外的步骤来识别有用的预测分析洞察。

Insight storming通过展望并考虑如果您事先知道事件将要发生可能会发生什么，扩展了基本方法。这些知识如何改变你的行为，你会在事件发生之前做些什么？

将洞察力视为将分析扩展到派生事件。衍生事件不是过去事件的事实记录，而是前瞻性或预测性事件。也就是说，“这个事件可能会在接下来的n个小时内发生”。

通过使用这种前瞻性洞察力和来自早期事件的已知业务数据，人员和事件触发策略可以更好地决定如何在新事件发生时做出反应。在洞察力冲击中，您询问研讨会参与者，“哪些数据对每个事件触发有帮助，以帮助人类用户或自动事件触发策略来决定如何以及何时采取行动？”

推动使用事件驱动架构的一个重要动机是它简化了高响应系统的设计和实现。这些系统以个性化和上下文感知的方式立即和智能地做出反应，并在新事件发生时对其进行最佳响应。这种反应性表明，预测分析和生成预测性见解的模型可以发挥重要作用。

预测性分析洞察力是关于未来事件可能发生的有效概率陈述以及这些事件的可能属性。这些概率陈述是通过使用由数据科学家创建的模型或使用AI或机器学习生成的。关联或连接独立收集的信息源也可以生成重要的预测见解或输入预测分析模型。

事件风暴研讨会的企业主和利益相关者可以在以下几个方面提供良好的直觉：

• 哪些概率见解可能会导致改进或最佳决策和行动？
  • 该操作可能采取对事件发生时立即响应的形式。
  • 该行动可能是主动行为，以避免不良事件。
• 什么综合信息来源可能有助于创建一个模型来预测这种洞察力？

通过基本事件风暴，您可以回顾每个事件，因为事件发生了。当您确定参与者或策略决定何时以及如何发出命令所需的数据时，您可以将注意事项限制为先前已知和捕获的业务事件的属性。在洞察力冲击中，您可以扩展方法以期待并考虑特定事件可能发生的概率以及其预期的属性值可能是什么。如果发生此事件，这些知识将如何改变最佳行动？您是否可以在预期的不良事件发生之前主动采取行动以防止其发生或减轻后果？

在洞察步骤中，研讨会参与者通过添加派生事件以及生成它们的模型所需的数据源来识别价值。添加使用这些问题的洞察力攻击步骤可以改善最终设计中的决策制定和主动行为。

通过识别派生事件，您可以将分析模型和机器学习集成到设计的解决方案中。可以处理，过滤，加入，汇总，建模和评分事件和派生事件源，以创建有价值的预测性见解。

在洞察步骤中使用这些新表示法：

• 派生事件的一种粘滞便笺。在这个例子中，使用淡蓝色粘滞便笺。
• 平行四边形图显示何时组合事件和派生事件以实现更深入的洞察模型和预测。

在开发生命周期中尽早识别预测性见解。识别它们的最佳方法是将此步骤添加到事件风暴研讨会中。

这两个图表显示了集装箱运输分析用例的洞察力测试步骤的结果。第一张图捕获了每个冷藏集装箱的见解和相关联系。它确定何时可以对恒温器设置进行自动更改，何时必须安排单元维护，以及何时必须考虑容器内容损坏。

第二张图捕获了可能触发建议以调整船舶航向或速度以响应某些条件的见解：

• 预计未来路线的恶劣天气预报
• 在下一个停靠港预测拥堵和预期的对接和卸载延迟

活动风暴和用户故事

在敏捷方法中，创建用户故事或史诗是项目管理中最重要的元素之一。 与事件相关的命令和策略可以描述为用户故事，因为命令和决策由演员完成。 演员也可以是一个系统。 对于数据，您必须将创建，检索，更新和删除操作建模为用户故事，主要由系统角色支持。

事件是用户故事的结果或结果。 可以添加事件作为用户故事的验收标准的一部分，以验证事件是否发生。

来自集装箱运输用例的事件风暴工件

K Container Shipment用例演示了验证事件驱动架构的实现解决方案。 此集装箱运输分析示例显示了事件风暴和主要的企业设计思维工件，包括用于监控冷藏集装箱的工件。

What's next

• Check out the original paper about EventStorming by Alberto Brandolini.

• Read A step by step guide to Event Storming, which describes Boldare's experience with conducting event storming workshops.

• Get an introduction to Domain-Driven Design.

• See Eric Evan's book on Domain Driven Design - Tackling complexity in the heart of software.

• Review this collection of Patterns related to Domain Driven Design by Martin Fowler.

 

原文 ： https://www.ibm.com/cloud/garage/architectures/eventDrivenArchitecture/event-storming-methodology

讨论:加入知识星球【首席架构师圈】

参与重大战略变革（如合并，收购和剥离）的组织通常主要关注变革的财务和市场方面。对您的市场份额有何影响？如何增加供应商的购买力？利用协同效应可以节省多少成本？组织和人力资源问题也是高管参与的首要考虑因素。

但是，通常在游戏后期才会考虑在更高的操作级别进行整合。企业领导者必须确保整个组织的利益相关者之间的有效协作，以便他们获得必要的见解并提高决策的质量和速度。

合并或收购期间要解决的挑战

将来自不同母公司的业务流程和IT系统结合起来很复杂。它需要回答以下问题：

• 接管目标的哪些功能有所区别，哪些是常见的或与您自己的重叠？
• 不同产品组合之间的潜在协同作用是什么？
• 我们如何整合系统并减少技术债务？
• 我们如何确定业务流程的最佳实践？

•  

剥离期间要解决的挑战

在资产剥离中，我们遇到的问题包括：

• 什么是必要的业务流程和IT系统，哪些是多余的？
• 在将部分企业出售给新的所有者时，我们的业务和IT环境中的哪些依赖关系特别重要？
• 在剥离部分业务后，我们如何清楚地定义我们自己未来的业务和IT状态？我们现在需要填补哪些空白？
• 哪些部分需要重复，因为它们对剥离和收购组织都至关重要？
• 我们如何处理涉及的数据？应该转移什么以及必须保留什么

模型如何帮助回答这些问题？

为了支持处于如此复杂情况的组织，模型是必不可少的工具。

• 模特不仅仅是漂亮的照片
• 模型提供精确，明确定义和明确的信息。可以检查，可视化，分析，管理，集成，转换，解释模型，有时甚至执行模型。
• 模型可用于不同的业务和技术领域
• 组织对合并，收购或剥离的不同阶段使用不同类型的模型，例如战略地图，流程图，架构视图，产品分解结构和组织结构图。
• 通过模型，您可以分析功能，产品，流程，人员和系统之间的所有关系
• 模型提供有关所有这些依赖关系的信息，从战略到操作的所有连接。因此，您可以通过其可交付成果，它影响的应用程序，这些应用程序支持的业务流程和产品以及这些有助于实现的业务目标，了解某些IT项目对整体业务战略的贡献。
• 模型支持基于事实的决策
• 模型可以整合来自各种来源的数据，确保其一致性，并为有根据的决策提供重要的输入。例如，将财务数据与架构模型中的结构信息相关联对于计算IT整合项目的潜在节省至关重要，提供比仅仅基于某些财务的简单回报估计更好的数据数字，没有考虑您的架构中可能会阻碍看似简单的解决方案的依赖关系。
• 模型可帮助您在应用更改之前分析更改的影响
• 使用模型评估企业的各个方面和元素之间的联系和依赖关系，有助于理解变更的影响，风险和收益。在进行合并或资产剥离之前这样做有助于降低与此类重大转型相关的风险。

下图中显示了其中几个方面，我们在合并后不久看到了保险公司的（简化）能力图。这用于突出显示支持这些功能的底层应用程序环境显示效率低下的位置，例如重复。通过这种方式，管理人员可以快速确定应关注哪些内容以及应用程序整合工作可能会影响哪些功能。

当然，模型的使用需要可靠的软件支持。 BiZZdesign独特的Enterprise Studio平台为所涉及的许多学科提供建模和分析支持，从战略开发和项目组合管理到架构，流程和数据管理。这使您可以对您的并购或剥离进行综合视图，从组织的战略方向和业务模式通过其架构和设计，到变更计划的优先级划分。

为您的利益相关者带来的好处

模型的使用可以使所有利益相关者受益，包括C级决策者; LoB管理等企业主;投资组合，项目和项目经理;建筑师和设计师;和那些在日常运作中的人。他们可以对所涉及的更改有自己的看法，Enterprise Studio以用户友好的方式呈现与其工作相关的那些方面。所有这些观点都基于单一的事实来源，确保一致性和透明度。

这种方法的好处很明显：

• 通过更快地利用协同效应，股东可以看到合并的时间更短。
• C级处于控制之中，具有决定合并，收购或剥离的成本，收益和风险的必要事实。
• 建筑师和设计师拥有降低复杂性和增加协同效应所需的信息。
• 投资组合经理可以根据成本，价值和风险的准确数据设定优先级。
• 计划和项目经理有明确的范围，知道他们所负责的举措是如何与他人相互依赖的。
• 运营经理了解什么是关键业务，可以降低运营风险。
• 风险和合规经理可以确保由此产生的企业符合内部和外部法规的条款。

了解更多有关BiZZdesign Enterprise Studio如何帮助您在我们的资料单中成功完成合并，收购或资产剥离的信息，您可以点击下面的链接找到。

原文：https://bizzdesign.com/blog/how-enterprise-models-contribute-to-successfully-completing-a-merger-acquisition-or-divestiture/

本文：http://pub.intelligentx.net/how-enterprise-models-contribute-successfully-completing-merger-acquisition-or-divestiture

讨论：请加入知识星球【首席架构师圈】

在我们之前的博客中，我们简要概述了我们的示例保险公司ArchiSurance正在探索的两个战略选择。 通过分析卓越运营战略，他们将其效率与行业平均水平进行了对比：平均能力以蓝色显示，高于绿色平均能力和低于平均水平的红色能力（图1）。 以红色显示的功能是ArchiSurance希望在卓越运营战略背景下找到改进空间的地方。

下面的示例显示了如何使用蜘蛛图表更详细地可视化您的功能分析。 每个图表显示了沿不同轴的功能的当前和期望性能。 此页面上的示例显示了此功能的增量开发概念。 对于“索赔管理”功能，定义了六个维度。 此功能的基线分析会生成不同尺寸的值，这些值使用红线链接。 所需的成熟度（细分为各个尺寸的值）用绿线表示。

图2.能力分析。

对于功能分析的不同维度，我们使用ArchiMate 3.0的语言自定义机制将Metric概念定义为Driver的特化。度量标准可以是复合的，如图所示：能力分析的过程维度包括过程适应性，成熟度，性能和方差的加权平均值。当然，您需要以支持组织战略方向的方式定义指标。

在BiZZdesign Enterprise Studio中，您可以轻松定义此类指标。这些可以基于外部导入的数据，也可以基于模型的分析。例如，您可以通过它们支持的流程跟踪应用程序对策略的重要性，这有助于实现提供预期业务成果所需的功能。

从更广泛的意义上讲，能力被证明是与您组织的战略一致的资本分配的良好起点。能力分析可以帮助您制定投资计划，例如为需要在一个或多个维度上实质性改进的那些能力分配更多预算。它们提供了解决特定结果的业务的连贯部分。 Enterprise Studio的项目组合管理功能非常适合支持此类决策。

ArchiSurance战略实施的下一步是实现这些所需的功能和能力水平。此外，ArchiSurance需要新的功能来实现其“数字客户亲密度”战略。我们将在下一篇博客中解决这个问题。我们还将讨论功能和业务功能之间的差异，这是一个经常讨论的主题。

原文:https://bizzdesign.com/blog/archimate-3-0-capability-analysis/

本文:http://pub.intelligentx.net/enterprise-architecture-archimater-30-capability-analysis

讨论:加入知识星球【首席架构师圈】

正如我们在之前的博客中看到的那样，ArchiSurance希望建立几项新功能来支持其“数字客户亲密度”战略，例如数字客户管理，数据驱动保险，数据采集和数据分析。 将这些定位在其当前功能的上下文中，使用BiZZdesign Enterprise Studio的“突出显示”功能来强调这些新元素。

能力与业务职能

请注意，业务功能与功能不同。能力代表组织当前或所需的能力，通过其人员，流程，信息和技术实现。它们专注于特定的业务成果，并用于战略规划目的。相比之下，业务功能描述了组织实际完成的工作;它们通常是明确管理的，并且与组织结构更紧密地结合在一起。每个功能在能力图中仅发生一次，而在企业的功能分解中，相同的子功能可以多次发生。

在描述基准业务体系结构时，功能映射的价值主要在于分析当前与期望的功能级别，以及发现组织已拥有但未明确识别或管理的功能。目标业务体系结构中的功能和功能级别为更改提供了高级方向。这是基于能力的计划的核心。

当然，当您绘制组织当前功能的地图时，其当前的业务功能通常会占据显着位置，因为您今天实际所做的事情本质上必须是您能够做到的事情。并且多个业务功能（可以与其他元素一起）有助于实现能力。

下图显示了上图中ArchiSurance的许多主要功能与其当前业务功能之间的一些关系。上图中的新子功能是此图中两个绿色功能的一部分。这些可以通过扩充现有的业务功能（及其中的流程）来实现，但它们也可能需要新的功能和资源。例如，数据驱动的保险能力及其子能力可能需要建立一个全新的组织部分，并且精算，索赔和承保业务职能可能会发生重大变化。

这些功能需要由合适的资源支持，包括具有适合数字时代的知识和技能的人员，用于数据采集的智能设备以及客户数据本身。

这些资源本身由企业架构核心实现。这也可能是导致这种情况的一小部分。请注意，这并未描述实现这些资源所需的所有元素，而只描述了代表性的示例。实际上，通常会创建单独的视图来显示各个功能和资源是如何实现的。

通过将所有内容放在一起，这可以提供从您的不同资产到其支持的功能以及我们之前博客中概述的策略，目标和结果的视线。您甚至可以通过将更详细的模型（例如BPMN中的流程或UML中的数据）连接到ArchiMate中的体系结构模型，只需将这些模型链接到BiZZdesign Enterprise Studio中即可。通过这种方式，您可以深入了解战略决策的影响，反之亦然，可以发现您所使用资源提供的新选项和创新。规划，执行和控制整个企业的变更从未如此简单！

原文：https://bizzdesign.com/blog/archimate-3.0-capability-realization/

本文:

讨论:加入知识星球【首席架构师圈】

Salesforce 运营、治理和架构框架 (SOGAF) 将 MIT-CISR 企业架构框架应用于 Salesforce 实施和程序。

介绍

运营模式有两个维度：业务流程标准化和业务流程集成。业务流程和相关系统的标准化意味着准确定义流程的执行方式。运营模式可提高整个公司的效率和可预测性。

业务流程的集成通过共享数据将组织单位的工作联系起来。这种数据共享可以在流程之间进行，以实现端到端的交易处理，也可以在流程之间进行，以使公司能够向客户提供统一的体验。业务流程集成的好处包括提高效率、协调性、透明度和敏捷性。

运营模式类型

SOGAF中有四种运营模式：

• 多样化（不同的流程和数据）
• 复制（相同的进程，不同的数据）
• 协调（不同进程、共享数据）
• 统一（相同流程，共享数据）

适当的运营模式将取决于业务流程标准化的水平和所需的数据集成水平。该运营模式将推动整个公司提高效率和可预测性所需的技术能力，如下所示：

如何选择运营模式

选择取决于您的业务流程是否相同以及数据是否在此决策树中显示的业务单位之间共享。 突出显示的方块表示应针对每种情况评估的两种运营模式。 在实践中，公司倾向于坐在四种模式中的两种模式之间的连续统一体上。

关于贡献者

Martin Griffiths 是 Salesforce 的业务架构师总监，具有英法背景，常驻法国巴黎。 Martin 5 年前加入 Salesforce。 他在 CRM、ERP 和数字化转型方面拥有 30 年的职业生涯，涵盖业务咨询、企业架构和项目交付角色。 他的重点是为客户提供基于 Salesforce 的复杂转型、运营模型和架构方面的建议，应用学术框架来指导决策制定并成功解决大规模主题的治理问题。

原文：https://architect.salesforce.com/govern/operating-models/sogaf-operatin…

本文：https://jiagoushi.pro/node/1872

过去，APQC就APQC的产品（流程管理、内容/知识管理和基准测试）详细讨论了流程分类框架®（PCF）。受同事Holly最近研究的启发，我开始思考APQC如何在企业架构（EA）领域定位自己。专注于企业架构的组织如何利用APQC的PCF实现更好的EA结果？我们的流程管理工具MosaiQ®如何加速EA工作？我们的流程管理方法如何减少返工？

什么是企业架构？

企业架构有很多定义。有些重叠。有些冲突。一些人将这一概念推向了新的方向。我并没有试图设定EA是什么的标准定义，所以我更愿意投入其中，让你知道我是如何看待它的。企业架构是对企业建模并管理相关模型的实践。原则上简单，执行上复杂，就像所有事情一样。

企业架构中包括哪些模型？

让我们花一分钟讨论一下理解企业常用的各种模型：

• 组织结构——我们如何组织起来为客户和股东创造价值；包括人员、地点和物品——所有必要的资源
• 流程模型–我们如何为客户和利益相关者创造价值
• 系统架构–我们如何自动化各种流程和数据流
• 数据模型–我们处理哪些信息来运营我们的业务，以及如何管理这些信息
• 产品/服务组合–我们将哪些产品和服务推向市场，为股东创造价值？

这些都是企业架构的一部分吗？当然–它们是企业特定方面的模型。

但问题出现了：孤立的模型最终会收敛。组织模型开始定义流程。数据模型指的是系统架构。流程模型包括数据模型和系统架构。

趋同：好，坏，还是丑？

当模型在没有治理的情况下聚合时，坏事就会发生。考虑系统架构模型和数据模型合并（好）但没有人告诉客户端（坏）的情况。然后业务人员对数据模型进行更改。它实现了特定系统中的更改（好），但是集成了数据模型的系统架构模型从未得到更新（坏）。然后，有人假设集成到系统架构模型中的数据模型是一致的（不好），并对不正确的（非常糟糕）和引入返工或某种修补（丑陋）的内容做出决策。

只是重申一下：模型收敛是好的——它有助于创建一致性并降低成本，但前提是治理和管理得当。当它不受管理时，它可能会产生问题。但治理并不是这个后模型融合的主题，特别是将流程的融合建模成……好的，实际上是所有模型。

我是这个流程的一员

没有流程，数据就不存在；没有数据，进程就无法存在。这是一种真正的“谁先来”的情况。在企业架构中，您也可以对任何其他模型提出相同的问题。“组织结构或在该结构中执行的流程哪一个先出现？”您也可以针对系统架构这样做：“什么先出现，系统架构，或在该结构中执行的流程？”您可以针对企业体系结构的任何方面这样做。去吧，好好想想。我会等的。

…

你有没有想过，在大多数情况下，流程必须放在第一位？是的，我也是。

理解一个组织所做的事情——流程本身的“清单”——对于理解所有其他模型之间的关系至关重要。请记住——模型是趋同的，但在趋同之外，模型——当一起考虑时——代表的是它们打算……建模的企业。您拥有的模型越多，就越有可能有效地理解和管理企业。

因此，在考虑流程模型时，为什么不考虑一个没有组织结构、业务规则、自动化等的陷阱呢？为什么不考虑创建一个结构化的构建块，遵循结构化的业务规则来确保一致性？为什么不考虑PCF？

简单集成

2016年，APQC推出了MosaiQ，这是一款基于云的工具，用于创建和管理定制流程框架。MosaiQ是支持EA工作的完美工具，因为它可以防止您在每次建模时重新创建轮子。

假设您正在创建一个反映您最新创新的组织结构图：将订单转现金流程转移到两个主要地区的集中处理中心。您已经在MosaiQ环境中确定了流程。现在只需要将组织模型链接回MosaiQ流程元素。定义不会更改–您已经创建了一次定义并将其超链接到该定义。但是现在，关注您的组织模型的人知道，模型的聚合是一件“好”事情，因为流程仍然由MosaiQ工具管理。您不必搜索并链接到包含不必要细节的流程图。一旦链接到MosaiQ，其中包含您的定制流程框架和*boom*，您就可以确定新的集中式处理中心提供的“what”的最新版本。

原文：https://www.apqc.org/blog/what-comes-first-architecture-or-process

本文：http://jiagoushi.pro/node/1521

讨论：请加入知识星球【首席架构师圈】或者加微信【cea_csa_cto】

利益相关者管理

远程参与企业架构和类似学科的每个人都知道了解利益相关者的重要性。利益相关者管理是EA中的关键技术，包括TOGAF在内的许多方法都强调其重要性。但管理层要比保持个人利益相关者的幸福更多。在这篇博文中，我想介绍三种技术，不仅可以帮助您确保利益相关者的满意度，还可以充分利用利益相关者及其对实现业务目标的影响。

增强的权力网络

我想讨论的第一种技术是增强型电网，与许多建筑师熟悉的经典电网略有不同。 TOGAF第21章描述的关于利益相关者管理的版本描绘了利益相关者权力的利益水平，然后确定了如何在以下四个象限中解决利益相关者的问题（如下图所示）：

• 低功耗，低兴趣：监视器
• 低功耗，高兴趣：随时了解情况
• 高功率，低利益：保持满意
• 高权力，高利益：密切合作

基于此分析，您可以为不同的利益相关方群体定义具有特定参与可交付成果的沟通策略。

在BiZZdesign Enterprise Studio中，我们支持此电网的增强版本，如下图所示。我们在标准电网中增加了两件事：

• 利益相关者对手头变化目标的态度（用颜色和笑脸/皱眉脸表示）
• 利益相关者对彼此的影响（用箭头表示）

在下面一家保险公司的例子中，我们看到员工对降低成本的目标并不满意，并可能对董事会产生负面影响，董事会本身目前无动于衷。然而，中间商和客户都对降低成本持积极态度，因为中介会影响他们的客户以及他们对某些产品的选择。这是该保险公司商业模式中的一个重要关系。

了解这些关系也是了解公司政治的关键。此外，它可以帮助您通过定位可以直接解决的其他人来影响您无法直接联系的利益相关者。但请注意，这可能是敏感的知识。

将利益相关者与架构模型相关联

除了知道您的利益相关者是谁之外，您还必须了解他们的顾虑或驱动因素。然后，您可以根据这些评估来评估当前情况，并根据这些评估，确定变更目标和期望（以及不期望的）业务成果。要实现这些目标，您需要了解关键业务功能以及所需的资源。然后将这些目标的实现建模为您的体系结构的核心。反过来，变更计划可以与这些架构元素相关联。

所有这些都可以在Enterprise Studio支持的ArchiMate建模语言中表达：

• 动机概念用于对利益相关者，目标和结果进行建模
• 策略概念用于您的功能和资源
• 核心架构以ArchiMate的业务，应用程序和技术层为模型
• 变更计划以实施和迁移概念为模型

总之，这为您提供了从项目和项目投资，通过您开发或改进的能力，到您实现的业务成果以及您所服务的利益相关者的完全可追溯性。这种可追溯性是投资优先事项知情决策的关键。我常常看到“分贝驱动”的项目组合管理，其中最响亮的声音得到了他们的项目批准，而声音较少的利益相关者则处于冷落状态。

生态系统模型

企业是日益复杂的客户，供应商，合作伙伴，监管机构，股东和各种其他方面的网络的一部分。所有这些都应该被视为利益相关者。为了更深入地了解这些网络，生态系统模型可能会有所帮助。生态系统模型不是将自己的企业放在中心，只关注与其他企业的关系，而是从更广泛的角度着眼，并包含其他利益相关者之间的关系。

关于这些关系的知识可以帮助您，就像增强电网一样。此外，您可以从经济角度出发，对这样一个生态系统中的价值创造和分配进行建模，研究不同方面的价值贡献，并分析变化对该生态系统内相关各方的影响。

下图显示了一个非常简单的三方生态系统模型，为知名的保险公司ArchiSurance提供各种信息，产品和资金。正如您所看到的，它还显示了客户和中介之间的关系，这些关系超出了您自己组织的范围，但对于理解您的价值网络至关重要。在此之前，我们已经看到了中介如何影响他们的客户，这是我们可能也会在这个数字中添加的另一种相关关系。

当然，这里显示的三种技术完全由Enterprise Studio支持，并与许多其他类型的分析和可视化相结合。 例如，放大这种生态系统模型，您可能希望创建业务成果旅程地图，提供有关价值创建的更多详细信息，或者客户旅程地图，帮助您了解和改善客户体验。

底层的集成模型为您提供了一个强大的工具来满足您的利益相关者的需求。 这些模型不是将管理决策建立在希望和直觉上，而是为决策提供坚实的基础，并帮助您以平衡的，基于事实的方式为利益相关者提供帮助。

 

原文：https://bizzdesign.com/blog/three-key-techniques-for-managing-your-stakeholders/

本文：http://pub.intelligentx.net/enterprise-architecture-three-key-techniques-managing-your-stakeholders

讨论：请加入知识星球【首席架构师圈】

企业一直在寻找新的方法来提高他们的利润。做出正确的决策是成功的关键，其中之一就是在经过验证的事实和尖端分析的基础上建立公司模型。

技术和工具用于衡量商业智能的方式最近发生了变化。然而，这种策略也有缺点。过度依赖平台和仪表板可能会扭曲您的观点。

正因为如此，在开发商业智能时，将商业见解考虑在内至关重要。商业洞察并没有关注过去的情况，而是提供了一个细致入微的视角。根据过去的结果做出决策的企业主肯定会错过重要的机会。

您可以通过将业务洞察力纳入您的战略来更有效地使用您的工具。让我们更深入地了解商业见解是如何有益的。

目录

• 分析和见解之间的差异
• 数据对收集业务见解的重要性
• 从数据分析中获得商业见解的关键因素
• 了解从数据到业务洞察力之旅的四步指南
• 商业洞察概述
• 如何创建可操作的商业见解？
• 什么是更深层次的见解？
• 如何创建高水平的业务洞察力？
• 要旨

 

在我们前进之前，让我们了解分析和见解之间的区别。

分析和见解之间的差异

虽然数据可能会随着时间的推移或通过使用分析或分析的活动来查看，但见解是您从分析中得出的结论。通过分析获得的知识有助于对环境、场景或偶尔对一个人的准确把握。

见解是您从研究数据中获得的，无论我们谈论的是关于您的目标市场的见解、关于营销或SEO有效性的见解，还是关于对整个努力的特定贡献的见解。

洞察是大多数消费者真正想要的产品。这些是您将其纳入付费广告、社交媒体、公共关系、电子邮件、内容营销和其他战略计划的具体建议。你可以利用洞察力来选择下一步发布什么内容，找出竞争对手在SERP中排名高于你的原因，或者在社交媒体上获得更大的发言权。

在对什么是分析和见解有了广泛的理解之后，让我们加入深入学习商业见解的潮流。但在此之前，你不认为我们应该专注于数据量的重要性以及如何获得实用的商业见解吗。

数据对收集业务见解的重要性

在当今高度智能化和信息化的企业环境中，数据是非常有用的信息来源。

但许多企业都在浪费时间，囤积商业分析根本忽视的重要数据。除非管理者积极使用、评估数据并从中建立知识，否则数据在业务中不会得到充分利用。

数据洞察力至关重要，因为它们可以揭示发展机会，同时促进对公司运营和市场的更深入了解。然而，只有在整个组织真正使用和正确使用数据的情况下，才能做到这一点。下面提供的建议解释了管理者如何最大限度地利用他们目前掌握的知识。

从数据分析中获得商业见解的关键因素

在开始任何研究之前，企业应该决定即将进行的数据分析项目的目标是什么。管理层希望从现有信息源中收集哪些知识和信息？它需要考虑到以下关键因素。

上下文

以大局为出发点。数据分析完成后，这些目标看起来如何？为了在更广泛的背景下进行分析，管理层应该主动确定目标，并设定项目的最后期限和里程碑。

需要

管理层应设计一个分析项目，以最好地满足组织最紧迫的需求，从而最大限度地利用资源。建立需求有助于有效地指导分析，无论目标是增加总体收入、降低特定成本还是提高运营效率。

视野

该项目应包含愿景。管理层应该知道公司问题的任何合理答案，以及如何使用数据和信息来做到这一点。

结果

在分析阶段，必须始终牢记项目的目标。尽管数据挖掘和分析是一个迭代的过程，但有一个持续的思维定式边界，并将注意力集中在当前项目上。考虑以下内容：如何使用这些结果？谁将使用结果？相关的可量化目标是什么？

业务增长在很大程度上受到洞察力的影响。任何想要获得最大成果的公司都必须采用手动方法，帮助他们从一开始就收集见解，简化方法，并专注于正确的技术。最重要的是，永远不要忽视可能促进公司目标的关键信息。

让我们快速查看4步指南，以正确理解此过程。

了解从数据到业务洞察力之旅的四步指南

• ·收集：任何公司都可以从规模庞大、高质量的数据库中获得可靠的商业智能。例如，网络参与、论坛、博客、评论、网站点击流和广告参与都可以用于获取潜在客户的数据。
• ·Connect：数据可能是压倒性的和广泛的，在不同的位置提供了多种信息来源。它的设计方式可能会阻碍分析师建立联系，而不是相反。通过连接和链接各种数据类型和来源，可以产生比仅依靠零散数据更多的信息。
• ·管理：在一个以社交媒体为中心的社会中，公司存在并蓬勃发展。通过适当的方法和工具，可以从这些快速交换中收集和利用大量数据。虽然一些数据点可以很容易地保存，但某些信息只能实时访问。
• ·发现和分析：最后，利用数据找到关键的商业见解需要合作。整个公司的数据科学家、营销专家和其他主题专家都应该参与这一过程。目标是提供可用于实现各种业务目标的重要数据。

商业洞察概述

竞争矩阵和大数据分析是两种可以帮助小企业主做出明智决策的决策技术。尽管单独使用这些模型并不总是获得真正商业见解的最佳方法，但您可以将它们与其他技术相结合来实现这一点。

商业洞察力结合了数据和分析，可以理解和加深您对形势的理解，使您的公司具有竞争优势。这使您能够更深入地了解与您自己的业务相关的关键机制，超越对问题的基本掌握。在发展业务洞察力的过程中，为环境设置场景和向讨论中的所有参与者正确陈述难题是两个要素。

然后，你应该能够解释为什么现实中确实发生了一些事情，并可能确定一些影响客户行为的因素。从消费者的角度阐述理想体验的最后一步通常很容易完成。

分析这些过程并不能确保您能够深入了解业务。制作这些助理没有万无一失的方法，你和你的团队经常需要批判性地思考。由于商业洞察力能够实现巨大的增长，我们的努力恰恰证明了它们对发现它们的公司的价值。

你可能会在任何行业找到一种革命性的产品，在每一种革命性产品背后，你通常会发现一种或多种对消费者心理或使用它的公司运作的见解。提供最多见解的企业更有可能成功。

如何创建可操作的商业见解？

如果洞察力使您能够完成以下任务，则它们将被视为可操作的：

• ·准确分析现有情况
• ·为未来设定目标。
• ·了解如何评估成功

简而言之，业务目标应该与支持它们的数据保持一致。如果你想从数据中获得实际的见解，你必须考虑KPI和公司战略目标等因素。

因此，如果你只想增强公司流程的一部分，你应该专注于与这个特定目标相关的数据。同样，请记住，开发将彻底改变整个公司的战略商业见解需要一组独特的数据。

在以上部分中，我们已经阅读了数据如何在业务洞察力中发挥重要作用。让我们深入了解如何利用数据。

什么是更深层次的见解？

毫无疑问，您对商业智能工具的选择至关重要。然而，你也必须努力收集有关你的组织的有用信息。业务洞察力曾经主要用于知识评估和销售预测。

它们经常关注供应链、产品和提高利润等方面。这可能是指产品或消费者的盈利能力。生产线的运营商需要这些关键信息来做出明智的选择。

该行业垂直应用程序以部门职能为重点。这可以通过使用横向策略来扩展。

这就需要利用跨组织的数据将所有相关的组成部分联系在一起。通过这样做，您将拥有一个共同的视角，使您能够预测业务许多方面即将出现的趋势。

此外，它将帮助你确定你的努力的结果。一个成功的企业需要这类可行的知识。从本质上讲，这种程度的企业知识使人们能够看到一项活动如何影响其他领域。人员配置、流动性和现金流就是这些类别中的几个例子。

它最终会给你带来盈利能力吗？它会对您的客户产生什么影响？凭借商业洞察力，您将获得内幕消息，为您的组织选择最佳行动方案。

让我们来看看如何建立高水平的业务洞察力。

如何创建高水平的业务洞察力？

在构建有效的商业智能解决方案时，您需要考虑以下几点。让我们探索一下。

·强大的数据结构：

这源于您公司使用的应用程序。这些包括供应链管理、客户记录和财务会计等事项。基本上，任何允许您垂直查看公司的区域。

当你把它们组合在一起时，你可以看到整体图像。此外，您可以在任何时候成功地确定您的业务目的。然后，您可以组合这些数据来创建水平数据段。

一旦你掌握了这些专业知识，你就可以用他们所需要的知识武装你的领导者。这将使他们能够对您的业务进行必要的调整。数据提取技术在这种情况下很有用。

·展望未来：

在检查业务分析活动时，您需要向前看，而不是向后看。当你把注意力集中在你已经做过的事情上，而不是你还需要完成的事情上时，你可能会忽视提升业务的机会。这种复杂的分析方法太有优势了，不容忽视。

·使用正确的工具：

最后，确保使用适当的报告工具。您可以将收集到的数据输入到理想的工具中，以更好地管理您的团队和项目。想更有效、更紧密地管理时间吗？你可以用正确的工具完成所有这些，甚至更多。

拥有正确的工具是成功的关键。在您知道要在工具中输入哪些数据后，您可能会开始调整组织的各个方面。主要目标是为贵公司实施重大改进。

业务洞察力还使您能够观察您所做的更改如何在各个领域影响您的公司。

要旨

商业洞察力将如何帮助您的公司？通过遵循本文中提供的与商业见解相关的所有说明和信息，您将了解商业见解的来龙去脉。

你可以相信，既然你有了数据，并且了解拥有正确的工具来了解你的组织的真实情况是多么重要，你今后做出的决定会更好。

今天的企业应用程序无疑是复杂的，并依赖一些专门技术（持久性，AJAX，Web服务等）来完成它们的工作。作为开发人员，我们倾向于关注这些技术细节是可以理解的。但事实是，一个不能解决业务需求的系统对任何人都没有用，无论它看起来多么漂亮或者如何很好地构建其基础设施。

领域驱动设计（DDD）的理念 - 首先由Eric Evans在他的同名书[1]中描述 - 是关于将我们的注意力放在应用程序的核心，关注业务领域固有的复杂性本身。我们还将核心域（业务独有）与支持子域（通常是通用的，如金钱或时间）区分开来，并将更多的设计工作放在核心上。

域驱动设计包含一组用于从域模型构建企业应用程序的模式。在您的软件生涯中，您可能已经遇到过许多这样的想法，特别是如果您是OO语言的经验丰富的开发人员。但将它们一起应用将允许您构建真正满足业务需求的系统。

在本文中，我将介绍DDD的一些主要模式，了解一些新手似乎很难解决的问题，并重点介绍一些工具和资源（特别是一个），以帮助您在工作中应用DDD。

代码和模型......

使用DDD，我们希望创建问题域的模型。持久性，用户界面和消息传递的东西可以在以后出现，这是需要理解的领域，因为正在构建的系统中，可以区分公司的业务与竞争对手。 （如果不是这样，那么考虑购买包装产品）。

按模型，我们不是指图表或一组图表;确定，图表很有用，但它们不是模型，只是模型的不同视图（参见图）。不，模型是我们选择在软件中实现的概念集，以代码和用于构建交付系统的任何其他软件工件表示。换句话说，代码就是模型。文本编辑器提供了一种使用此模型的方法，尽管现代工具也提供了大量其他可视化（UML类图，实体关系图，Spring beandocs [2]，Struts / JSF流等）。

Figure 1: Model vs Views of the Model

这是DDD模式的第一个：模型驱动设计（model-driven design）。这意味着能够将模型中的概念映射到设计/代码的概念（理想情况下）。模型的变化意味着代码的变化;更改代码意味着模型已更改。 DDD并没有强制要求您使用面向对象来构建域 - 例如，我们可以使用规则引擎构建模型 - 但鉴于主流企业编程语言是基于OO的，大多数模型本质上都是OO。毕竟，OO基于建模范例。模型的概念将表示为类和接口，作为类成员的职责。

语言

现在让我们看一下域驱动设计的另一个基本原则。回顾一下：我们想要构建一个捕获正在构建的系统的问题域的域模型，并且我们将在代码/软件工件中表达这种理解。为了帮助我们做到这一点，DDD提倡领域专家和开发人员有意识地使用模型中的概念进行沟通。因此，域专家不会根据屏幕或菜单项上的字段描述新的用户故事，而是讨论域对象所需的基础属性或行为。类似地，开发人员不会讨论数据库表中的类或列的新实例变量。

严格要求我们开发一种普世的语言（ubiquitous language）。如果一个想法不能轻易表达，那么它表明了一个概念，这个概念在领域模型中缺失，并且团队共同努力找出缺失的概念是什么。一旦建立了这个，那么数据库表中的屏幕或列上的新字段就会继续显示。

像DDD一样，这种开发无处不在的语言的想法并不是一个新想法：XPers称之为“名称系统”，多年来DBA将数据字典组合在一起。但无处不在的语言是一个令人回味的术语，可以出售给商业和技术人员。现在，“整个团队”敏捷实践正在成为主流，这也很有意义。

模型和上下文......

每当我们讨论模型时，它总是在某种情况下。通常可以从使用该系统的最终用户集推断出该上下文。因此，我们有一个部署到交易员的前台交易系统，或超市收银员使用的销售点系统。这些用户以特定方式与模型的概念相关，并且模型的术语对这些用户有意义，但不一定对该上下文之外的任何其他人有意义。 DDD称之为有界上下文（BC）。每个域模型都只存在于一个BC中，而BC只包含一个域模型。

我必须承认，当我第一次读到关于BC时，我看不出这一点：如果BC与域模型同构，为什么要引入一个新术语？如果只有与BC相互作用的最终用户，则可能不需要这个术语。然而，不同的系统（BC）也相互交互，发送文件，传递消息，调用API等。如果我们知道有两个BC相互交互，那么我们知道我们必须注意在一个概念之间进行转换。领域和其他领域。

在模型周围设置明确的边界也意味着我们可以开始讨论这些BC之间的关系。实际上，DDD确定了BC之间的一整套关系，因此当我们需要将不同的BC链接在一起时，我们可以合理地确定应该做什么：

• 已发布的语言：交互式BCs就共同的语言（例如企业服务总线上的一堆XML模式）达成一致，通过它们可以相互交互;
• 开放主机服务：BC指定任何其他BC可以使用其服务的协议（例如RESTful Web服务）;
• 共享内核：两个BC使用一个共同的代码内核（例如一个库）作为一个通用的通用语言，但是否则以他们自己的特定方式执行其他的东西;
• 客户/供应商：一个BC使用另一个BC的服务，并且是另一个BC的利益相关者（客户）。因此，它可以影响该BC提供的服务;
• 顺从者：一个BC使用另一个BC的服务，但不是其他BC的利益相关者。因此，它使用“原样”（符合）BC提供的协议或API;
• 反腐蚀层：一个BC使用另一个服务而不是利益相关者，但旨在通过引入一组适配器 - 一个反腐败层来最小化它所依赖的BC变化的影响。

你可以看到，在这个列表中，两个BC之间的合作水平逐渐降低（见图2）。使用已发布的语言（published language），我们从BC建立一个他们可以互动的共同标准开始;既不拥有这种语言，而是由他们所居住的企业所拥有（甚至可能是行业标准）。有了开放主机服务（open host），我们仍然做得很好; BC提供其作为任何其他BC调用的运行时服务的功能，但是（可能）随着服务的发展将保持向后兼容性。

Figure 2: Spectrum of Bounded Context Relationship

然而，当我们走向顺从时，我们只是和我们一起生活; 一个BC明显屈服于另一个。 如果我们必须与购买megabucks的总分类帐系统集成，那可能就是我们所处的情况。如果我们使用反腐败层，那么我们通常会与遗留系统集成，但是 额外的层将我们尽可能地隔离开来。 当然，这需要花钱来实施，但它降低了依赖风险。 反腐败层也比重新实现遗留系统便宜很多，这最多会分散我们对核心域的注意力，最坏的情况是以失败告终。

DDD建议我们制定一个上下文图（context map t）来识别我们的BC以及我们依赖或依赖的BC，以确定这些依赖关系的性质。 图3显示了我过去5年左右一直在研究的系统的上下文映射。

Figure 3: Context Mapping Example

所有这些关于背景图和BC的讨论有时被称为战略性DDD（ strategic DDD），并且有充分的理由。 毕竟，当你想到它时，弄清楚BC之间的关系是非常政治的：我的系统将依赖哪些上游系统，我是否容易与它们集成，我是否能够利用它们，我相信它们吗？ 下游也是如此：哪些系统将使用我的服务，我如何将我的功能作为服务公开，他们会对我有利吗？ 误解了这一点，您的应用程序可能很容易失败。

层和六边形

现在让我们转向内部并考虑我们自己的BC（系统）的架构。 从根本上说，DDD只关心域层，实际上，它对其他层有很多话要说：表示，应用程序或基础架构（或持久层）。 但它确实期望它们存在。 这是分层架构模式（图4）。

Figure 4: Layered Architecture

当然，我们多年来一直在构建多层系统，但这并不意味着我们必须擅长它。确实，过去的一些主流技术 - 是的，EJB 2，我正在看着你！ - 对域模型可以作为有意义的层存在的想法产生了积极的影响。所有的业务逻辑似乎渗透到应用层或（更糟糕的）表示层，留下一组贫血的域类[3]作为数据持有者的空壳。这不是DDD的意思。

因此，要绝对清楚，应用程序层中不应存在任何域逻辑。相反，应用程序层负责事务管理和安全性等事务。在某些体系结构中，它还可能负责确保从基础结构/持久层中检索的域对象在与之交互之前已正确初始化（尽管我更喜欢基础结构层执行此操作）。

在表示层在单独的存储空间中运行的情况下，应用层也充当表示层和域层之间的中介。表示层通常处理域对象或域对象（数据传输对象或DTO）的可序列化表示，通常每个“视图”一个。如果这些被修改，那么表示层会将任何更改发送回应用程序层，而应用程序层又确定已修改的域对象，从持久层加载它们，然后转发对这些域对象的更改。

分层体系结构的一个缺点是它建议从表示层一直到基础结构层的依赖性的线性堆叠。但是，我们可能希望在表示层和基础结构层中支持不同的实现。如果（正如我认为的那样！）我们想要测试我们的应用程序就是这种情况：

• 例如，FitNesse [4]等工具允许我们从最终用户的角度验证我们系统的行为。但是这些工具通常不会通过表示层，而是直接进入下一层，即应用层。所以从某种意义上说，FitNesse就是另一种观察者。
• 同样，我们可能有多个持久性实现。我们的生产实现可能使用RDBMS或类似技术，但是对于测试和原型设计，我们可能有一个轻量级实现（甚至可能在内存中），因此我们可以模拟持久性。

我们可能还想区分“内部”和“外部”层之间的交互，其中内部我指的是两个层完全在我们的系统（或BC）内的交互，而外部交互跨越BC。

因此，不要将我们的应用程序视为一组图层，另一种方法是将其视为六边形[5]，如图5所示。我们的最终用户使用的查看器以及FitNesse测试使用内部客户端API（或端口），而来自其他BC的调用（例如，RESTful用于开放主机交互，或来自ESB适配器的调用用于已发布的语言交互）命中外部客户端端口。对于后端基础架构层，我们可以看到用于替代对象存储实现的持久性端口，此外，域层中的对象可以通过外部服务端口调用其他BC。

Figure 5: Hexagonal Architecture

但这足够大的东西; 让我们来看看DDD在煤炭面板上的样子。

构建模块

正如我们已经注意到的，大多数DDD系统可能会使用OO范例。因此，我们的域对象的许多构建块可能很​​熟悉，例如实体，值对象和模块（entities, value objects and modules. ）。例如，如果您是Java程序员，那么将DDD实体视为与JPA实体基本相同（使用@Entity注释）就足够安全了;值对象是字符串，数字和日期之类的东西;一个模块就是一个包。

但是，DDD倾向于更多地强调值对象（value objects ），而不是过去习惯。所以，是的，您可以使用String来保存Customer的givenName属性的值，例如，这可能是合理的。但是一笔钱，例如产品的价格呢？我们可以使用int或double，但是（甚至忽略可能的舍入错误）1或1.0是什么意思？ $ 1吗？ €1？ ¥1？ 1分，甚至？相反，我们应该引入一个Money值类型，它封装了Currency和任何舍入规则（将特定于Currency）。

而且，值对象应该是不可变的，并且应该提供一组无副作用的函数来操作它们。我们应该写：

Money m1 = new Money("GBP", 10);
Money m2 = new Money("GBP", 20);
Money m3 = m1.add(m2);

将m2添加到m1不会改变m1，而是返回一个新的Money对象（由m3引用），它表示一起添加的两个Money。

值也应该具有值语义，这意味着（例如在Java和C＃中）它们实现equals（）和hashCode（）。它们通常也可以序列化，可以是字节流，也可以是String格式。当我们需要坚持它们时，这很有用。

值对象常见的另一种情况是标识符。因此，（US）SocialSecurityNumber将是一个很好的例子，车辆的RegistrationNumber也是如此。 URL也是如此。因为我们已经重写了equals（）和hashCode（），所以这些都可以安全地用作哈希映射中的键。

引入价值对象不仅扩展了我们无处不在的语言，还意味着我们可以将行为推向价值观本身。因此，如果我们确定Money永远不会包含负值，我们可以在Money内部实现此检查，而不是在使用Money的任何地方。如果SocialSecurityNumber具有校验和数字（在某些国家/地区就是这种情况），则该校验和的验证可以在值对象中。我们可以要求URL验证其格式，返回其方案（例如http），或者确定相对于其他URL的资源位置。

我们的另外两个构建块可能需要更少的解释。实体通常是持久的，通常是可变的并且（因此）倾向于具有一生的状态变化。在许多体系结构中，实体将作为行保存在数据库表中。同时，模块（包或命名空间）是确保域模型保持解耦的关键，并且不会成为泥浆中的一大块[6]。在他的书中，埃文斯谈到概念轮廓，这是一个优雅的短语，用于描述如何区分域的主要关注领域。模块是实现这种分离的主要方式，以及确保模块依赖性严格非循环的接口。我们使用诸如Uncle“Bob”Martin的依赖倒置原则[7]之类的技术来确保依赖关系是严格单向的。

实体，值和模块是核心构建块，但DDD还有一些不太熟悉的构建块。我们现在来看看这些。

聚合和聚合根

如果您精通UML，那么您将记住，它允许我们将两个对象之间的关联建模为简单关联，聚合或使用组合。聚合根（有时缩写为AR）是通过组合组成其他实体（以及它自己的值）的实体。也就是说，聚合实体仅由根引用（可能是可传递的），并且可能不会被聚合外的任何对象（永久地）引用。换句话说，如果实体具有对另一个实体的引用，则引用的实体必须位于同一聚合内，或者是某个其他聚合的根。

许多实体是聚合根，不包含其他实体。对于不可变的实体（相当于数据库中的引用或静态数据）尤其如此。示例可能包括Country，VehicleModel，TaxRate，Category，BookTitle等。

但是，更复杂的可变（事务）实体在建模为聚合时确实会受益，主要是通过减少概念开销。我们不必考虑每个实体，而只考虑聚合根;聚合实体仅仅是聚合的“内部运作”。它们还简化了实体之间的相互作用;我们遵循以下规则：（持久化）引用可能只是聚合的根，而不是聚合中的任何其他实体。

另一个DDD原则是聚合根负责确保聚合实体始终处于有效状态。例如，Order（root）可能包含OrderItems的集合（聚合）。可能存在以下规则：订单发货后，任何OrderItem都无法更新。或者，如果两个OrderItem引用相同的产品并具有相同的运输要求，则它们将合并到同一个OrderItem中。或者，Order的派生totalPrice属性应该是OrderItems的价格总和。维护这些不变量是root的责任。

但是......只有聚合根才能完全在聚合中维护对象之间的不变量。 OrderItem引用的产品几乎肯定不会在AR中，因为还有其他用例需要与Product进行交互，而不管是否有订单。因此，如果有一条规则不能对已停产的产品下达订单，那么订单将需要以某种方式处理。实际上，这通常意味着在订单交易更新时使用隔离级别2或3来“锁定”产品。或者，可以使用带外过程来协调交叉聚合不变量的任何破坏。

在我们继续前进之前退一步，我们可以看到我们有一系列粒度：

value < entity < aggregate < module < bounded context

现在让我们继续研究一些DDD构建块。

存储库，工厂和服务（Repositories, Factories and Services）

在企业应用程序中，实体通常是持久的，其值表示这些实体的状态。但是，我们如何从持久性存储中获取实体呢？

存储库是持久性存储的抽象，返回实体 - 或者更确切地说是聚合根 - 满足某些标准。例如，客户存储库将返回Customer聚合根实体，订单存储库将返回Orders（及其OrderItems）。通常，每个聚合根有一个存储库。

因为我们通常希望支持持久性存储的多个实现，所以存储库通常由具有不同持久性存储实现的不同实现的接口（例如，CustomerRepository）组成（例如，CustomerRepositoryHibernate或CustomerRepositoryInMemory）。由于此接口返回实体（域层的一部分），因此接口本身也是域层的一部分。接口的实现（与一些特定的持久性实现耦合）是基础结构层的一部分。

我们搜索的标准通常隐含在名为的方法名称中。因此，CustomerRepository可能会提供findByLastName（String）方法来返回具有指定姓氏的Customer实体。或者我们可以让OrderRepository返回Orders，findByOrderNum（OrderNum）返回与OrderNum匹配的Order（请注意，这里使用值类型！）。

更复杂的设计将标准包装到查询或规范中，类似于findBy（Query <T>），其中Query包含描述标准的抽象语法树。然后，不同的实现解包查询以确定如何以他们自己的特定方式定位满足条件的实体。

也就是说，如果你是.NET开发人员，那么值得一提的是LINQ [8]。因为LINQ本身是可插拔的，所以我们通常可以使用LINQ编写存储库的单个实现。然后变化​​的不是存储库实现，而是我们配置LINQ以获取其数据源的方式（例如，针对Entity Framework或针对内存中的对象库）。

每个聚合根使用特定存储库接口的变体是使用通用存储库，例如Repository <Customer>。这提供了一组通用方法，例如每个实体的findById（int）。当使用Query <T>（例如Query <Customer>）对象指定条件时，这很有效。对于Java平台，还有一些框架，例如Hades [9]，允许混合和匹配方法（从通用实现开始，然后在需要时添加自定义接口）。

存储库不是从持久层引入对象的唯一方法。如果使用对象关系映射（ORM）工具（如Hibernate），我们可以在实体之间导航引用，允许我们透明地遍历图形。根据经验，对其他实体的聚合根的引用应该是延迟加载的，而聚合中的聚合实体应该被急切加载。但与ORM一样，期望进行一些调整，以便为最关键的用例获得合适的性能特征。

在大多数设计中，存储库还用于保存新实例，以及更新或删除现有实例。如果底层持久性技术支持它，那么它们很可能存在于通用存储库中，但是从方法签名的角度来看，没有什么可以区分保存新客户和保存新订单。

最后一点......直接创建新的聚合根很少见。相反，它们倾向于由其他聚合根创建。订单就是一个很好的例子：它可能是通过客户调用一个动作来创建的。

这整齐地带给我们：

工厂

如果我们要求Order创建一个OrderItem，那么（因为毕竟OrderItem是其聚合的一部分），Order知道要实例化的具体OrderItem类是合理的。实际上，实体知道它需要实例化的同一模块（命名空间或包）中的任何实体的具体类是合理的。

假设客户使用Customer的placeOrder操作创建订单（参见图6）。如果客户知道具体的订单类，则意味着客户模块依赖于订单模块。如果订单具有对客户的反向引用，那么我们将在两个模块之间获得循环依赖。

Figure 6: Customers and Orders (cyclic dependencie

如前所述，我们可以使用依赖性反转原则来解决这类问题：从订单中删除依赖关系 - >客户模块我们将引入OrderOwner接口，使Order引用为OrderOwner，并使Customer实现OrderOwner（参见图7））。

Figure 7: Customers and Orders (customer depends o

那么另一种方式呢：如果我们想要订单 - >客户？ 在这种情况下，需要在客户模块中有一个表示Order的接口（这是Customer的placeOrder操作的返回类型）。 然后，订单模块将提供订单的实现。 由于客户不能依赖订单，因此必须定义OrderFactory接口。 然后，订单模块依次提供OrderFactory的实现（参见图8）。

 

可能还有相应的存储库接口。例如，如果客户可能有数千个订单，那么我们可能会删除其订单集合。相反，客户将使用OrderRepository根据需要定位其订单（的一部分）。或者（如某些人所愿），您可以通过将对存储库的调用移动到应用程序体系结构的更高层（例如域服务或应用程序服务）来避免从实体到存储库的显式依赖性。

实际上，服务是我们需要探索的下一个话题。

域服务，基础结构服务和应用程序服务（Domain services, Infrastructure services and Application services）

域服务（domain service）是在域层内定义的域服务，但实现可以是基础结构层的一部分。存储库是域服务，其实现确实在基础结构层中，而工厂也是域服务，其实现通常在域层内。特别是在适当的模块中定义了存储库和工厂：CustomerRepository位于客户模块中，依此类推。

更一般地说，域服务是任何不容易在实体中生存的业务逻辑。埃文斯建议在两个银行账户之间进行转账服务，但我不确定这是最好的例子（我会将转账本身建模为一个实体）。但另一种域服务是一种充当其他有界上下文的代理。例如，我们可能希望与暴露开放主机服务的General Ledger系统集成。我们可以定义一个公开我们需要的功能的服务，以便我们的应用程序可以将条目发布到总帐。这些服务有时会定义自己的实体，这些实体可能会持久化;这些实体实际上影响了在另一个BC中远程保存的显着信息。

我们还可以获得技术性更强的服务，例如发送电子邮件或SMS文本消息，或将Correspondence实体转换为PDF，或使用条形码标记生成的PDF。接口在域层中定义，但实现在基础架构层中非常明确。因为这些非常技术性服务的接口通常是根据简单的值类型（而不是实体）来定义的，所以我倾向于使用术语基础结构服务（infrastructure service）而不是域服务。但是如果你想成为一个“电子邮件”BC或“SMS”BC的桥梁，你可以想到它们。

虽然域服务既可以调用域实体也可以调用域实体，但应用服务（application service）位于域层之上，因此域层内的实体不能调用，只能反过来调用。换句话说，应用层（我们的分层架构）可以被认为是一组（无状态）应用服务。

如前所述，应用程序服务通常处理交叉和安全等交叉问题。他们还可以通过以下方式与表示层进行调解：解组入站请求;使用域服务（存储库或工厂）获取对与之交互的聚合根的引用;在该聚合根上调用适当的操作;并将结果编组回表示层。

我还应该指出，在某些体系结构中，应用程序服务调用基础结构服务。因此，应用服务可以直接调用PdfGenerationService，传递从实体中提取的信息，而不是实体调用PdfGenerationService将其自身转换为PDF。这不是我的特别偏好，但它是一种常见的设计。我很快就会谈到这一点。

好的，这完成了我们对主要DDD模式的概述。在Evans 500 +页面书中还有更多内容 - 值得一读 - 但我接下来要做的是突出显示人们似乎很难应用DDD的一些领域。

问题和障碍

实施分层架构

这是第一件事：严格执行架构分层可能很困难。特别是，从域层到应用层的业务逻辑渗透可能特别隐蔽。

我已经在这里挑出了Java的EJB2作为罪魁祸首，但是模型 - 视图 - 控制器模式的不良实现也可能导致这种情况发生。控制器（=应用层）会发生什么，承担太多责任，让模型（=域层）变得贫血。事实上，有更新的Web框架（在Java世界中，Wicket [10]是一个崭露头角的例子），出于这种原因明确地避免了MVC模式。

表示层模糊了域层

另一个问题是尝试开发无处不在的语言。领域专家在屏幕方面谈话是很自然的，因为毕竟，这就是他们可以看到的系统。要求他们在屏幕后面查看并在域概念方面表达他们的问题可能非常困难。

表示层本身也可能存在问题，因为自定义表示层可能无法准确反映（可能会扭曲）底层域概念，从而破坏我们无处不在的语言。即使不是这种情况，也只需要将用户界面组合在一起所需的时间。使用敏捷术语，速度降低意味着每次迭代的进度较少，因此对整个域的深入了解较少。

存储库模式的实现

从更技术性的角度来看，新手有时似乎也会混淆将存储库（在域层中）与其实现（在基础架构层中）的接口分离出来。我不确定为什么会这样：毕竟，这是一个非常简单的OO模式。我想这可能是因为埃文斯的书并没有达到这个细节水平，这让一些人变得高高在上。但这也可能是因为替换持久性实现（根据六边形体系结构）的想法并不普遍，导致持久性实现渗透到域层的系统。

服务依赖项的实现

另一个技术问题 - 在DDD从业者之间可能存在分歧 - 就实体与域/基础设施服务（包括存储库和工厂）之间的关系而言。有些人认为实体根本不应该依赖域服务，但如果是这种情况，则外部应用程序服务与域服务交互并将结果传递给域实体。根据我的思维方式，这使我们走向了一个贫血的领域模型。

稍微柔和的观点是实体可以依赖于域服务，但应用程序服务应该根据需要传递它们，例如作为操作的参数。我也不喜欢这个：对我而言，它将实现细节暴露给应用层（“这个实体需要这样一个服务才能完成这个操作”）。但是许多从业者对这种方法感到满意。

我自己的首选方案是使用依赖注入将服务注入实体。实体可以声明它们的依赖关系，然后基础结构层（例如Hibernate，Spring或其他一些框架）可以将服务注入实体：

public class Customer {
…
 private OrderFactory orderFactory;
 public void setOrderFactory(OrderFactory orderFactory) {
 this.orderFactory = orderFactory;
 }
 …
 public Order placeOrder( … ) {
 Order order = orderFactory.createOrder();
 …
 return order;
 }
 }

一种替代方法是使用服务定位器模式。例如，将所有服务注册到JNDI中，然后每个域对象查找它所需的服务。在我看来，这引入了对运行时环境的依赖。但是，与依赖注入相比，它对实体的内存需求较低，这可能是一个决定性因素。

不合适的模块化

正如我们已经确定的那样，DDD在实体之上区分了几种不同的粒度级别，即聚合，模块和BC。获得正确的模块化水平需要一些练习。正如RDBMS模式可能被非规范化一样，系统也没有模块化（成为泥浆的大球）。但是，过度规范化的RDBMS模式（其中单个实体在多个表上被分解）也可能是有害的，过模块化系统也是如此，因为它变得难以理解系统如何作为整体工作。

我们首先考虑模块和BC。记住，模块类似于Java包或.NET命名空间。我们希望两个模块之间的依赖关系是非循环的，但是如果我们确定（比如说）客户依赖于订单，那么我们不需要做任何额外的事情：客户可以简单地导入Order包/命名空间并使用它接口和类根据需要。

但是，如果我们将客户和订单放入单独的BC中，那么我们还有更多的工作要做，因为我们必须将客户BC中的概念映射到BC订单的概念。在实践中，这还意味着在客户BC中具有订单实体的表示（根据前面给出的总分类帐示例），以及通过消息总线或其他东西实际协作的机制。请记住：拥有两个BC的原因是当有不同的最终用户和/或利益相关者时，我们无法保证不同BC中的相关概念将朝着相同的方向发展。

另一个可能存在混淆的领域是将实体与聚合区分开来。每个聚合都有一个实体作为其聚合根，对于很多很多实体，聚合将只包含这个实体（“琐碎”的情况，正如数学家所说的那样）。但我看到开发人员认为整个世界必须存在于一个聚合中。因此，例如，订单包含引用产品的OrderItems（到目前为止一直很好），因此开发人员得出结论，产品也在聚合中（不！）更糟糕的是，开发人员会观察到客户有订单，所以想想这个意味着我们必须拥有Customer / Order / OrderItem / Product的巨型聚合（不，不，不！）。关键是“客户有订单”并不意味着暗示汇总;客户，订单和产品都是集合的根源。

实际上，一个典型的模块（这是非常粗糙和准备好的）可能包含六个聚合，每个聚合可能包含一个实体和几个实体之间。在这六个中，一个好的数字可能是不可变的“参考数据”类。还要记住，我们模块化的原因是我们可以理解一件事（在一定的粒度级别）。所以要记住，典型的人一次只能保持在5到9个之间[11]。

入门

正如我在开始时所说，你可能在DDD之前遇到过很多想法。事实上，我所说过的每一个Smalltalker（我不是一个，我不敢说）似乎很高兴能够在EJB2等人的荒野岁月之后回归域驱动的方法。

另一方面，如果这些东西是新的怎么办？有这么多不同的方式来绊倒，有没有办法可靠地开始使用DDD？

如果你环顾一下Java领域（对.NET来说并不那么糟糕），实际上有数百个用于构建Web应用程序的框架（JSP，Struts，JSF，Spring MVC，Seam，Wicket，Tapestry等）。从持久性角度（JDO，JPA，Hibernate，iBatis，TopLink，JCloud等）或其他问题（RestEasy，Camel，ServiceMix，Mule等），有很多针对基础架构层的框架。但是很少有框架或工具来帮助DDD所说的最重要的层，即域层。

自2002年以来，我一直参与（现在是一个提交者）一个名为Naked Objects的项目，Java上的开源[12]和.NET上的商业[13]。虽然Naked Objects没有明确地开始考虑领域驱动的设计 - 事实上它早于Evans的书 - 它与DDD的原理非常相似。它还可以轻松克服前面提到的障碍。

您可以将Naked Objects视为与Hibernate等ORM类似。 ORM构建域对象的元模型并使用它来自动将域对象持久保存到RDBMS，而Naked Objects构建元模型并使用它在面向对象的用户界面中自动呈现这些域对象。

开箱即用的Naked Objects支持两个用户界面，一个富客户端查看器（参见图9）和一个HTML查看器（参见图10）。这些都是功能完备的应用程序，需要开发人员只编写要运行的域层（实体，值，存储库，工厂，服务）。

Figure 9: Naked Objects Drag-n-Drop Viewer

 

我们来看看Claim类的（Java）代码（如屏幕截图所示）。首先，这些类基本上是pojos，尽管我们通常从便捷类AbstractDomainObject继承，只是为了分解注入通用存储库并提供一些帮助方法：

public class Claim extends AbstractDomainObject {
...
}
Next, we have some value properties:
// {{ Description
private String description;
@MemberOrder(sequence = "1")
public String getDescription() { return description; }
public void setDescription(String d) { description = d; }
// }}

// {{ Date
private Date date;
@MemberOrder(sequence="2")
public Date getDate() { return date; }
public void setDate(Date d) { date = d; }
// }}

// {{ Status
private String status;
@Disabled
@MemberOrder(sequence = "3")
public String getStatus() { return status; }
public void setStatus(String s) { status = s; }
// }}

这些是简单的getter / setter，返回类型为String，日期，整数等（尽管Naked Objects也支持自定义值类型）。接下来，我们有一些参考属性：

// {{ Claimant
private Claimant claimant;
@Disabled
@MemberOrder(sequence = "4")
public Claimant getClaimant() { return claimant; }
public void setClaimant(Claimant c) { claimant = c; }
// }}

// {{ Approver
private Approver approver;
@Disabled
@MemberOrder(sequence = "5")
public Approver getApprover() { return approver; }
public void setApprover(Approver a) { approver = a; }
// }}

这里我们的Claim实体引用其他实体。实际上，Claimant和Approver是接口，因此这允许我们将域模型分解为模块，如前所述。

实体也可以拥有实体集合。在我们的案例中，Claim有一个ClaimItems的集合：

// {{ Items
private List<ClaimItem> items = new
ArrayList<ClaimItem>();
@MemberOrder(sequence = "6")
public List<ClaimItem> getItems() { return items; }
public void addToItems(ClaimItem item) {
items.add(item);
}
// }}

我们还有（Naked Objects调用的）动作，即submit和addItem：这些都是不代表属性和集合的公共方法：

// {{ action: addItem
public void addItem(
@Named("Days since")
int days,
@Named("Amount")
double amount,
@Named("Description")
String description) {
ClaimItem claimItem = newTransientInstance(ClaimItem.class);
Date date = new Date();
date = date.add(0,0, days);
claimItem.setDateIncurred(date);
claimItem.setDescription(description);
claimItem.setAmount(new Money(amount, "USD"));
persist(claimItem);
addToItems(claimItem);
}
public String disableAddItem() {
return "Submitted".equals(getStatus()) ? "Already
submitted" : null;
}
// }}
// {{ action: Submit
public void submit(Approver approver) {
setStatus("Submitted");
setApprover(approver);
}
public String disableSubmit() {
return getStatus().equals("New")?
null : "Claim has already been submitted";
}
public Object[] defaultSubmit() {
return new Object[] { getClaimant().getApprover() };
}

// }}

这些操作会在Naked Objects查看器中自动呈现为菜单项或链接。而这些行动的存在意味着Naked Objects应用程序不仅仅是CRUD风格的应用程序。

最后，有一些支持方法可以显示标签（或标题）并挂钩持久性生命周期：

// {{ Title
public String title() {
return getStatus() + " - " + getDate();
}
// }}

// {{ Lifecycle
public void created() {
status = "New";
date = new Date();
}
// }}

之前我将Naked Objects域对象描述为pojos，但您会注意到我们使用注释（例如@Disabled）以及命令式帮助器方法（例如disableSubmit（））来强制执行业务约束。 Naked Objects查看器通过查询启动时构建的元模型来尊重这些语义。如果您不喜欢这些编程约定，则可以更改它们。

典型的Naked Objects应用程序由一组域类组成，例如上面的Claim类，以及存储库，工厂和域/基础结构服务的接口和实现。特别是，没有表示层或应用层代码。那么Naked Objects如何帮助解决我们已经确定的一些障碍？

• 实施分层架构：因为我们编写的唯一代码是域对象，域逻辑无法渗透到其他层。实际上，Naked Objects最初的动机之一就是帮助开发行为完整的对象
• 表示层模糊了域层：因为表示层是域对象的直接反映，整个团队可以迅速加深对域模型的理解。默认情况下，Naked Objects直接从代码中获取类名和方法名，因此强烈要求在无处不在的语言中获得命名权。通过这种方式，Naked Objects也支持DDD的模型驱动设计原理
• 存储库模式的实现：您可以在屏幕截图中看到的图标/链接实际上是存储库：EmployeeRepository和ClaimRepository。 Naked Objects支持可插入对象存储，通常在原型设计中，我们使用针对内存中对象存储的实现。当我们转向生产时，我们会编写一个实现数据库的实现。
• 服务依赖项的实现：Naked Objects会自动将服务依赖项注入每个域对象。这是在从对象库中检索对象时，或者首次创建对象时完成的（请参阅上面的newTransientInstance（））。事实上，这些辅助方法所做的就是委托Naked Objects提供的名为DomainObjectContainer的通用存储库/工厂。
• 不合适的模块化：我们可以通过正常方式使用Java包（或.NET命名空间）模块化为模块，并使用Structure101 [14]和NDepend [15]等可视化工具来确保我们的代码库中没有循环依赖。我们可以通过注释@Hidden来模块化为聚合，任何聚合对象代表我们可见聚合根的内部工作;这些将不会出现在Naked Objects查看器中。我们可以编写域和基础设施服务，以便根据需要桥接到其他BC。
• Naked Objects提供了许多其他功能：它具有可扩展的体系结构 - 特别是 - 允许实现其他查看器和对象存储。正在开发的下一代观众（例如Scimpi [16]）提供更复杂的定制功能。此外，它还提供多种部署选项：例如，您可以使用Naked Objects进行原型设计，然后在进行生产时开发自己的定制表示层。它还与FitNesse [17]等工具集成，可以自动为域对象提供RESTful接口[18]。

下一步

领域驱动的设计汇集了一组用于开发复杂企业应用程序的最佳实践模式。一些开发人员多年来一直在应用这些模式，对于这些人来说，DDD可能只是对他们现有实践的肯定。但对于其他人来说，应用这些模式可能是一个真正的挑战。

Naked Objects为Java和.NET提供了一个框架，通过处理其他层，团队可以专注于重要的部分，即域模型。通过直接在UI中公开域对象，Naked Objects允许团队非常自然地构建一个明确无处不在的语言。随着域层的建立，团队可以根据需要开发更加量身定制的表示层。

那么，下一步呢？

嗯，DDD本身的圣经是埃里克埃文斯的原着，“领域驱动设计”[1]，建议阅读所有人。雅虎新闻组DDD [19]也是一个非常好的资源。如果你有兴趣了解Naked Objects的更多信息，你可以搜索我的书“使用Naked Objects的域驱动设计”[20]，或者我的博客[21]（NO for Java）或Naked Objects网站[13 ]（对于.NET而言）。快乐DDD'ing！

References

• [1] Domain Driven Design Community http://domaindrivendesign.org/
• [2] Spring BeanDoc http://spring-beandoc.sourceforge.net/
• [3] Anaemic Domain Model, Martin Fowler http://martinfowler.com/bliki/AnemicDomainModel.html
• [4] FitNesse http://fitnesse.org
• [5] Hexagonal Architecture, Alistair Cockburn http://alistair.cockburn.us/Hexagonal+architecture
• [6] Big Ball of Mud,> Brian Foote & Joseph Yoder http://www.laputan.org/mud/
• [7] Dependency Inversion Principle, Robert Martin http://www.objectmentor.com/resources/articles/dip.pdf
• [8] LINQ http://msdn.microsoft.com/en-us/netframework/aa904594.aspx
• [9] Hades http://hades.synyx.org/
• [10] Apache Wicket Web Framework http://wicket.apache.org
• [11] Magical Number Seven, ±2 http://en.wikipedia.org/wiki/The_Magical Number_Seven,_Plus_or_Minus_Two
• [12] Naked Objects for Java http://nakedobjects.org
• [13] Naked Objects for .NET http://nakedobjects.net
• [14] Structure101 (for Java) http://www.headwaysoftware.com/products/structure101
• [15] NDepend (for .NET) http://www.ndepend.com/
• [16] Scimpi http://scimpi.org
• [17] Tested Objects (FitNesse for Naked Objects) http://testedobjects.sourceforge.net
• [18] Restful Objects (REST for Naked Objects) http://restfulobjects.sourceforge.net
• [19] Yahoo DDD Newsgroup http://tech.groups.yahoo.com/group/domaindrivendesign/
• [20] Domain Driven Design using Naked Objects, Dan Haywood http://pragprog.com/titles/dhnako
• [21] Dan Haywood’s Blog http://danhaywood.com

Related Methods & Tools articles

• Domain-Specific Modeling for Full Code Generation
• Mass Customizing Solutions with Software Factories
• Introduction to the Emerging Practice of Software Product Line Development

More Domain Driven Design Knowledge

• Strategic Design by Eric Evans
• Is Domain-Driven Design more than Entities and Repositories?
• Use of Domain Driven Design in Enterprise Application Development

在重塑组织以支持敏捷性时，您做出的最重要的决定之一是建立我们通常所说的产品团队，这是最不为人所知的决定之一。
在我指导过的一些组织中，产品的定义更多地是对已经存在或大到无意义的事物进行增强。
在前者中，如果您为短期增强创建一个团队，那么根据定义，您将不会创建一个长期存在的团队，他们将获得用于项目增强的资金，然后解散。
相反，将产品定义为您的网站会错过标记，因为您通常不会有一个产品团队负责整个网站。
在短期内组织产品团队将面临的挑战是，您不会意识到长期敬业的团队在生产力、质量和员工敬业度方面为您提供的潜在价值。
当您开始围绕敏捷性重塑组织时，需要做出两个关键决定：

•  改变你的资助模式——从资助项目转向团队。
•  确定您的长期团队——从转移到项目的人员转移到稳定团队中的人员。

您将从敏捷教练那里得到的标准指导是您必须创建产品团队。问题在于，对于我们大多数人来说，我们对产品的心态是我们购买的东西：汽车、iPhone、华夫饼铁等……
不幸的是，大多数组织并没有从这种思维方式生产“产品”，而是拥有支持其业务运营的长期业务能力。

我的建议是，当你开始创建专门的团队时，你应该专注于业务能力思维而不是产品思维。

什么是能力？将应付账款/应收账款视为一个简单的例子。您的组织从一开始就对应付账款和应收账款活动有业务需求。当您还小的时候，也许 Quickbooks 足以支持此操作，但随着您变得越来越大，支持此操作的应用程序可能已经改变，但向我们的供应商付款和从我们的客户那里收取现金的能力没有改变。
支持我们的应付账款和应收账款业务能力的持续增强、支持和增长的能力是您将创建一个专门的团队的地方。

创建一个如何调整团队的模型的最佳方法是生成一个企业业务能力模型，该模型将定义您的最高级别业务能力，直至支持您的日常运营的业务功能。

如果您在错误的级别上调整您的团队，您可能没有一个强大的战略上一致的运营团队。获得持续的工作流程，从您的年度资金周期中移除是您实现高水平业务敏捷性的目标。

避免更常见的团队协调方式，即通过支持您的能力的底层应用程序。按系统而非功能对齐可确保我们更多地关注系统的健康状况，而不是业务所需的内容。

在一个组织中，技术领导者非常专注于他们用于我们正在开发的新产品的技术，以至于他们从未为客户提供任何东西。当他们取消合同时，经理告诉我，‘如果他们能看到我们正在使用的所有很酷的技术’……我说他们不在乎，我们没有提供他们现在需要的东西。

当您寻求在我们瞬息万变的世界中保持竞争力时，敏捷性会帮助您，但是，如果做得不好，它会减慢您的速度。专注于围绕能力建设团队，不要担心他们支持什么“产品”。

原文：https://michael-72054.medium.com/product-or-capability-teams-ffdabc6e6f…

本文：https://jiagoushi.pro/node/1887

我们认为世界体系应该为人服务。 我们以人为本的使命的核心是企业设计思维：一个以现代企业的速度和规模解决用户问题的框架。

 

原则指导我们

将问题和解决方案视为持续对话。

关注用户结果

与您的用户成功合作

花一点时间思考一下你的团队的价值观。

并非每个组织都将用户放在首位 有时候，他们有明确的商业理由。 例如，在高度商品化的行业中，您可以优先考虑交付成本而不是用户体验。 作为设计思想家，您可能不同意这一点，但它仍然是一个有效的策略。

但我们并没有通过我们发布的功能和功能来衡量。 我们衡量的是我们如何满足用户的需求。 无论我们是帮助他们找到治愈癌症的方法，在各大洲合作，还是只是更快地完成他们的费用报告，我们的用户依靠我们来帮助他们每天完成工作。

当我们将关于特性和功能的对话转变为关于用户和用户结果的对话时，我们提供了更多有用，可用和理想的解决方案。 我们提升专业，重新定义行业。 但最重要的是，我们赢得了所服务员工的信任，尊重和重复业务。

实践

在用户需求越来越多地成为市场需求的同义时，提供卓越的用户成果越来越成为商业成功的代名词。 但随着用户需求的增长和发展，他们希望我们的产品能够不断发展壮大。 它不再足以让我们找到出色的用户成果。 我们团队工作方式的每个方面 - 从我们衡量的指标到我们使用的语言 - 都必须以用户为中心。

作为团队经理，您可以通过确定用户的真实身份并根据用户结果调整管理方式来发挥自己的作用。 作为团队成员，您可以通过了解用户和了解他们在团队中扮演的角色来发挥自己的作用。 最后，花时间了解更多关于以人为本的设计实践。

作为团队经理

区分用户和客户

您与客户组织的第一线联系通常是客户或经济买家（例如，CIO），而不是最终用户。

获取有关用户体验的任何二手信息。虽然您的客户可能尽最大努力尽可能忠实地代表最终用户，但他们可能没有真正理解组织中用户生活体验所需的曝光度。与他们合作，识别并与您正在设计的真实用户建立联系。

管理用户结果

提供卓越的用户成果需要领导力和管理实践，以使团队的工作与用户的需求保持一致。无论您今天使用何种项目治理流程，企业设计思维的关键点都有助于将用户成果置于工作的中心：

Hills根据离散的用户结果而不是特征和功能列表来定义成功。

通过从他们的角度讲故事，回放捕捉用户背景的细微差别。

赞助商用户从一开始就获得参与项目的真实用户。

衡量用户结果指标

你是你衡量的。只关注收入和运营成本等指标会削弱您的团队专注于对我们产品用户最重要的问题的努力。选择适当的用户结果指标，以帮助我们了解和理解用户行为。衡量开发和市场中的可用性，实用性和可取性。

如果您不知道从哪里开始，请考虑使用诸如Net Promoter Score（NPS）之类的指标，该指标衡量用户对产品的忠诚度。产品的NPS显示与其他类似指标（如客户努力得分）相关联。它也被证明是增长的领先指标 - 当您的NPS上升时，您的收入可能也会增加。

 

作为团队成员

与用户建立共鸣

对用户的真实关注始于一个简单的确认：我们不是我们的用户。了解对人们真正重要的事情要求您和您的团队放弃偏见，抛开个人偏好，并在他们看到的时候看世界。这需要同理心。

当我们努力真正理解用户时，我们理解我们的用户是真实的人，他们的价值观，行为，希望和恐惧都像我们一样复杂。这些特征中的每一个都会影响我们的用户与我们构建的系统交互的方式。

了解用户不仅仅是创建出色的角色或使用数据进行准确的用户行为预测。这是关于以人为先了解他们，“用户”第二。

了解他们的角色

实际上，大多数用户不单独工作。它们通常是复杂，相互依存的人员和流程系统的一部分，它们共同努力实现更大的目标。

虽然每个用户都很重要，但了解他们团队的需求同样重要。了解您的用户参与的流程范围以及他们对其角色的期望，从关键任务到平凡。找出他们依赖谁以及依赖他们的人。请记住，他们的业务需求将在塑造他们的行为方式中发挥关键作用。

 

不安的重塑

以新的方式解决老问题

人的需求从根本上不会改变。 我们解决这些问题的方式。

考虑一下：我们仍在改进从A点到B点的方式。昨天的马车是今天汽车的原型。 今天的汽车只是未来交通突破的另一个原型。

问题的定义是人类的基本需求：从A到B.从任何时间点的解决方案都处于时代的限制和可供性中：技术进步，不断变化的资源，不断变化的消费者期望。

随着时间的推移，对您的用户和客户至关重要的是通过您提供的解决方案与他们进行持续的对话。 当您迭代下一代产品时，请坚持您正在解决的基本人类需求，并与其所居住的不断变化的环境保持联系。

在实践中

这是关于不安定的重塑的事情：你永远不会感觉到完成。 总会有一个更好的解决方案即将到来。 如果只有你多一点时间。 如果只有你有更多的资源。 如果只有技术好一点。

但是，如果你不承诺一个想法，随着市场的发展和用户的生活继续前进，你可能会错失机会之窗。 没有承诺，就没有结果。

从用户的角度认识到，没有任何解决方案是完美的。 当您使用企业设计思维时，您的偏见就是行动。 你会谦虚地追求完美，因为他们知道在时间的充实中，没有什么是完美的。 那就是：一切都是原型。

 

多元化的强化团队

更好地在一起

团队：一群为共同成果共同努力的人

我们经常被要求解决用户和客户最难的问题 - 问题太复杂和多方面，无法单独解决。 我们依靠团队的力量来解决这些复杂的问题，为我们的用户和客户创造价值。

虽然重点关注用户结果很重要，但设计我们的团队组织方式以实现这些结果同样重要。 为了确保我们的团队能够为用户创造更好的想法和实现真实的成果，我们考虑了两个重要的团队因素：多样性和赋权。

通过多样性进行差异化

多样化：由不同的元素或品质组成

多样性不仅仅是道德责任。 这对我们团队的成功至关重要。 考虑一下：在建立团队时，您不只是分配资源 - 您正在构建解决问题的方法。 每个团队成员都会为团队带来他们独特的视角和专业知识，扩大可能的成果范围。 如果你想要一个突破性的想法，你更有可能通过一个多元化的团队来获得它。

不同的团队从多个角度看待同样的问题。 他们对任何特定情况有了更好的理解，并产生更多的想法，使他们成为更有效的问题解决者。 虽然需要努力来利用和调整这些不同的观点，但正是在我们的差异的交叉点上，我们发现了最有意义的突破。

通过授权加快速度

赋权：拥有实现理想结果的专业知识和权威

如果多样性帮助团队产生突破性的想法，赋权使他们能够将这些想法转化为成果。

考虑一个可以快速提供模型但必须等待单独的工程团队来实施工作的设计团队。 或者考虑一个团队在会议中陷入困境，不断尝试赢得利益相关方协议，以便做出每一个小的运营决策。 这两种情况都不能让团队快速行动。

相比之下，授权团队让代理商自己做出日常运营决策。 他们具备提供成果的专业知识和权威，而无需依赖其他人获得领导或技术支持。 通过将运营决策推向最低水平，我们使我们的团队能够实现用户和客户所需的快速迭代。

在实践中

在实践中
最近，乔治亚州亚特兰大一所历史悠久的黑人学院的视觉设计毕业生可能会在中国北京与一位软件架构师合作，他在科技行业已有数十年的历史。 他们可能不了解彼此的生活方式。 他们可能永远不会亲自见面。 但他们的命运本质上是相互关联的 - 因为在我们正在解决的复杂问题中，他们比以往任何时候都更需要彼此。

使这些关系发挥作用需要管理人员和团队成员的努力。 作为一名团队经理，您的责任始于人员配备团队，他们拥有成功所需的多样化视角和专业知识。 作为团队成员，您的责任是培养包容性行为，利用相互冲突的观点来产生新的想法，并主动取得成果。

作为团队经理

分配团队领导力

我们将团队定义为共同努力实现共同成果的人。当您使用Enterprise Design Thinking时，您将使用Hills来定义您的预期用户结果，从而确定您的团队细分。

对于每个希尔团队，您还需要指派一个核心领导团队。这些领导团队应该由每个学科的职能领导组成。授予他们处理团队日常分类的权力，并让他们对实现分配的结果负责。

组建独立的团队

考虑您自己的身份，经验和专业知识的这些不同方面。没有一个维度可以定义我们是谁。相反，它们结合在一起塑造了我们独特的视角。

身分

• 年龄和能力
• 性别认同
• 种族和民族

经验

• 文化教养
• 地理
• 语言

专门知识

• 教育
• 组织
• 学科

建立多元化的团队需要您积极寻找具有不同观点的人。根据身份，经验或专业知识的一致性，避免配备人员。虽然这一开始看似违反直觉，但请记住，多样性的每个方面对于团队管理复杂性和产生突破性想法的能力至关重要。

但是，授权您的团队将这些想法转化为成果需要特别关注团队的多样化专业知识。为了实现自力更生，为每个团队配备独立交付指定成果所需的全部专业知识。这最大限度地减少了对其无法控制的资源的依赖性，使他们能够快速，独立地做出决策。

给他们空间

与真正多元化的授权团队合作最具挑战性的部分可能与人员配置无关。

作为利益相关者，与授权团队合作需要您给他们空间来定义他们独特的角色。虽然这并不意味着您无法与他们保持联系，但这确实意味着可以控制团队的日常运营决策。

你可能并不总是同意他们的工作方式。但请记住：当约翰肯尼迪挑战美国宇航局登月时，他没有对该团队进行微观管理。他不顾一切地让他们做了他们最擅长的事情。

作为团队成员

包容

当您将人员添加到会议邀请时，您会想到什么？你包括谁？你排除谁？ - 为什么？

事实是，本能经常导致我们避免冲突并寻找那些思维相似的人。但请记住：当球队失败时，通常不是因为他们没有好主意。这是因为他们不包括拥有它们的人。

作为设计师，您可能会发现自己很难理解技术堆栈的局限性。作为一名工程师，您可能会发现自己在努力确定客户组织文化的主流价值。但如果你没有依靠彼此的专业知识，你们都无法成长。

至少，关键的团队对话应该包括受影响的每个学科的代表。如果没有让对话中的管理人员参与，或者产品设计师在没有咨询营销团队的情况下做出品牌决策，那么制定时间表决策是不明智的。

这种激进的合作需要在团队中建立信任，尊重和共享所有权的基础。

利用冲突

考虑一下有人不同意你的情况。

你听过他们理解他们的论点了，还是你听了戳洞？您是否探究了他们观点背后的根本原因，或者您是否寻求与其他人分享您的观点？

多样性引发冲突 - 冲突是创造力的源泉。利用这种创造力要求我们倾听与可能不同意的人的理解，而不仅仅是与之争论。当您倾听并理解时，您会一起发现全新的想法，并为更加开放和协作的文化做出贡献。

我们有一句谚语：“同理心：首先是彼此，然后是我们的用户。”下次有人不同意你的意见时，不要直接说出他们为什么错了。试着说：“帮助我理解。”承认我们不了解一切都需要勇气，但这对于提高我们团队的集体成果至关重要。

主动

被授权采取行动意味着您的利益相关者已经委托您为您的团队的集体成功承担共同的责任。虽然这并不意味着您可以忽略他们的建议和方向，但这确实意味着您的团队需要主动解决问题并自行交付您指定的结果。

这个责任一开始可能会让人感到不舒服。但是，当您的团队应对时，您可以更快地提供更好的结果，与利益相关者建立信任关系，并提高您作为领导者的技能。

 

循环驱动我们理解现在，并在观察，反思和制作的连续循环中展望未来。

视察

让自己沉浸在现实世界中

无论您是在寻找新的机会还是评估现有的创意，我们都会深刻理解我们为用户解决的现实问题。 坐在我们的办公桌和会议桌上无法获得这种理解。 它是通过走出大楼并与我们的用户会面而获得的。

在他们的世界中观察用户让您有机会体验他们的经验，了解他们的背景，发现隐藏的需求，并听取他们诚实和不受约束的反馈。 当你调查他们的世界时，在没有判断的情况下吸收你所看到的东西，并以批判的眼光观察这些明显的东西 伟大的发现往往始于你无法解释的观察。

理解不能委派。 尽可能以团队形式观察，并在不能的时候彼此分享您的发现。 团队中的每个人都应该有机会看到用户的世界，这样他们就可以为这种情况贡献自己独特的视角。

了解用户

移情开始于将人们视为人，而不仅仅是用户。询问有关他们如何生活和工作的开放式问题。聆听他们的故事，了解他们激励他们的希望，恐惧和目标。更好的是，把自己放在自己的鞋子里，亲自吸收他们生活经历的高潮，低谷和细微差别。

理解背景

您的用户不会生活在泡沫中。它们通常是复杂，相互依存的人员和流程系统的一部分，它们共同努力实现更大的目标。观看用户与其环境中的人员和工具进行交互。找出他们依赖的人以及依赖他们的人。有时，帮助用户的最有效方法是帮助周围的人。

揭开需求

您的用户并不总是能够表达他们的需求，因此您的工作就是在线路之间进行阅读并揭开它们。揭示他们的挑战，并找出失败后的利害关系。了解他们如何衡量成功以及他们现有解决方案的不足之处。

听取反馈意见

通过将它们放在用户手中来测试您的想法，假设和原型。观察他们的互动，仔细聆听，尽可能忠实地捕捉他们的反馈。注意避免引发问题。

请记住：这不是出售创意或寻求批准。这是为了发现改善项目成果的新机会。

互相问对方

如果您不知道从哪里开始，请从未回答的问题开始。 标记答案基于未经测试的假设或答案，这些假设或答案可能自您上次观察后发生变化。

1. 谁是我们的用户？
   1. 他们的故事是什么？
   2. 他们的经历是什么？
   3. 影响他们经历的是什么
2. 他们的背景是什么？
   1. 他们和谁一起工作？
   2. 它们属于哪些流程？
   3. 对他们有什么期望？
3. 他们的需求是什么？
   1. 他们解决了什么问题？
   2. 他们如何定义成功？
   3. 他们有什么收获或失败？
4. 他们的反馈是什么？
   1. 他们对我们有什么看法？
   2. 什么工作，什么不工作？
   3. 他们对我们有什么想法？

思考（Reflect）

走到一起看看

随着项目的进展，我们不断收集新信息。观察产生关于现实世界的新数据，同时产生新的想法和追求的机会。但是，由于这些信息揭示了我们问题空间的复杂性，它很容易被淹没，失去对齐，或者忽略了我们共同完成的任务。

这就是为什么定期反映团队的重要性。反思将您的团队聚集在一起，使您的动作同步，综合您学到的​​知识，并相互分享您的“aha”时刻。如果情况发生了变化，那也是重新思考如何向前发展的时候了。

反思时，要有同理心去理解不同的观点，灵活应对变化，以及保持团队价值观的诚信。要诚实地对待你所知道的事情，并对所听到的事情保持开放 - 积极或消极。开始并不容易，但是当你经常反思时，你收到的反馈会产生你最好的想法。

了解对方

通过发现将你团结在一起的东西来培养共同的身份。相互了解彼此，并像对待用户一样建立对他们的同情。评估观点的多样性。承认每个人的优势，并将自己的局限视为他人发光的机会。

调整意图

如果你发现自己偏离了方向，放慢速度并检查你工作背后的意图和动机。了解您的用户，您正在解决的问题以及您共同努力实现的成果。评估您正在进行的工作，并确保它与您团队的全局任务保持一致。

揭开新的见解

当您接收新信息时，要评估您所知道的以及您不知道的内容。综合您的知识，发现隐藏的洞察力，照亮前进的道路。洞察力不是重复观察 - 它是一个清晰的飞跃，重新构思你的观点，改变你对重要事项的信念。

未雨绸缪

随着你的理解的发展，不要盲目前进。一起决定你的下一步行动。你既可以采取另一种循环，也可以放在地上并投入一个想法。无论你做出什么决定，都要确保你清楚自己接下来要做什么。

互相问对方

如果您不知道从哪里开始，请将这些问题视为个人和团队。 努力解决您可能发现的任何分歧。

1. 谁是我们的用户？
   1. 我们的能力是什么？
   2. 谁是我们的利益相关者
   3. 我们能控制和影响什么？
2. 我们是否一致？
   1. 我们解决了什么问题？
   2. 我们如何定义成功？
   3. 我们的收获或失败是什么？
3. 我们在学什么？
   1. 我们观察或制造了什么？
   2. 什么工作，什么不工作？
   3. 我们能获得任何见解吗？
4. 我们的计划是什么？
   1. 我们的路线图是什么？
   2. 我们需要什么资源？
   3. 我们准备好了吗？

行动(Make)

给出具体的形式来抽象思想

我们有时会陷入“分析瘫痪”。 推迟制作是很诱人的，因为我们对自己没有足够的理解并不自信。 有时我们只是害怕在完全出炉之前分享想法。 我们中的一些人有条件保留最后的制作。

但在一天结束时，看到结果的唯一方法就是制作一个。 制作抽象概念的形式，让您有机会尝试新的想法，并看到它们在现实世界中生效。 你做得越早，你学得越快。 召唤好奇心尝试未经探索的想法。 勇敢地将你的想法带入世界。 你可能错了 - 这并没有错。

当你去做时，要求别人参与并共同构建你的想法。 与您的团队成员合作通常是您最好的想法诞生的地方。

探索可能性

不要等到一个想法完美 - 它不会发生。用双手思考，实时发现新想法。找出哪些有效，哪些无效。利用快乐的事故。当你的想法用尽时，邀请其他人回复，重新混合并改变你所做的事情。你永远不会知道你可以向别人学到什么。

沟通想法

我们看到的是同一件事吗？一张图片胜过千言万语，所以不要告诉别人你的想法;让他们看。通过制作表达您意图的内容来获取您的想法。想出你的故事并向他们展示它的重要性。

原型概念

原型是有助于验证或使您的假设和假设无效的实验。尽管将您所做的一切都视为原型是有帮助的，但低保真原型可以帮助您快速，低成本地模拟想法和检验假设。无需使其完美 - 只需使其适合您需要的反馈。

推动成果

一旦你致力于一个想法，将你的意图转化为结果。你不需要知道一切都要动起来。在制定细节时，聆听，学习和修正课程。请记住：一切都是原型 - 甚至是市场上的解决方案。早早失败，快速学习。

考虑这些问题

如果您不知道从哪里开始，请考虑这些问题的答案。 如果您遇到一个尚未探索过的问题，请停止说话并开始制作。

1. 什么可能？
   1. 我们能做什么？
   2. 我们可以结合哪些想法？
   3. 我们怎么能做到呢？
2. 发生了什么？
   1. 我们的主意是什么？
   2. 预期的结果是什么？
   3. 我们如何向他人展示？
3. 这是什么概念？
   1. 它的形式是什么？
   2. 它的部分是什么？
   3. 零件如何相关？
4. 我们如何交付？
   1. 我们如何建造它？
   2. 我们如何部署它？
   3. 我们如何维护它？

关键与我们保持一致

关键有助于团队保持专注，并与用户关注的结果保持一致。

丘陵（Hills）

 

让我们谈谈过程

在实践中，复杂的问题通常需要复杂的团队 - 复杂的团队可能是一个管理挑战。项目管理框架可以帮助管理复杂性。我们可能将团队划分为“小队”或“工作流”，或者我们可能将时间划分为“冲刺”或“阶段”。我们甚至可以围绕团队遵循的共同流程进行标准化。

无论我们如何组织团队，提供卓越的用户成果都需要我们保持专注并始终关注对用户至关重要的事项。

当我们从想法转向结果时，钥匙是我们三种最重要的技术，可以让不同的团队一起反思。它们帮助我们保持一致，保持一致，并与现实世界的需求保持联系 - 即使我们深入工作。虽然他们已经通过我们与最大团队的经验磨练，但我们发现钥匙对各种规模的团队都非常宝贵。

Hills将我们团结在一起

Hills是意图声明，写成有意义的用户结果。 他们告诉你去哪里，而不是如何到达那里，让团队能够在不忽视目标的情况下探索突破性的想法。

获得同步

这是事实：在复杂的项目中，事情并不总是按计划进行。 永无止境的功能请求和技术障碍可能会破坏进度，延迟发布，甚至使最健康的团队失去一致性。 尽管存在这些不确定性，团队如何才能忠于项目的意图？

Hills以清晰和灵活的方式传达我们对项目的意图。 它们将问题视为预期的用户结果，而不是预先确定的实施，使团队能够发现突破性的解决方案。 它们帮助我们密切关注奖项，即使我们遇到了许多挑战。

 

一个山的解剖

要编写Hill，请从您要提供服务的用户开始。 接下来，指定您希望它们实现的结果，以及使您的解决方案值得一试的差异化因素。 我们将这些元素称为Who，the What和Wow。

一个好的Hill是与实现无关的。 它应该指定用户尝试完成的内容，而不是他们用来执行此操作的工具。 如果你读回希尔，感觉它已经描述了具体的实现，请退一步再试一次。

谁（Who)

谁是你的用户？ 明确你的目标是谁以及你不是谁。

什么 (What)

他们想要满足的需求是什么？ 将用户需求转化为项目目标。

哇(Wow)

您将如何与竞争对手区分开来？ 你将如何衡量成功？

例子

 

基于GMU的销售负责人可以在24小时内组建敏捷响应团队，无需管理层参与。

IBM Connections，2012

 

开发人员使用IBM和第三方API构建和运行应用程序的时间不应超过30分钟。

IBM Bluemix，2014年

 

我相信这个国家应该致力于实现让一个人登上月球并将他安全返回地球的目标。

约翰·肯尼迪，1961年

与Hills一起管理

如果您在产品团队中，Hills由产品管理所有，并与设计和工程部门合作定义。如果您是服务团队，Hills由高级客户利益相关者拥有，但与交付团队合作定义。与您的客户合作，以​​达到明确定义的Hills，您的团队可以在您的限制范围内实现。

不要担心在第一天写完美的山丘。 Hills应该根据您对问题的理解而发展。在您进行迭代时，请尽早并经常进行Hills Playbacks。您的Hills可以更改为Playback Zero  - 当您需要真正提交时。

三山，一个基金会

你可以做任何事情，但你不能做任何事情。 Hills应该反映出对用户最有价值的成果的投资，以及对您的组织最重要的区别。这就是为什么我们强烈建议任何时候项目不超过三个Hills。这有助于您专注于一组可管理的目标。

除了三个Hills之外，您还可以将一部分资源投入基金会，以解决过去发布的问题，或者为项目的未来支付预付款。

提交资源

根据您对用户和组织的相对价值，为Hills和Foundation分配资源。在每个山丘周围组建不同的赋权团队，并为每个人提供独立交付成果所需的专业知识和权威。力争每个Hill至少招募一名赞助商用户。

一旦资源分配给Hill，将其视为线程安全投资。 Hills提供了围绕资源进行结果驱动对话的语言。如果希尔需要额外的资源，那么您的决定就是重新分配每项投资的价值。

例如：假设您已将25％的资源分配给三个Hills中的每一个，其余25％分配给基金会。如果基金会出现问题，请问自己：是否值得冒险从希尔转移资源来修复它？

分解他们

有时，希尔必然是复杂的，可能会受益于另一种分解水平，以进一步划分工作。如果您选择编写Sub-Hills，请确保每个人都是一个合适的Hill，如果独立发布，仍然可以为用户提供有意义的价值。

 

回放(Playbacks)

 

回放时间与我们保持一致

专注于用户结果
在回放中，用户是节目的明星。 给他们一张脸并按名字介绍他们。 让您的受众体验成为用户的体验。 您的受众对用户的同情心越多，他们的反馈就越有价值。

回放将利益相关者带入安全空间的循环中，以讲述故事和交换反馈。 他们揭示了错位并衡量了你正在解决的大局问题的进展。

保持同步
实际上，并非每个人都有时间参与每个项目的循环。 如果您是项目的利益相关者，可能会觉得团队随着时间的推移而偏离了轨道。 如果您在团队中，可能会觉得您的利益相关者与您的团队对问题和解决方案的了解不一致。 您如何让团队和利益相关者保持一致？

回放是让利益相关者进入循环以反映在一起的时间。 他们是讲述故事和交换有关工作反馈的安全空间。 持续播放可以使团队和利益相关者保持一致并在项目不断变化的情况下保持同步。

 

回放的解剖

播放有各种尺寸的形状。您可以将它们与一对一或更大的组保持在一起。您可以展示低保真草图或抛光演示。在需要利益相关方的反馈时随时保留它们，但考虑在常规里程碑上安排它们。

1）邀请利益相关者

考虑您打算分享的工作以及它可能影响的利益相关者。如果您是一名软件团队，那么您的法律顾问可能需要知道您正在使用新的开源库。也许您的销售团队需要知道路线图中的下一步。

如果你不确定邀请谁，那么就误入歧途。回放将利益相关者聚集在整个组织孤岛和层次结构中，为对话带来不同的观点，并促进透明和包容的文化。

2）讲述你的故事

功能和要求被遗忘。故事持久。

故事显示背景。他们有角色，关系和情节。故事揭示了构成用户体验的整体情况，并帮助受众以超出项目项目的方式理解赌注。换句话说：故事让我们关心。

3）听取反馈和错位

无论他们是实习生还是高级副总裁，都可以从任何人那里获得良好的反馈。让每个人都有机会听取他们的意见。无需判断即可捕获您所听到的

回放显示团队的对齐或错位。如果播放顺利，祝贺 - 您向前迈进了一步。如果出现分歧，请不要惊慌。现在是时候围绕问题采取另一个循环，然后再试一次。

 

使用里程碑回放进行管理

您可以在需要反馈时随时进行播放。 但是，当您的团队和利益相关者需要聚集在一起并就如何向前发展达成一致时，在项目的关键时刻安排里程碑回放是有帮助的。 虽然每个团队都有其独特的里程碑时刻，但这里是典型软件产品团队如何设置其里程碑的示例。

 

Hills Playbacks

在你的工作中
尽可能早地进行Hills Playback。 在精炼您的山丘时，请根据需要继续按住它们。 而不是试图在第一次尝试时使你的Hills正确，向前移动并在你了解更多时重复它们。

在项目开始时，团队安排Hills Playback以确保所有利益相关方就项目的预期结果达成一致。

该团队通过分享他们对用户的了解，他们的产品当前用户体验不足以及所涉及的内容来打开Hills Playback。 他们讨论了项目的Hills，Foundation和建议的资源分配。

在成功进行Hills Play后，球队分解成了他们的子队。 每个子团队都会探索对其指定的希尔采取的潜在解决方案。

Playback Zero

在你的工作中
团队达成共识需要时间。 不要等到Playback Zero才能从利益相关者那里获得投资。 保持播放播放（“播放-2”，“播放-1”等）导致播放归零。 迭代直到你达到对齐。

 

一旦团队认为他们已经为每个Hill达成了一个建议的解决方案，他们就会安排他们的下一个里程碑：Playback Zero。 回放零点是团队和利益相关者就团队实际承诺提供的内容达成一致的时间。

在Playback Zero期间，团队专注于他们提出的用户体验。 他们讲述了一个逼真的，引人入胜的故事，讲述了他们每个Hills的完整用户旅程，在中保真度下可视化建议的解决方案：低到足以留出精致的空间，但足够高以获得有意义的反馈。 它们以高帧率穿过解决方案，以用户可能穿过它们的方式穿过每个屏幕。

在成功播放Zero后，团队将他们提出的解决方案分解为敏捷的史诗和用户故事，并开始提供真实的生产代码。

Delivery Playbacks

在你的工作中
在重要的交付里程碑之后保持交付回放 - 例如，在每个冲刺结束时，或在您达到希尔之后。

 

在每个sprint结束时，团队都会进行交付回放以审核整体用户体验并衡量他们对Hills的进度。

该团队不依赖于模型或原型，而是使用真实的工作解决方案运行Playback。 但是，与简单的sprint结束演示不同，Delivery Playbacks通过解决方案告诉用户端到端的故事，帮助团队确定他们优先排序所需的重要用户体验差距。

成功交付播放后，团队负责人会讨论产品是否已准备好发布给真实用户。

 

Client Playbacks

在你的工作中
在进行客户端播放之前，请确保您已签署必要的法律协议以共享机密信息。

随着解决方案的发展，该团队与已同意签署保密协议的重要客户进行回放。 在客户端播放中，团队展示了他们的产品路线图，他们的三个Hills以及他们打算提供的用户体验。 作为回报，客户为团队提供反馈，以不断改进他们的产品。

 

赞助商用户

 

赞助商用户将我们与现实联系起来

赞助商用户是真实用户，定期向您的团队贡献他们的领域专业知识，帮助您在整个项目中与用户的实际需求保持联系。

保持联系
尽管我们付出了最大努力，但同理心仍有其局限性 如果你正在设计一架客机的驾驶舱，但你不是飞行员，你根本就不知道降落飞机的感觉。 如果没有第一手的经验，很容易与用户的现实失去联系，并允许偏见和个人偏好蔓延到我们的工作中。

赞助商用户是真正的用户或潜在用户，他们将自己的经验和专业知识带给团队。 他们不是被动的主体 - 他们是与您一起工作以获得良好结果的积极参与者。 虽然它们不会完全取代正式的设计研究和可用性研究，但赞助商用户将帮助您打破移情障碍，并在整个项目中与实际需求保持联系。

赞助商用户的剖析

优秀的赞助商用户代表您的目标用户，他们会投入到结果中，并且他们可以定期与您和您的团队合作。

1）它们代表您的目标用户吗？

优秀的赞助商用户反映您打算提供的实际用户。尽管您的客户，客户或经济买家可能会对您提供帮助，但他们通常不会是最终从您的产品中获取个人价值的用户。

2）他们是否亲自投资于结果？

一个好的赞助商用户会像你一样关心你的项目结果。寻找具有特别严格的使用案例的候选人 - 严重依赖您的服务成功的赞助商用户将对您项目的成功产生既得利益。

需要注意的是：不要将要求严格的用例误认为是“极端”用例。如果你在一个涉及家庭小型货车的希尔工作，赛车手可能不是赞助商用户的好选择，无论他们对你有多大兴趣。

3）他们可以合作吗？

一个好的赞助商用户是开放的，愿意与您的团队分享他们的专业知识和经验。

虽然作为赞助商用户不是一份全职工作，但这是一项承诺。设定期望，但要尊重他们的时间，并在他们的日程安排上保持灵活性。重要的是听取他们的见解和想法。

 

与赞助商用户合作

如果您是产品团队，赞助商用户关系归产品管理和设计所有，但值得与您的销售和营销团队联系以提供候选人。如果您是服务团队，您的客户将与您组织中的赞助商用户候选人联系，但产品团队负责向客户传达赞助商用户标准。

虽然赞助商用户不会取代正式的设计研究和可用性研究，但您与他们的每次互动都会缩小您的假设与现实之间的差距。将他们视为团队的一部分。作为合作者，他们将在项目上留下重要的印记。

赞助商用户和Hills

在尝试招募赞助商用户之前，请务必写下Hills并了解目标用户。当您优化Hills并澄清目标用户时，您可以开始招募其用例最适合特定Hill的赞助商用户。我们建议每座山至少有一名赞助商用户。

通过他们的眼睛观察

让赞助商用户向您展示他们的世界。帮助他们以清新的眼光看待他们并让他们与您分享他们的见解。分享您的见解。你可能会发现他们不会看到的故事的一面。

一起反思

仔细聆听赞助商用户的意见。将它们包含在您的播放中并让它们帮助您完善您的山丘。像任何其他团队成员一样，他们并不总能得到他们想要的东西。但如果他们告诉你，你没有解决他们的问题或者你的生活增加了复杂性，那么你可能会走错方向。

合作

在您制作时，请让您的赞助商用户成为您的指南。经常咨询他们。更好的是，鼓励他们通过为他们提供表达自己和与你并肩作战的工具来贡献他们自己的想法。

 

原文: https://www.ibm.com/design/thinking/page/framework/

讨论 ：加入知识星球【数字化和智能转型】

想知道更多关于DDD的信息吗?参加6月26日在纽约QCon的红帽开放创新实验室的专家，他们将带您踏上发现之旅，使用领域驱动设计的实践来帮助您的企业实现精益产品开发、共享理解和“左移”哲学。

背景

域驱动设计(DDD)是关于将业务域概念映射到软件构件的。关于这个主题的大多数文章和文章都是基于Eric Evans的《领域驱动设计》一书，主要从概念和设计的角度覆盖了领域建模和设计方面。这些文章讨论了DDD的主要元素，如实体、价值对象、服务等，或者讨论了泛在语言、有界上下文和反腐败层等概念。

本文的目标是从一个实际的角度来讨论如何获取域模型并实际实现它，从而涵盖域建模和设计。我们将查看技术主管和架构师在实现工作中可以使用的指导方针、最佳实践、框架和工具。领域驱动的设计和开发还受到几个体系结构、设计和实现方面的影响，比如:

• 业务规则
• 持久性
• 缓存
• 事务管理
• 安全
• 代码生成
• 测试驱动开发
• 重构

本文讨论了这些不同的因素是如何在项目的整个生命周期中影响项目的实现的，以及架构师在实现一个成功的DDD实现时应该注意什么。我将从一个典型的域模型应该具有的特征列表开始，以及何时在企业中使用域模型(与完全不使用域模型或使用贫血域模型相比)。

本文包括一个示例贷款处理应用程序，以演示如何在实际的域驱动开发项目中使用这里讨论的设计方面和开发最佳实践。示例应用程序在实现贷款处理域模型时使用Spring、Dozer、Spring Security、JAXB、Arid pojo和Spring Dynamic模块等框架。示例代码将使用Java，但是对于大多数开发人员来说，无论其语言背景如何，都应该非常容易理解。

介绍

域模型提供了以下几个好处:

• 它帮助团队在公司的业务和It涉众之间创建一个公共模型，团队可以使用该模型来沟通业务需求、数据实体和流程模型。
• 模型是模块化的，可扩展的，易于维护，因为设计反映了业务模型。
• 它提高了业务域对象的可重用性和可测试性。

另一方面，让我们看看当IT团队不遵循用于开发大中型企业软件应用程序的域模型方法时会发生什么。

不投资域模型和开发工作将导致应用程序体系结构“臃肿的服务层”和“贫血的域模型”，其中facade类(通常是无状态会话bean)开始积累越来越多的业务逻辑，而域对象则变成只有getter和setter的数据载体。这种方法还会导致领域特定的业务逻辑和规则分散(在某些情况下还会重复)到几个不同的facade类中。

贫血的领域模型，在大多数情况下，是不划算的;它们不会给公司带来比其他公司更大的竞争优势，因为在此体系结构中实现业务需求更改需要很长时间才能开发和部署到生产环境中。

在查看DDD实现项目中的不同体系结构和设计注意事项之前，让我们先看看富域模型的特征。

• 域模型应该关注特定的业务操作域。它应该与业务模型、策略和业务流程保持一致。
• 它应该与业务中的其他域以及应用程序体系结构中的其他层隔离。
• 它应该是可重用的，以避免相同核心业务域元素的任何重复模型和实现。
• 模型应该与应用程序中的其他层松散耦合设计，这意味着不依赖于域层(即数据库层和facade层)任何一侧的层。
• 它应该是一个抽象的、干净的独立层，支持更容易的维护、测试和版本控制。域类应该在容器外部(和IDE内部)是单元可测试的。
• 它应该使用POJO编程模型进行设计，而不需要任何技术或框架依赖(我总是告诉我公司的项目团队，我们用于软件开发的技术是Java)。
• 域模型应该独立于持久性实现细节(尽管技术确实对模型施加了一些约束)。
• 它应该对任何基础架构框架具有最小的依赖性，因为它将比这些框架存在得更久，而且我们不希望任何外部框架上有任何紧密耦合。

为了在软件开发工作上获得更好的投资回报(ROI)，业务部门和IT部门的高级管理人员必须致力于业务领域建模及其实现的投资(时间、金钱和资源)。让我们看看实现域模型所需的其他一些因素。

• 团队应该定期访问业务领域的主题专家。
• IT团队(建模人员、架构师和开发人员)应该具有良好的建模和设计技能。
• 分析师应该具有良好的业务流程建模技能。
• 架构师和开发人员应该具有很强的面向对象设计(OOD)和编程(OOP)经验。

 

领域驱动设计在企业架构中的角色

领域建模和DDD在企业架构(EA)中扮演着重要的角色。自从EA的目标之一是保持IT与业务的单位,业务实体的域模型的表示,变成一个EA的核心部分。这就是为什么大多数的EA组件(业务或基础设施)应该在域模型设计和实现。

领域驱动设计和SOA

面向服务的体系结构(Service Oriented Architecture, SOA)在最近获得了越来越多的动力，以帮助团队构建基于业务流程的软件组件和服务，并加快新产品的上市时间。域驱动设计是SOA体系结构的关键元素，因为它有助于将业务逻辑和规则封装到域对象中。域模型还提供了用于定义服务契约的语言和上下文。

如果还没有域模型，SOA工作应该包括域模型的设计和实现。如果我们过于强调SOA服务而忽略了域模型的重要性，那么我们最终将得到一个贫血的域模型和应用程序体系结构中膨胀的服务。

一个理想的场景是，DDD工作通过迭代实现，同时开发应用层和SOA组件，因为它们是域模型元素的直接消费者。有了丰富的域实现，通过向域对象提供shell(代理)，SOA设计将变得相对简单。但是，如果我们过于关注SOA层，而在后端没有像样的域模型，则业务服务将调用不完整的域模型，这可能导致脆弱的SOA体系结构。

项目管理

域建模项目通常包括以下步骤:

• 首先对业务流程建模并编制文档。
• 选择一个候选业务流程，并与业务领域专家合作，使用通用语言对其进行文档化。
• 标识候选业务流程所需的所有服务。这些服务可以是原子的(单个步骤)，也可以是协调的(多步骤，有或没有工作流)。它们也可以是业务(例如承销或融资)或基础设施(例如电子邮件或工作安排)。
• 标识并记录上一步中标识的服务使用的对象的状态和行为。

重要的是保持模型在高层次上，首先关注业务领域的核心元素。

从项目管理的角度来看，一个实际的DDD实施项目与任何其他软件开发项目包含相同的阶段。这些阶段包括:

• 模型的域
• 设计
• 发展
• 单元和集成测试
• 基于设计和开发(模型概念的持续集成(CI))，细化和重构域模型。
• 使用更新的域模型(域实现的CI)重复上述步骤。

敏捷软件开发方法非常适合这里，因为敏捷方法关注业务价值的交付，就像DDD关注软件系统与业务模型的一致性一样。而且，由于DDD的迭代性质，SCRUM或DSDM等敏捷方法是管理项目的更好框架。使用SCRUM(用于项目管理)和XP(用于软件开发)方法是管理DDD实现项目的良好组合。

DDD迭代周期的这个项目管理模型如下面的图1所示。

图1所示。DDD迭代周期图(单击屏幕快照打开全尺寸视图)。

域驱动设计工作从域建模结束的地方开始。Ramnivas Laddad介绍了如何实现域对象模型的以下步骤。他强调在域模型中更多地关注域对象而不是服务。

• 从域实体和域逻辑开始。
• 开始时不使用服务层，只添加逻辑不属于任何域实体或值对象的服务。
• 使用无所不在的语言、契约式设计(DbC)、自动化测试、CI和重构，使实现尽可能与域模型紧密一致。

从设计和实现的角度来看，一个典型的DDD框架应该支持以下特性。

• 它应该是一个基于POJO的框架(如果您的公司是一个. net商店，则应该是POCO)。
• 它应该支持使用DDD概念的业务领域模型的设计和实现。
• 它应该支持象依赖注入(DI)和面向方面编程(AOP)这样的开箱即用的概念。(注意:本文后面将更详细地解释这些概念)。
• 集成单元测试框架，如JUnit, TestNG, Unitils等。
• 与其他Java/Java EE框架如JPA、Hibernate、TopLink等的良好集成。

样例应用程序

本文使用的示例应用程序是一个住房贷款处理系统，业务用例是批准住房贷款(抵押贷款)的资金请求。当贷款申请被提交给抵押贷款公司时，首先要经过承销商根据客户的收入明细、信用记录和其他因素批准或拒绝贷款申请的承销过程。如果贷款申请被核保集团批准，则在贷款批准过程中要经历关闭和融资的步骤。

贷款处理系统中的资金模块自动处理向借款人发放资金的过程。融资过程通常从抵押贷款方(通常是银行)将贷款包转发给产权公司开始。然后，产权公司审查贷款包，并安排一个日期与卖方和买方的财产结束贷款。借款人和卖方与产权公司的交割代理人会面，签署转让产权的文件。

体系结构

一个典型的企业应用架构由以下四个概念层组成:

• 用户界面(表示层):负责向用户表示信息和解释用户命令。
• 应用层:这一层负责协调应用程序活动。它不包含任何业务逻辑。它不保存业务对象的状态，但可以保存应用程序任务进程的状态。
• 域层:此层包含有关业务域的信息。业务对象的状态保存在这里。业务对象的持久性及其状态可能被委托给基础结构层。
• 基础结构层:这一层作为所有其他层的支持库。它提供层之间的通信，实现业务对象的持久性，包含用户界面层的支持库，等等。

让我们更详细地研究一下应用程序和域层。

应用程序层:

• 负责在应用程序中的UI屏幕之间导航，以及与其他系统的应用程序层的交互。
• 还可以对用户输入数据执行基本的(与业务无关的)验证，然后再将其传输到应用程序的其他(较低的)层。
• 不包含任何业务或域相关逻辑或数据访问逻辑。
• 没有任何反映业务用例的状态，但它可以管理用户会话的状态或任务的进度。

领域层:

• 负责业务领域的概念、关于业务用例和业务规则的信息。域对象封装了业务实体的状态和行为。处理贷款申请的业务实体包括抵押贷款、财产和借款人。
• 还可以管理业务用例的状态(会话)如果用例跨多个用户请求(如贷款登记流程,由多个步骤组成:用户进入贷款细节,系统返回产品和基于贷款利率参数,用户选择一个特定的产品/率组合,最后系统锁定的贷款利率)。
• 包含仅具有定义的不属于任何域对象的操作行为的服务对象。服务封装了不适合域对象本身的业务域行为。
• 是业务应用程序的核心，应该与应用程序的其他层隔离。而且，它不应该依赖于其他层(JSP/JSF、Struts、EJB、Hibernate、XMLBeans等)中使用的应用程序框架。

下面的图2显示了应用程序中使用的不同架构层以及它们与DDD的关系。

 

图2。分层应用程序架构图(单击屏幕快照以打开全尺寸视图)。

以下设计方面被认为是当前DDD实现配方的主要成分:

• 面向对象编程(OOP)
• 依赖注入(DI)
• 面向方面编程(AOP)

OOP是域实现中最重要的元素。应该利用继承、封装和多态性等OOP概念，使用普通的Java类和接口设计域对象。大多数域元素都是同时具有状态(属性)和行为(作用于状态的方法或操作)的真对象。它们也符合现实世界的概念，并且能够很好地适应面向对象编程的概念。DDD中的实体和值对象是OOP概念的经典示例，因为它们同时具有状态和行为。

在一个典型的工作单元(UOW)中，域对象需要与其他对象协作，无论它们是服务、存储库还是工厂。域对象还需要管理其他关注点，如域状态更改跟踪、审计、缓存、事务管理(包括事务重试)，这些实际上是横切的。这些是可重用的与域无关的关注点，通常会分散在整个代码(包括域层)中。将此逻辑嵌入到域对象中会导致域层与非域相关代码的纠缠和混乱。

在没有对象之间的紧密耦合和隔离横切关注点的情况下管理代码依赖项时，OOP本身无法为域驱动的设计和开发提供优雅的设计解决方案。在这里，像DI和AOP这样的设计概念可以用来补充OOP，从而最小化紧密耦合，增强模块化，更好地管理横切关注点。

依赖注入

DI是将配置和依赖项代码移出域对象的好方法。另外，域类对数据访问对象(DAO)类和服务类对域类的设计依赖性使得DI在DDD实现中成为“必须有的”。DI通过将其他对象(如存储库和服务)注入域对象，促进了更干净的松散耦合设计。

在样例应用程序中，服务对象(FundingServiceImpl)使用DI注入实体对象(贷款、借款人和FundingRequest)。另外，实体通过DI引用存储库。类似地，其他Java EE资源(如数据源、Hibernate会话工厂和事务管理器)也被注入到服务和存储库对象中。

面向方面的编程

AOP通过从域对象中删除审计、域状态变化跟踪等横切关注点代码来帮助更好的设计(即在域模型中减少混乱)。它可用于将协作对象和服务注入域对象，特别是未被容器实例化的对象(例如持久性对象)。域层中可以使用AOP的其他方面包括缓存、事务管理和基于角色的安全性(授权)。

贷款处理应用程序使用自定义方面将数据缓存引入服务对象。贷款产品和利率信息从数据库表中加载一次(客户端首先请求此信息)，然后存储在对象缓存(JBossCache)中，用于后续产品和利率查找。Product和rate数据经常被访问，但是不经常更新，所以它是缓存数据而不是每次都命中后端数据库的好选择。

DI和AOP概念在DDD中的作用是最近一个讨论线程中的主要主题。这个讨论是基于Ramnivas Laddad的一个演讲，他在演讲中断言，没有AOP和DI的帮助，DDD是无法实现的。在演讲中，Ramnivas谈到了使用AOP使域对象重新获得智能行为的“细粒度DI”概念。他提到域对象需要访问其他细粒度对象来提供丰富的行为，对此的解决方案是将服务、工厂或存储库注入域对象(通过使用方面在构造函数或setter调用时注入依赖项)。

Chris Richardson还讨论了使用DI、对象和方面来通过减少耦合和增加模块化来改进应用程序设计。Chris谈到了“大型服务”反模式，它是应用程序代码耦合、纠缠和分散的结果，以及如何使用DI和AOP概念来避免它。

注释

定义和管理方面和DI的一个最新趋势是使用注释。注释有助于最小化实现远程服务(如EJB或Web服务)所需的构件。它们还简化了配置管理任务。Spring 2.5、Hibernate 3和其他框架充分利用了注释来在Java企业应用程序的不同层中配置组件。

我们应该利用注释来生成锅炉板代码，从而增加灵活性方面的价值。同时，应该谨慎使用注释。它们应该用于在理解实际代码时不会造成混淆或误导的地方。使用注释的一个很好的例子是Hibernate ORM映射，它增加了在类或属性名旁边指定SQL表名或列名的值。另一方面，像JDBC驱动程序配置(驱动程序名、JDBC url、用户名和密码)这样的细节更适合存储在XML文件中，而不是使用注释。这是基于数据库在相同上下文中的假设。如果需要在域模型和数据库表之间进行重要的转换，那么设计应该考虑这个问题。

Java EE 5提供了诸如@Entity、@PersistenceUnit、@PersistenceContext等JPA注释来为普通Java类添加持久性细节。在域建模的上下文中，实体、存储库和服务是使用注释的很好选择。

@ configured是Spring将存储库和服务注入域对象的方式。Spring框架将“域对象DI”的概念扩展到了@ configurationannotation之外。Ramnivas最近在博客中提到了即将发布的Spring 2.5.2版本的最新改进(从项目快照构建379开始可用)。有三个新的方面(AnnotationBeanConfigurerAspect、AbstractInterfaceDrivenDependencyInjectionAspect和AbstractDependencyInjectionAspect)为域对象DI提供了简单而灵活的选项。Ramnivas说，引入中间方面(AbstractInterfaceDrivenDependencyInjectionAspect)的主要原因是允许领域特定的注释和接口发挥作用。Spring还提供了@Repository、@Service和@Transactional等其他注释来帮助设计域类。

在示例应用程序中使用的一些注释，实体对象(贷款、借款人和FundingRequest)使用@Entity注释。这些对象还使用@ configurationannotation连接存储库对象。服务类使用@Transactional注释用事务行为装饰服务方法。

域模型和安全性

域层中的应用程序安全性确保只有经过授权的客户机(人类用户或其他应用程序)调用域操作并访问域状态。

Spring Security (Spring Portfolio中的子项目)在应用程序的表示层(基于URL)和域层(方法层)中提供了细粒度的访问控制。框架使用Spring的Bean代理拦截方法调用并应用安全约束。它使用MethodSecurityInterceptor类为Java对象提供了基于角色的声明性安全性。对于域对象，还存在以访问控制列表(ACL的)形式的实例级安全性，以便在实例级控制用户访问。

使用Spring Security来管理域模型中的授权需求的主要优点是，该框架具有非侵入性的体系结构，因此我们可以在域和安全方面进行清晰的分离。而且，业务对象不会与安全实现细节混淆。我们可以在一个地方编写通用的安全规则，并在需要实现它们的地方应用它们(使用AOP技术)。

在域和服务类中，授权是在类方法调用级别进行管理的。例如,“贷款批准”方法在承销域对象可以调用任何用户提供一个“保险人”的角色对贷款高达100万美元而审批方法在相同的域对象的贷款申请,贷款金额大于100万美元只能被一个用户“承销主管”角色。

下表总结了应用程序体系结构每一层中的各种应用程序安全问题。

表1。各种应用程序层中的安全问题

 

Layer	Security Concern
Client/Controller	Authentication, Web Page (URL) Level Authorization
Facade	Role based authorization
Domain	Domain instance level authorization, ACL
Database	DB object level authorization (Stored procedures, Stored functions, Triggers)

业务规则

业务规则是业务领域的重要组成部分。它们定义了需要应用于特定业务流程场景中的域对象的数据验证和其他约束。业务规则通常分为以下几类:

• 数据验证
• 数据转换
• 业务决策
• 流程路由(工作流逻辑)

语境在DDD世界中非常重要。上下文的特异性决定了域对象的协作以及其他运行时因素，如应用什么业务规则等。验证和其他业务规则总是在特定的业务上下文中处理。这意味着相同的域对象在不同的业务上下文中必须处理不同的业务规则集。例如，贷款域对象的某些属性(如贷款金额和利率)在贷款通过贷款审批流程中的审批步骤后不能更改。但是，在为特定利率注册和锁定贷款时，可以更改相同的属性。

尽管所有特定于域的业务规则都应该封装在域层中，但是一些应用程序设计将这些规则放在facade类中，这导致域类在业务规则逻辑方面变得“贫血”。在小型应用程序中，这可能是一个可接受的解决方案，但是对于包含复杂业务规则的中型到大型企业应用程序，不推荐使用这种解决方案。更好的设计选项是将规则放在它们所属的地方，即域对象中。如果业务规则逻辑跨越两个或多个实体对象，那么它应该成为服务类的一部分。

此外，如果我们不认真对待应用程序，设计业务规则最终将以代码中几个switch语句的形式编码。随着时间的推移，规则变得越来越复杂，开发人员不需要花时间重构代码来将“switch”语句转移到更易于管理的设计中。在类中硬编码复杂的路由或决策规则逻辑会导致类中的方法变长、代码重复，最终导致僵化的应用程序设计，从长远来看，这将成为维护的噩梦。一个好的设计是将所有的规则(特别是随着业务策略的变化而频繁变化的复杂规则)放到一个规则引擎中(使用JBoss规则、OpenRules或Mandarax之类的规则框架)，并从域类中调用它们。

验证规则通常用不同的语言实现，如Javascript、XML、Java代码和其他脚本语言。但是由于业务规则的动态性，脚本语言(如Ruby、Groovy或领域特定语言(DSL))是定义和管理这些规则的更好选择。Struts(应用层)、Spring(服务)和Hibernate (ORM)都有自己的验证模块，我们可以在这些模块中对传入或传出的数据对象应用验证规则。在某些情况下，验证规则也可以作为方面来管理(链接AOP规则的文章)，这些方面可以被编织到应用程序的不同层(例如服务和控制器)中。

在编写域类来管理业务规则时，一定要记住单元测试方面。规则逻辑中的任何更改都应该很容易在隔离状态下进行单元测试。

示例应用程序包含一个业务规则集，用于验证贷款参数是否在允许的产品和利率规范中。这些规则在脚本语言(Groovy)中定义，并应用于传递给FundingService对象的贷款数据。

设计

从设计的角度来看，域层应该有一个定义良好的边界，以避免非核心域层的破坏，比如特定于供应商的转换、数据过滤、转换等。应该设计域元素来正确地保存域状态和行为。基于状态和行为，不同的域元素有不同的结构。下面的表2显示了域元素及其包含的内容。

表2。具有状态和行为的域元素

Domain Element	State/Behavior
Entity, Value Object, Aggregate	State and Behavior
Data Transfer Object	State only
Service, Repository	Behavior only

包含状态(数据)和行为(操作)的实体、值对象和聚合应该有明确定义的状态和行为。同时，这种行为不应该超出对象边界的限制。在用例中，实体应该根据它们的本地状态完成大部分工作。但是他们不应该知道太多不相关的概念。

好的设计实践是只包含用于封装域对象状态的属性的getter /setter。在设计域对象时，仅为那些可以更改的字段提供setter方法。另外，公共构造函数应该只包含必需的字段，而不是包含域类中所有字段的构造函数。

在大多数用例中，我们实际上不必能够直接更改对象的状态。因此，与其更改内部状态，不如使用更改后的状态创建一个新对象并返回新对象。在这些用例中，这就足够了，而且还减少了设计的复杂性。

聚合类向调用者隐藏协作类的用法。它们可用于在域类中封装复杂的、介入的和依赖于状态的需求。

支持DDD的设计模式

有几种设计模式可以帮助领域驱动的设计和开发。以下是这些设计模式的列表:

• 域对象(做)
• 数据传输对象(DTO)
• DTO汇编
• 存储库:存储库包含以域为中心的方法，并使用DAO与数据库交互。
• 泛型DAO的
• 时态模式:这些模式向丰富的域模型添加了时间维度。双时态框架基于Martin Fowler的时态模式，为处理域模型中的双时态问题提供了一种设计方法。可以使用诸如Hibernate之类的ORM产品来持久化核心域对象及其双时态属性。

DDD中使用的其他设计模式包括策略、外观和工厂。Jimmy Nilsson在他的书中将工厂作为一个域模式进行了讨论。

DDD反模式

在最佳实践和设计模式的反面，有一些DDD的味道是架构师和开发人员在实现域模型时应该注意的。由于这些反模式，域层成为应用程序体系结构中最不重要的部分，而facade类在模型中扮演更重要的角色。以下是一些反模式:

• 贫血的域对象
• 重复DAO的
• 胖服务层:这是服务类最终拥有所有业务逻辑的地方。
• 特性嫉妒:这是Martin Fowler关于重构的书中提到的一种典型的味道，其中类中的方法对属于其他类的数据太感兴趣了。

数据访问对象

DAO和存储库在域驱动设计中也很重要。DAO是关系数据库和应用程序之间的契约。它封装了来自web应用程序的数据库CRUD操作的细节。另一方面，存储库是一个单独的抽象，它与dao交互，并向域模型提供“业务接口”。

存储库使用域的通用语言，使用所有必要的dao，并以域所理解的语言为域模型提供数据访问服务。

DAO方法是细粒度的，更接近于数据库，而存储库方法是粗粒度的，更接近于域。另外，一个存储库类可能注入了多个DAO。存储库和DAO使域模型与处理数据访问和持久性细节分离。

域对象应该仅依赖于存储库接口。这就是为什么注入存储库而不是DAO会产生一个更干净的域模型的原因。不应该直接从客户机(服务和其他使用者类)调用DAO类。客户机应该总是调用域对象，而域对象又应该调用DAO来将数据持久化到数据存储中。

管理域对象之间的依赖关系(例如，实体及其存储库之间的依赖关系)是开发人员经常遇到的一个经典问题。此问题的通常设计解决方案是让服务或Facade类直接调用存储库，当调用存储库时，存储库将向客户端返回实体对象。这种设计最终导致了前面提到的贫血域模型，其中facade类开始积累更多的业务逻辑，域对象成为纯粹的数据载体。一个好的设计是使用DI和AOP技术将存储库和服务注入域对象。

样例应用程序在实现贷款处理域模型时遵循这些设计原则。

持久性

持久性是一个基础结构方面，应该对域层进行解耦。JPA通过对类隐藏持久性实现的细节来提供这种抽象。它是注释驱动的，因此不需要XML映射文件。但同时，表名和列名被嵌入到代码中，这在某些情况下可能不是一个灵活的解决方案。

使用提供数据网格解决方案的网格计算产品(如Oracle Coherence、WebSphere对象网格和GigaSpaces)，开发人员在建模和设计业务域时甚至不需要考虑RDBMS。数据库层以内存对象/数据网格的形式从域层抽象出来。

缓存

当我们讨论域层的状态(数据)时，我们必须讨论缓存的方面。频繁访问的域数据(如按揭贷款处理应用程序中的产品和利率)是很好的缓存候选者。缓存可以提高性能并减少数据库服务器上的负载。服务层是缓存域状态的理想选择。像TopLink和Hibernate这样的ORM框架也提供了数据缓存。

贷款处理示例应用程序使用JBossCache框架来缓存产品和费率细节，以最小化数据库调用并提高应用程序性能。

事务管理

事务管理对于保持数据完整性和提交或回滚UOW非常重要。关于在应用程序体系结构层中应该在何处管理事务，一直存在争议。还有跨实体事务(跨越同一UOW中的多个域对象)，它们影响应该在何处管理事务的设计决策。

有些开发人员喜欢在DAO类中管理事务，这是一个糟糕的设计。这导致了过于细粒度的事务控制，这没有提供管理事务跨多个域对象的用例的灵活性。服务类应该处理事务;这样，即使事务跨越多个域对象，服务类也可以管理事务，因为在大多数用例中，服务类处理控制流。

示例应用程序中的FundingServiceImpl类管理资金请求的事务，并通过调用存储库执行多个数据库操作，并在单个事务中提交或回滚所有数据库更改。

数据传输对象

DTO也是SOA环境中设计的一个重要部分，在SOA环境中，域对象模型在结构上与从业务服务接收和发送的消息不兼容。消息通常在XML模式定义文档(XSD)中定义和维护，从XSD中编写(或代码生成)DTO对象并将其用于域和SOA服务层之间的数据(消息)传输是一种常见的实践。在分布式应用程序中，将数据从一个或多个域对象映射到一个DTO将成为一个必要的麻烦，因为从性能和安全角度来看，通过网络发送域对象可能并不实际。

从DDD的角度来看，DTO还有助于维护服务层和UI层之间的分离，其中DO用于域，服务层用于表示层，DTO用于表示层。

Dozer框架用于将一个或多个域对象组装到一个DTO对象中。它是双向的，这节省了大量额外的代码和时间转换域对象到DTO的，反之亦然。DO和DTO对象之间的双向映射有助于消除单独的DO -> DTO和DTO -> DO转换逻辑。框架还正确处理类型和数组转换。

当请求进入资金处理时，样例应用程序使用Dozer映射文件(XML)将FundingRequestDTO对象分割为贷款、借款人和FundingRequest实体对象。该映射还负责将来自实体的资金响应数据聚合到返回客户端的单个DTO对象中。

DDD实施框架

Spring和Real Object Oriented (ROO)、Hibernate等框架有助于设计和实现域模型。其他支持DDD实现的框架有JMatter、Naked Objects、Ruby On Rails、Grails和Spring Modules XT框架。

Spring负责实例化和连接域类(如服务、工厂和存储库)。它还使用@ configurationannotation将服务注入实体。该注释是特定于Spring的，因此实现此注入的其他选项是使用诸如Hibernate拦截器之类的东西。

ROO是一个建立在“领域第一，基础设施第二”理念上的DDD实现框架。开发该框架是为了减少web应用程序开发中模式的样板代码。在使用ROO时，我们定义域模型，然后框架(基于Maven原型)为模型-视图-控制器(MVC)、DTO、业务层Facade和DAO层生成代码。它甚至为单元测试和集成测试生成存根。

ROO有一些非常实用的实现模式。例如，它区分状态管理的字段，持久层使用字段级访问，公共构造函数只反映强制字段。

开发

没有实际的实现，模型是没有用的。实现阶段应该包括尽可能多地自动化开发任务。要查看哪些任务可以自动化，让我们来看一个涉及域模型的典型用例。以下是用例中的步骤列表:

请求:

• 客户端调用Facade类，以XML文档的形式发送数据(与XSD兼容);Facade类为UOW启动一个新的事务。
• 对输入的数据运行验证。这些验证包括主要的(基本的/数据类型/字段级别的检查)和业务验证。如果存在任何验证错误，则提出适当的异常。
• 将描述翻译成代码(对域友好)。
• 使数据格式更改对域模型友好。
• 对属性进行任何分离(例如将客户名拆分为customer实体对象中的first和last name属性)。
• 将DTO数据分解为一个或多个域对象。
• 持久化域对象的状态。

响应:

• 从数据存储中获取域对象的状态。
• 必要时缓存状态。
• 将域对象组装到应用程序友好的数据对象(DTO)中。
• 对数据元素进行任何合并或分离(例如将姓和名合并到单个客户名属性中)。
• 把代码翻译成描述。
• 对数据格式进行必要的更改，以满足客户端数据使用需求。
• 必要时缓存DTO状态
• 当控制流退出时，事务提交(或回滚)。

下表显示了在应用程序中将数据从一个层传送到另一个层的不同对象。

表3。数据流经应用程序层

Layer	From Object	To Object	Framework
DAO	Database Table(s)	DO	Hibernate
Domain Delegate	DO	DTO	Dozer
Data Transfer	DTO	XML	JAXB

正如您所看到的，在应用程序架构中有几个层，其中相同的数据以不同的形式(DO、DTO、XML等)流动。这些包含数据和其他类(如DAO、DAOImpl和DAOTest)的大多数对象(Java或XML)本质上都是基础结构。这些具有样板代码和结构的类和XML文件非常适合用于代码生成。

代码生成

ROO之类的框架还为新项目创建了一个标准的、一致的项目模板(使用Maven插件)。使用预先生成的项目模板，我们可以在目录结构中实现一致性，在哪里存储源和测试类、配置文件，以及内部和外部(第三方)组件库的依赖性。

当我们考虑到开发一个典型的企业软件应用程序需要大量的类和配置文件时，这可能会让人难以承受。代码生成是解决这个问题的最佳方法。代码生成工具通常使用某种模板框架来定义模板或映射，代码生成器可以从这些模板或映射生成代码。Eclipse Modeling Framework (EMF)有几个子项目，可以帮助生成web应用程序项目中所需的各种构件的代码。像AndroMDA这样的模型驱动架构(Model Driven Architecture, MDA)工具使用EMF根据架构模型生成代码。

当涉及到在域层中编写委托类时，我看到开发人员手动编写这些类(主要是从头开始编写第一个类，然后按照“复制和粘贴”模式为其他域对象创建所需的委托类。由于大多数这些类基本上都是域类的外观，所以它们是代码生成的良好候选对象。代码生成选项是一个很好的长期解决方案，即使它涉及一些初始投资(在编码和时间方面)来构建和测试代码生成器(引擎)。

对于生成的测试类，一个好的选择是为需要进行单元测试的主类中具有复杂业务逻辑的方法创建抽象方法。通过这种方式，开发人员可以扩展生成的基本测试类，并实现不能自动生成的自定义业务逻辑。对于任何具有不能自动创建的测试逻辑的测试方法都是一样的。

脚本语言是编写代码生成器的更好选择，因为它们的开销更少，并且支持模板创建和自定义选项。如果我们利用DDD项目中的代码生成，我们只需要从头开始编写几个类。必须从头创建的工件包括:

• XSD
• 域对象
• 服务

一旦我们定义了XSD和Java类，我们就可以通过代码生成以下所有或大部分类和配置文件:

• DAO接口和实现类
• 工厂
• 存储库
• 域委托(如果需要)
• Facade(包括EJB和web服务类)
• DTO的
• 以上类的单元测试(包括测试类和测试数据)
• Spring配置文件

下面的表4列出了web应用程序体系结构中的不同层，以及可以在该层生成什么工件(Java类或XML文件)。

表4:DDD实现项目中的代码生成

Layer/Function	Pattern	Code You Write	Generated Code	Framework
Data Access	DAO/Repository		DAO Interface, DAO Implementation class, DAOTest, Test Seed Data	Unitils, DBUnit
Domain	DO	Domain class	DomainTest
Persistence	ORM	Domain Class	ORM Mappings, ORM Mapping Test	Hibernate, ORMUnit
Data Transfer	DTO	XSD	DTO	JAXB
DTO Assembly	Assembler	Mapping	DO-DTO Mapping	Dozer
Delegate	Business Delegate	Code to translate DO's to DTO's
Facade		Facade		Remote Service, EJB, Web Service
Controller	MVC	Controller Mapping Files	Struts/Spring MVC
Presentation	MVC	View configuration files	Spring MVC

委托层是唯一同时具有领域对象和DTO知识的层。其他层，如持久层，应该不知道DTO的。

重构

重构是在不改变应用程序的功能或行为的情况下改变或重组应用程序代码。重构可以与设计或代码相关。进行设计重构是为了不断地细化模型并重构代码以改进域模型。

重构在DDD项目中扮演着重要的角色，因为它具有领域建模的迭代和进化性质。将重构任务集成到项目中的一种方法是在调用迭代完成之前将其添加到项目的每个迭代中。理想情况下，重构应该在每个开发任务之前和之后进行。

重构应该严格遵守规则。结合使用重构、CI和单元测试来确保代码更改不会破坏任何功能，同时这些更改确实有助于预期的代码或性能改进。

自动化测试在重构应用程序代码中起着至关重要的作用。如果没有良好的自动化开发人员测试和测试驱动开发(TDD)实践，重构可能会适得其反，因为没有自动的方法来验证作为重构工作一部分的设计和代码更改不会改变行为或破坏功能。

Eclipse之类的工具可以帮助以迭代的方式实现域模型，并将重构作为开发工作的一部分。Eclipse具有诸如提取或将方法移动到不同的类或将方法下推到子类等特性。还有一些Eclipse的代码分析插件可以帮助管理代码依赖项和识别DDD反模式。当我对项目进行设计和代码评审时，我依赖JDepend、Classycle和Metrics等插件来评估应用程序中域和其他模块的质量。

Chris Richardson谈到了使用Eclipse提供的重构特性，应用代码重构将过程设计转换为面向对象设计。

单元测试/持续集成

我们前面谈到的目标之一是，域类应该是单元可测试的(在初始开发期间以及稍后重构现有代码时)，而不需要对容器或其他基础结构代码有太多依赖。TDD方法帮助团队在项目的早期发现任何设计问题，并验证代码是否与域模型一致。DDD对于测试优先的开发是理想的，因为状态和行为包含在域类中，并且应该很容易对它们进行隔离测试。重要的是测试域模型的状态和行为，而不是过多地关注数据访问或持久性的实现细节。

像JUnit或TestNG这样的单元测试框架是实现和管理域模型的好工具。其他测试框架，如DBUnit和Unitils，也可以用来测试域层，特别是将测试数据注入到DAO类中。这将最小化为在单元测试类中填充测试数据而编写的额外代码。

模拟对象还有助于在隔离状态下测试域对象。但是重要的是不要在域层中疯狂地使用模拟对象。如果有其他测试域类的简单方法，您应该使用这些选项，而不是使用模拟对象。例如，如果您可以使用后端中真实的DAO类(而不是模拟DAO实现)和内存中的HSQL数据库(而不是真实数据库)来测试实体类;它将使域层单元测试运行得更快，这是使用模拟对象背后的主要思想。这样，您将测试域对象之间的协作(交互)以及它们之间交换的状态(数据)。对于模拟对象，我们将只测试域对象之间的交互。

一旦开发任务完成，在开发阶段创建的所有单元和集成测试(使用或不使用TDD实践)都将成为自动化测试套件的一部分。应该在本地和更高的开发环境中频繁地维护和执行这些测试，以确定新代码更改是否将任何bug引入了域类。

Eric Evans在他的书中谈到了CI，他说CI工作应该总是在有限的上下文中应用，它应该包括人和代码的同步。CI工具比如CruiseControl和哈德逊可以用来建立一个自动构建和测试环境中运行应用程序构建脚本(使用Ant或Maven这样的构建工具创建)检出代码从SCM存储库(如CVS, Subversion等),编译域类(以及其他类的应用程序),如果没有构建错误,然后自动运行所有的测试(单元测试和集成)。如果有任何构建或测试错误，也可以设置CI工具来通知项目团队(通过电子邮件或RSS提要)。

部署

域模型从不是静态的;它们随着项目生命周期中业务需求的演进和新项目中出现的新需求而变化。另外，在开发和实现域模型时，您需要不断地学习和改进，并希望将新知识应用到现有的模型中。

在打包和部署域类时，隔离是关键。由于域层的一端依赖于DAO层，另一端依赖于服务Facade层(参见图2中的应用程序体系结构关系图)，因此将域类打包并部署为一个或多个模块以优雅地管理这些依赖关系非常有意义。

虽然DI、AOP和工厂等设计模式在设计时最小化了对象之间的耦合并使应用程序模块化，但OSGi(以前称为开放服务网关计划)在运行时解决了模块化问题。OSGi正在成为打包和分发企业应用程序的标准机制。它很好地处理了模块之间的依赖关系。我们还可以使用OSGi进行域模型版本控制。

我们可以将DAO类打包在一个OSGi包中(DAO包)，将服务facade类打包在另一个包中(服务包)，因此当修改DAO或服务实现或部署应用程序的不同版本时，由于OSGi，不需要重新启动应用程序。如果为了向后兼容而必须支持某些域对象的现有版本和新版本，我们还可以部署同一个域类的两个不同版本。

为了利用OSGi的功能，应用程序对象在被使用之前必须在OSGi平台上注册(也就是说，在客户端对它们进行查找之前)。这意味着我们必须使用OSGi api来进行注册，但是我们还必须在服务启动和停止使用OSGi容器时处理故障场景。Spring Dynamic Modules框架通过允许在应用程序中导出和导入任何类型的对象而不需要修改任何代码，在这方面提供了帮助。

Spring DM还提供了在容器外运行OSGi集成测试的测试类。例如，AbstractOsgiTests可用于直接从IDE运行集成测试。设置由测试基础结构处理，因此我们不必编写清单。MF文件进行测试，或做任何打包或部署。该框架支持当前可用的大多数OSGi实现(Equinox、Knopflerfish和Apache Felix)。

贷款处理应用程序使用OSGi、Spring DM和Equinox容器来管理模块级依赖项以及域和其他模块的部署。LoanAppDeploymentTests展示了Spring DM测试模块的使用。

示例应用程序设计

贷款处理样本申请中使用的域类如下:

实体:

• Loan
• Borrower
• UnderwritingDecision
• FundingRequest

值对象:

• ProductRate
• State

服务:

• FundingService

存储库:

• LoanRepository
• BorrowerRepository
• FundingRepository

图3显示了示例应用程序的域模型图。

图3。分层应用程序域模型(单击屏幕快照打开全尺寸视图)。

本文中讨论的大多数DDD设计概念和技术都应用于示例应用程序。使用了诸如DI、AOP、注释、域级安全性和持久性等概念。此外，我还使用了几个开源框架来帮助完成DDD开发和实现任务。这些框架如下:

• Spring
• Dozer
• Spring Security
• JAXB (Spring-WS for marshalling and unmarshalling the data)
• Spring Testing (for unit and integration testing)
• DBUnit
• Spring Dynamic Modules

样例应用程序中的域类使用Equinox和Spring DM框架部署为一个OSGi模块。下表显示了示例应用程序的模块打包细节。

表5所示。打包和部署细节

Layer	Deployment Artifact Name	Module Contents	Spring Configuration File(s)
Client/Controller	loanapp-controller.jar	Controller, Client Delegate classes	LoanAppContext-Controller.xml
Facade	loanapp-service.jar	Facade (Remote) Service, Server Delegate classes, XSD's	LoanAppContext-RemoteServices.xml
Domain	loanapp-domain.jar	Domain classes, DAO, Common DTO's	LoanAppContext-Domain.xml, LoanAppContext-Persistence.xml
Framework	loanapp-framework.jar	Framework, Utility, Monitoring (JMX) classes, Aspects	LoanAppContext-Framework.xml, LoanAppContext-Monitoring.xml, LoanApp-Aspects.xml

结论

DDD是一个强大的概念，它将改变建模人员、架构师、开发人员和测试人员在团队接受了DDD培训并开始应用“领域第一，基础设施第二”的理念之后看待软件的方式。不同利益相关者(从IT和业务单位)与不同背景和领域的专业知识参与域建模、设计和实现工作,引用Eric Evans,“重要的是不要模糊的哲学之间的线路设计(DDD)和技术工具框,帮助我们完成它(OOP, DI和AOP)”。

推进前沿

本节介绍一些影响DDD设计和开发的新方法。其中一些概念仍在发展中，看看它们将如何影响DDD将是很有趣的。

体系结构规则和契约实施设计在域模型标准和实现最佳实践的治理和策略实施中扮演重要角色。Ramnivas谈到了使用方面来执行只通过工厂创建存储库对象的规则;这是一个容易违反设计规则在领域层。

领域特定语言(DSL)和业务自然语言(BNL)近年来受到越来越多的关注。可以使用这些语言表示域类中的业务逻辑。BNL的强大之处在于，它们可以用来捕获业务规范、记录业务规则，以及作为可执行代码。它们还可以用来创建测试用例，以验证系统是否按预期工作。

行为驱动开发(BDD)是最近讨论的另一个有趣的概念。BDD通过提供跨越业务和技术之间的鸿沟的公共词汇表(普遍存在的语言)，帮助将开发重点放在交付优先级高的、可验证的业务价值上。通过使用关注于系统的行为方面而不是测试方面的术语，BDD试图帮助开发人员将注意力集中在TDD最成功的地方的真正价值上。如果正确地实践，BDD可以成为DDD的一个很好的补充，在DDD中，领域对象的开发受到BDD概念的积极影响;毕竟，所有的域对象都应该封装状态和行为。

事件驱动架构(EDA)是另一个可以在领域驱动设计中发挥作用的领域。例如，用于通知域对象实例中的任何状态更改的事件模型将有助于处理需要在域对象的状态更改时触发的事件后处理任务。EDA有助于封装基于事件的逻辑，从而避免嵌入到核心域逻辑中。Martin Fowler记录了关于域事件设计模式的内容。

资源

• 领域驱动设计，解决软件核心的复杂性，Eric Evans, Addison Wesley
• 应用领域驱动的设计和模式，Jimmy Nilsson, Addison Wesley
• 《重构到模式》，Joshua Kerievsky, Addison Wesley著
• DDD可以在没有DI和AOP的情况下充分实现吗?

 

原文：https://www.infoq.com/articles/ddd-in-practice/

本文：https://pub.intelligentx.net/node/823

讨论：请加入知识星球【首席架构师圈】或者飞聊小组【首席架构师智库】

我刚刚创建了一个新的 kata，您和您的团队/朋友可以使用它来练习您的架构和领域驱动的设计技能。 它完全免费使用，不涉及营销，只需将此 Miro 板上的内容复制到您自己的 Miro 板上即可。 您可以随意重新混合、重复使用和修改任何内容，并且不需要我的许可。

这个 kata 是基于我的研讨会的内容。 我已经用过几次了，感觉效果很好，所以我觉得分享一下会很好。

这个 kata 分为四个部分，分别解决架构软件系统的不同方面。

第一部分是为一家名为 Dreamland Dealership 的虚构公司创建一个商业模式，这是一家完全在线的汽车经销商（这不是基于任何真实的公司）。 所有架构决策最终都是由公司的商业模式驱动的，所以我认为这是一个明智的起点。

• 研讨会的第二部分使用事件风暴探索公司的领域格局（业务流程、用户旅程、产品、系统等）。 首先进行域测验，然后将提供的事件风暴分割成域。

• 工作坊的第三部分侧重于战略——不同领域如何连接到业务战略。 每个领域是核心的、支持的还是通用的？ 提供了一个示例域列表，参与者可以将其相应地放置在核心域图表上。

此活动没有正确答案。 像大多数练习一样，目的是创造一个空间来讨论启发式、原则、模式、权衡等。

• kata 的最后一部分为尝试消息流建模提供了空间。 这是一种使用命令、事件和查询将域拼接在一起的技术，以确定建议的域边界是否是软件架构边界的良好候选者。

原文：https://medium.com/nick-tune-tech-strategy-blog/architecture-ddd-kata-o…

本文：

 

在过去的几周里，我们研究了领域驱动设计领域中的一些重要主题。

首先，我们看看什么是领域模型，以及它们为什么对领域驱动设计如此重要。领域模型是围绕业务的特定问题的重点知识。

接下来，我们研究了有界的上下文，以及它们如何适应整个组织的上下文映射。有界上下文是特定域模型周围的边界，而上下文映射是每个有界上下文如何适应全局的全局视图。

绝大多数领域驱动的设计应用程序都有多个有界的上下文。这可能意味着与第三方服务集成，但通常情况下，您还需要与现有的遗留应用程序或同一应用程序的其他模型集成。

有许多技术方法可以集成有界上下文、第三方服务和遗留应用程序。

然而，选择正确的集成模式非常重要，因为它将对应用程序的设计和整个项目的未来产生重大影响。

在今天的文章中，我们将讨论在域驱动设计应用程序中集成有界上下文的策略，每种策略的优缺点以及如何决定为项目选择哪种上下文。

重述域模型和有界上下文

在开始讨论集成策略之前，我们先快速回顾一下域模型和边界上下文。

领域模型是围绕特定问题的重点知识。这包括实体、值对象和特定于特定问题的重要事物之间的关系。

有界上下文是关于域模型的边界。在有限的上下文中，对象的语言、名称和思想应该形成手边问题的统一模型。有界的上下文将内部模型与外部世界的复杂性隔离开来。每个有界的上下文应该有一个内部模型，团队的所有成员都能清楚地理解这个模型。这很重要，因为在大多数组织中，某些术语在不同的部门或业务领域有不同的含义。

最后，上下文映射是每个有界上下文如何在应用程序或组织中相互配合的全局视图。这个更大的问题视图确保应用程序的目标不会丢失在每个有界上下文的重点细节中。对于每个有界的上下文，最好有一个真正的内部模型和一层转换，而不是使用单一的对象来试图填补不同的、常常相互冲突的工作。

 

软件项目的现实

在理想的情况下，每个软件项目都可以从头开始，有一个干净的git存储库，没有遗留问题。

然而，在现实世界中，这种类型的项目非常少见。

绝大多数重要的应用程序开发项目都需要多个有界上下文。

在与现有组织合作时，通常需要与遗留应用程序或第三方服务集成。

因此，您的工作就是将这些遗留应用程序和第三方系统与您正在进行的新项目集成起来。

这些类型的集成的问题是，您可以发现自己处于无限多的情况中。例如，您可能会发现自己受制于第三方服务，或者您可能负责为现有遗留系统提供接口。

我将在本文中讨论许多不同的集成策略。每种策略都有其优点和缺点。

为特定的情况选择正确的集成策略非常重要，因为它将对应用程序的设计和未来的开发路径产生重大影响。

一个简单的翻译例子

在我们开始讨论集成策略之前，首先我将解释一个简单的示例，以便我们都能理解为什么这很重要。

想象一下，我们以顾问的身份进入一家现有的线下零售商，为该公司创建一个新的在线电子商务网站。

这家公司已经在商业大街上经营了很多年，所以它已经有了现有的股票管理、分销和金融系统。

我们的任务是创建一个电子商务网站，可以接口与公司现有的系统，提供一个无缝的销售新渠道。

我们的新开发项目显然是一个新的有界的环境，在组织作为一个整体的环境地图的范围内。我们不会扩展当前的任何系统，但是我们必须使用并返回来自每个现有系统的数据，以便使新通道无缝地集成到当前的体系结构中。

我们将需要能够要求从库存管理系统的数据，以便知道什么应该提供网上购买。

我们还需要将数据发送到配送和财务系统，以便正确处理订单和处理公司的会计责任。

如果这是一个真实的情况，我们可能不得不与大量其他现有系统和第三方服务进行交互。但是，希望您能够通过一层转换看到与现有系统集成的需求。

而在一个理论的想法世界，如果电子商务销售、库存管理、分销和财务都是一个统一的模型的一部分，那就太好了。然而，这样一个系统的复杂性将很快失去控制。

相反，我们需要找到通过翻译层进行集成的方法。以下是7种方法。

共享内核

第一个集成策略是使用一个共享内核，其中域模型的一部分在处理相同应用程序的不同团队之间共享。

共享内核集成策略是有益的，因为它减少了重复代码的数量和翻译层的开销。

但是，只有当所有的开发团队都致力于共享和交流共享代码的需求时，共享的内核才能工作。这意味着共享内核的设计不能像应用程序的其他方面那样快速发展，任何更改都必须得到每个开发团队成员的同意。

每个开发团队还必须承担维护单元测试的同等责任，以确保共享内核的功能保持一致。

当应用程序的某个方面存在一个共享需求，并且通信水平较高，政治动荡程度较低时，共享内核集成策略比我们将在本文中看到的许多其他集成策略更容易实现。

在我们的电子商务类比中使用共享内核的一个例子可能是，客户模型在交易团队和在线营销团队之间共享。

交易团队需要客户模型来关联交易和请求支付，而在线营销团队需要客户模型来发送营销信息来刺激新购买，并让客户了解新产品和新报价。

与两个团队编写自己的客户模型并来回转换不同，他们可以使用一个共同的客户模型来满足他们的需求。这意味着团队需要就客户模型的规范达成一致，并且任何未来的变更都必须由两个团队签署。

客户/供应商

两个软件应用程序之间的常见关系是，下游应用程序需要来自上游应用程序的数据，但上游应用程序不依赖于下游应用程序。

这种关系可以通过许多不同的方式表现出来。

首先，如果上游团队不考虑下游团队的需求而进行更改，那么下游团队就会受到上游团队的支配。

另外，如果下游团队能够控制他们的应用程序的发展，那么上游团队就会感到他们的应用程序的设计和实现受到了限制。

下游团队依赖于上游团队，但上游团队不负责下游团队的交付。为了使这种情况起作用，两个团队需要有一个正式的关系，其中考虑了下游团队的需求，就像在任何客户/供应商关系中一样。

这意味着未来的发展优先事项、任务和要求必须得到两个工作队成员的同意。

两个团队还应该就一系列验收测试达成一致，以确保边界的接口保持一致。这意味着只要接口保持一致，上游团队就可以发展他们的应用程序，而下游团队可以确信，他们不会因为上游团队的更改而某天醒来发现他们的应用程序被破坏。

当两个团队的目标是一致的，或者他们都向相同的管理层报告时，客户/供应商关系工作得最好。当两个团队的目标不一致时，关系往往会破裂。

电子商务类比中的客户/供应商关系的一个例子是，一个单独的分析应用程序必须从电子商务应用程序获取数据，以生成客户建议并预测新的趋势。

分析应用程序位于不同的有界上下文中，因为它可能使用不同的编程语言编写，使用与电子商务应用程序非常不同的工具和持久存储。

分析应用程序依赖于电子商务应用程序来发送事务、客户概要和跟踪事件的数据，以便运行分析。

两队应就数据的类型、格式和方法以及如何向下游传送数据达成协议。如果两个团队在提高公司整体的成功和盈利能力上保持一致，这种关系就更有可能奏效。

墨守成规

当客户和供应商之间的关系不一致时，下游团队可能最终处于一种受上游团队支配的情况。

这可能发生在同一家公司，其中每个团队向具有不同目标的非常不同的管理层报告，或者供应商有许多小客户，因此每个单独的客户对供应商来说不是特别重要。

这意味着上游团队没有动力为下游团队提供任何类型的优先级甚至一致性。下游团队必须接受这样一个事实，即他们不能依赖上游团队和关系边界上一致的接口。

如果上游应用程序的价值对下游应用程序至关重要，那么继续下去的唯一方法就是坚持上游团队的想法。

这将意味着上游团队将完全控制这两个应用程序的集成，因此下游团队只能让它工作。

这将导致下游团队对上游团队有很深的依赖性，因此任何未来的开发都将受到形势的限制。

在我们的电子商务类比中，因循守旧关系的一个例子可能是，我们依赖第三方送货服务向客户发送包裹。为了更新客户的进度位置，我们需要从第三方交付服务请求更新。

然而，我们只是数以千计的快递服务客户中的一员，所以他们没有动力提供我们需要的数据。交付服务也可以在任何时候自由地更改它们的API，这可能会破坏我们的集成。

在这种情况下，我们完全处于交付服务的支配之下，因此我们必须负责接受他们的数据和他们提供的请求数据的接口。如果接口发生了变化，我们有责任遵循这些变化并演进我们的集成以满足那些需求。

反腐败层

在使用现有的遗留应用程序或第三方服务时，集成需求通常很复杂。虽然一开始似乎很容易避免集成，但是如果其他系统非常重要，那么集成中可能有更多的价值。

集成其他系统是困难的，因为其他模型可能通过集成而泄漏，并开始影响新系统自己的模型。过多地适应现有的系统，我们最终会得到一个新的系统，它的模型不一致或者不适合解决它自己的问题。

为了防止模型从外部系统内部泄漏到新系统，我们需要一种方法来在两个模型之间转换数据。这通常意味着确保在新模型中解释数据的上下文是一致的，但也要防止在集成过程中出现不必要的数据泄漏。

为了实现这一点，我们需要创建一个隔离层，它可以与遗留系统和第三方系统的现有接口进行通信，然后在内部模型之间来回转换请求。

在我们的电子商务类比中使用反腐败层的一个例子是，将现有的线下零售系统的客户忠诚度计划与新的在线零售系统的客户忠诚度计划联系起来。

如果现有的线下客户与零售商之间存在忠诚度平衡，并且她开始在网上购物，那么这两个系统应该相互了解，这样客户就不会失去优惠或折扣。

然而，这两个系统可能会有不同的模型和不同的支持数据，而这些模型和数据在这两个系统之间是不相关的。

为了保持两个系统的一致性，我们可以设置Web挂钩(什么是Web挂钩?)，每当客户忠诚度平衡在关系的一端更新时，它就会发送请求。

当请求被发送或接收时，它将通过反腐败层被转换为接收应用程序的适当形式。这意味着数据可以在两个系统之间流动，而不必更改现有的脱机系统，也不必使新系统符合现有系统的模型。

开放主机

当您的应用程序需要与另一个系统集成时，您通常会提供一个转换层来简化集成。

然而，当您的应用程序需要与许多其他现有系统集成时，拥有所有这些翻译层可能会变得难以处理。

不是为每个集成提供一个独立的翻译层，而是提供一组可由任何其他有界上下文使用的服务。

通过将应用程序作为一系列服务提供，可以减少维护多层翻译所需的开销。

随着新功能在内部创建或从外部使用者请求，这些服务可能会发展。然而，对于一次性集成需求，单层转换要比牺牲通用服务接口更好。

在我们的电子商务应用程序中使用开放主机策略的一个例子可能是将客户和交易的数据作为一系列服务提供。

公司内部的许多现有应用程序可能需要从我们的应用程序请求数据来完成订单或补充产品库存，因此，我们可以提供一组服务来减少这种开销，而不是为每个系统提供翻译层。

发布的语言

将来自外部系统的模型集成到新系统中是困难的，因为您不希望您的新系统受到外部系统设计的影响。

外部系统的模型可能与您的内部模型不兼容，因此接受它们的模型作为数据交换语言意味着您的模型依赖于外部系统并受到外部系统的影响。

我们不应该依赖模型作为数据交换语言，而应该使用通用的发布语言，如JSON或XML，这些语言允许使用通用格式在不同的系统之间转换数据。

在我们的电子商务类比中，使用已发布语言的一个例子可能是每当发生新事务时更新消息传递应用程序。消息传递应用程序将向客户发送电子邮件，通知他们产品更新、折扣和相关产品。

我们可以通过将请求的详细信息发送为JSON或XML来确保数据与消息传递应用程序兼容。通过将数据作为公共格式发送，我们并没有强迫消息传递系统遵从我们的内部模型，或者在如何设计内部应用程序方面做出妥协。

分道扬镳

在许多情况下，集成的成本可能比它的价值要高。这可能是由于墨守成规的情况，或者可能是其他团队太难以合作。

如果两个系统之间的功能或数据没有内在的联系，仅仅因为它是相关的，并不意味着它应该被集成。

另一个有吸引力的选择是允许两个系统以各自的方式运行，而不是试图强制进行集成。

在我们的电子商务类比中，另一种方法的例子可能是向零售商现有的财务部门报告财务统计数据。财务部门使用一个古老的系统，需要很长时间才能与我们新的电子商务应用程序集成。

公司的财务负债需要每周、每月、每季、每年报告一次。对我们的需求来说，花费时间在两个系统之间构建实时报告的集成是多余的。

相反，我们可以简单地确保财务报告能够以所需的格式导出。这意味着两个系统根本不需要集成，因此我们失去了使集成工作正常进行的开销。

结论

在任何重要的应用程序中，几乎不可避免地需要与现有的应用程序、第三方服务或多个有界上下文集成。

世界上许多不同类型的公司都可以通过在组织内集成新的和现有的系统来获得巨大的生产力收益。

当您被要求集成两个非常不同的系统时，理解围绕集成的通用模式将是一项巨大的资产。

在开发全新的应用程序时，集成也是需要记住的重要内容。通过将您的应用程序作为一系列的服务来提供，您将使将来与您的应用程序的集成需求变得更加容易!

当分布式系统可以作为一个整体进行集成和利用时，软件的力量就会被放大。了解如何在不同的环境下集成应用程序是非常有价值的知识。

 

原文：https://culttt.com/2014/11/26/strategies-integrating-bounded-contexts/

本文：https://pub.intelligentx.net/ddd-strategies-integrating-bounded-contexts

讨论：请加入知识星球【首席架构师圈】或者飞聊小组【首席架构师智库】

上下文映射是一个工具，它允许您识别有界上下文之间的关系以及负责它们的团队之间的关系。

Image taken from https://www.oreilly.com/library/view/domain-driven-design-distilled/9780134434964/ch04.html

 

Vaughn Vernon的IDDD书中描述了几种集成多个有界上下文的方法:

• 伙伴关系
• 共享内核
• 客户的供应商
• 墨守成规
• 反腐败层
• 开放主机服务
• 发布的语言

根据代码的情况、团队的性质、业务本身、是否涉及第三方软件等，应该灵活地应用每一种方法。我将试着给出一个如何使用这些的例子。

伙伴关系

它更多地描述了团队之间的关系，而不是实际的代码。这种情况通常发生在两个团队在两个有界的环境中工作，并且有一致和相关的目标集的时候。每个团队至少应该理解他们的合作伙伴的一些无处不在的语言，即对他们自己的上下文感兴趣的东西。当两个有界上下文都处于项目的早期阶段时，这种方法可以很好地工作，因为在早期阶段，通信比实现其他一些技术更快、更有效。当双方变得更加稳定时，团队可能会因为理解彼此的通用语言而承担太多的义务。当然，如果一个团队要在这两个有限的上下文中工作，那么“伙伴关系”的成本就会低得多。

共享内核

2个或多个有界上下文可以共享一个公共模型。在设计术语中，这个共享部分的通用语言对于所有相关的团队都是通用的。在代码术语中，您可能有一个共享库或服务。这通常是一个小的代码库，但是随着相关的有界上下文的发展而难以维护，因为随着团队自身的有界上下文的发展，团队将倾向于采用不同的方式。

消费者/供应者

此方法将两个有界上下文放入上游和下游，其中上游是供应商，并且必须尝试满足客户(下游)的期望。但是最终决定客户得到什么的是供应商。这通常在同一组织内的自治环境中工作，或者如果客户是供应商的唯一客户。

墨守成规

此关系描述了两个有界上下文的关系，其中上游出于某种原因没有兴趣支持下游。相反，下游必须遵循上游所提供的内容。当将一个新特性与一个已经建立的大型现有解决方案集成时，可能会出现这种情况;或者使用一组api，而下游不是唯一的客户。

反腐败层(ACL)

这是较低级别上的另一个上游/下游关系，其中下游有界上下文实现了自身与上游之间的一个层。这一层负责将上游给出的对象转换成它自己的模型。这种方法将保证下游有界上下文的完整性，并使其完全不受任何外来概念的影响。此方法通常用于将新功能集成到某些现有遗留软件中，在这些软件中，可以将现有遗留软件视为黑盒边界上下文，并为新功能创建ACL。

开放主机服务(OHS) /发布的语言(PL)

我将同时讨论这两种方法，因为它们都定义了一种关系，在这种关系中，上游提供了一组关于集成模型的良好记录或随时可用的信息。这是建立在早期的墨守成规的方法之上的，在早期，下游要容易得多。上游还需要提供版本支持。通常，上游有界上下文将支持多个客户机，并且对特别支持某个客户机不感兴趣。例如，为了符合Amazon api，下游将通过理解Amazon提供的文档对集成有信心。

总之，理解各种上下文映射技术可以更有效地集成有界上下文。同样重要的是，首先要考虑集成是否必要并为业务带来好处。同时使用多种方法也是可以接受的，有时是首选的。例如，拥有RESTful API自然会提供OHS，但同时，下游也可能被鼓励实现自己的ACL，特别是当上游服务由第三方提供时。您的团队将是根据当前情况决定使用哪种方法的最佳人员。

 

原文：https://medium.com/ingeniouslysimple/context-mapping-in-domain-driven-design-9063465d2eb8

本文：https://pub.intelligentx.net/ddd-context-mapping-domain-driven-design

讨论：请加入知识星球【首席架构师圈】或者飞聊小组【首席架构师智库】

六方面的学习，帮你走上业务架构师之路

https://www.infoq.cn/article/k*daDrBiIlx7tJlttpuK

 

中台之上（二）：为什么业务架构存在 20 多年，技术人员还觉得它有点虚？

https://www.infoq.cn/article/th-QkbHEr82MaxS9BMof