UX & Model Driven Development
The implications for your UX development process within an MDD context
Model-driven development (MDD), sometimes referred to as model-driven engineering (MDE), is a software development methodology that focuses on leveraging a domain model, which is a conceptual model of all topics related to a specific problem.
Like any software methodology, there are trade-offs where value may or may not be provided within a specific context. No modern development methodology is entirely perfect, nor entirely without value, but a thorough understanding of the implications of a software development methodology should understood before adopting it and tools tailored to support it.
With regards to MDD/MDE, there are several areas where your UX team and development process may be impacted:
- Project Roles
- Architectures
- Requirements
- Tools
- Development Workflow
Project Roles
In other design/development methodologies there is a division of labor between UX designers, front-end coders, back-end coders, business analysts, and database developers. Each tier of an application has its own specialized role and specific silo. This specialization is required since each specific silo is potentially deep and it is difficult to find someone who is an expert in terms of business requirement development and front-end development, or back-end development and design.
MDD takes a meta-programming approach to the design and development process and, rather than requiring specific design and development roles within specific silos, the MDD developer has a much broader set of responsibilities and is often referred to as a business engineer, rather than a specific kind of developer. Business engineers, and other MDD roles, need high levels of domain knowledge, and must be able to convert use cases and requirements from a data model all the way through to UI implementation in order to leverage the value of MDD and the tools that support the methodology.
Before implementing MDD, you may need to re-think how your team is constructed in order to realize the value MDD offers.
Architecture
The business engineers who develop applications use MDD tools that operate at much higher levels of abstraction. Typically, code is generated by a tool due to some sort of interpretation of a model utilizing various pre-defined patterns and libraries. This has some definite cost benefits, such as fewer possibilities for the introduction of bugs, and a more consistent code base, but this comes at the expense of just how much control over the code a developer will have. Your developers will most likely be writing meta-code, and will not be spend much time, or will have limited ability, to affect every aspect of the delivered code.
With MDD you can produce more code in shorter periods of time but you will have far less control over the architecture and the code you develop.
Requirements
There can be a large gap between what UX designers produce and what can actually be produced using MDD tools. Business analysts who drive requirements, the designers who produce UX solutions, and the developers who implement the model based upon business needs must be in complete alignment with regards to what is actually possible within the confines of MDD. Much of this understanding will come from being an expert in the particular tool being used as that will have an large impact on what is implemented and how.
MDD can assist you with combatting design process entropy, but it will require all members of the team to understand the constraints of the methodology and their chosen tools.
Tools
The methodology you use should drive the tools you utilize, not the converse. Often business stakeholders will be sold a suite of tools, or will be convinced a particular feature is worth having in a suite, and don’t necessarily understand that in order to realize the full value of the tool, they must adopt an MDD methodology. Or, if the acquire the tool and do not plan on adopting MDD, they will spend a lot of time fighting against the intentions and tendencies of the methodology the tool is intended to support.
Understanding the trade-offs associated with MDD will help you understand whether or not a suite of tools intended for an MDD environment is required or desirable.
Development Workflow
When you adopt an MDD methodology, and tools which constrain your flexibility, there is a trade-off employed where you will keep your team much more focused and meeting business needs, rather than focusing on technology, and you will do so by possibly reducing innovation on your team. This may be a double-edge sword. If you spend time on acquiring and leveraging problem domain expertise, the distractions offered by experimentation and iterative approaches to process improvements will be minimized. Depending upon the team you assembled, this may be viewed as either a cost or a benefit. Trying to shoe-horn traditional developers into MDD may prove challenging. On the other hand, if you have business analysts with specialized domain knowledge, and they have the desire and aptitude to learn the specifics of how to use a suite of tools developed for an MDD environment, a great deal of value may be realized.
Realize that MDD may minimize opportunities for tool and process improvement which may, depending upon the particular skills your team possesses, be either a net positive or negative.
Conclusion
Model-driven development, like any development methodology, contains various trade-offs and may be perfectly suited for some environments, but not others. When evaluating tools, be sure your tools do not dictate your methodology. Your methodology, your personnel, and your approach to solving business problems should guide you in your decisions making process surrounding your tools. Be aware of the trade-offs you are choosing and how they will impact your team before committing to a course in order to deliver the value you desire.
