A couple of years ago at work started a move towards MDA guided by the architecture area. Former essays delivered MVC layered applications which needed code implementation for business methods. Since we go as far as analyzing and designing and hire coding, what our code providers had to do was simpler, shorter, less error prone and cheaper. Actually a bold move. Now close to be filed under failures.
MDA approach put one or two applications on production but several issues stopped it from continuity. Many were unrelated to actual MDA but to the technologies supporting it, the biggest one was the time builds would take due to cartridges’ snapshot dependencies needed to be downloaded. Some others where related to method signatures needed to be changed and it would cause our code providers to go through an approbation process on its method-signature-change-request. You know, no design is flawless.
Solutions might have been found if time for thinking would have been given, but from the desk the request was shout: a solution is due for tomorrow. So, the momentary solution, which became definitive, was to model the analysis and to design only the M layer. The result is we deliver the analysis artifacts and a jar with entities. The design of the business model and the code is done by our code providers now.
All this long introduction is not to cry over spilled milk, but to bring some lessons out of it. Three actually.
First, you should never leave a momentary solution, because of habit and new worries, be promoted to definitive solution. This causes many times to build over sandy grounds. Sending an email to those related to the problem and/or the solution reminding of the pending issue to be addressed, before it becomes a bigger issue, helps a lot to retake it where left.
Second, initiatives need to be followed so issues can be identified early. This is a place where many (we) architects fail to help an initiative to succeed, because even when you deliver tons of docs the new-adopter needs someone’s shoulder to cry on if something doesn’t work at first try. And as adoption spreads many new cases might come up, and you need to know about the new issues early-enough so you can have a plan for actions to be taken before the solution request is demanded asap.
Third, grab a pen and a piece of paper and write down at least a synthesis of the problem, or blog it, so you won’t make the same mistakes if you reopen the case. Like code generated from models, many other processes, techniques and so have been going back and forth for many years, so it’s not odd at all if after a couple of years or a few months the initiative goes back to trending topic in your work or everywhere. And you need to make sure you won’t bump into the same rock.
There you go, three lessons out of spilled milk. Hope someone find them useful.