- Intro to MDSD
- Where I'm heading
I've been a heavy user of AndroMDA over the past few years and have found it to be a great time saver along with producing high quality, feature rich code. For the first time I felt like I could spend most of my time on the business logic and relatively little on the wiring. I can remember the first time that I successfully ran it against one of my models; I was so thankful that I didn't have to handcraft the WSDL file or EJBs or the persistence layer. Don't get me wrong, the learning curve wasn't a walk in the park, but it was ultimately rewarding. The hook had been set and there was no turning back. I've always had a predisposition toward code generation probably more from a productivity boosting motivation rather than one of laziness or boredom. This predisposition is sated with the current release of openArchitectureWare.
One of the main things that I really like about model driven anything is that it marries the design models and the code. I believe that it's a relatively large problem to have design documents that are not only poor images of the deployed programs but, in most cases, bearing very little resemblance to the component parts of the system at all. By adopting MD*, the software development life cycle is in tact because it has to be or the project is out of control. This is good news especially for those working in the government and regulated sectors.
So the two immediate benefits are time savings and a complete life cycle. Yet another benefit is that it reintroduces the creativity back into programming. You see, the generators are very good at creating the mundane stuff, leaving it to the programmers to create (note the use of the word create) the code that realizes the business logic. Generally, this will require two tiers or peers of programming staff, those who attend to the business things and those who attend to the architecture and the plumbing generators. So you see, this is as significant an advance as subroutines, C, 4GLs, and OOP were. So now we are at the point where the target architectures are being codified; we've moved from Assembler all the way up through components and are now focused on the services layer. Next up would be the dream of composable systems and what I like to call the percolating enterprise. Beyond that would be a sort of "universal consciousness" (go to a quiet place, sit on the floor, close your eyes, and say Ummmm) as we create a trusted layer between networked entities; a piece of which is envisioned as the semantic web.
It's my opinion that the leading edge at the moment is the work around creating secure, consistent, high performance, networked systems, i.e. just a few steps behind those bleeding edge pioneers who are working on the "Ummmm" generation of systems. There are a host of tools available in this space and, as for my investment, openArchitectureWare is a clear choice. They have very functional tools for M2M and M2T work as well as a solid platform that integrates it all. They can work with almost everything that could constitute a model from a simple text file via their Xtext DSL modeling framework to UML2 compliant models. It's all there and ready to use. One of the interesting things that the oAW team has chosen to do is to leave out cartridge development; leaving this task to third parties while they concentrate on the enabling platform. This is a very good move in my estimation. Just for reference, one of the cartridge factories that has already cropped up is the Fornax Platform. I really don't see a downside to adopting this platform other than the cartridge issue but given it's flexibility, there is no reason why AndroMDA compliant models can't be generated that could then leverage their cartridges. The sky is the limit.
The waters that I'm wading into seem to be fairly deep. But coming from the AndroMDA world, the terrain is fairly familiar and the good news is that I don't have to loose touch with where I came from; it still can play a significant part in my efforts. At the same time, I am very sure that it will be worth the risk and the effort in the crossing. Along with my experience using MDSD and creating DSLs, odds are good that I'll have a healthy diet of software architecture patterns to talk about and more than a few diagrams to boot. This blog will function as my bulletin board, diary, and forum. A good friend of mine has this maxim when it comes to organizing her world, "for everything a place, a place for everything". Though I'm still coming to grips with the implications of this, I've decided that this blog will be my place to put things about software development and architecture.
'nuf said for now, eh? :)
