Raise your level of abstraction
To gain momentum, it obviously seems to be necessary to craft solutions with a clear and understandable business benefit. Such solutions should meet the following requirements (to be completed and discussed):
I. Business Benefits
1. understandable and business-editable models which are in sync with IT provide a great direct value (control, flexibility, consistency etc.)
2. ready-to-use-models increase the potential market segment by a magnitude (individual development from scratch is rather the excepion than the rule)
3. complete solutions: this is a must, since incomplete solutions require extensive IT involvement, i.e. they're just not business solutions
4. completeness in certain scenarios (specifically: large enerprise context) implies integration with BPM
5. "business/IT scalability" - there will be times, when "business" cannot specify everything, because the skills to precisely define e.g. formulas are not given or the will to do so; in this case it must be possible to pass on the baton to IT; nevertheless, this must not exclude business from future modifications
1. translation and overall picture: MDx has many technical advantages, these are advantages, too, but indirect ones. We need to translate them, and sum up benefits and trade offs (that's basically marketing)
2. coining terms: a better name then "ABALCPMS"; personally I like the direction of "Agile Modelling", "Model Driven Enterprise", "Model Operation"", "Application (...) Management", but maybe each of us has to decide upon that ourselves :)
III. Application Completeness
1. business layer: classes, true BL logic
2. database layer: including schema, complex queries, transacion boundaries
3. user interface: all operations, transactions, flows, workflow, UI logic, including normal "content", ergonomics, multiple frontends
4. integration: service APIs, legacy adapters
5. evolvability: this requires, that the complete application is at each point in time reproducable from the model (plus optional manual additions) without any further manual intervention; furtheron, reused standard models must never be modified within a project
6. not to forget: automated documentation of models, integrated tests etc.
1. development process, agility: the process, however implemented, should lead to results within a rather short time frame; additionally, no redundancy should be produced (like "business model" translated manually to "technical model")
2. development process, automation: ideally, the process is "one-click", only then true agility is doable
3. complete process: automated testing, integration, packaging, deployment
V. Risk Management
This might be one of the most crucial aspects. Looking at this requirements list, it's obvious that an ABALCPMS is based upon several innovations. If we apply only one of them (like using a generator), we're far from a complete solution. If we apply all of them, that scares customers as well as the majority of developers. Maybe this is the real reason why MDx does not take off as we wish: we need to take several steps simultaneously, we need to leap over the "gap of complexity", and noone alone is able to this, neither the small ones, nor the big (or interest is low, since it affects selling of manmonth in a rather nonlinear fashion).
- emergency brake: the customer should be able to continue to work with the generated application and stop using MDx (this requires well crafted and non-dirty generated code)
- far better: open, (quasi) standardized models: the customer can exchange the MDx technology supplier as he wishes or even use models as precise specification to hand over to manual team
This is just absolutely great!
100% agree. That's THE target, IMHO
Good point: need integration to BPM. Could be a BPM solution integrated in the whole modeling platform, or: integration with existing BPM solutions of the market (if you target a user already using a BPM solution you MUST provide him with an integration point between his BPM and your model-driven platform)
And mode generally: the business modeling platform should include the facility to integrate to any external data sources in a consolidated way. Be it enterprise directories, databases, files, custom apps, web services etc. etc. Because in the enterprise today, there's nothing such as an autonomous application: applications have to integrate fully to the entreprise IT and existing applications/data.
So yes we can build business platforms for modeling/generating (generating rather than interpreting because of objective of not putting any vendor-locking to the customer: we generate standard code) and executing enterprise apps. Let's sell it as is. And that's our job to internally find the best possible MDx technologies and practices to make that possible.
I'll certainly come back with more thoughts..