You can use MDriven to keep enterprise business rules, application use cases, and system dependencies connected in one model; this example is for architects and delivery teams planning a complex business application.
Reported enterprise implementation: investment-services bank
An anonymous bank in Frankfurt reports using MDriven for a system that acts as an interface between investment management companies, service providers, and investors. The bank manages approximately EUR 130 billion in funds and reports that it is expanding the business by approximately EUR 50 billion.
| Reported model and application measure | Reported value |
|---|---|
| Modeled classes | 677 |
| Classes with MDriven persistence | About 50% of the model |
| Versioned classes | About 25% of the model |
| Application code | About 850,000 lines of code |
The reported implementation shows how a model can remain the organizing structure for a large application. The reported organization uses modeled classes for business concepts, persistence for the portion of the model that must be stored, and versioning for a defined portion of the model. The customer states that the application would likely have been larger with different techniques.
Implementation pattern: trace a change before you make it
Use enterprise architecture information to document how a business change reaches the technical solution. Start with the business process and trace it through the information, applications, and infrastructure that the process depends on.
- Define the process and its steps. For example, define a loan-approval process with a step named Assess application.
- Define the actors and their motivation. For example, a loan officer performs Assess application to decide whether an application can proceed.
- Define the information used by the step as catalog terms, then connect those terms to the modeled classes that implement them. A catalog term is the business name for information; it can match a class name or provide a lexicon when business and IT use different names.
- Connect the step to the application or application part that supports it. ViewModels can encapsulate use cases for data manipulation or UI presentation.
- Define the infrastructure nodes that the application depends on. You can then trace a planned infrastructure change back through applications and process steps to identify affected actors and stakeholders.
- Model rules for information changes with state diagrams and use OCL (Object Constraint Language) expressions for methods and attribute or association derivation.
For example, before replacing a router on floor 5, trace the infrastructure node to the application parts that depend on it. Then trace those application parts to the process steps that use them and the actors affected by those steps. This turns an infrastructure question into a documented business-impact check.
How to interpret delivery and cost claims
The Enterprise site states that MDriven can reduce manual coding by 80%, reduce labor costs by 50% or more, and shorten enterprise-system delivery from 12 or more months to 3–6 months. Treat these as product-stated planning claims, not as outcomes demonstrated by the bank example above. Validate them against the scope, integration work, data migration, security requirements, and change governance of your own implementation.
The bank example provides reported scale figures, but it does not report delivery duration, labor cost, or savings. Do not calculate ROI from the model size or code-line count alone.