一、什么是业务架构?

实际上，当一个简单产品诞生时，它的业务、产品都相对简单，比如：某些工具类的产品，在做产品规划时，往往就不再单独考虑“业务架构”了。

还有一种情况是：产品经理主动不去考虑“业务架构”，而是直奔主题，动手画“产品原型”。

关于业务架构，简单的说就是，“企业希望从这个产品身上得到什么”，以及“用户想从产品身上得到什么”，比如：电商平台这种战略性目标是显而易见的，用户买到想要的东西，企业卖出可以赚钱的商品。

为了实现这一目标，我们还必须弄清楚那些用户，能够通过什么渠道达成他们的目标，甚至还可能会有其他的目标。

也就意味着产品端必须清晰的规划出一个完整的业务互动的过程，搞清楚一个产品涉及到的各种不同的角色，他们所期望的目标，以及他们的需要完成的业务动作，从而为产品设计打下基础。

客户的期望才是产品的真正价值。如何实现客户的期望则是产品经理的价值。

比如：音乐类产品的业务大致包括了内容版权的生产、管理、消费，涉及到的就是用户如何消费内容，版权方如何产生内容，以及平台方如何基于内容进行的运营等。

这个过程用一个图的表达，可以是这样的：

音乐平台的业务架构模型

这种构建的方式，就是“以什么业务作为驱动”的设计方法，它考虑的是整个业务之间的互相协作来达成整体业务发展的问题。

换言之，“业务架构”考虑的是：如何为用户提供价值，以及企业可以通过什么方式来实现盈利的问题。

强调的是：我们能为用户提供什么？为了实现这一目标，我们需要做什么？

用这个思路来看新浪微博，其在营收业务层面，新浪微博主要依靠流量变现业务，比如广告业务等；在用户增长业务方面，微博主要的思路就是通过扶持KOL来产生内容和社交关系，从而做大垂直领域的流量。

基本上，微博就是以社交为支撑，发力垂直业务来增加用户活跃，带来广告的变现。在此基础上的用户画像和社交关系，都是为了推动精准广告收入的提高。

用这个思路来看O2O平台，它涉及的用户既可以是终端用户，也可以是企业用户如电器卖场。作为连接用户和服务用户的“实体”则有坐席、门店和工程师，整个平台基于用户的服务请求形成的业务订单实现整个平台的业务流程。

业务架构图示例

（ ps：实际上业务架构图的表达方式并无定式，关键是如何清晰的表达整个模型是如何有效的开展业务，并在此基础上，能够进一步分解出产品的架构。）

通过整个业务的架构，我们能够清晰的厘清整个平台的用户对象、业务关系，也就确定了整个产品的业务边界范围，确定了整个团队内的业务语言。所有的产品功能都基于两端（用户端和服务端）的业务价值来展开，从而避免了很多不必要的系统开支和过度设计。

二、什么是产品架构？

如果把业务架构比作房子的地基，那产品架构就是房子的承重墙了，决定了产品的整体方向的结构。

以O2O平台为例：其业务主要是为了解决用户的“设备配送”、“设备安装”、“设备维修”三大类型，涉及的业务对象包括终端用户（发起服务请求）、门店（响应用户的服务请求）、工程师（履约服务工单）。

为了解决这一业务需求，整个平台需要完成三类服务实体（用户、门店、工程师）围绕“服务工单”的业务流转过程，我们可以用一个图来表达这种关系。

产品架构图示例

（ps：此文为简化版，后续再另文再详细阐述如何构建整个产品架构。）

这个图，我们能从上往下看用户发起请求后的一系列动作过程，也可以从下往上看，为了支撑用户的服务请求所需要构建的一系列服务。

从上图可以也可以得出一个结论：产品架构可以指导产品经理思考如何解决用户的问题，如何满足用户的期望。

作为产品的指南，“产品架构”解决的是如下三个问题：

1. 产品方向

按照产品架构图的结构和路径，产品的RoadMap也就可以被清晰的拆解出来，同时它还能指导技术架构的选型，比如：业务的容量，扩展性等等，为未来的产品发展指明了方向。

2. 产品边界

不做什么，很多时候更为重要，明确一个产品的基本边界，可以让这个产品少走很多弯路，降低很多的风险和不必要的成本。这对于创业团队来说，有些时候非常关键。

