| 编辑推荐: |
文章主要从视角、技术视角、业务视角及数据逻辑模型几个方面来讲解了UML建模实践——选“对”企业架构建模视角很关键。
本文来自于csdn，由火龙果软件Linda编辑、推荐。 |
|
1.关于企业架构
根据开放群组的业务领导层IT架构指引：“有效的企业架构（Enterprise Architecture，EA）对企业的生存和成功具有决定性的作用，是企业通过IT获得竞争优势的不可缺少的手段。”
企业架构如同战略规划，可以辅助企业完成业务及IT战略规划。在业务战略方面，可使用TOGAF及其架构开发方法（Architecture
Development Method，ADM）来定义企业的愿景/使命、目标/目的/驱动力、组织架构、职能和角色。在IT战略方面，TOGAF及ADM详细描述了如何定义业务架构、数据架构、应用架构和技术架构，是IT战略规划的最佳实践的指引。企业架构是承接企业业务战略与IT战略之间的桥梁与标准接口，是企业信息化规划的核心。
TOGAF架构开发方法ADM是一个可靠的、行之有效的方法，以发展能够满足企业商务需求的企业架构。
（1）预备阶段
这一阶段关注的是满足新企业架构的业务指导所需的准备和初始活动，在此阶段，应当采纳面向服务的原则。这将帮助本阶段两项额外的输出——治理和支持策略，以及初始架构库进行相互的调整适应。
（2）架构愿景
本阶段关注于愿景、范围、业务驱动力以及准备情况评估。需要在这个阶段定义架构项目的规模，风险承担者以及架构视图。
（3）业务架构
这个阶段关注于业务架构方面的事情，如人员、流程和职能。需要在这一阶段开发出一个基准和目标业务架构，并进行支持已有架构视图的缺口分析。
（4）信息系统架构
这一阶段解决的是应用和数据架构问题。需要开发基准和信息系统架构，进行支持已有架构视图的缺口分析，架构信息系统服务，并将它们与业务服务相关联。
（5）技术架构
本阶段定义架构所需的软硬件基础设施。在定义技术时，应当使用SOA参考模型。
（6）机会及解决方案
本阶段关注于初级实施规划，然后确认前面阶段所定义的架构的交付工具。对解决方案组合、集成以及管理，以及内部或外部服务供应商的确认在本阶段完成。
（7）迁移规划
本阶段的关注点是利用一个支撑性的先前阶段确认计划搭建一套细化的系列过渡架构，和项目实现团队一同创建可行的实施和迁移。
（8）实施治理
本阶段关注实施的架构性监管。架构实施应当坚持按照先前阶段所定义的TOGAF和SOA治理及策略模型进行。
（9）架构变更管理
本阶段关注新架构的变更管理，并帮助考虑采纳面向对象的原则。架构变更管理的目标是要确保架构能够实现其原有的目标业务值。这一目标包括以紧凑的架构方式管理架构变化。
（10）需求管理
处理所有类型的需求，包括显著的业务推动者、关系，及新的功能和变更请求。
参照此ADM模型，完成及预计完成工作内容如下表所示：
创建、维护一个企业架构是一件非常复杂繁琐的事情，因为这项工作需要面对许多背景、利益各异的干系人，对他们所关注的问题进行解答，并能够在他们之间形成无障碍的沟通流。为了简化这个问题的复杂度，各种企业架构框架从各个方面对企业架构的建设提供了帮助和指导。虽然这些架构框架就其具体内容来讲差异性较大，但是无论哪一种框架对于企业架构的内容却都有着自己的一套定义和分类方法，不过也正是这些分类明确、条理清晰的分类方法却使得各种企业架构框架对于各领域内容的描述缺失了他们之间的关联，因而不同领域之间的内容很难保持一致性。
不仅仅创建、维护企业架构是个复杂的问题，对于企业架构的使用也是一个非常繁琐的事情。即便我们已经创建了一个全面的企业架构，并在之后的维护中保持了良好的一致性，但是面对这样一个包罗万象的企业架构，每个干系人又如何获得其想要的信息呢？举例来说，企业的总经理需要的是组织中各个领域的概括，但并不关注于每个领域的细节，而对于基层的设计师来讲，其所关注的却是某个领域的细节。从目标和详细度这两个维度来看，没有干系人会关注所有领域的所有细节，每个干系人关心的只是和自己的利益相关的企业架构的一个侧面。因而如何从一个面面俱到的企业架构模型（描述）中根据干系人的关注点来获取相应的侧面信息也是一个亟需解决的重要问题。
综上所述，不论是创建、维护企业架构，还是对其进行使用，都需要面对一个架构内容一致性的问题。之所以会有这个问题，究其根本是因为企业架构本身是对企业这一包罗万象的客观事物的抽象和描述，而对其进行创建、维护和使用的干系人由于其本身的背景、利益不同，他们对企业架构描述的操作也只能着眼于某一个侧面。由此可见，企业架构描述与干系人的创建、维护和使用操作之间需要一个“接口”，用来规范干系人对于企业架构描述的各种操作，从而保证针对企业架构描述的修改和信息共享的一致性。
2.视角
此“接口”就是前面提到过的视图（View）和视角（Viewpoint）。其中，视图通常被定义为面向各干系人关注点的企业架构描述的一个部分，而视角则是对视图内容的抽象和描述，他定义了视图中所使用的概念元素、分析方法和展示方式。一言以蔽之，视图定义了所看到的内容，而视角则定义了所采用的观察角度。
3.技术视角
去年，我在做办公系统升级改造规划的时候，更多的考虑是系统平台升级到云计算PaaS平台，并解决一些问题及优化业务。例如《云计算统一办公运营平台服务能力设计方案》所描述的方案。其中，对流程全生命周期管理（注：这里流程是指广义上的业务，办公管理支撑范围的业务，多以走流程形式体现，因此文中命名为业务。）的理解如下面“管理业务信息”用例图（图1）所示。
图1
按图1中所示，此用例是以办公能力基础平台为视角进行设计的。例如：
平台提供快速流程开发服务，相应的需要管理其开发成果，对开发出来的工作流进行版本管理，并管理工作流使用到那些业务中及工作流所绑定的表单，并以此支撑业务全生命周期管理；
平台提供快速开发表单服务，相应的需要管理其开发成果，对开发出来的表单进行版本管理，并管理表单使用到那些业务中，并以此支撑业务全生命周期管理。
以表单为例，模拟操作步骤可以描述如下：
（1）开发或变更表单；
（2）管理表单版本，用以支撑表单所承载业务数据的历史数据可追溯，以及表单自身变更历史版本（《include》表示包括，是组成不可分割的一部分）；
（3）为业务提供表单信息，一般情况下是最新版本表单信息；
（4）管理业务信息绑定表单信息；
（5）管理业务信息衍生出业务版本信息。
因此，软件功能方面必须包括：表单版本管理、工作流版本管理、业务信息版本功能。没有这些功能就无法实现业务全生命周期管理。
在项目实施过程中，初期我更多的是关注管理和需求，为项目组提供业务建模指导，例如《易扩展的办公流程化管理核心模型（第2版）》所描述的业务核心模型，文中，分析出本项目的核心业务模型为：审批流+文档=业务流程，也就是围绕这三点进行需求分析和设计。
核心业务模型中，审批流就是指工作流，文档就是指表单，业务流程就是指业务。
从上文写的顺序分析，仍是以办公能力基础平台为视角，也就是说以技术视角在进行分析、设计。
4、业务视角
但是，在项目实施过程中，由于人力的短缺，我必须投入大量的精力参与设计工作，我的分工是主持业务全生命周期管理部分，以及业务的监控和分析。接下来，我的视角自然而然发生了转变，聚焦到业务信息及其全生命周期管理，经过分析，设计出的用例图如下图2所示。
图2
如上图2所示，此用例图从管理业务的视角进行设计，虽然表面上差别不大，但却是“差之千里”。
仍以表单为例，模拟操作步骤可以描述如下：
（1）变更业务就是新建业务，通过办公能力平台开发或变更表单；
（2）管理表单信息，把新表单绑定到业务信息上，其中，管理表单信息只管理从办公能力平台上开发出来的表单信息（《extend》表示扩展，是开发表单服务扩展衍生出的一部分，为业务信息提供关联）；
（3）管理业务信息绑定表单信息；
（4）管理业务信息绑定工作流信息，由快速流程开发服务提供新复制出的工作流信息；
（5）管理业务信息衍生出业务版本信息，历史业务版本追溯业务历史数据。
通过用例图的对比，实际上，就是视角的转变：
按业务视角，表单、流程二者或任一变化，就是业务变化，只记录业务变化版本；
而以技术视角，表单、流程分别管理版本变化，同时，按业务要求，也要管理业务的版本变化，如此管理将是非常复杂的工作，目前来看也是没有必要的。
这样，在数据库设计和功能设计上将有天壤之别。如下图3所示，按业务视角设计出业务变更过程的时序图。
图3
如上图图3所示，从核心业务角度来看，根本不需要表单版本管理、工作流版本管理功能。
按业务视角，对应数据库设计，复杂度将降低很多，不需要表单版本管理表、工作流版本管理表，以及相关的关联表。
5、数据逻辑模型
根据业务视角，推到数据逻辑模型，更多的是管理支撑业务的管理。早期，之所以出现370个流程等问题，原因是企业架构更多关注技术架构原因造成的。没有对业务架构进行有效的、全面的管理。在此推出的业务架构模型是管理流程的全生命周期管理。
技术架构为流程全生命周期管理提供定义视图、执行视图、监控及分析视图，其中，定义视图和监控及分析视图是本期建设的亮点。
图4
按全省周期管理模型建模如上图所示，此种模型类似于传统简化营业业务数据模型。
业务信息实体（假设为数据库表）通过其中“原业务信息记录号”与“业务信息记录号”自关联，以此追朔变更历史；通过与流程/信息运行实例与流程平台对接，形成闭环并且全生命周期管理。
|
