APIs, integration and the ecosystem

This article is part of a series and follows on and is a deeper dive on the challenges of “Realizing AI ROI”, which identified these areas of focus:

• The trade offs between AI experimentation, investment and returns;
• Balancing internal versus outside expertise
• Breaking down subject matter and technical matter expert (TME and SME) boundaries;
• Taking an ecosystems approach to AI;
• Data (hard to avoid);

While this is the first deep dive on the above challenges, I am actually starting with the idea of taking an ecosystems approach to AI. This topic sets up many of the others and maps on well to tangible examples. Also, while the initial article just touched on the importance of an ecosystems and API first model this article will consider this model in the context of a micro-services & end to end MLOps approach, to provide a broader context and value proposition of AI as APIs. The key concepts I’ll cover will be:

• How fungibility and accessibility of AI impact ROI;
• What role an API & micro-services model plays in leverage i.e. enterprise usage;
• How this approach compliments with CI / CD frameworks;
• The role micro-services and CI/CD play in MLOps and faster more nimble product delivery;
• How this approach provides greater transparency on value and cost trade offs of any given AI project

So let’s set up the use case for this article against which we’ll play off the above concepts. We’re going to use the increasingly common business issue of anti-money laundering (AML) and risk management, at least in the FS industry. The client problem here, which is rather standard and well defined cross the FS industry, is how to assess the potential risk of a given client engaging in money laundering, based on a range of behavioral and account related factors. The model itself is not overly important but rather how it was implemented. Here we have a core prediction engine, trained on a data set, that integrates with various underlying data sources e.g. broader customer data, and an on-boarding workflow, as well as a periodic reporting requirement. The engine itself was contained within the application code base and generated daily batch driven result sets. The model itself was years in the making, the product of internal policy changes, regulatory and internal stakeholder engagement and agreement and ultimately model development, tuning and integration i.e. an incredibly long, expensive process.

This client rating drives a range of downstream processes at the time of on-boarding and sets up a series of periodic processes, dictated by the severity of the rating. The rating itself though, is not only relevant to on-boarding and the resultant periodic processes. The rating itself has value and relevance to broader aspects of AML such country risk assessment, transaction risk and other AML domains. Additionally, the model may change over time, which can trigger a range of data requirements requiring “uplift” i.e. additional data sourcing etc, which the client needs to understand from a scale and planning perspective. And of course there are periodic monitoring requirements that need to be met.

So in summary we have an integrated solution and model code base, leveraged on a batch basis. Potential changes to the model or solution and their related impacts are run and assessed in a development as well as larger test environment.

Straight out of the gate, we can see the model fungibility and accessibility is very limited and the realizable ROI is defined and constrained from the outset. In fact, no other process has access to the production model and any access will require starting up a development or test environment, which has a range of support considerations, volume constraints etc. A far more accessible approach and set up, that would add almost no additional complexity, would be to wrap the core prediction engine within a RESTful API framework, with a well defined set of services available. This can be accompanied by a range of access protocols, as well as sit on a scalable and isolated infrastructure i.e. containerized, to help manage security, scalability & reproducibility issues. One of the considerations here for the client was how changes in model weights and certain binary rules around rating, may change the client portfolio ratings mix. Such changes could be enabled with well defined API calls, for certain user types, enabling more rapid iteration and impact assessments.

More importantly, these other processes could experiment, iterate and slowly integrate the engine into their processes, all without coordination with the central development team, thus enhancing the value of the AI engine with minimal additional cost. This is leverage. Extracting more value at little to no cost. Leverage also works across other dimensions — speed of iteration; reduced time and resource spend on low value support; development teams focused on the next solution or enhancement; increased moral, team engagement etc.

All of these impacts are the product of what is more broadly defined as a micro-services approach to solution delivery. Rather than creating a single application under one code base, an application is an aggregation of multiple separate services, all with their own points of integration. A micro-services approach additionally fits well with a continuous integration and delivery (CI/CD) model. The CI/CD system or model, moves teams and enterprises away from large, infrequent releases towards many, smaller releases with more contained impacts. CI/CD automates testing and to the greatest extent possible, the release process, by isolating services into core, well defined modules, packaging each with related regression and other testing scripts that run any time a service is pushed into the code repository, providing immediate issue generation and feedback.

CI/CD and more broadly Dev Ops is a general delivery framework for more rapid iteration and release however this approach has laid the ground work for a AI specific variant called Machine Learning Operations or MLOps. MLOps covers the entire end to end AI delivery lifecycle however for my liking, I think of it as really encompassing the lifecycle post model development which includes the model packaging and API creation, the CI/CD code and scripting, versioning and containerization and then release, monitoring and maintenance. So…a lot. However, to a large extent, the components within this framework are reproducible and scalable, and as teams get up the curve on MLOPs, ultimately positioned to extract far more value from AI delivery.

See a summary view of the pipeline below.

In terms of the API solution in the context of full stack AI delivery, we can see in my summary full stack view at the top of this article, this is really just a piece of a wider full stack approach and strategy.

For this use case, we’re a long way from this API, CI/CD and MLOps approach and as a result a long way from extracting the full value from this AI initiative. There are industry and regulatory constraints at play here that would slow down a pure MLOps CI/CD approach however to the extent you function within a highly regulated industry, and particularly in the FS industry, regulators are increasingly as interested in rapid response and iteration as businesses are and evolving in their methods to support these frameworks.

Finally, an API model, especially when part of a MLOps, CI/CD approach, help strip away the noise from AI releases and provide more precise insight into AI use cases and their related true ROI. Without the added baggage of the entire application, the actual estimated benefit and cost can be more readily and easily quantified, including the potential for leverage (discounted in whatever way makes most sense eg likelihood) to assess the ultimate value. With firms earlier in the MLOps evolution, the value of the skills being learnt will be higher in the ROI estimation (see forthcoming AI returns article), while more mature firms will weight the pure AI value higher.

Overall, as detailed in my prior article, a well articulated AI strategy that looks at infrastructure strategy, skill set acquisition and growth as well as the business benefits, all supported by a API ecosystem approach, will put a firm in a solid position to make informed decisions about where to place their AI bets and assess their success over time.

I hope this was interesting. Thank you for reading. If you liked this article, be sure to click [clap] below and if you have any questions, feel free to leave a comment and I will try my best to answer. And feel free to follow me.