You can use MDriven to turn your business rules, workflows, and data needs into a working application, and this page is for business stakeholders assessing delivery time, team size, cost, and change risk.
What business outcome can you expect?
MDriven is a model-driven development platform: instead of starting with large amounts of hand-written code, your team creates a shared visual description of the business and uses it to produce the application.
For example, a team building a loan-request process can describe:
- the information to capture, such as applicant, amount, and decision;
- the rule that requests above a chosen amount need approval; and
- the workflow from submitted to approved or declined.
That description is the model. It gives business and technical team members one place to review what the application must do before and while it is built.
| Business question | What MDriven changes | Example |
|---|---|---|
| How quickly can we test an idea? | MDriven can turn a model into a working application so that the team can review behavior early. | Build a loan-request screen and approval flow, then have the operations team test it before committing to a larger delivery. |
| Can business and IT review the same definition? | The model records data, rules, and workflows in a shared visual form. | A finance manager reviews the approval rule while a developer reviews how it is implemented, using the same model. |
| What happens when a rule changes? | The team updates the model rather than rewriting the system from scratch. | Change the approval threshold in the model, then review the updated application behavior. |
| Can we begin with a limited scope? | You can start with one department or one workflow and extend the same model later. | Start with finance approvals, then add HR or customer-service workflows when the first process is established. |
MDriven also states that model-driven development eliminates 80% of manual coding. Use this published figure to form questions for an evaluation; validate it against your scope, existing systems, security requirements, and team skills.
A concrete evaluation example
Use a pre-study to decide whether a workflow is feasible before funding a full project. For a loan-request process, ask the team to produce the following:
- Define the data the process needs: applicant, request amount, supporting documents, approver, and decision.
- Define the business rules: for example, requests above a defined amount require a manager approval.
- Define the workflow: submitted, under review, approved, or declined.
- Run the model as an application and ask the business users to test the process.
- Record what changed after the review: rules, fields, workflow steps, integrations, and delivery scope.
This evaluation produces evidence that stakeholders can inspect: a working flow, the shared model behind it, and a list of decisions made before a full implementation. MDriven features and benefits describes how live execution and early feedback can reduce costly rework.
Terms you may hear during an evaluation
| Term | Meaning for a business stakeholder | Example |
|---|---|---|
| MDriven Designer | The visual tool used to describe the application's data, rules, and workflows. | A business analyst uses it to describe a loan request and its approval steps. |
| UML | A standard visual notation for describing parts of a business system and how they relate. | A diagram can show that each loan request belongs to one applicant and has one or more approval decisions. |
| ViewModel | A definition of the information and actions presented for a specific user task. | An approver sees the applicant, requested amount, documents, and Approve or Decline actions. |
| OCL | A language for expressing a business rule in the model. | A rule can state that a request above a defined amount requires approval. |
| State machine | A definition of the allowed stages of an item and the moves between them. | A loan request can move from Submitted to Under review, then to Approved or Declined. |
Technical formats and implementation details, such as XMI, XPS, or standard projections, are relevant to technical integration or modeling work. They are not the primary measures for a business decision. Focus first on the process to improve, the evidence required for a go/no-go decision, expected delivery scope, and the cost of changes.
Published customer context
One published customer statement describes a financial application with 677 modeled classes, approximately 850,000 lines of code, and funds of about EUR 130 billion under management. The customer states that the application would likely have been much larger using different techniques. This illustrates the scale at which MDriven is used, but it is not a measured comparison of delivery time, cost, or rework.