Copyright © 2018 DataScience.US All Rights Reserved.
Patterns of Enterprise AI Architecture
When I started my software engineering career, I craved the structure of feeling like I was building systems The Right Way.
This might have had something to do with the state of the web and PHP in the early 2000s. I was working with artists, designers and entrepreneurs who were trying to build businesses and online communities. Fortunately a few grey beards gave me books like Fowler’s seminal Refactoring, Patterns of Enterprise Application Architecture (PoEAA) and of course The Pragmatic Programmer.
Recently I’ve been looking into pre-trained AI models and am excited about the potential they could have in shaping software architecture. There’s a parallel between a software developer applying the most applicable software pattern and the machine performing pattern detection.
Companies today are building new algorithms based on AI models: detecting fraud in financial transactions, finding cancer cells in images, or listening to a newborn’s cry to identify birth asphyxia. All of these examples take a signal or some form of input and resolve to a set of labels and a level of confidence around the domain of analysis. These approaches treat the model as a kind of API or microservices. More often than not, they are running as a separate process or in their own cluster. Could we not build software out of AI models instead?
Let’s imagine a simple MVC application that books tours for individuals and corporations. It has an administrative backend, an API for a mobile app and a mobile responsive website. A user can sign up and set a budget for tours on behalf of an organization or themselves.
A pre-trained model could replace every Regular Expression in your application. Your boring Email validator could be swapped out with a Machine Learning equivalent, predicting whether the email is valid, but also whether it’s a corporate account or a free email address. The classifier could resolve the gender of the account holder or even the country of origin. A price validator could provide a correctness value based on existing prices entered into for that same field in our application’s domain.
Injecting pre-trained models into model validation seems like it could be useful. What about routing? Could we replace the application’s routing table with an ML algorithm? We could route REST calls to an appropriate API endpoint based on what the model *thinks* you’re trying to resolve. No more time spent reading public APIs and calling specific routes. If you provide a particular JSON payload, we could pass the request to a different version of the responder. The discussion around API versioning, GraphQL and SOAP disappears.
Source Continue Reading