认识达内从这里开始

认真做教育专心促就业

运城IT培训关于业务架构的结构组成分析

发布：运城达内教育官网
来源：互联网
时间：2018-11-26 09:23

业务架构一般在一些大型的复杂的系统编程开发项目中才会有这部分的项目构建，所以今天我们就一起来简单了解一下关于业务架构都有哪些常见的类型。

运城IT培训关于业务架构的结构组成分析

业务架构这个词并不新，它隐藏在企业架构(EA)中。企业架构是上世纪 80 年代的产物，其标志就是 1987 年 Zachman 提出的企业架构模型，该模型按照“5W1H”，即 what(数据)、how(功能)、where(网络)、who(角色)、when(时间)、why(动机)六个维度，结合目标范围、业务模型、信息系统模型、技术模型、详细展现、功能系统六个层次，将企业架构分成 36 个组成部分，描述了一个完整的企业架构要考虑的内容。

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

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

难设计。业务架构，特别是大型企业这种错综复杂的业务架构，说起来容易做起来难，业务架构对战略的分解、业务架构自身的整合与标准化、到 IT 设计的过渡都有不少坑，业务越复杂越宽泛就越难驾驭，因此，即便做过业务架构设计的企业，也有不少将业务架构设计保持在高阶状态，有点儿“虚”;

易跑偏。施工期间由于客观因素可能导致实施对业务架构的偏离，这种偏离如果没有及时纠正或者调整架构，累积久了会造成业务架构的失真，会变“虚”;

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

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

【免责声明】：本内容转载于网络，转载目的在于传递信息。文章内容为作者个人意见，本平台对文中陈述、观点保持中立，不对所包含内容的准确性、可靠性与完整性提供形式地保证。请读者仅作参考。

< 上一篇：JavaScript编程开发项目中的常见错误处理方法

下一篇：运城IT培训关于函数式编程开发语言的类型与优点 >