Business can now adjust technology processes without having to involve IT.
While this level of agility is only possible in very narrow contexts, says Dr Rebecca Parsons, CTO for ThoughtWorks, it is a definitive step in the right direction as organisations attempt to close the gap between business and IT and look to put some level of technological control in the hands of the business.
Although not a formal part of Agile and continuous software delivery, domain-specific languages (DSLs) are a working example of how an Agile approach increases communication between the business and IT about requirements and priorities, she says.
She used the example of a language that allows a marketing department to specify the conditions for various offers that should be made to a customer calling in to cancel a credit card. The objective would be for the marketing people to write the rules of the offers without the involvement of IT.
According to Parsons, the IT industry has always struggled to craft languages that allow business people to understand IT solutions without knowing programming.
"Initially, we used a general language to which we kept adding more and more concepts until we had a set of domain concepts in a general-purpose language. But this meant that business people had to read, write and understand programs, when the whole point was to remove the need for them to understand programs," Parsons notes.
What we know now is that the language must meet three quite specific criteria," Parsons says.
Firstly, the language must be special-purpose and must apply to a certain domain rather than to the business or industry in general, says Parsons. "It must be specific to that particular domain. Things that are general must not be included in the language. It is not possible to write everything in a DSL."
In addition, language specification (syntax), meaning (semantics) and a distinct way of being processed is essential, Parsons says.
The idea is to develop the language so that business people can read the DSL program, which requires that the program expresses concepts in domain terms and not in IT terms, she points out. "This also ensures that business users and IT have a common language through which they can communicate more effectively, thereby eliminating the usual disconnect between the two groupings."
Costs and benefits is another area where a disconnect between business and IT exists, says Parsons. "IT often discusses its initiatives in terms of IT benefits, whereas the business is looking for the value that will be generated for the organisation."
Share
