本篇文章介绍了在从0到1设计过程中，需要考虑哪些环节，搭建哪些基础功能，以及如何进行运营管理。
随着技术和合作共享思维的发展，硅谷率先推出了开放平台，比如谷歌开放了map api，将自己的地图能力进行开放。
twitter开放了社交api，其他厂商，比如游戏等就可以直接调用twitter账户进行登录，同时关联好友关系。国内随后也掀起了一场开放浪潮，逐渐开放了地图、新闻门户、电商、支付等很多行业的核心能力。
本次我们主要集中聊一聊一个开放平台在从0到1设计过程中，我们需要考虑哪些环节，我们需要搭建哪些基础功能，以及我们如何进行运营管理。
一、为什么要搭建开放平台？
通过开放自己平台产品服务的各种API接口，让其他第三方开发者在开发应用时根据需求直接调用，例如微博登录、支付宝支付，微信支付、酒店查询预订等等。
此种方式在我从业经验中用的较多的其实是一些智能硬件设备厂商，将管理设备的能力开放给合作伙伴和客户，帮助客户或者合作伙伴能够快速在自己系统中集成相应的能力。
比如之前我在物业集团做智慧社区，涉及到智慧停车、智慧门禁、智慧安防、智慧对讲，如果我们一个一个自己搭建，当然是费力费事，如果我们借助于硬件厂商的开放平台，就可以快速在我们自己的系统搭建起相应能力，作为厂商来说，他们就成功将自己的服务能力提供给了我们，提升了他们的品牌效力，同时加强了产品竞争力。
备注：部分情况下，也可以开放H5给第三方，此种情况下第三方不需要再进行页面和后台开发，只需要根据平台方要求传入相应的参数即可。
二、开放平台服务形式
开放平台主要是将自己的资源或者服务通过API、H5的形式开放给第三方合作伙伴或者客户进行对接，帮助他们快速构建自己的某一项应用。
从形式上来说，大致分为两类：
1. 开发者请求时，开放平台返回对应的H5链接，在这种形式下，通常是开发者传入自己系统的用户账户信息，然后直接在开放平台的H5链接内进行服务。这种形式的开放在支付宝的服务中就有很多，比如社保公积金查询、汽车服务等。
优势：对于开发者来说，开发成本极低，基本上没有什么开发量，上线时间更快，且无需详细了解对应业务的逻辑及规则等。对于平台方来说，也更简单，不用重复和不同的开发者进行接口联调。
劣势：开发者无法直接获取自己系统用户实际的业务情况，比如下单量、下单金额等，完全依靠平台提供的数据；相应的页面的风格无法变更，可能存在不符合自身系统风格风险；
2. 开发者请求时，根据API的函数传入对应的参数，平台返回对应的数据内容，开发者再将内容进行整合后按照自己的风格进行呈现。
优势：开发者可以按照自己系统的设计规范进行呈现，使用户无法感知相关的资源和服务是第三方平台提供的。对于有交易类型及分成的业务，开发者可以自己掌握相关订单数据，不用完全受制于平台方提供的数据；
劣势：开发成本相对较高，开发者需要详细了解业务规则及逻辑，同时还要进行前端页面设计和开发；平台技术方，需要对接开发者的接口联调及问题解释，对于人力资源的投入相对来说更高；
综合起来看，也不一定能说哪种形式更好，具体的需要结合实际情况来定自己的开放平台采用哪些形式进行开放。合作关系、业务模式、团队情况、业务发展阶段、系统稳定性等都是考虑的因素，最后详细拟定采用哪种或者多种形式；
三、开放平台设计
本次我们主要说一说API方式的开放平台设计，其中属于企业服务类型的，主要需求符合智能硬件厂商开放平台的设计需求，与支付宝、微信类型的标准接入型开放平台有差异。主要从产品需求层面进行剖析，从需求引申到功能，不涉及具体技术层面。
开放平台主要解决以下几个层面的需求：
- 开发者身份注册与数据权限范围授权
- 开发者获取相关资料（接口文档、使用说明、对接人联系方式等）
- 平台方内部管理，申请审核流程、服务配置、业务交易管理、参数配置、人员分配等
- 业务交易管理及统计报表分析（涉及双方需要结算的类型）
- 安全层面需求，加密、应用秘钥、应用接口权限控制、访问黑白名单、字段脱敏还原等
结合针对需求的分析，我们整理了一下开放平台的基础功能的清单，主要是针对开发者、内部管理员的，其次是基于安全层面的一些功能需求。
1. 开发者门户
通常情况下，开放平台会挂在公司的官网上某个入口，当然有些时候也会放在一个特定的门户地址。开发者门户主要是帮助用户在平台进行注册、申请接入、查询审核进度、查看相关接入参数、下载文档等，接入成功并上线后，查看一些运营数据，方便与平台方进行对账。
注册&接入申请：开发者通过公司名称、手机号或者邮箱进行账号注册，注册后即可以填写接入申请，申请单内容一般主要包含接入需求描述、关联项目、联系人（平台方，一般是商务人员）、申请方联系人及联系方式、接入模式、费用、申请类型等等；
备注：关于费用问题一定要描述清楚，有些合作伙伴需要定制开发，通常是需要收费的，一般是标准API接入免费，定制化需求及定制化系统开发需要收取费用（有些合作伙伴会有开发需求）；
进度查看&参数获取：申请提交后，开发者可以在线查看申请进度，审核成功后即可查看相关接入参数，如果审核不成功可以重新修改后提交；
下载相关文档：开发者可以自助下载相关接口文档及其他说明文档；
业务交易管理：针对开放的业务不同涉及的内容不同，对于有订单业务或者付费服务的业务来说，需要进行交易管理，主要是查看交易、对账、结算等基础功能；
统计报表：主要是根据开发者的业务类型，提供相关业务的一些数据报表，比如订单数量、变化趋势、用户数据等等，具体结合开放的业务拟定；
2. 开放平台内管系统
开放平台内管系统，主要是解决内部商务人员对需求的补充，相关部门负责人对接入需求的审核、系统管理员对参数配置以及服务管理等，同时也管理相关对接人员制定及运营管理部分的配置和查看等。
接入申请审核&参数配置：内部相关人员对开发者申请需求进行审批，审批成功后执行的人员对参数进行配置并制定对接人负责后续接口联调及相关问题解答；
运营管理：主要是对交易类型订单的管理及对账，同时管理相关报表数据的需求，进行配置；
3. 安全机制
安全机制中主要是对开发者账号及权限进行管理，访问次数流量监控，IP地址管控，黑白名单管控等，其中针对公司人员变动问题，对于访问服务器地址控制是比较重要的。
四、接口设计
开放平台的功能基本上说清楚了，还有一个细分部分我们单独拉出来说一下，就是接口的设计。
通常情况下，开放的相关服务我们自己的系统已经进行引用，并且有相应的接口函数，但是不能直接用，因为作为平台服务方，我们由于版本问题及一些历史原因等可能存在一些历史遗留问题，作为开放平台对外输出的接口我们应该关注并处理一下几个方面：
1. 对接口的整合
对于一些比较复杂的无用的字段一定要进行删除，避免给开发者造成不必要困扰
2. 对各版本系统兼容性
这个主要针对的是有些厂商，设备前端软件版本不同，造成参数内容范围统计不完善的情况，云平台一定要进行整合兼容。
比如停场场景下，前端停车管理软件历史性版本中返给云平台的车辆状态码有20种，但是云平台对外开放时只考虑到了10种状态码（或许是本来就只有10种状态），而这样在实际运行中，如果云平台只是做一个透传没有做兼容，那么就有可能第三方系统获取到了未知状态码（接口文档上没有），从而造成第三方开发者设计的系统存在缺陷。
3. 协议适配
提供服务的可能是一些老旧的系统，报文格式可能是XML、定长报文等，这时就需要对不同协议的报文进行适配转化，形成统一
五、开放平台管理
开放平台设计好后，还需要进行良好的运营管理，才能发挥开放平台应有的用途，同时增强公司的品牌力量及核心竞争力。
首先我们来看一下一个案例，我梳理的一个开放平台的对接流程图：
接入对接的各个环节流程，基本上就是上面这个流程图所示，下面主要讲解几个注意事项：
1. 开发者提交申请后，通常建议是售前或者商务人员进行审核和补充，其中包括客户的价值、项目价值，费用核算等，因为客户填写的需求通常只会设计功能及使用层面。公司前端销售人员填写的资料有助于审核通过，公司项目管控肯定是基于销售情况，比如有订单的优先、高价值客户优先等
2. 审核负责人一般包含两部分，一个是市场端的负责人审核，便于后期对公司内部做结算管理一个是技术支撑端负责人审核，主要是需求明确及工作量和费用
备注：关于审核，前端销售容易什么需求都接，也不太考虑相关成本，因此平台公司最好建立良好的成本管控意识及机制，并且在审核时涉及工作量的一定要反馈给前端，不然容易造成什么需求都在接，接了后实际并没有对公司整体业务有太大价值，或者技术支撑人员疲于第三方的对接。
3. 配置参数后，通常可以直接将相关的技术对接人在平台给到开发者，相关问题可以直接沟通。当项目启动后，也可以平台方前端人员将两方的相关人员一并拉在一个群里面进行沟通。平台方技术人员也需要具备客户意识，尽量尊重和有礼有节的处理客户需求。
4. 在测试环境通过后，开发者可以发起正式环境上线申请，平台方配置相关参数，开发者进行生产环境发布
5. 发布后，开发者的运营及财务就需要介入了，进行数据查看及订单对账结算等
六、后记
至此呢，基本上就将一个智能硬件厂商的开放平台的设计和管理总结清楚了，当然本方案其实也适用于一些其他行业或者系统，希望对同行有一点点启发，同时如有不正确之处，欢迎指正和交流！
2019年回归物联网，我们一起成长，春季期间将陆续整理相关总结及知识进行分析，尽请持续关注！
作者：Kent，*Liuke2019
本文由 @Kent 原创发布于人人都是产品经理。未经许可，禁止转载
题图来自Unsplash，基于CC0协议
