惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

小众软件
小众软件
C
Check Point Blog
Vercel News
Vercel News
Y
Y Combinator Blog
G
Google Developers Blog
P
Proofpoint News Feed
WordPress大学
WordPress大学
MongoDB | Blog
MongoDB | Blog
博客园 - 司徒正美
Last Week in AI
Last Week in AI
博客园 - 【当耐特】
N
Netflix TechBlog - Medium
L
LangChain Blog
V
V2EX
钛媒体:引领未来商业与生活新知
钛媒体:引领未来商业与生活新知
Cyber Security Advisories - MS-ISAC
Cyber Security Advisories - MS-ISAC
大猫的无限游戏
大猫的无限游戏
D
DataBreaches.Net
博客园_首页
B
Blog RSS Feed
The Cloudflare Blog
MyScale Blog
MyScale Blog
freeCodeCamp Programming Tutorials: Python, JavaScript, Git & More
Microsoft Security Blog
Microsoft Security Blog

人人都是产品经理

为什么你的产品找不到差异化?90%的失败都卡在第一步上(下) – 人人都是产品经理, 3年从30万到1300万用户、获2200万美元融资,这个AI教育产品用“抽卡”破解了获客难题 – 人人都是产品经理, 园区招商系统怎么做才能真正帮到去化?我加了这一个功能,推广链接转发400次阅读过万 – 人人都是产品经理, AI大事件:OpenAI发完网络安全模型又搞药物研发,小鹏汽车要抓”DeepSeek时刻” – 人人都是产品经理, 电商不是卖货,是一场更残酷的产品经理实战 – 人人都是产品经理, 没想到,活动营销又回来了! – 人人都是产品经理, 为何All-in海外KOC:一场关于AI时代窗口期的豪赌 – 人人都是产品经理, 重新理解企业的内部协作 – 人人都是产品经理, 苹果的 AI 战略到底是什么? – 人人都是产品经理, 医疗智能体·第2讲——合规护城河:等保、PIPL与HIPAA的架构实战 – 人人都是产品经理, 向量知识库五步法:从“答非所问”到“精准回复” – 人人都是产品经理, 鸿蒙PC三方库构建总指挥HPKBUILD(sha)库为例 – 人人都是产品经理, 何时该用LLM?AI产品经理的LLM设计指南 – 人人都是产品经理, 医疗信息领域的需求方、决策方、准入方以及关注点(二) – 人人都是产品经理, 即梦涨价:一场被误读的「傲慢」 – 人人都是产品经理, 面试AI PM必答题:Hermes和OpenClaw的区别,如何讲清楚业务价值 – 人人都是产品经理, AI的下一张船票:世界模型——AI产品经理必须理解的技术拐点 – 人人都是产品经理, 小红书做GEO,怎么让AI信你?记住这 3 个重要信息 – 人人都是产品经理, 5 家印度 AI 初创公司,看看印度 AI 再做什么 – 人人都是产品经理, AI项目跨团队协作:产品技术业务如何不打架 – 人人都是产品经理, Agentic Workflow(智能体工作流):让AI从”答案生成器”变成”数字员工” – 人人都是产品经理, lycium_plusplus 项目全景解读:OpenHarmony 三方库构建的“大管家” – 人人都是产品经理, 从爆单救火到前置履约:两套预采策略,把生鲜大促履约效率拉满 – 人人都是产品经理, 什么时候该补货?我用一轮数据做了一个决定 – 人人都是产品经理, 从“机械兜底”到“动态分流”:AI客服重复进线治理的4大底层逻辑 – 人人都是产品经理, 抖音拼效率,红书拼洞察 – 人人都是产品经理, 全民狂欢与退潮——为什么龙虾这波热潮冷却得如此之快? – 人人都是产品经理, Stripe押注!MPP重塑全球支付 – 人人都是产品经理, 小红书GEO:AI引用你的内容,不是因为你对,而是因为你看起来可信 – 人人都是产品经理, 前百度副总裁押注办公Agent,日韩付费爆发,Manus迎来强劲对手 – 人人都是产品经理,
看完还不会画产品架构图来打我
咪说产品 · 2024-11-08 · via 人人都是产品经理

