You can use this guide to evaluate whether MDriven fits your business application project, whether you are assessing a new application, a legacy modernization effort, or a team that needs closer business and development collaboration.
Evaluate the project fit
MDriven is a model-driven development platform for creating business applications. You define the business domain in models, then use MDriven to generate application parts and extend the result where needed.
Use the following questions to assess your project.
| Evaluation area | What to assess | Example |
|---|---|---|
| Delivery speed | Determine how much repetitive frontend and backend work your project requires. | A team building standard business screens can assess whether generated application parts reduce the manual work required for each screen. |
| Business and development alignment | Determine whether domain experts need to review and contribute to business logic directly. | A finance specialist can review a visual model of invoices and relationships instead of relying only on a developer's explanation of code. |
| Maintainability | Determine whether critical business knowledge is concentrated in individual developers or represented in reusable models and documentation. | When a developer changes roles, the model remains available to the next team member as a description of the business domain. |
| Legacy modernization | Determine whether the new application must work alongside existing systems before a full migration is possible. | A team can keep an existing system in place while assessing integrations with C and APIs and the use of reverse engineering for modernization. |
| Scale and architecture | Determine whether the application must adapt to changing demand without adding recurring architectural work. | A business with variable demand can assess a modular, cloud-ready architecture and the handling of concerns such as security, concurrency, and fault tolerance. |
Compare development approaches
Use this comparison to frame an evaluation against a conventional approach in which business logic is primarily implemented and retained in hand-written code.
| Criterion | MDriven approach | Conventional development concern to evaluate |
|---|---|---|
| Business logic | Capture business logic visually with UML, a language-agnostic method for describing the business domain. | Determine how much of the domain is only represented in code and individual developer knowledge. |
| Application delivery | Generate frontend and backend application parts from the model. | Determine the effort required to build and maintain repetitive application infrastructure manually. |
| Collaboration | Let domain experts contribute through visual models. | Determine how requirements are communicated, reviewed, and preserved between business stakeholders and developers. |
| Documentation | Use models as transparent, reusable documentation of the business domain. | Determine whether important decisions are documented or depend on verbal knowledge within the team. |
| Integration and modernization | Work alongside legacy systems and assess integrations with C and APIs; reverse engineering can accelerate modernization. | Determine whether a replacement requires a full migration before it delivers value. |
Assess return on investment
Assess return on investment by comparing the current cost of delivery and change with the expected cost after modeling the application.
- List the work that currently consumes delivery time, such as repetitive frontend and backend implementation, rework caused by misunderstood requirements, and upgrades to difficult-to-maintain systems.
- Identify the people who must participate in each change. Include domain experts when business rules need clarification.
- Select one representative business flow for evaluation. For example, model an invoice process with its data, relationships, business rules, and user interface behavior.
- Compare the effort to implement and revise that flow with your current approach. Include the effort to explain the solution, document it, and transfer knowledge to another team member.
- Assess whether the same model can support future integration, modernization, and deployment requirements.
The value case is strongest when your project has slow or expensive development cycles, repeated rework, legacy limitations, knowledge silos, or a need for systems that can evolve as business requirements change.
Run a focused evaluation
Use a small, representative application area rather than an abstract feature list.
- Choose a business area with clear data relationships and rules, such as customers, orders, and invoices.
- Model the domain in MDriven Designer.
- Define business rules and UI behavior with OCL where applicable.
- Generate the database and application, then identify any required custom code or external-service integration.
- Review the result with both a domain expert and a developer. Confirm that the model communicates the intended business behavior and identify the remaining delivery work.
- Evaluate deployment needs, including on-premises, cloud, hybrid, or container-based deployment options described in Deployment.
Decision checklist
MDriven is a fit to investigate when you need to:
- reduce repetitive application development work;
- make business logic visible to domain experts and developers;
- preserve knowledge in models rather than in individual team members;
- modernize while working alongside legacy systems;
- extend generated applications with OCL, C, REST API integrations, or modular add-ons; or
- deploy business applications in cloud, on-premises, hybrid, or container-based environments.