Infosys Microsoft Alliance and Solutions blog

« MSMQ - Receiving messages from remote private queues | Main | Software Factory: The ABC of DSM »

Software Factory: Adopting DSM for High Evolvement Systems

How you wish you could write a software and say – "Write it, Shut it, Forget it"? If only businesses were so simple and straightforward, and everybody in the world understood everybody else every time of the year. Sigh! There is no dearth of dreams.

Coming back to reality, fuzzy or frequently changing requirements are one of the biggest problems dealing with software systems. Today's requirements are tomorrow's legacy (whether you like it or not), and so on. And keeping your software systems on its toes has, historically, been a pain. The idea of Software Factories draws its nucleus from Domain Specific Modeling, and tries to address this to a very significant extent.

Modeling, at its very core, defines a way for the business users to define what his business is all about, and the mechanisms working together with it – Code Generation, Transformations – make sure the model is parsed and emitted out as appropriate source code and other artifacts that fuel the software system being developed. In a traditional world, a change in requirement would have to be understood through non-intelligent models, and then understood by a bunch of smart people from IT, and establish processes around this so that they flow down as precisely as possible to the developers.

And History and experience tells us, that even in its most precise form the change in business requirements is never conveyed as-is to the developers, thanks to the eternal troubles of human mind and the limitation of verbal and inter-personal communication. With DSM, this trouble is partially taken over by the mechanism itself.

So the business user makes changes to the model; and because the models are tightly coupled with the domain specific Transformation Mechanisms, they immediately churn out code and artifacts that adhere to the new model to hitherto impossible levels of precision. The developer can take over from here and add customizations and other business logic to the generated artifacts to fine tune them to best suit the software's needs.

The mechanism just described addresses the needs of fuzzy and changing requirements to a great extent, because the generated source code is a direct representation of the changed model, and the transformation logic used to churn out the code is also specific to the domain. And thereby ensuring much lesser pain and loads of reduction in time spent on understanding, translating, coding and validating the requirements.

In the next few posts, I'll discuss the theories, concepts and practices of Domain Specific Modeling.


Domain specific modeling is quite a well established in theory. But in the world of custom solution implementation and software engineering in general, there a often very narrow implementations of this concept and that too in narrow verticals (like CAD/CAM, MatLab). I know honeywell had been researching on domain specific models or languages. How much practical world has benefitted (again apart from CAD/CAM etc) is still debatable. Would be interesting to see how you address these in your posts.

The vision of contemporary DSM is beyond what CAD/CAM etc deal with. The definition of "domain" could vary from Business Verticals to Technology Domains - that is, I could very well have a Domain-Specific Language that lets me map Service Definition to its corresponding Business Process Definition.

Post a comment

(If you haven't left a comment here before, you may need to be approved by the site owner before your comment will appear. Until then, it won't appear on the entry. Thanks for waiting.)

Please key in the two words you see in the box to validate your identity as an authentic user and reduce spam.

Subscribe to this blog's feed

Follow us on

Blogger Profiles

Infosys on Twitter