These Anti-Patterns are Slowing AI Adoption in Enterprises in 2020

Claims about the promise of artificial intelligence (AI) to deliver real-life business benefits are abundant. By performing functions that enable hyper-personalisation of the customer experience, or optimisation of assets utilisation by harnessing sensor data, AI can augment business processes and capabilities exponentially. Yet adoption of AI at enterprise level has been slow, with many organisations across different industries facing foundational barriers in generating  value from AI at scale.

In a McKinsey global survey on the adoption of AI1, only one-fifth of respondents report embedding AI into multiple business units and functions successfully.  At BasisAI, we have seen many enterprises find it difficult to go beyond the experimental or pilot stage. One critical challenge is the presence of anti-patterns in enterprise AI strategy, which ultimately slow adoption and harm the path to scalability.


What is an anti-pattern and what effect does it have on enterprise AI strategy?

Anti-patterns are the opposite of design patterns which serve as common, effective and reusable solutions to a problem. In software development, design patterns help to design object-oriented software, but patterns that are considered bad software development practices are referred to as anti-patterns. In a business context, this translates to a pattern of behaviours or processes which might produce quick results in the short term but have a fundamentally negative effect on an organisation's ability to generate material impact and scale in the longer term.

According to the authors of Design Patterns2, there must be at least two key elements present to formally distinguish an actual anti-pattern from a simple bad habit, bad practice, or bad idea: 

  1. A commonly used process, structure, or pattern of action that despite initially appearing to be an appropriate and effective response to a problem, has more bad consequences than good ones.
  2. Another solution exists that is documented, repeatable, and proven to be effective.

To eliminate anti-patterns, we need to recognise them. We share four primary anti-patterns that slow the embedding of AI solutions into the organisational core:


AI Superheroes

An AI Superhero is a member of the team who understands every aspect of the development and deployment of an AI system. This person has a broad range of skills, from machine learning research, software engineering, development operations, to project management. For specialised application domains, the AI Superhero may even have expertise in a specific field, such as finance or biotechnology. 

Remarkably, this person can translate a business problem into a machine learning problem, and write the necessary code to scale the solution, making them a hugely valuable team member at the early stages of AI development.

But over-reliance on the AI Superhero can cause problems. Being highly sought after, he or she may leave the enterprise before internal capability is built. Or the business could scale up too quickly for the rest of the team to keep up. A simple solution to this problem is to hire additional employees, one for each of the AI Superhero’s skills. However, this is a time consuming and expensive process. 


Using a 'Black Box'

Black Box AI is an artificial intelligence system whose inputs and processes are not visible to the user, as opposed to a bespoke solution that allows for explainable AI. Black Box AI is often a proprietary engine that is pre-trained, or one that makes use of an Application Program Interface (API) through business cloud services such as Amazon Web Services (AWS), Google Cloud Platform (GCP), and Microsoft Azure. These solutions can be useful for generic cases, such as image classification or machine translation, where training data is vast and easy to acquire. 

But the problem with Black Box AI occurs when the business context for your company differs greatly from the generic black box models that have been pre-trained. For example, if you need to process language that has local dialects or involves technical discussions, then natural language processing (NLP) models trained on general language, typically obtained from open information on the internet, is unlikely to work well. 


Throwing Models Over the Wall

This anti-pattern develops when the segregation of employee skill-sets is too strong - the opposite of the AI superhero anti-pattern. 

Here is a common scenario. 

A machine learning researcher or data scientist builds a complex, functioning machine learning model. This is handed off to a machine learning engineer who refactors the code without fully understanding the mathematical intricacies. A DevOps engineer then containerises and deploys the application. 

The model is now running at scale, but not as well as expected. The team comes together to solve the problem. But the machine learning researcher struggles to understand the refactored and containerised version of the original code. Debugging the model becomes very difficult. The model may be running slowly because it does not have access to sufficient computing power. Furthermore, issues with the model may not be immediately apparent to the DevOps engineer. Any issues that are flagged then need to be fed back to the machine learning researcher and there is often no clear process for how to monitor and feedback on model performance, an aspect of the machine learning development cycle which is critical to generating well-performing AI engines with the greatest predictive power.

The problem can be exacerbated when the development team does not use version control or document their code well. This makes it hard to interpret the code when a key member leaves the team, or when there is a bug, or a significant drop in model performance. Throwing models over the wall to DevOps teams is therefore often a primary reason why enterprises find it so hard to get machine learning applications into production.


Quick Wins

The promise of quick wins in AI adoption needs to be tested against the path to scalability. In the interest of time, AI solutions are often developed by a data scientist. The AI solution may work well on the data scientist's laptop, but it is unlikely to work at enterprise-level. When machine learning occurs in a vacuum, it can slow down the incorporation of the AI solution, ultimately limiting its business impact. 

What this might look like is a data scientist building an end-to-end pipeline in a Jupyter Notebook. The notebook can perform data acquisition, preprocessing, model training and validation on a small subset of data. It uses non-scalable data frameworks such as R dataframes or Pandas. While this notebook may produce desirable results, its technical debt is very high because it is not compartmentalised and needs to be run in a specific sequential order. This often requires extensive refactoring to make it more robust to changes in the data structure.  This approach may be good for prototyping, but the lack of scalability requires a significant time investment before deployment. 


How to avoid anti-patterns in scaling enterprise AI

To help circumvent these issues, we suggest four strategies:

  1. Use the right mix of talent with the right technology platform strategy. Hire a team of good data scientists for feature engineering and algorithm development. And harness the right machine learning platforms to complement your team through automation and auditability.
  2. Match your problem and data to the right AI solution. This can make or break the success of your project. Get advice from experienced AI practitioners on using black box solutions. Find out their views on whether these pre-trained models can be trusted, the benefits, risks and limits of such solutions. Black boxes may only address one component of the problem. Don’t neglect other parts of the problem that need to be addressed.
  3. Start small, but be sure to have a path to scalability. Don’t “lock in” to non-scalable, monolithic solutions that don’t integrate well. Consider a microservices architecture so that each machine learning application is exposed as an API endpoint with a clear contract that can be re-used by different applications in your stack.
  4. Continuous evaluation and retraining. Machine learning models rot and degrade because the real world and data change so quickly. Make sure your teams have the means to review, update and retrain your models. Having fresh simple models often beats using the latest deep learning architecture. 

Incorporation of AI solutions into enterprise platforms is critical for businesses to stay competitive. Have a healthy dose of humility, and swiftly address patterns that are counter-productive to your path to making AI scalable, responsible and explainable in your enterprise.




2 Design Patterns: Elements of Reusable Object-Oriented Software. Erich GammaRichard HelmRalph JohnsonJohn Vlissides. Pearson Education31 Oct 1994.