荐书丨企业业务架构的发展及与IT架构的关系

正文

请到「今天看啥」查看全文

1.3　FEA和 DODAF

在 TOGAF之后，又先后诞生了 FEA（联邦企业架构）和 DODAF

（美国国防部体系架构框架）。 前者的体系由 5个参考模型组成： 绩效参考模型（PRM）、业务参考模型（BRM）、服务构件参考模型（FRM）、数据参考模型（ DRM）和技术参考模型（ TRM），该方法应用于美国电子政务领域，着眼于跨部门、跨机构提升业务效率，解决重复建设、信息孤岛等问题，相当具有“企业级”理念； 虽然没有明确的业务架构定义，但是很好地应用了业务架构的思维。 后者体系比较复杂，共有 8个视点 52个模型，但是实用性不错，据说美国国防部和一些相关企业都在使用，详细内容如表 1-3所示。

表1- 3　DODAF的核心—8个视点与 52个模型

表 1-3中能力视点和作战视点就是我们做企业架构时通常关注的业务部分。 这两个模型在网上都有相关资料，感兴趣的读者可以自行查阅。

1.4　沉吟至今

通过寻根溯源我们可以发现，即便是从 TOGAF算起，业务架构这个词也有 20多年的历史了，但是在开发人员中，业务架构显然没有需求分析的概念明确，业务架构师也远不如产品经理常见。 笔者曾就职的单位曾经实施了一个长达数年的、以企业级业务架构驱动的转型项目，但是很多企业并没有这样的经历，因此，每当与技术人员讨论至此，他们就会觉得业务架构有点儿虚，细究可能有如下几点原因。

• 用得少

原有的单体式或竖井式开发依然是企业更常采用的项目构建方法，而这种开发基本上没有横向视角，所以无需强调业务架构，通常的产品分析或者需求分析即足以满足其开发需要。

• 难设计

业务架构，特别是大型企业这种错综复杂的业务架构，说起来容易做起来难。 业务架构对战略的分解、业务架构自身的整合与标准化，到 IT设计的过渡都存在不少陷阱，业务越复杂宽泛就越难驾驭。 因此，即便是尝试过业务架构设计的企业，也有不少是将业务架构设计保持在高阶状态，让做过的人自己都觉得有点儿没底气。

• 易偏离

施工期间由于客观因素可能会导致实施对业务架构的偏离，这种偏离如果没有得到及时纠正或架构调整，那么累积久了就会造成业务架构的失真。

• 难维护

少数度过了业务架构落地困难期的企业，也会由于感受到维护架构的难度而心生放弃，从而降低了对业务架构的评价。

1.5　业务架构的定义

业务架构从诞生之初就很清楚地定义了自己的使命： 面向复杂系统构建。 也就是说，业务架构与其他架构一样，其目的也是要降低复杂度，从更好地规划和实现系统，因此 TOGAF将业务架构归属于 IT战略部分。 但是从笔者的实践经验来看，业务架构更突出的特点是影响了参加过企业级业务架构设计工作的业务人员，他们的逻辑思维能力、结构化能力、企业级观念和意识都发生了明显的改变，所以，应当将业务架构从 IT战略中独立出来，更多地面向业务人员，以充当业务与技术之间的桥梁。 当然，业务架构要想真正承担起这一职责，还需要改进、简化业务架构设计的方法，对业务人员更友好，并且坚持使用业务架构方法做企业级需求管控，否则，“熵增”一定会将已经建好的架构秩序回归到混沌状态。

说到这里，本书也尝试为业务架构提供一个简单的定义：

请到「今天看啥」查看全文