Ten Key Principles of AI Platforms – Part 1/2

Today we would like to present ten basic principles of AI platforms in enterprises. But how do these requirements actually differ from the various AI requirements we presented last year?
On the one hand, these two articles refer to platforms, i.e., to the collaborative use of AI from different locations or companies. On the other hand, these principles are cross-industry and therefore not subject-specific and generally valid. C3.ai conducted the study on which this article is based.

1. Data Aggregation: Unified Federated Data Image Across the Business
To ensure comprehensive data management for the generation of reliable AIs, it is necessary to integrate different data from numerous systems and sensors, mostly in real-time. In most cases, however, different data is available in different systems and formats. Customers, suppliers, orders, prices, products, accounting, production, and planning are often separated, and a unified database is not feasible. For this, a data aggregation service must be provided on the enterprise message bus. These data exchange models for this should, in turn, be designed industry-specifically to work out the maximum synergy effects. Examples are HL7 for the healthcare sector, eTOM for telecommunications, CIM for electronics, PRODML and WITSML for oil and gas products, and SWIFT for the financial sector. An AI platform with appropriate data integration interfaces greatly simplifies introducing new systems, and interfacing and data aggregation to the overall system is straightforward.

2. Multi-Cloud Computing and Data Persistence

Since the data also has to be used off-site, currently primarily due to home offices, cloud access to the data pool is essential. Besides, the AI platform must be able to provide various services. This works with providers such as AWS and Azure, among others. Since many providers are pioneers in different areas, it is also necessary that multi-cloud operations are supported so that Google Translator can run alongside an AWS Kinesis application. Furthermore, it is also important that data persistence can operate with different databases. It must be possible to create relational, key-value, and HDFS databases to store different data formats and perform the corresponding accesses efficiently.

3. Edge Computing

Since many situations arise with poor Internet or insufficient computing power, and data or analysis must be retrieved, an AI platform is required to enable edge computing, minimizing the bottlenecks of current technologies so that AI analysis can also be performed on remote gateways and edge devices.

4. Platform Services and Data Virtualization for Accessing Data In-Place

AI applications require a comprehensive set of platform services for processing data in batches, real-time streams, and iteratively in memory across a cluster of servers to help data scientists test analytic functions and algorithms using production-scale datasets. Secure data processing is also required to ensure that data is encrypted while in motion or at rest. Enterprise AI, the enterprise AI platform’s architecture, should allow these services to be plugged in without changing the application code.

Data virtualization is another issue, especially for developers to manipulate data in wrong data cases – without causing problems. For this, appropriate database technologies must be provided: relational data stores, distributed file systems, key-value stores, graph stores, and legacy applications and systems such as SAP, OSIsoft PI, and SCADA systems.

5. Enterprise Semantic Model

Now, it’s not just data storage that’s important. It must also be possible to record the context in which data is collected and for which it is intended. This is possible with a semantic model, which maps the company with metadata and provides further information to help the AI consider additional factors and relationships in the analysis. For this purpose, data models must also be provided for the individual devices. The platform actively enables increased flexibility during runtime and thus presents the analysis in a more fine-grained manner. Finally, the platform must also be able to process changes to the models and schemas in real-time so that users are not shown incorrect analyses and can continue to work flexibly.

Next week, the remaining aspects will be published as part of the second part, and a critical conclusion will be drawn. Therefore, we look forward to welcoming you back to our site next week.