MCP for enterprise architecture and ADD preparation

A retirement decision built from recorded dependencies

A bank plans to retire a payments application. Before recommending a date, the architect needs its consumers, the business capabilities it supports and the interfaces still in use. An assistant connected to the repository can retrieve those objects and assemble the impact analysis.

A nightly reporting feed missing from the model can distort the analysis. The architect compares the retrieved dependencies with production flows and has discrepancies checked. The review distinguishes recorded dependencies from assumptions about production.

MCP access in ArchiLU

The Model Context Protocol connects an assistant to tools provided by an external system. The assistant chooses a tool, sends its parameters and receives a structured result. ArchiLU provides this connection through its MCP gateway.

An assistant can read the architecture model, start an ADD from a portfolio source, create a standalone ADD and update its content. It can also compare candidate solutions and submit proposed changes to the model.

The application hosting the assistant controls its conversation and model calls. ArchiLU handles the repository operations sent to its backend. This distinction matters when configuring access and tracing where retrieved content goes.

From the request to the ADD

For the payments replacement, the architect can ask the assistant to prepare an ADD covering the current application, its dependencies and the replacement options. The assistant gathers the available context, creates the ADD and fills the relevant sections.

The architect checks whether the scope includes reconciliation, reporting and recovery. Missing throughput figures or an unconfirmed interface stay visible as open points. The team then reviews the options, records its decision and assigns the follow-up work.

Saving an ADD and changing the architecture model are separate operations. A draft can describe a proposed migration while the model still records the current application. Proposed model changes follow the authorization and governance rules for the connected identity.

Questions supported by the model

The assistant can prepare several kinds of analysis from the objects and relationships that the team maintains. Each answer should name its source objects and any missing information.

• Impact analysis lists the applications and capabilities linked to a system scheduled for retirement.
• Portfolio review compares applications assigned to the same capabilities, then checks whether their functions actually overlap.
• Technology planning identifies recorded end-of-support dates and the applications that depend on those components.
• Cost analysis uses the costs entered in the model and states the period and missing amounts.
• Project preparation links an initiative to its objectives, requirements and affected capabilities.
• Risk review follows documented dependencies between a service, its applications and its suppliers.

Access rights and processing locations

An assistant works with the authority of its connection. A shared service account and a personal connection can have different permissions. Before the pilot, test a permitted read, a denied operation and a proposed change with the intended account.

ArchiLU evaluates model changes through its backend controls. Depending on the identity, authorization and policies, a change may execute or require approval. The team must agree who can grant access and who answers for the decisions recorded in an ADD.

Repository hosting does not determine where an external assistant processes a tool result. Record the model service, processing region, retention terms and any additional storage used by the client. Check those choices against the data included in the pilot.

A pilot with a reviewable result

Choose one application and one planned change. Ask the assistant for an impact analysis and an ADD draft, then compare both with the application owner’s knowledge. Keep the missing links and corrections in the review record.

Measure the time spent preparing and checking the ADD, the factual corrections required and the unresolved dependencies. Those results show which work the assistant can take over and which parts of the repository need attention before a wider rollout.