APP开发如何设计好业务架构

在APP开发中，业务架构这个词大家时常提到，但是能解释得清楚的却不多，也常有人问起业务架构师和产品经理什么区别？业务架构分析和需求分析什么区别？在APP开发中如何做好业务架构。

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

Zachman 模型虽然没有明确提出业务架构这个概念，但是已经包含了业务架构关注的一些主要内容：如流程模型、数据、角色组织等，既然没有提出业务架构概念，自然也就没有包含构建方法，所以，Zachman 模型应该算是业务架构的启蒙，同时，它也表明了这一工具或者技术的最佳使用场景——面向复杂系统构建企业架构。

TOGAF架构模型明确提出了业务架构的概念，TOGAF 将企业定义为有着共同目标集合的组织的聚集。例如，企业可能是政府部门、一个完整的公司、公司部门、单个处 / 科室，或通过共同拥有权连接在一起的地理上疏远的组织链。TOGAF 进一步认为企业架构分为两大部分：业务架构和 IT 架构，大部分企业架构方法都是从 IT 架构发展而来的。业务架构是把企业的业务战略转化为日常运作的渠道，业务战略决定业务架构，它包括业务的运营模式、流程体系、组织结构、地域分布等内容。TOGAF 强调基于业务导向和驱动的架构来理解、分析、设计、构建、集成、扩展、运行和管理信息系统，复杂系统集成的关键，是基于架构（或体系）的集成，而不是基于部件（或组件）的集成。

TOGAF 之后，又先后诞生了 FEA（联邦企业架构）和 DODAF（美国国防部体系架构框架）。前者的体系由五个参考模型组成：绩效参考模型（PRM）、业务参考模型（BRM）、服务构件参考模型（FRM）、数据参考模型（DRM）、技术参考模型（TRM），该方法应用于美国电子政务领域，着眼于跨部门、跨机构提升业务效率，解决重复建设、信息孤岛等问题，很具有“企业级”理念，虽然没有明确的业务架构定义，但是很好地应用了业务架构的思维。后者体系挺复杂的，8 个视点 52 个模型，但是实用性不错，美国国防部和一些企业在用。

业务架构这个词也有 20 多年的历史了，但是在开发人员中，业务架构显然没有需求分析的概念明确，业务架构师也远不如产品经理常见。与APP开发人员讨论，他们也常觉得业务架构有点儿“虚”。细究其原因，可能有如下几点：
用得少。原有的单体式或者竖井式开发依然是大家更经常采用的项目构建方法，而这种开发基本上没有横向视角，所以无需强调业务架构，通常的产品分析或者需求分析足以满足开发需要；
难设计。业务架构，特别是大型企业这种错综复杂的业务架构，说起来容易做起来难，业务架构对战略的分解、业务架构自身的整合与标准化、到 IT 设计的过渡都有不少坑，业务越复杂越宽泛就越难驾驭，因此，即便做过业务架构设计的企业，也有不少将业务架构设计保持在高阶状态，有点儿“虚”；
易跑偏。施工期间由于客观因素可能导致实施对业务架构的偏离，这种偏离如果没有及时纠正或者调整架构，累积久了会造成业务架构的失真，会变“虚”；
难维护。少数扛过了业务架构落地困难期的企业，也会由于感受到维护架构的难度而心生放弃，从而降低了对业务架构的评价。

其实，业务架构从诞生之初就很清楚地定义了自己的使命：面向复杂系统构建。也就是说，业务架构同其他架构一样，目的也是要降低复杂度，更好地规划系统，因此 TOGAF 是将业务架构归属于 IT 战略部分。应当将业务架构从 IT 战略中独立出来，更多面向业务人员，以充当业务与技术之间的桥梁。当然，业务架构真正要承担起这一职责，还需要改进、简化业务架构设计方法，对业务人员更友好，并且坚持使用业务架构方法做企业级需求管控。

未来，业务不再仅仅是业务，技术也不再仅仅是技术，谁先实现思维方式的改进，谁就能赢得转型的先手，而业务架构能力可以在这方面发挥关键作用。