16c504a7d10f449a7fd1c2a8e8072403
《产品架构分享会》演讲稿

背景:内部分享会:产品架构 - 小专栏


大家好,感谢大家能够参加这次分享会。

根据领导的要求,希望我能够针对这个产品做一些方向性的规划,所以,跟咱们项目团队沟通了几次,最后产出了这张架构图。

下面我将花大概半个小时的时间,给大家分享一下这张图所表达的意思。

前言

产品架构这个词定义比较宽泛,针对信息型产品,可能等同于信息架构,针对功能型产品,可能等同于功能架构。

而产品架构更多的表示信息架构和功能架构的总称。

当然,具体叫什么并不重要,重要的是要把想要说的事情,描述清楚就行了,在这里,我希望能够把咱们产品未来的发展方向说清楚,就可以了。

画架构图,有一些固有的模型,可分为层次结构,自然结构,线性结构以及矩阵结构。

最为广泛使用的就是层次结构。

在层次结构中,不同的产品架构图,表现也不一样。有的可能分支比较多,但是层数少;有点可能分支少,但是层数多。这个要看具体是什么产品(好像说了句废话)。

例如,淘宝的产品架构表现出来,肯定是分支多,层数少,因为业务范围太大,已经不仅仅只是电商这么简单了;而同样为电商行业,唯品会的产品架构图,分支就要相对少些,层数会多,因为它属于电商里的某个垂直领域。

至于怎么画,主要还得看产品自身的定位,以及产品的侧重点在哪里。

输入层

我们从这张图的最底层开始看,最底层是输入层,这个是根据我们业务方向定的。

由于是工具软件的定位,这个产品是要建立在别人已有的数据仓库基础上,我们的输入来源是客户端数据平台或文件系统里的试验数据。

我把这个叫做输入层,对于产品来说,这里的工作相对比较被动,但是由于咱们软件所在行业的特殊性,这里的工作又非常重要的。

如果能做到反过来去规范客户方输入的数据格式,那将是非常有意义的一件事情。

从龙哥那边了解,老板那边可能想要做成像 Excel 那样的工具。
但是咱们与之不同的是,我们需要做培养用户习惯的工作,而 Office 是软件时代的开创,它是带领用户习惯的。
所以,你看,我们现在的 Windows 桌面端软件,几乎都是照着 Office 软件的界面设计的。这就是差距。
这些都是题外话了。

所以,我这里单独把管理规范列出来了,这也是我们要去做的工作,从之前几次项目组的沟通会上了解到,目前咱们开发人员的痛点,从大面上讲,其实就是两点:数据标准化问题,以及业务流程标准化问题。

回到数据的输入层,咱们客户端的试验数据分为三种类型,文本数据,原始二进制,以及数据库数据。

之前我们都是对接客户的文件系统,不过,年前已经有研究所提出直接对接数据库的需求了。
我相信这个应该是趋势,随着客户方数据管理平台的逐渐上线,慢慢应该都会向这个方向发展。

再往上,数据的产生形式有两类:实时数据,以及滞后数据。

这块也是龙哥建议要区分开的,我认为还是有必要的。
两种形式对于上层数据预处理来说,采用的是完全不同的技术,也对应了不同的业务类型,这个后面再说。

输入层这块说完了,接下来往上是数据层。

数据接入层

实际上,这一层才是咱们软件平台的最底层,对我们的产品来说,首先要解决的问题是,输入过来的数据,如何接入?

这块原本想要作为独立的接入层,由于没有考虑清楚,就没有往下细化了。
到时候讨论的时候,可以看看大家有什么建议。

说到这,涉及一个问题,那就是层与层之间到底是什么关系,什么标准划分?

这里说一下我这里的标准,那就是解耦,每一层都可以拎出来作为独立的产品,独立的软件,也许是采用完全不同的语言开发的,也没有关系,定义好接口规范就可以了。

回到这里,我认为数据接入这里,其实是可以作为独立产品的。

目前我们专注于这个特定行业,有一定的优势,假如我们把所有的研究所的判读数据接入这块做了,其实是可以形成一个平台化的产品,这个产品也许就是一个 API,但是盘子够大,价值还是很明显的。

就类似于 Windows 操作系统接管了所有电脑硬件。这个比喻有点不自量力,但大体上是这个意思。

数据预处理 & 存储

接入了数据之后,接下来就是数据预处理以及存储的过程。

这块就简单说一下,因为这块的技术比较成熟了,关键是要根据业务,定义好数据格式以及数据规范。

top Created with Sketch.