在这个架构模型系列的前一部分中，我写了关于根据业务，信息和技术领域组织模型库的文章。我还解释了创建单独的当前和未来状态模型以及模型内容和视图之间的分离的必要性。在本系列的这一部分中，我还有一些关于命名和建模约定的内容，以及有关如何在模型周围建立治理和质量保证结构的建议。
4.定义命名和其他建模约定
为了能够在大型模型中找到任何东西，您必须知道要寻找什么。用简单的语言，您需要知道模型中所谓的内容以及标记方式。这就是定义明确的命名约定至关重要的原因。不同的组织将有自己的特定命名方案，因此没有普遍的约定适用于所有情况。
不过，这里有一些常见的技巧可以帮助您创建命名过程：
- 让业务专家“拥有”功能，业务流程，功能等的名称和定义。如果IT人员为这些人创造了新名称，那么企业往往无法识别其中的“业务”，从而导致误解和误解。
- 为特定类型的元素定义特定的命名约定。例如，对过程名称使用现在时动词加名词（例如'Handle Claim'）。这样，元素的名称已经为您提供了有关被建模事物类型的信息。
- 在大型组织中，使用名称的前缀或后缀，例如元素的业务域。如果这些域使用相同的名称，这一点尤为重要。例如，在保险公司中，“健康”，“生活”或“财产”等不同的域可能都有“处理索赔”流程，但这些流程会有所不同。称他们为“处理索赔 - 健康”或“处理索赔 - 财产”有助于区分他们。
- 在建模的同一现实生活实体的不同方面之间进行明确分离。如果您为作为参与者参与流程的客户建模，请不要对您在该客户上捕获的信息使用相同的名称。您还应该在存储该信息的客户文件或数据库中使用不同的名称。将所有这些元素称为“客户”肯定会让使用您的模型的人感到困惑。
- 在使用建模概念时要有选择性。像ArchiMate这样的语言非常丰富和强大，但你很少需要他们所有的概念。选择将哪些概念用于哪些目的并限制自己的基本要素是保持架构易于理解的关键。
5.建立'编委会'
要在大型联合组织中创建协作，您不能依赖中央部门的简单自上而下控制。必须有局部差异的空间，因为在大型组织中，没有标准适合所有情况。
尽管如此，您确实需要在不同的部门和域之间进行协调，以确保他们的工作方式兼容，并分享彼此的经验，从而建立自己的组织特定最佳实践库。
与这些庞大而复杂的组织合作，我看到创建一种“编辑板”通常很有帮助，该编辑板由来自组织不同领域的代表性架构和建模专家组成。他们可以在您的架构中找到共享的工作方式和其他共性（例如前面提到的建模惯例和结构），并且他们可以指导他们经验不足的同事应用这些实践来推广高质量的模型。
但是，“编辑板”与典型的架构板不同，后者决定架构内容本身。相反，这个编辑委员会负责监督架构的建模和描述方式。这是两个截然不同的能力：良好的架构可能记录得很糟糕，而且糟糕的架构可能有很好的文档记录。确保两者都做得好。
6.明确职责，访问权限，用户组和程序
在任何大型组织中，您必须清楚谁做什么以及谁有权访问哪些材料。如果每个人都可以编辑您的架构模型中的任何内容，您可以猜测会发生什么。事情可能会被移动或整个模型可能被删除。
一般而言，我不主张从视图中隐藏部分体系结构（除非出于特定的安全相关原因）。应该信任建筑师，看看同行的工作并充分利用它。但是，您可能需要限制对在创建或更新模型中具有已定义角色的人员的写访问权限。否则，你的模型很快就会变得一团糟。
实现此目的的一种方法是在项目中组织未来状态体系结构的工作，每个体系结构都有自己的特定模型，如上所述。项目团队有权更改他们的项目模型，但结果只有在他们已经足够准备好时才会发布到更广泛的体系结构存储库，这是由组织中的首席架构师或决策者决定的。
Enterprise Studio的团队平台支持组织为设计人员和首席设计人员提供的不同项目，角色和权限，并提供可组织为项目团队的用户组。 此外，HoriZZon门户中的工作流程设施允许您创建批准和审核工作流以组织体系结构开发过程。
有兴趣了解我们支持大规模架构工作的方式吗？ 加入我们的网络研讨会或预订演示
原文:https://bizzdesign.com/blog/6-ways-to-organize-your-architecture-models-part-2/
本文:http://pub.intelligentx.net/node/380
讨论：加入知识星球【首席架构师圈】