在产品经理的工作中,绘制架构图也是一箱必备技能。但不少同学只是一些简单的设计,没有体系的思路。本文组综合分享的TOGAF这种框架,希望可以帮到大家。

早期入行产品经理时,看到大厂产品他们绘制的架构图,我满心羡慕。虽然那时看不懂,但那丰富的模块和看不懂的话术,也是让我憧憬何时拥有这种装A的能力。

日后这些年,我在网上找绘制架构图的方法,看了大量图和他人总结的方法,几乎没有能讲清产品架构图绘制底层逻辑和要领的内容。随着工作推进和对产品思考的深入,我总结出一套自己的产品架构图绘制思路,在此分享给大家,与大家交流。

一、认识这4个架构视图

在职场交流中,架构一词频繁出现,尤其对于产品经理而言,业务架构、数据架构、产品架构、技术架构及信息架构等概念屡见不鲜。那么,架构究竟是什么?这些架构之间又存在怎样的关联?

这里我们先简要了解一下TOGAF,这是一个广受认可的企业架构框架。TOGAF旨在为企业设计、规划及管理复杂的架构系统提供指导,它通过一套清晰、结构化的方法论,如架构开发方法、架构内容框架和企业架构能力框架等,确保企业在追求业务目标的同时,技术架构能够紧密贴合业务需求。值得一提的是,目前已有80%的福布斯50强企业采用了TOGAF框架。

TOGAF框架下,企业架构由四个核心层面构成:业务架构、应用架构、信息架构和技术架构。每个架构都涉及组织不同方面的运作和支持,为了确保企业整体目标的实现,它们需要紧密协作,形成系统化的支持结构。

1、业务架构

业务架构描述了组织的业务战略、目标、流程、功能、组织结构和职能等内容。它提供了整个企业架构的背景,是所有技术架构、应用架构、信息架构等设计的基础。业务架构确保技术和信息架构与组织的业务目标、战略方向和运营模式相匹配。

2、应用架构

应用架构描述了企业内各个应用系统、软件组件、服务以及它们之间的关系与交互方式。它提供了一个整体的应用系统结构,展示了企业如何通过技术手段来支撑和实现业务流程。应用架构关注系统的功能、服务、数据流和系统间的集成。

3、信息架构

信息架构关注企业中的信息管理、数据流动、存储、分析与应用等方面。它涉及数据的结构、存储、处理和访问方式,确保企业能够高效地获取、处理和使用数据,以支持业务运营和决策。信息架构确保数据的质量、可访问性和安全性。

4、技术架构

技术架构描述了支撑整个业务和应用架构的技术基础设施,包括硬件设备、操作系统、网络架构、数据库管理系统、云平台等。技术架构确保企业的技术平台和系统能够高效、安全、可靠地运行。

四者是一个系统化和协同的关系,它们之间相互影响、相辅相成,共同构成了一个完整的系统架构蓝图。在实际操作中,理解这些架构之间的关联,可以帮助产品经理、架构师、开发人员更好地进行架构决策和产品规划。

更多关于TOGAF的内容,大家有兴趣可以自行网上找资料阅读。或者留言,我给大家发一些关于TOGAF的完整资料。

二、应用架构和产品架构区别

现在,我们已然对企业架构有所了解。细心看到这里的同学会发现,似乎文章至此并未触及产品经理最为关注的产品架构这一关键内容。那么,产品架构究竟是什么呢?它和应用架构之间又存在着怎样的联系与区别呢?

我们知道,应用架构是 TOGAF 框架中明确界定的架构类型之一,可对于产品架构,该框架却未直接提及。为了深入探究两者的关系,我在网络上搜寻了大量相关资料,这些资料大致呈现出两种观点。

观点一:应用架构等同于产品架构的集合,是多个产品汇聚而成的应用。就好像是一群各自有着独特功能的个体(产品),组合在一起形成了一个功能更丰富、更复杂的整体(应用)。

观点二:应用架构服务于产品架构,处于产品架构的下一层级。这种观点下,产品架构更像是战略层面的规划者,应用架构则是负责执行战略的具体实施者。

