提起架构，大部分人都会望而生畏。对于B端产品经理来说，要想在职业上获得长远发展，除了实现具体功能，还要持续学习让自己具备全局视野、业务视角、技术思维，过程是艰辛的。我很喜欢《中庸》中的一句话，共勉：
人一能之，己百之；人十能之，己千之。果能此道矣，虽愚必明，虽柔必强。
人话是：菜就多练练。
一、企业架构的意义企业的战略决定了企业的业务，企业的业务决定了所需的技术。也就是说我们做系统、做企业信息化，本质上是为了支撑具体的业务。
企业架构提供了一种高层设计方法，用于指导IT规划，让我们从全局视角审视业务、信息、应用、技术间的相互关系，避免业务与IT系统“两层皮”。
二、企业架构理论框架企业架构最早由JohnZachman在《信息系统架构框架》中提出，其架构的核心是组织结构+数据+流程。
而目前应用最广泛的是TOGAF框架，提供了一套完整的方法论和工具集，并且体现了业务驱动IT的思想。
该框架提供了4个建模级别：业务，应用程序，数据和技术，这种分层对企业架构设计起到很好的指导作用。
三、商业地产业务的企业架构设计案例分享接下来我以商业地产业务为例，聊聊企业架构的具体步骤。不同的业务场景可以参考这个步骤，逻辑是一样的。
1.业务实质在开始企业架构设计之前，首先分析业务实质。商业地产本质上是一个可以提供长期收益权的金融工具。
进一步展开：房地产是载体，整合了土地、建筑材料、资金、技术、劳动力、品牌、供方、客户、基础配套设施等资源；商业是灵魂，通过一系列规划、设计、品牌组合、运营、资源配置等手段，实现顾客满意，从而为租户提供可持续盈利能力，进而为业主提供可持续租金收益。
从上述分析可知，商业地产以稳定、持续的租金收益为目标，核心利益主体是顾客、租户、业主。有效的经营管理是实现该目标的关键要素之一。经营管理者链接顾客、租户、业主等利益主体，既是管理者，也是服务者、沟通者、协调者。
2.管理理念在商业地产经营管理相关的资料中，多次出现“统一招商管理、统一营销管理、统一服务监督、统一物业管理”的统一经营管理理念，业内认为该模式有助于实现商业物业的整体价值提升。
商业地产发展的初期以销售型物业为主要模式（即“只售不租”），开发商通过开发-销售-再开发的方式迅速回笼资金，扩大生产。这种模式下的物业所有者是分散的商铺业主，统一管理难度大，物业管理即是经营管理的全部内容。
随着房地产开发企业完成原始的资本、能力、经验的积累，商业地产逐步发展为“只租不售”或“租售结合”模式，开发商既是投资者，也是物业持有者，追求长期、稳定的投资回报。
在这种模式下，物业管理是经营管理的基础手段和重要组成部分，还需要与统一的业态规划、招商、运营、客户服务等管理手段整合，共同支撑商业物业实现稳定的租金收益和市场价值的提升。
3.业务架构基于统一经营管理理念，可以得到商业地产业务的价值链模型（图1），对应流程分级管理体系中的L1级、L2级流程。
图1商业地产价值链模型
将价值链模型进一步细化（仅对主体活动），可以得到如图2所示的业务架构。每个业务活动都包含决策、管理、执行三个层次。
注：也可以按照流程分级管理体系拆细颗粒度，按照L3、L4、L5…的方式表述，这里我更想补充用户角色的维度和视角。
图2商业地产业务架构
4.数据架构基于价值链模型和业务架构，梳理数据架构如图3。业务产生的核心数据资产集中在物业管理、招商管理、营销管理、服务监督、财务、人事6大主题数据域。由于L1业务流程之间的关联性、依赖性，为保证数据跨域流动的一致性，还需要构建一个共享数据层：
主数据：维护共享的静态数据（变动不频繁的、核心业务实体）。例如招商阶段收集的商户档案，正式签约后成为租户，对同一客户而言，在系统中仅保存一份档案，避免数据冗余或不一致。下游的应用场景均读取该份档案，如租金收取、合同续签、投诉处理时对租户档案的调用。
业务数据：维护共享的交易数据（频繁、重复发生的业务过程）。例如与物业管理公司签订的合同、与租户签订的合同、与买量渠道签订的推广合同等，统一维护。财务处理应收、应付业务时可以进行调用。
图3商业地产数据架构
5.应用架构基于价值链模型、业务架构和数据架构，梳理应用架构如图4。基于SOA设计思想（ServiceOrientedArchitecture），将应用架构分为4层：
平台层：提供底层的技术能力、业务能力、数据能力。
服务层：由于应用场景的庞杂性，将应用层中的可复用组件进行抽象、剥离，下沉至服务层。
应用层：具有高度灵活性、可定制性，满足不同场景、不同用户的应用需求。
交互层：与终端用户的交互界面，提供对应用层的访问入口。
图4商业地产应用架构
四、关于技术架构的浅见在第三部分，眼尖的读者可以发现我没有给出技术架构方案。这部分内容需要更深厚的技术积累，作为一个产品经理，还远远达不到。我仅从一般性的角度，补充一点个人理解。
关于什么是架构（主要指软件架构），不同的组织、个人，有不同的定义和理解，难以一概而论。我在这里列举一些，供大家从不同角度理解。
1.IEEE对架构的定义Thefundamentalorganizationofasystem,embodiedinitscomponents,theirrelationshipstoeachotherandtheenvironment,andtheprinciplesgoverningitsdesignandevolution.
IEEE简洁、清晰地定义了架构的几个核心要素：系统的组织、组件及联系、设计与演进原则。这个定义带给我的一个启发是，架构是动态演进的，架构经历了从单体模式，到SOA，到微服务，到云原生的演变，未来会继续演化。对于任何系统而言，没有最好的架构，只有最合适的架构。
2.软件开发大师MartinFowler对架构的定义SoftwareArchitecture=Importantandhardtochangedecisions.
3.王概凯的《架构漫谈》中对架构的定义根据要解决的问题，对目标系统的边界进行界定。
并对目标系统按某个原则的进行切分。切分的原则，要便于不同的角色，对切分出来的部分，并行或串行开展工作，一般并行才能减少时间。
并对这些切分出来的部分，设立沟通机制。
根据3，使得这些部分之间能够进行有机的联系，合并组装成为一个整体，完成目标系统的所有工作。
本文由@大愚原创发布于人人都是产品经理，未经作者许可，禁止转载。
题图来自Unsplash，基于CC0协议。
该文观点仅代表作者本人，人人都是产品经理平台仅提供信息存储空间服务。
