Have you noticed that dirty stare your developer gives you, when you walk up to him with a change in requirement? Let’s see – there needs to be an impact analysis, change of design, change of code, more dirty stares, updating dependencies, regression tests, more change of code, more dirty stares. And then there is another change in requirement. You figure.
Fast changing businesses are often categorized by fuzzy or frequently changing requirements. In such times which are increasingly becoming the new orders of the present day, changing requirements result in seriously impacting the IT systems. Lack of time, investment, human resources and intense pressure from competition makes it an enormous task to keep software development constantly streamlined vis-à-vis their change in requirements.
A single change in requirement could actually mean revisiting the design and the code of the software being developed, rewriting your test cases, and regression testing the dependent components. And this in turn impacts the go-live deadlines, eventually affecting the business, the time to market, and finally your bottom line, and you get another dirty stare – this time from your CEO.
The need of the day is to provide a way for the businesses to define the context and model the business processes and their dependent activities, which can directly feed into the core technical design and code. This way the ever-widening gap between proper understanding of requirements and converting them into technological outputs is minimized to a great extent. In case of fuzzy or fast changing requirements, the business user would be able to re-model his business activities to reflect the change in business and the natural mechanism would automatically update the relevant design artifacts and code, thereby optimizing time, as well as validating the system for regressive impacts.
Domain-Specific Modeling (DSM) is what we are driving it. The days of dead diagrams drawn using a modeling tool, which – at its best – can generate some dumb classes without any context of what business it is into, is fast giving way to creating intelligent models which can understand and act according to its business. DSM is a way of creating your own vocabulary specific to your business domain and technology, which can be used by the business user to define his requirements and lay down his expectations from the upcoming software system. And then use a combination of various mechanisms built around DSM concepts to design, generate code and test scripts based on the models.
DSM is the soul of Software Factories, and what makes it the call of the future is the neat way it deals with the following two types of systems.
1. High Complexity Systems
2. High Evolvement Systems
In the next post, I’ll discuss the role of DSM in developing and maintaining High Complexity Systems.
