无论是软件开发商,咨询公司还是甲方自己,要把业务模型完整的建立起来,都需要非常高的功力。这些功力,更多的不是业务或技术本身,而是模型化的能力。所谓模型化,核心强调的是业务架构、业务组成和业务关系等的抽象能力。当你面对复杂的业务单元,面对复杂的业务规则和业务数据,你如何才能在最短的时间内完成对业务系统的再认识和模型化呢?这是个挑战!

    以往的系统需求开发过程,我们的工作常常从访谈开始。我们和不同的岗位、和不同的级别访谈。访谈让我们很快了解到业务的某些细节或者轮廓,了解到某些业务问题或者期望。但是,随着时间的推移,我们很容易“沦陷”在越来越庞大的访谈记录中,变成了业务系统的学习者。我们的软件也就变成了业务系统的“模仿者”。这种“学习---整理---再学习---再整理---直到拥有足够的模型元素”的被动式建模过程,它的模型化工作并不突出,往往很难看到业务系统的架构。当面对不同复杂程度的业务系统时,这个建模思路成功的概率并不相同。另外,这种建模方式已经不能满足业务战略变化对软件系统的要求。

    业务架构驱动的需求开发过程,把业务建模过程的核心工作突出出来。业务建模的核心工作是对构成业务架构的关键业务功能、关键业务流程和关键业务数据的优先捕获和优先模型化。业务架构驱动的需求开发过程的价值在于:

    (1)把需求开发工作分解成业务架构开发和一般需求开发。这种两段论思路,优先对业务架构及其构成元素进行建模,有利于尽早的分析软件系统的架构。因为业务架构决定和影响着软件架构;而尽早的开始考虑软件架构,为软件系统的成功赢得了充足的时间。

     (2)建立业务架构有利于适应业务战略的变化。现代企业竞争已经变成了常态竞争。企业需要随时根据市场变化调整自己的业务,其中包括:开发短线的细分市场产品,调整业务规则,服务或产品的融合等等。这些业务的调整,需要快速甚至实时地体现在信息系统中。为此,需要设计一个高灵活性的业务架构,相应地,对应一个高灵活性的软件架构。否则,就很难满足企业的上述要求。一个高灵活性的业务架构意味着,基础稳定的业务组件和动态配置的业务规则,以及灵活多变的服务接口和业务衔接点等。

    (3)有助于控制需求的变更。那么不能确定的、也不影响业务架构的需求,我们不用急着实现,给它的稳定留足时间,避免过早的实现导致返工。

   (4)有利于不同业务在应用层的集成。多个不同的业务系统,当需要协作完成新的产品或服务时,各个业务架构能够彼此衔接对方的服务接口。

一个良好的业务架构如何描述呢?简单来讲,无非以下几点:

(1)抽象出稳定的基础业务元数据。

(2)抽象出稳定的基础业务组件。

(3)若干业务组件的协作完成一个业务流程。

(4)根据客户的要求,动态生成服务接口。

(5)若干业务流程组合实现一个服务接口。

    业务架构驱动的需求开发过程,是一个行业内或跨行业的业务建模思路,它至少超越了企业业务。它要求我们站在行业的全局高度关注业务架构的规划和设计。在这一点上,日本比我们要高瞻远瞩。