业务与 IT 之间的那些爱恨纠葛，怎么来化解？从IT规划说起

业务和 IT 之间的矛盾，这是一个由来已久的老话题了。

比如：

• IT辛辛苦苦把系统做上线了，结果业务还不咋满意；
• 系统上线后一开始感觉还行，可过两年就怨声一片；
• 业务部门老说他们要的功能没做出来，说IT部门能力不行；
• IT 就觉得委屈，业务提需求老是不能一次说全，还反反复复的；
• 做出来的系统就像是打补丁，然后补丁之上再叠补丁，最后这些系统都成孤岛，互相不通了……

这些都是很真实的情况。

要解决这些矛盾，

我们还得追根朔源，从一开始的 IT 规划说起。

一、企业 IT 规划的路：业务架构→功能架构→技术架构

企业 IT 规划的路是这样的：

先是业务架构，再到功能架构，最后到技术架构。

业务架构呢，

就是说一个企业的业务结构和关系，

像有哪些业务功能模块、业务域、业务单元，

还有企业价值链结构和业务模式啥样，

有啥业务场景，还有描述这些场景的结构和逻辑关系等等。

这些东西，你不用管细节，

那是 IT 系统设计和实施的事。

业务架构不是技术活，

或者说

业务架构的技术，不是 IT 技术。

虽然业务架构不要求"技术"，但也并不容易，

不但要对业务有系统性的理解，

还得有结构化概念思维和模型化表达，

这里面还涉及业务之间、管理之间，

以及业务和管理之间的关系。

二、功能架构：业务与IT的"翻译层"

功能架构呢，

就是在业务架构基础上，

想想怎么用 IT 系统实现那些功能。

包括企业 IT 建设的整体蓝图、原则标准啥的，

还有 IT 系统之间以及和人之间怎么协作。

功能架构是业务架构和技术架构的桥梁，

得考虑业务需要，也得考虑 IT 系统功能的特点。

（* 功能架构在TOGAF标准中属于4个架构中的应用架构的一部分）

从经济上说，

规划的价值就是用尽量小的成本保证实现预期目标。

所以说，

功能架构不是单纯业务活，也不是单纯 IT 活。

业务人员需要懂需求，IT 人员则去考虑技术路线，

这个过程是需要对话的，需要业务和 IT 一起来完成。

三、技术架构：纯技术的规划工作

技术架构呢，

还在功能架构之后，

就是实现功能的技术策略。

像基础设施和系统设计，

选啥语言、啥框架、啥数据库，

咋部署、咋通信这些。

技术架构是纯技术的规划工作，

得由 IT 架构师来做，

然后才是 IT 系统开发和实施的具体工作。

功能架构和技术架构可以说是企业IT规划的整体蓝图，

也可以应用于对单个IT系统的规划和设计。

四、矛盾根源：各自"自说自话"

业务和IT之间为什么总有解不开的矛盾？

主要原因在于业务人员和IT人员之间

没有一个很好的彼此沟通的语言，

都是在自己的语境和逻辑中"自说自话"。

他们之间需要一个"翻译官"和"联络员"的角色，

企业架构师（EA）或业务架构师（BA），其实是最合适的。

或者是能把《需求规格说明书》写清楚的

产品经理（PM）或项目经理（PM），

也可以充当这个角色。

这里提到的《需求规格说明书》，

或者类似产品需求文档之类的，

这个文档需要描述系统（产品）的功能、性能、数据的需求，

也要描述开发的目标、过程和标准等等。

一句话：

IT需求设计得越详尽，实现起来就越简单；

最后，也不会出现IT与业务之间相互推诿扯皮的现象。

好了，以上就是对于IT规划和IT需求设计方面的一些基础的介绍。想要进一步学习，建议参加TOGAF企业架构师认证（或者CBA业务架构师认证）。

TOGAF 提供了一套全面且规范的架构框架，使得 IT 人员和业务人员能够拥有共同的语言和理解基础。它是连接 IT 与业务之间的重要沟通桥梁，不论你是做IT的，还是做业务的，都可以学一下。

小艾老师科普时间：

左右滑动查看更多

左右滑动查看更多