3. 产品路径

产品架构设计了各个功能模块的业务范围，针对每个功能的内外关系有清晰完整的定义。当一个产品的架构被确定后，也就确定了产品的迭代周内的范围，并且能够帮助上下游清晰的理解产品的结构、功能和复杂度。

从其解决的问题来看，我们也能很清晰的了解，一个好的产品架构图的基本要求：

• 功能经过抽象，做到标准化、互相独立

• 清晰的功能边界，架构分层明确

• 具备迭代优化的能力

  
  

三、什么是信息架构？

很多时候，产品经理拿到一个“业务需求”，就不自觉的启动类似axure的工具，开始在画布上指点江山，构建产品原型。

这其实是一种对产品的误解，也是一种不太高效的工作方式。

我们太容易从内容的呈现的角度去思考解决方案了（人类的思考惰性是更倾向于直接得到某种结果），而原型确实能够快速的看清楚产品的功能模块、页面布局和交互逻辑等元素。

这种误解，让我们惯性般只顾产品的外观体现，而忽略内在的构建逻辑，最终的结果就是产品的健壮性，扩展性不够，用户体验欠佳。

这个内在的构建逻辑就是：信息架构，它决定这个界面需要呈现什么内容，以及呈现的方式，明确的表达这个界面所需要解决的问题，也就是业务痛点。

信息架构最直接的例子就是商城了。

商城导视图

从地下的停车场，到各个不同品类的楼层，然后各个楼层通过电梯、走道进行连接，让有不同需求的顾客分流在不同的楼层。每个人都可以找到一个路径去到自己想去的地方，这个就是商城的信息架构。

对产品而言（是一个商城本质上也可以被看成是一个产品），是同一个道理，在同一个界面上，如何按照一定规则对产品的信息和内容进行组织变成极为关键，包括每一个功能按钮的位置都变成极为重要。因为它决定了用户在使用产品时的行进路线是否顺畅（体验是否良好）。

也就是在画原型之前，首先要对用户的行进路线做一个规划，让用户在任何一个页面都找到他想要的信息，能够通过最合适的路径去到下一个想去的页面。思考的重点是在功能架构被确定的情况下，如果摆放按钮，设置跳转连接，才能高效的满足用户的使用需求。

这就像一个超市，怎么设计一条合适的路线，让用户能够逛到你想TA逛到的地方，买到TA想买的东西。如果没有合理的信息架构，整个超市就一定会变成杂乱无章。

信息架构考虑的是如何高效的解决用户的问题，也就是如何提升用户的体验问题。

要注意的是在信息架构层，业务架构和产品架构都是黑盒不可见状态，也就是业务价格和产品功能架构都已经被确定，你可以尽最大的能力装修房子，而不是拆除房子的承重墙，不可以撬掉天花板，也不能动地基。

ps：产品经理应该学一点建筑学。

四、架构，是一种递进的能力

信息架构、产品架构与业务架构的关系，可以认为是一种递进的思考方式：

• 信息架构：是最前端的表现层架构，也就是给最终用户呈现的内容；

• 产品架构：连接业务和用户表现层的产品功能的架构，解决的是如何实现用户的价值问题（解决具体的问题）；

• 业务架构：包含商业逻辑在内的业务运转机制的架构，解决的是产品边界的问题，最终的目的是阐述整个产品商业模式。

以上分析可以得到一个结论，形象一些来说，业务架构是心脏，产品架构是骨架，信息架构是肌理脉络，最外面呈现的UI，只是皮肤了。

这个结论给我们的实际指导意义是：“别再把自己当原型仔，画原型是最容易的一件事”。《用户体验五要素》一书中，详细阐述了这3层结构在使用产品开发中的应用（有兴趣的朋友可以再读一读这本书）。

业务架构、产品架构和信息架构，既可以从上往下看，也可以从下往上看，都能够推导出最终呈现再用户面去的产品形态，只是取决于设计者如何结合实际应用采用的方式。

如果反过来看，其实是从业务架构一步步推导出最后的信息架构，从而以前端的表现层呈现在用户面前。

对三种架构的思考是我们把事情做对的重要方法，作为产品经理，持续对用户、业务和商业模式的深刻洞察，特别从商业层面去梳理业务架构，是产品经理的高阶能力。