Srinath Perera是WSO2的研究副总裁。
API已成为连接内部和外部服务，应用程序，数据，身份和其他数字资产的一种选择机制。 结果，API现在有潜力用作类似的有价值的分析机制。 同样重要的是，API可以为传统的临时数据收集和数据分析方法提供易于使用的替代方法，这些方法减慢了将信息转换为当今数据驱动型组织所需的智能的过程。
API和分析的联盟是自然而然的，因为这两种技术对于简化运营和解锁创新都是至关重要的。 通常，组织将通过拥抱API来开始其数字化转型，以增强系统集成和流程自动化。 借助市场上几种全面的交钥匙API管理解决方案，企业开发人员可以在数周至数月内将系统投入生产，并进行集成以轻松填补任何空白。 从那里，团队可以不断改进实施。
[InfoWorld的要点： 什么是Apache Spark？ 大数据分析平台介绍了以下内容 • Spark教程：Apache Spark入门 • 什么是数据挖掘？ 分析如何发现见解 。 | 通过《 InfoWorld日报》时事通讯了解最新的企业技术中的关键新闻和问题。 ]
随着企业向数据驱动型企业发展，数字化转型的下一步是分析。 用来理解组织动态并帮助决策的技术包括复杂的数据聚合，机器学习，数据挖掘和数据可视化。 它们一起使企业团队能够了解业务动态，检测模式并预测未来的发展。 但是，与收集数据和建立自定义分析相关的挑战阻碍了分析的采用。 即使采用分析技术，一旦预测就可以带来巨大的变革影响。
本文探讨了使用传统方法进行分析的挑战，探讨了API管理如何应对这些挑战，并提出了使用API管理挖掘有价值的数据进行分析的解决方案蓝图。
采用分析的障碍
在实施分析时，组织面临三个关键挑战，每个挑战都有可能延迟或使项目脱轨。
首先，与API管理不同，没有交钥匙分析解决方案。 相反，组织必须通过组合不同的分析技术（无论是产品还是开源项目）来构建自定义分析解决方案。 反过来，这要求开发团队编写大量代码以集成必要的技术和现有系统。
其次，组织将需要雇用对统计，机器学习和系统有深入了解的数据工程师（开发人员）和数据科学家（架构师）。 这些专业人员（供不应求）将需要确定有用的见解，确定要跟踪的关键绩效指标（KPI），设计要收集数据的系统以及让组织中的其他小组添加数据收集代码。 他们还必须编写自己的分析逻辑，通过编写更多代码来基于分析结果执行操作，并从第一级到第n级了解这些观察结果。
第三，为了收集数据，组织需要在整个组织中添加检测（传感器），以便生成表示重要活动的事件。 这样的项目需要跨多个小组的协调-大型企业中的团队从10到20个不等。 此外，组织可能需要等待将传感器运送给他们。 结果，仪器化过程通常既昂贵又费时。
尽管分析可能产生深远的影响，但迄今为止所有这些障碍都限制了分析的采用。
API驱动的分析的优势
由于两个因素，API管理有潜力使分析得到更广泛的使用。 首先是API管理解决方案的广泛采用，自2016年以来，API管理解决方案一直以每年35％的速度增长，这是由于客户和合作伙伴要求将业务活动作为API公开以实现更紧密的集成和更轻松的自动化而推动的。 此API技术以成熟的工具和强大的生态系统为后盾。
其次是API管理在组织的所有消息流中的战略定位。 API正在成为企业所有内部和外部交互所通过的通道。 甚至网站和其他用户界面也依靠这些API来执行其后端功能。 可以很容易地看到观察API流量如何使团队能够确定组织随着时间的推移如何运作。 当API成为所有交互的中介者时，API管理解决方案就可以成为显示组织工作方式的门户。
因此，我们应该考虑将一站式API驱动的分析解决方案作为API管理工具的组成部分，而不是构建一站式分析解决方案。 出于两个原因，这种解决方案是可行的。
首先，由于API管理处于组织内部或组织内部所有通信的十字路口，因此我们可以使用API管理工具代替实际系统。 这可以作为API管理框架的一部分完成一次，可以根据需要进行更新。 然后，通过收集通过API的消息，我们可以获得组织的完整视图。 这种集中式方法消除了企业协调10或20个团队向所有系统添加工具的需求。 它还消除了管理通过传统分析的系统工具收集的多种格式数据的挑战。
相反，由于所有数据都是通过API管理系统通过一个逻辑层收集的，因此数据的格式是已知的。 这使开箱即用的API驱动的分析解决方案得以开发，该解决方案支持现成场景中的常见用例，例如欺诈检测，客户旅程跟踪和细分分析等。 无论是在软件供应商，系统集成公司还是企业开发团队中，一支熟练的数据科学家团队都可以投资构建涵盖大多数常见用例的复杂分析。 然后，大型企业中的多个组织或多个组可以使用针对这些场景的分析。
下一部分将描述遵循此过程的，由API驱动的交钥匙分析解决方案的蓝图。
API驱动分析的蓝图
在交钥匙API驱动的分析解决方案中，我们可以使用API管理工具，而不是对整个企业中的每个系统或子系统进行检测。 通过检测所有API活动收集的数据可以提供足够的信息来分析和深入了解组织及其内部工作。 此外，更新分析功能可以通过更新API管理软件来实现，该API管理软件是一个由单个组管理的系统，而不是组织中的多个系统和团队。
下图显示了API驱动的分析解决方案的高级蓝图，该解决方案位于API管理之上。
WSO2 在API管理之上分层分析。
在此处说明的方法中，在API层收集的数据将包含有关以下内容的信息：
- 请求和响应，包括时间戳，标头，完整消息，消息大小和请求路径URL
- 调用，IP地址，用户名和用户代理
- 处理，包括开始时间，结束时间，结果，错误，API名称，主机名和协议
仅使用以上信息，分析系统就可以详细显示哪些用户正在从何时何地调用哪些API。 可以对该视图进行进一步分析，以了解客户的旅程，例如了解导致客户购买的活动以及了解API收到的负载。
但是，上面列出的视图对于许多用户来说太技术性了，而没有对业务概念的更高层次的映射。 以下是此类映射的一些示例：
- 除了知道收到了多少个请求外，了解与每个请求相关的资金流将很有用。
- 除了只知道API名称之外，了解API属于哪个业务单位以及服务请求的平均成本将非常有用。
- 除了了解客户名称之外，引入客户人口统计信息并根据人口统计数据对数据进行切片和切分也很有用。
简而言之，要提供更多的业务级别见解，数据收集层必须超越显而易见的范围并收集其他信息。 让我们探索实现此目的的两种技术。
第一种技术是用有关消息内容内可用的有趣数据的信息来注释API定义。 这使数据收集层能够自动提取此类信息并将其发送到分析系统。 大多数消息使用XML或XPath，提取信息的指令可以作为XPath或JSON XPath表达式提供。
第二种技术是用有关数据集的详细信息注释API定义，这些数据集可以与收集的数据结合起来以进行进一步处理。 例如，数据集可能会提供可以与客户名称或其他信息（例如API所属的业务部门以及服务请求的平均费用）相结合的客户人口统计数据。
如前所述，所有数据都是通过一个逻辑层收集的，因此数据的格式是已知的。 因此，一支技术熟练的数据科学家团队可以构建涵盖大多数常见用例的复杂分析。 例如：
- 持续详细分析不同业务部门，API，业务活动，不同客户群和地区的收入和成本贡献。
- 基于趋势和历史数据的趋势分析以及对进出资金流的预测。
- 客户旅程分析，探讨销售渠道如何转化为客户以及哪些活动更有可能促成转化。
- 基于总体活动以及个别客户偏离正常行为时的欺诈检测
实施这样的解决方案将使公司能够集中他们的资源，将他们的时间和知识投入到提供最佳产品和体验上，而不必重新发现分析并从头开始进行分析。 交钥匙分析不会涵盖所有用例，但从一开始就可以增加公认的价值。 开箱即用地覆盖关键用例，然后团队可以在收集的数据之上构建自己的分析应用程序，以处理边际用例。 最后，API本身可以在交钥匙解决方案的支持下触发动作。
此处描述的建议解决方案可以建立在现有分析解决方案之上，例如MapReduce系统，机器学习框架和流处理器。 该解决方案无需替代这些技术，而是可以与它们一起定义数据格式，提供统包式数据收集机制并提供从一开始就可以使用的统包式分析应用程序。
API驱动分析的挑战
本文介绍的交钥匙API驱动的分析方法并非没有挑战。
第一个挑战是在API定义中添加注释，这些注释描述了如何作为API开发经验的一部分从消息中提取有趣的信息。 重要的是使此步骤尽可能地轻松。 要实现此目的，可能包括提供工具来探索消息，选择要提取的特定区域，甚至建议要提取的重要数据点。
第二个挑战是在API网关内有效地实施数据提取和数据收集步骤，这些步骤将充当客户和服务实现之间的代理。 由于它们是所有API调用的关键路径，因此次佳的实现可能会严重影响性能。
第三个挑战是识别和实施可以基于从API调用收集的数据的通用分析解决方案。 这包括找出最佳算法以及代表数据和最佳用户体验的最佳方法。 这是一个难题。 但是，与维持每个组织或业务部门自己的分析能力的现状相比，该提议的方法可以为分析场景开发可重用的解决方案。
API充当门户，显示组织的工作方式，提供有关企业运营，交互和业务部门详细信息的信息以及其他见解。 这为使用API管理工具来收集数据而不是对整个企业进行检测提供了机会。
From: https://www.infoworld.com/article/3282425/it-s-time-we-tapped-apis-for-business-analytics.html