结合过往工作经验,我对产品架构和应用架构的区别有以下总结:

产品架构侧重于把控整体业务需求、规划功能设计和优化用户体验。例如设计社交软件时,要确定社交关系建立、信息分享、隐私保护等业务需求和使用便捷性、舒适度。

应用架构负责将需求转化为可运行的技术方案,保障系统高效稳定运行。要考虑技术框架、数据库结构、服务器配置等细节,以实现产品功能。比如社交软件信息分享功能,要确定是用即时通讯还是异步消息传递技术,用哪种数据库存储数据,服务器如何部署应对高并发传输。

可见,产品架构和应用架构相互依赖、相辅相成。产品架构为应用架构提供需求和方向指引,应用架构为产品架构提供技术实现基础,二者共同推动产品落地,为用户创造价值。

这里我梳理了一个产品架构和应用架构的对比,能让你对我的观点有更好的理解。

三、绘制产品架构图

现在,我们已经对系统架构图有了更为深入的理解,并且清晰地认识到,产品架构的设计和业务需求是紧密相连的。实际上,产品架构的构建和优化往往是由业务需求驱动的,业务流程、用户需求、市场趋势等因素都直接影响着产品架构的设计与调整。这种紧密的关系要求我们在设计产品架构时,不仅要考虑技术实现,还要深入理解业务的背景与目标。

下面将通过一个实际案例,详细解析产品架构的绘制过程。

1、业务梳理

在着手绘制产品架构图之前,我们首先要对业务进行全面且细致的梳理。如图,这里我针对连锁餐饮门店管理相关业务绘制了一个视图。在这个视图中,涵盖了业务目标、门店赋能、总部数字化以及门店数字化等多方面内容。通过这个视图,能够非常直观地观察到总部为门店所需要开展的一系列赋能工作以及动作。也能清晰地看到门店运营过程中所必需的数字化产品和工具。这为后面绘制产品架构图提供了坚实的业务基础,确保架构能够充分支持业务需求。

2、提炼业务

根据业务目标,提炼出了两个关键点:提升门店营收提升门店管理效率。这两个目标不仅是推动门店发展的核心动力,也是产品架构设计和功能规划的核心出发点。围绕这两个目标展开了一轮产品功能的头脑风暴,构思了多个创新和高效的功能模块,旨在通过技术手段优化门店运营、提升业绩。

3、架构分层

到了这步,我们已经具备了绘制产品架构图的基本素材。接下来,我们需要对产品架构进行分层处理,以便更加清晰地展示系统的结构和功能关系。通常,产品架构图的分层包括四个层次:表现层、应用层、支撑层、数据层。这四个层级可以有效地展示产品的各个组成部分,以及它们之间的相互作用。然后我们遵循自上而下的信息传递即可。

表现层:表现层是与用户直接交互的部分,负责展示数据并接收用户输入。

如:APP、小程序、Web、PC桌面端。

应用层:应用层是负责业务逻辑和操作流程的核心部分,将基础服务和数据处理结果转化为具体的应用功能。

如:订单管理、物流管理、商品管理等。

支撑层:为应用提供基础服务和通用功能的层,支撑系统的高效运行与可靠性。主要是将可复用的组件或模块进行下沉,为产品提供统一的支撑。

如:流程引擎、消息通知、任务调度等。

数据层:数据层是系统中负责数据收集、存储、处理和流转的部分。它是应用系统的核心数据管理层,确保数据的安全性、一致性和可访问性。

如:交易数据、行为数据、日志数据等。

4、整理分块

最后,我们将已提炼出的产品应用进行分组,形成应用层,将产品的基础服务提取出来,构建基础服务层,并将产品中通用的组件、引擎等提炼为支撑层。至此,整个产品架构图就绘制完成了。大家日后多加练习,早日进阶哦。

本文由 @Tamil 原创发布于人人都是产品经理。未经许可,禁止转载。

题图来自 Unsplash,基于 CC0 协议

该文观点仅代表作者本人,人人都是产品经理平台仅提供信息存储空间服务。