业务架构的主题和规则

业务架构已经成了个时髦的词儿。就像安全一样，所有人都听说过，也都有自己的看法，但只有极少一部分人知道它的真正含义是什么。

本文在同时考虑主题和规则的情况下对业务架构的现象进行了探讨。不知道业务架构的主题，则很难判断业务架构角色的内涵和外延，比如规则。很多管理者和架构师会说：“这有什么问题？通过确定利益相关者，并收集他们的观点，基本上可以定义出业务架构。”很不幸，这种做法是极大的错误，它会引发很多自相矛盾的观点。

通过利益相关者的观点定义业务架构的支持者潜意识里会将重点从“它是什么”变成“它能为我做什么”，并且会参照ISO/IEC/IEEE 42010标准¹ 处理观点和看法。然而，这个标准警告说观点不能定义而只能用来描述主题。我们在这里要把“描述”和“定义”区分开。可能收集了上千条描述也得不到主题的定义，因为所有描述或看法都是主观的，换句话说，每个人看到的都是他或她想看的。

我在本文中介绍了一种方法，让我可以定义出和企业的业务领域无关的企业业务架构。结果我发现，业务架构比很多人想得都简单，同时跟企业中的其它业务有更复杂的关系。我将阐明这一结论的推理过程，同时列出一些成果。我注意到，在各种会议和网上对业务架构数不清的讨论中，大部分争论都是围绕着业务架构是做什么的，或者说应该做什么的，实际上这是另一码事。在我们定义对驾车的看法时，能给出车的定义吗？不能，因为驾车只与在车里的几个操作控制，以及它们对车怎么移动的影响相关。此外，还有从车上发现不了的驾驶规则和法规；只看车的外观和内饰看不出它的内部结构。如果在车上这样简单的例子都解决不了，那么对于业务架构而言，我们凭什么觉得利益相关者通过观察能比业务架构师知道得多？

业务架构定义

企业的架构业务元素

业务架构可以从业务和形式化两个角度定义。第一种方式基于业务价值。货币价值是一种众所周知的业务价值。很多人都认为这个价值，包括货币商品的等价物，是业务唯一看重的价值。货币价值的抽象非常简单，并且建模、测量和管理都很方便；然而，在消费型社会中，钱不能吃，也不能穿，更不能带走。

在成立一个新公司时，要写出企业的商业模式，就是公司的“业务面”。它通常是由企业的核心业务职能组成的，是企业在市场上区分于其它企业的关键。业务职能是企业跟消费型社会中的“供需”因素之间唯一的连接。

仅用货币价值衡量这个连接有点儿鼠目寸光。货币价值会混淆需求满足机制，经过长期的运营，在需求发生变化时，公司可能会错过调整这种机制以跟进需求的关键点。如果客户满意度下降了，公司的营收可能暂时还不会受到影响，但等到营收开始下降时可能就太迟了，公司在客户那里的名声可能已经坏掉了。也就是说货币价值可以用来衡量业务成效，但不应该作为唯一的标准。

与此同时，在消费型社会中，业务职能可以确定所有公司的业务价值。如果这个职能能够满足消费者的需求，它们就能帮公司赚钱。也就是说第二种方式用货币和职能来衡量业务架构。如果业务架构是基于业务职能的，那公司业务的精华和战略目标很可能能够适应市场的变化。