You can assess and reduce dependency on MDriven when planning a business application, and this page is for architects and delivery teams who need to retain control of their system knowledge, data, and integration choices.
Identify the dependency
Vendor lock-in is the cost or difficulty of changing a platform, tool, or supplier after a system depends on it. For an MDriven application, assess dependency separately for the business model, user interface definition, generated or executed application behaviour, data, and integrations.
MDriven keeps the business description in a model. MDriven Designer uses UML and OCL. UML is a standard for describing a system model; OCL is the declarative language used to express constraints and transformations. A ViewModel defines a perspective on model information for a particular use case and can also contain user-interface hints.
For example, a customer-service ViewModel may define which customer information an agent can see and which actions the agent can perform. Record that use case, its rules, and its integration contracts with the model rather than leaving the knowledge only in individual developers' work.
Assess the risks before committing
| Area | Question to answer | Mitigation using MDriven practices |
|---|---|---|
| Business rules and system knowledge | Can another team understand the business structure and rules? | Keep the model as the maintained system description. Use UML for the model and OCL for declarative rules. Review the model with domain experts so that business knowledge is not held only by individual developers. |
| User-interface behaviour | Are important use cases defined only by one implementation? | Document each ViewModel's purpose, information slice, actions, and access expectations. For example, document that the Customer service ViewModel shows assigned customers and provides an action to update an address. |
| Data | Can the team understand and work with the stored information independently of a screen? | Maintain the model-to-data understanding as part of delivery documentation. MDriven uses relational databases for information storage, and the model-driven approach describes the information structure. |
| Integrations | Can surrounding systems continue to exchange information if the application changes? | Define integration boundaries and contracts explicitly. MDriven is described as working alongside legacy systems and supporting integration with C and APIs; keep the responsibility, data exchanged, and failure handling documented for every integration. |
| Technology change | Can the business definition be carried forward when implementation technology changes? | Keep the business core expressed in the model and separate business concerns from technology concerns. Treat the model as the primary artifact to preserve when evaluating a different implementation approach. |
Work in a way that preserves options
- Make the MDriven model the reviewed description of the application. Include classes, associations, business rules, ViewModels, and access rules in normal change review.
- Keep a readable inventory of integrations. For each integration, record the external system, purpose, data exchanged, authentication responsibility, and owner. For example: ERP customer lookup: retrieve customer identifier and status for the Customer service ViewModel.
- Validate the data model with database-aware staff. The delivery team should be able to relate important business concepts in the model to their stored information.
- Avoid placing business knowledge only in informal handovers. Use the model and its documentation to reduce knowledge silos when people change roles.
- Reassess portability when requirements change. A new ViewModel, integration, or security rule can introduce a new dependency, so review it with the same questions in the table.
Keep security rules inspectable
Access-control decisions are part of the system knowledge that you need to retain. In MDriven Turnkey, a ViewModel defines the slice of data shown for an authorized use case, and the reduction from the complete model happens on the server using declarative OCL. Information security describes this server-side approach.
For example, when a ViewModel is intended for a support agent, document both the information slice and the authorization rule that permits the agent to use it. This makes the intended exposure available for review instead of burying it in client-side behaviour.
AccessGroups, InterestGroups and ViewModel-Enable also describes static analysis of whether expressions affect persistent data. Include such rules in access-control reviews, particularly when a ViewModel action can change stored information.
Questions to resolve with MDriven
Before treating a portability plan as complete, obtain confirmed answers for these areas:
- Supported procedures and formats for exporting an MDriven model, including UML, OCL, and ViewModel definitions.
- Supported procedures for extracting or migrating application data from each supported relational database.
- What parts of a running application can be regenerated, transformed, or used outside MDriven, and what parts remain MDriven-specific.
- Licensing, support, source-code access, and operational arrangements that apply if the organization stops using MDriven.
- A practical exit exercise for one representative application, including model, data, integrations, access rules, and acceptance criteria.