Enterprise AI Assistant in CSDM

This is the first diagram on the site drawn in Blueprint Modeler, my free CSDM canvas, rather than by hand. It is the Modeler's own “Enterprise AI Assistant” example, laid out for the page and exported from the same code that draws the canvas, so every element and relationship here is one the metamodel allows. The point of the example is in its name: an AI assistant is an application, and the CMDB should hold it like one.

Reading it top to bottom

Business layer. A business process, “Resolve a customer case,” depends on the assistant, and the “Customer support” capability is provided by it. Starting from process and capability is what lets a portfolio question (“what do we have for customer support?”) land on the assistant later.

Design layer. The Business Application “Support assistant” is the record a portfolio manager owns, with a TIME disposition and a cost. It uses an Information Object, “Knowledge articles,” which names the knowledge the assistant retrieves from without pretending the articles are a server. A second Business Application, “Refund agent (planned),” exists only as an intent: the capability is already pointing at it, and nothing below delivers it yet. The Modeler flags that gap as a hint, which is exactly the conversation an architecture review should have before the agent is built.

Service layer. Customers reach the assistant through a Business Service Offering, “Customer support — chat,” under the “Customer support” Business Service. That offering depends on the Application Service “Support assistant — production,” the thing that is actually up or down. The AI platform team shows up the same way any platform team does: a Technology Management Service, “AI platform,” with an offering, “Model gateway — production,” that contains both the assistant's production service and the “Hosted language model — production,” modeled as a CSDM 5 Data Service Instance because it is a managed capability you consume, not a box you run.

Functional and infrastructure layers. The production service depends on two Application CIs, an orchestrator and a vector index, and receives data from the “Model gateway API.” The orchestrator and index run on one host. The language model has no host of its own in this model, and that is the honest shape of a hosted service: the dependency is on the platform offering, and the platform owner's model is where the hardware lives.

What the shape buys you

• Impact analysis works. If “app-node-01” goes down, the chain runs up through the orchestrator and the index to the production service, the chat offering and the process that depends on it, and the on-call conversation starts with a business name rather than a hostname.
• Portfolio decisions have a record. The assistant has an owner, a disposition and a cost like any other Business Application, so “should we keep building this?” is answered in the same place as every other application.
• Platform dependencies are explicit. The model gateway is a shared offering with its own owner, so a change to the hosted model is a change to a service other people depend on, not a surprise in someone's chatbot.
• Intent is visible without being counted as delivered. The planned refund agent sits in the model with a hint against it, which is better than a slide and worse than a deployment, which is the right place for a plan to be.

Try it yourself

Open Blueprint Modeler, choose Examples › Application architecture › Enterprise AI Assistant, and look at the Hints panel. Then delete the planned agent, or give it a service, and watch the hint clear. The model file behind this figure is available to download and imports with Import… in the toolbar. Nothing here is a real system; the names are the example's.