MDA Skeptic - Part 5: Maintenance cycle

Here is one of the trickiest areas, but I’d better clarify mi point of view first. I work for a consulting company: we normally deal with enterprise software, sometimes we craft it, sometimes we test it, sometimes we coach/mentor an internal development team, sometimes we just audit the development process. In all of these situations the final owner of the produced code is the customer, there is an obvious maintenance tail at the end of the project, but our team is intended to be a “task force”, meaning that it’s not there to stay.
This raises a couple of possible problems, involving methodology and tools.
In a “pure” software company, MDA is much more a permanent asset, so some of these drawbacks will have a minor effect.

Methodology legacy
Adopting MDA is a big mindset shift for a development team, all of the usual operation for all the roles involved are different. You can be radical and forget about all the MDA stuff done by an external team: at the end PIM produces PSM which produces code. You just move the focus back to code. It’s like moving back from industry to artisanship, but if you’re just “decorating” the legacy MDA-engineered application, it can just make sense (but you’ll pay more if you want to move back to MDA, for example to apply some new functionality). In this case, the model and the architecture are just assets of the development task force, which can deliver proven yet custom applications in a shorter time.

Finding the hot spot
If you decide instead to adopt the full MDA round-trip also fro the maintenance phase, you’ll have to be aware that the whole maintenance methodology gets scrambled. For any reported bug, the problem determination cycle must determine whether the error resides in the PIM, PSM, (custom) transformation, or protected area. Each solution leads to a different way to resolve the bug maintaining the overall system integrity. You’re probably going to pay part of the savings in the early stages of the project, in the maintenance phase, ‘cause you need more skilled developers to get the job done properly. On the other hand you’ll probably have less bugs, in this project, or in the following if you correctly adjust the models and the mappings.

Tools Legacy
Regardless of the chosen approach (partial or full roundtrip), one of the greatest boost to development speed is given by the toolset used. Unfortunately, there’s still a big distance from the claimed official academic MDA approach and the real world offer of MDA tools on the market. Despite the OMG efforts for interoperability, looks like most of the tools have still chosen a “proprietary approach”, somehow forcing the development process to be tailored around the specific tool (which sounds a bit ironic, cause MDA aimed to achieve platform independence). Moreover, most MDA tools look pretty expensive, the vendor lock-in might so be enforced by your boss: “You asked all of this money for this tool? Now you’re going to use it till the end of your days to have it repaid!” (Lightning & thunder).

Diamonds are forever
I haven’t really found any information about somebody who switched from one MDA tool to another one, still inside an MDA process. I suppose it might be interesting to know. I haven’t seen such mobility also in UML tools probably due to price reasons as well, so we might expect a similar scenario in the MDA playground as well, with few big competitors, defining de-facto standards, as long as open source doesn’t show up as a real full-featured viable option.

Tags: MDA, Model Driven Architecture