使用决策管理系统的其中一个主要收益是可以让企业完全管理自动化决策的生命周期。

当决策逻辑保留在应用程序代码中时，很难将对决策逻辑代码的访问与其余代码分开。例如，通过通读代码的提交注释以查找与该决策逻辑相关的改动几乎是不可能的。同样，在代码程序中只允许决策逻辑被拥有特定角色的用户修改也几乎是难以实现的。
显然，如果您的业务数据完全掺杂在应用程序代码中，也会导致相同的情况。正如您不愿以应用程序代码的方式实现数据存储，同样的道理，您也不应该完全用代码的方式来实现业务决策逻辑。

决策管理系统将决策逻辑与其余代码分开。因此，根据业务需求灵活更新决策逻辑可以带来极大的收益。但是，只有将其与身份验证和访问控制相结合，才能取得最大收益：

• 对于特定决策逻辑资源项，您可以对访问用户进行权限设置与访问原因审核

• 并且可以追溯用户的修改轨迹，比如对哪些资源项在何时做出了哪些修改，以及修改的原因

当然，这里写的很多内容也都适用于其他系统，但这对于决策管理系统而言尤其重要。

角色和访问控制

首先要考虑的是如何控制谁有权访问决策管理系统中的哪些内容。这就是访问控制—有时候也被称为授权。
通常，人们会根据角色和资源项来定义访问控制。角色代表用户如何与系统中的资源项进行交互。
挑战在于，与自动化决策逻辑进行交互时涉及许多角色。同一个用户可能同时拥有许多不同的角色，以便他们用不同的方式使用决策管理系统。换句话说，这些不同的角色拥有不同的决策逻辑资源项的不同操作权限。

基础角色和访问控制

通常，决策管理系统中会存在以下几种角色（当然并不是唯一的划分方式）：

• 管理员
  管理员角色用户主要进行系统管理，几乎不参与其它事项。通常而言，IT或运维会被赋予此角色。

  
  

  
  

• 决策定义者
  决策定义角色是一个主要的用户角色，此角色用户主要负责管理自动化决策的需求及其预期的业务表现。通常，业务负责人和业务分析师会被赋予此角色。

  
  

  
  

• 决策实施者
  决策实施角色也是很重要的用户角色：此角色用户负责设计、实施、测试以及优化决策。通常来说，业务分析专家、数据分析家或科学家、决策所有者以及精通业务的IT人员会被赋予此角色。

  
  

  
  

• 决策测试员
  决策测试员负责对决策进行业务测试：验证决策是否符合业务需求。通常，业务分析师、数据分析师以及业务负责人会被赋予此角色。

  
  

  
  

• 生命周期管理员
  生命周期管理员角色负责确保决策逻辑资源从需求到实施，再到部署和退役遵循企业的标准操作流程。

其它进阶需求

决策管理系统中可能还需要很多其它角色，关键是要认识到企业开展业务的方式会影响这些角色的设立。比如, 我们公司 有很多企业客户，他们拥有两种类型的决策实施者角色：

• 普通决策实施者：设计、构建决策的框架以及其它部分内容，测试以及优化。

• 受限的决策实施者：设计并构建部分决策—特定规则组或模型。

上述第二类角色用户具体的权限内容因项目而异。

其它类似角色也可以在系统中进行定义，比如除了不能修改自动化决策与调用程序间的规范之外可以修改其它任何事项的角色等。

还有更加复杂的情况。您可能需要应对一种业务需求：只有特定角色的用户才能对特定决策资源进行管理。例如，您的决策中可能包含了只有特定用户才有权限看到的费率计算表，即使它是整体决策管理和执行的一部分。

对决策管理系统的要求

基于上述原因，我们期望决策管理系统能直接或通过集成的方式间接支持企业系统实现以下几点：

• 能够对决策逻辑资源进行基于角色的访问控制

• 能够根据企业业务需求自定义角色

• 能够通过角色来控制对特定决策资源的特定操作的访问

这可以通过几种方式来实现。一般来说：

• 如果所有决策资源都在由企业身份验证和访问控制系统管理的子系统中，那么您可以直接使用它。

• 如果不是这样，那么您可以将身份验证和基本访问控制委托给企业身份验证和访问控制系统，并在决策管理系统中进行更细粒度的访问控制

身份验证

当然，角色是与用户绑定的，为了确保用户的身份，您需要使用身份验证系统。企业中存在大量此类系统，它们在保护企业的资源方面发挥着核心作用。

原则

原则上对于每个需要访问企业系统的用户，身份验证系统中都应该有对应的条目。这样，验证系统才能对用户身份进行校验，并应用企业要求的所有验证策略：双因素验证、质询以及密码变更等。此外，它还可以对用户可访问时间进行控制。

这意味着需要确保有个中央系统能执行所有系统的身份验证，包括决策管理系统。例如：

• 决策管理系统仅允许通过身份验证的应用程序访问

• 或者将身份验证功能委托给企业身份验证系统

后者常见于低耦合的服务体系中。

对决策管理系统的要求

我们期望决策管理系统能够：

• 将其身份验证功能委托给企业身份验证和访问控制系统

• 或使用封装服务提供的身份验证信息

市场上存在许多不同的身份验证系统，且每个身份验证系统都可能具有多个协议。就协议而言，目前普遍使用的有：

• LDAP

• WS-Federation

• OAuth2

• OpenID Connect

• and more

追溯

此外，企业需要能够追溯到用户在决策管理系统中执行了哪些操作以及何时执行的。当然，使用身份验证系统以及用户始终在身份验证的会话中进行操作的事实将很大程度上允许它们对用户行为进行追溯。
但这不仅仅是变更日志记录的问题：公司一般还想知道谁处于活动状态、谁导出和导入了资源项、谁生成了项目报告以及谁触发了长时间的模拟运行等。

总体而言，对用户行为的追溯主要有三种类型：

• 态势感知：希望知道系统中最近发生的内容以及原因。

• 异常处理：希望当特定角色或用户完成特定操作时得到预警通知。比如，当某人在生产环境更新决策时。

• 审核取证：针对性地查找特定的操作行为，希望知道发生时间、参与人以及发生的原因等信息。例如，出于企业合规性的验证。

持久且可查询的活动流为第一类用法提供支持。与企业日志管理和通信管理系统的集成能够支持其余类型的用法。

对决策管理系统的要求

对于决策管理系统而言，我们一般希望：

• 其能提供可以浏览和查询的用户行为活动流

• 支持与企业系统的活动日志进行集成

• 并支持与企业系统中的预警系统进行集成

与这些身份验证、访问控制和追溯集成功能有关的更多细节可访问我司官网。一个有趣的趋势是，越来越多的企业从一开始就考虑上述所有因素，因为IT基础架构逐渐“云”化，即使在内部部署时也是如此。

该博客是技术系列的一部分，敬请期待