思考产品架构的4个视角：业务、场景、数据/功能、实现
我们今天以AIoT为例，来聊一聊思考产品架构的4个视角：业务、场景、数据/功能、实现 。
这篇文章的案例内容，主要来自于https://aiotframework.org/index.php?title=Product_Architecture，如果你对这个领域感兴趣，可以进一步的查看。
这是我目前查看到的非常具有代表性的，并且带有启发性的资料。
首先让我们看看这四个视角分别代表什么？
定义：产品架构的4个视角
业务视角：在业务模型的基础上，思考产品能力的展现 场景视角：重点关注用户、使用、流程等系统元素 数据/功能视角：关注产品功能和数据 实现视角：注重如何产品落地
在AIoT 的框架视角看，除了从4个维度思考产品架构，更要关注产品架构如何引导产品实践。而实践的有效方法是敏捷。
产品架构的业务视角
在产品架构中的业务视角中，需要建立业务模型、客户调研、人物角色、史诗故事。
在AIoT产品体系的业务视角是对业务模型中创建的不同组件的细化。鉴于AIoT解决方案严重依赖于现场部署的物理产品/资产，需要在实际部署场景中进行研究。
在许多传统的企业IT项目中，在哪里使用软件并不重要，特别是当主要的访问点是浏览器时。对于AIoT，这种情况有很大不同，因为物理产品可能会根据部署在其中的环境类型表现出不同的行为。另外，根据环境的不同，使用模式可能会有很大的不同。因此，产品设计的团队花时间在现场，并研究不同环境下的不同使用场景。
人物角色是产品或解决方案的典型用户。通常，人物角色代表的是基于你对真实用户的了解的虚构人物。
业务模型和敏捷工作计划紧密结合是很重要的。AIoT产品建议业务模型团队将高级的工作包定义为史诗故事，然后敏捷团队可以将其分解为更小的待办事项条目(例如用户故事)。
从AIoT的产品架构给我们的启发：产品架构来自业务流程和参与其中的关键角色，业务流程中抽象出高度概括的故事。
产品架构的场景视角
在产品架构的场景视角，需要解决方案草图，用户旅程地图，以及原型图。
业务模型的AIoT解决方案草图可以从这个角度进行细化，以一种稍微结构化的方式添加额外的细节层。
从业务模型出发的用户旅程可以作为起点。通常，在产品设计的这个阶段，为不同的场景创建单独的旅程地图是一个好主意，为原始的高级旅程添加更多细节。
原型图是沟通产品设计交互部分的强大方式，例如智能手机或平板电脑的web界面和应用程序。它们最初应该保持在概念层面。
从AIoT的产品架构给我们的启发：在场景视角下，需要用框架图展现产品，然后再使用用户地图展示详细的流程，最后用原型图展示产品。
产品架构的功能/数据视角
数据和功能的视角提供了设计细节，涵盖了数据和功能设计方面以及它们的依赖关系。这个视角的引入，便于抽象功能或数据封装系统组件的服务。
从产品架构的观点上，需要关注数据域和技术实现。
领域模型应该提供产品设计的关键实体的高级概述，包括它们与外部系统的关系。它的目的不是提供与详细数据模式或对象模型相同级别的详细信息。相反，它应该作为在产品团队中跨多个涉众组的涉众之间讨论数据需求的基础。下面的例子展示了智能电钻产品在制造中的细节，包括对MES系统的依赖。
AIoT的技术实现是需要从技术服务角度，通过不同的服务组件，搭建完成技术产品。
对于许多产品来说，能够将高层次的需求追溯到产品设计级别是一个关键点。在AIoT框架的角度来看，需要经历如下步骤：
需求被映射到敏捷的主题/特性 AIoT功能架构:AIoT服务架构被设计来支持不同的史诗故事/产品特性 AIoT技术架构:考虑延迟和带宽等技术约束，然后将功能服务映射到技术服务(包括应该将服务部署在何处的决策)
从AIoT的产品架构给我们的启发：在功能/数据视角下，逐渐的从宏观的流程和故事，细化成为具体的功能；并从数据角度，思考产品的功能和架构。细化到功能的视角时，就可以与技术进行关联。
不过，对于没有技术背景的产品经理来说，从数据到技术的跳跃，确实有一些难度。但是，梳理和构建产品架构的理论体系，并摆脱技术知识限制，也是我写这一系列文章的应有之义。
产品架构的实现视角
产品架构的实现视角，是需要产品经理与技术团队从软件、硬件的技术架构角度，选择可以与产品相匹配的架构。
总结
我们以AIoT产品架构为例子，来看一下在思考产品架构时候，需要考虑的4个视角：业务、场景、数据/功能、实现。通过这个案例，可以为我们提供一个思考产品架构的方向。不过，还是缺少了一部分视角，那就是商业视角，即从商业模式的角度思考产品是否能够成功。
题外话：
关于产品架构的知识非常的难找，中文资料如此，英文资料亦是如此。我个人倾向找一些英语资料，如果你感兴趣的话，可以使用Product Architecture的关键词来搜索。
如果你喜欢这篇文章，欢迎关注上面的公众号
点击“阅读原文”
查看更多干货