本文通过商业地产案例，详细解析了企业架构的设计与实施步骤，帮助读者理解架构设计的全局视角和具体实践。从业务实质到管理理念，再到具体的架构设计，每一步都是企业向数字化转型迈进的必经之路。

本文阐述了企业架构的一般方法论，并重点以商业地产业务为例，拆解架构设计的具体步骤，供大家交流参考。

提起架构，大部分人都会望而生畏。对于B端产品经理来说，要想在职业上获得长远发展，除了实现具体功能，还要持续学习让自己具备全局视野、业务视角、技术思维，过程是艰辛的。我很喜欢《中庸》中的一句话，共勉：

人一能之，己百之；人十能之，己千之。果能此道矣，虽愚必明，虽柔必强。

人话是：菜就多练练。

一、企业架构的意义

企业的战略决定了企业的业务，企业的业务决定了所需的技术。也就是说我们做系统、做企业信息化，本质上是为了支撑具体的业务。

企业架构提供了一种高层设计方法，用于指导IT规划，让我们从全局视角审视业务、信息、应用、技术间的相互关系，避免业务与IT系统“两层皮”。

二、企业架构理论框架

企业架构最早由John Zachman在《信息系统架构框架》中提出，其架构的核心是组织结构+数据+流程。

而目前应用最广泛的是TOGAF框架，提供了一套完整的方法论和工具集，并且体现了业务驱动IT的思想。

该框架提供了4个建模级别：业务，应用程序，数据和技术，这种分层对企业架构设计起到很好的指导作用。

三、商业地产业务的企业架构设计案例分享

接下来我以商业地产业务为例，聊聊企业架构的具体步骤。不同的业务场景可以参考这个步骤，逻辑是一样的。

1. 业务实质

在开始企业架构设计之前，首先分析业务实质。商业地产本质上是一个可以提供长期收益权的金融工具。

进一步展开：房地产是载体，整合了土地、建筑材料、资金、技术、劳动力、品牌、供方、客户、基础配套设施等资源；商业是灵魂，通过一系列规划、设计、品牌组合、运营、资源配置等手段，实现顾客满意，从而为租户提供可持续盈利能力，进而为业主提供可持续租金收益。

从上述分析可知，商业地产以稳定、持续的租金收益为目标，核心利益主体是顾客、租户、业主。有效的经营管理是实现该目标的关键要素之一。经营管理者链接顾客、租户、业主等利益主体，既是管理者，也是服务者、沟通者、协调者。

2. 管理理念

在商业地产经营管理相关的资料中，多次出现“统一招商管理、统一营销管理、统一服务监督、统一物业管理”的统一经营管理理念，业内认为该模式有助于实现商业物业的整体价值提升。

商业地产发展的初期以销售型物业为主要模式（即“只售不租”），开发商通过开发-销售-再开发的方式迅速回笼资金，扩大生产。这种模式下的物业所有者是分散的商铺业主，统一管理难度大，物业管理即是经营管理的全部内容。

随着房地产开发企业完成原始的资本、能力、经验的积累，商业地产逐步发展为“只租不售”或“租售结合”模式，开发商既是投资者，也是物业持有者，追求长期、稳定的投资回报。

在这种模式下，物业管理是经营管理的基础手段和重要组成部分，还需要与统一的业态规划、招商、运营、客户服务等管理手段整合，共同支撑商业物业实现稳定的租金收益和市场价值的提升。

3. 业务架构

基于统一经营管理理念，可以得到商业地产业务的价值链模型（图1），对应流程分级管理体系中的L1级、L2级流程。

图1 商业地产价值链模型

将价值链模型进一步细化（仅对主体活动），可以得到如图2所示的业务架构。每个业务活动都包含决策、管理、执行三个层次。

注：也可以按照流程分级管理体系拆细颗粒度，按照L3、L4、L5…的方式表述，这里我更想补充用户角色的维度和视角。

图2 商业地产业务架构

4. 数据架构

基于价值链模型和业务架构，梳理数据架构如图3。业务产生的核心数据资产集中在物业管理、招商管理、营销管理、服务监督、财务、人事6大主题数据域。由于L1业务流程之间的关联性、依赖性，为保证数据跨域流动的一致性，还需要构建一个共享数据层：

• 主数据：维护共享的静态数据（变动不频繁的、核心业务实体）。例如招商阶段收集的商户档案，正式签约后成为租户，对同一客户而言，在系统中仅保存一份档案，避免数据冗余或不一致。下游的应用场景均读取该份档案，如租金收取、合同续签、投诉处理时对租户档案的调用。
• 业务数据：维护共享的交易数据（频繁、重复发生的业务过程）。例如与物业管理公司签订的合同、与租户签订的合同、与买量渠道签订的推广合同等，统一维护。财务处理应收、应付业务时可以进行调用。

图3 商业地产数据架构

5. 应用架构

基于价值链模型、业务架构和数据架构，梳理应用架构如图4。基于SOA设计思想（Service Oriented Architecture），将应用架构分为4层：

• 平台层：提供底层的技术能力、业务能力、数据能力。
• 服务层：由于应用场景的庞杂性，将应用层中的可复用组件进行抽象、剥离，下沉至服务层。
• 应用层：具有高度灵活性、可定制性，满足不同场景、不同用户的应用需求。
• 交互层：与终端用户的交互界面，提供对应用层的访问入口。

图4 商业地产应用架构

四、关于技术架构的浅见

在第三部分，眼尖的读者可以发现我没有给出技术架构方案。这部分内容需要更深厚的技术积累，作为一个产品经理，还远远达不到。我仅从一般性的角度，补充一点个人理解。

关于什么是架构（主要指软件架构），不同的组织、个人，有不同的定义和理解，难以一概而论。我在这里列举一些，供大家从不同角度理解。

1. IEEE对架构的定义

The fundamental organization of a system, embodied in its components, their relationships to each other and the environment, and the principles governing its design and evolution.

IEEE简洁、清晰地定义了架构的几个核心要素：系统的组织、组件及联系、设计与演进原则。这个定义带给我的一个启发是，架构是动态演进的，架构经历了从单体模式，到SOA，到微服务，到云原生的演变，未来会继续演化。对于任何系统而言，没有最好的架构，只有最合适的架构。

2. 软件开发大师Martin Fowler对架构的定义

Software Architecture =Important and hard to change decisions.

大师说的一定有其道理。我不禁想起之前看过的一个访谈乔布斯的视频，他讲到如何将一个好的创意转化为好的产品时，提到一个词trade-off，所有的决策过程都是权衡利弊的艺术，越是重要的的决策越是如此，你必须把握好哪些是要坚持的、哪些是要让步的。

3. 王概凯的《架构漫谈》中对架构的定义

1. 根据要解决的问题，对目标系统的边界进行界定。
2. 并对目标系统按某个原则的进行切分。切分的原则，要便于不同的角色，对切分出来的部分，并行或串行开展工作，一般并行才能减少时间。
3. 并对这些切分出来的部分，设立沟通机制。
4. 根据3，使得这些部分之间能够进行有机的联系，合并组装成为一个整体，完成目标系统的所有工作。