Use this page to assess dependency considerations when evaluating MDriven for a business system.
Separate the business model from the technology platform
MDriven distinguishes the business-specific pattern from the underlying technology, which it calls the "Modernity." It states that the value lies in the business pattern rather than in the technology platform alone. MDriven also states that its visual programming techniques, patterns, and framework allow the business core to be independent of particular programming languages and development tools.
When assessing dependency, identify which parts of the solution express business-specific knowledge and how your organization will understand and maintain that model over time.
Maintain ownership and understanding of the model
MDriven states that visual models enable domain experts to contribute directly and that built-in documentation can replace knowledge held only by individual developers. It also presents its approach as a way to retain business logic when staff changes.
Consider the following practices:
- Treat the UML model and its documentation as business assets.
- Include domain experts in defining and reviewing the model.
- Review the model when business processes change.
- Avoid concentrating understanding of the model in a single developer or team.
These practices help an incoming team review the documented business logic rather than relying solely on individual recollections of how the system works.
Define integration boundaries
MDriven states that it can work alongside existing legacy systems and that its architecture has features for integration with C and APIs. It also describes reverse-engineering capabilities as a way to expedite migration when an organization is ready to move further to MDriven.
Document which systems remain in place, which system owns each business responsibility, and the interfaces required between systems. This makes the scope of any dependency on MDriven explicit rather than assuming that modernization requires an immediate replacement of legacy systems.
Review model-defined access behavior
The AccessGroups and ViewModel-Enable documentation describes behavior intended to distinguish transient actions from actions that change persistent data. For OCL expressions, MDriven states that it checks whether the resulting element is part of the model and persistent; when it is persistent, the expression is locked if View-Enable evaluates to false.
When evaluating a solution, review the model expressions and access behavior that govern actions affecting persistent data. Verify that the resulting behavior matches the organization's requirements.
Questions to resolve before adoption
| Area | Question |
|---|---|
| Business model | Which business-specific knowledge is represented in the UML model, and who is responsible for maintaining it? |
| Documentation | Can domain experts and incoming developers understand the model and its documentation? |
| Technology platform | Which parts of the solution depend on MDriven technologies, and which parts express the organization's business-specific knowledge? |
| Integration | Which legacy systems remain in place, and what C or API boundaries are required? |
| Access behavior | Which OCL expressions and other model expressions can affect persistent data, and how will their access behavior be reviewed and tested? |