You can shorten the path from a business idea to a deployed application by defining the application in a model and using MDriven to generate and execute the supporting application parts.
How MDriven affects time-to-market
Time-to-market is the time from defining an application need to making a working solution available. MDriven reduces work in this path by keeping data, business logic, and user-interface definitions in one model-driven environment.
In MDriven, you create a model for the application's data, business logic, and user interface. MDriven's features and benefits describe the capabilities available from that model. This reduces the amount of manual work needed between an agreed business requirement and a deployable application.
| Delivery activity | How the model-driven approach helps | Concrete example |
|---|---|---|
| Define the application | Model the data, business rules, and user interface together. | Model a Customer with its information and the rules that govern it, rather than maintaining separate descriptions for data, rules, and screens. |
| Create a first working version | Execute the model and use generated forms to get early feedback. | Use an AutoForm based on the Customer data structure to review how users enter and view customer information before expanding the application. |
| Apply a change | Change the model instead of coordinating separate manual changes across database, UI, and logic. | When a new customer field is needed, add it to the model and update the affected ViewModel. |
| Deploy and evolve | Use the same model for deployment as the model evolves. | Deliver the reviewed Customer workflow, then extend it with another modeled business rule without rewriting the application's core model. |
Work with feedback early
A ViewModel defines how a use case is presented and behaves. Use a ViewModel to make a business use case reviewable early in delivery.
For example, create a ViewModel for a customer-registration use case. Let stakeholders review the customer information and workflow in the running application. Record the required changes in the model, then run the revised model for the next review. This feedback cycle helps expose misunderstandings before they become rework in separately implemented database, UI, and business-logic layers.
Keep change work focused
MDriven separates the system's business gist from the technology used to deliver it. The business gist is the enduring description of the problem domain; modernity is the delivery technology and user-interface concerns that can change over time. Keeping these concerns separate lets you evolve business requirements without treating every delivery change as a rewrite of the system's core description.
For example, a business can revise a workflow rule in its model as its process changes. The model remains the structured description of that workflow while the delivery mechanism continues to execute it.
Use MDriven for common delivery scenarios
| Scenario | Time-to-market focus | Example |
|---|---|---|
| New business application | Model the application before building separate database, backend, and UI implementations. | Define a new internal workflow in the model, run it for feedback, and deploy the reviewed application. |
| MVP | Build the core logic once and evolve the database and backend as the business rules change. | Start with the core entities and rules for a SaaS idea, then update those rules as feedback identifies the next requirement. |
What determines the actual timeline
MDriven automates parts of application development, but it does not remove the need to understand the business problem, agree on requirements, review the model, integrate with existing systems, or prepare the organization to use the delivered solution. The delivered timeline depends on the scope of the application and those activities.