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

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

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

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

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

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

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

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

（1）抽象出稳定的基础业务元数据。

（2）抽象出稳定的基础业务组件。

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

（4）根据客户的要求，动态生成服务接口。

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

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