Friday, August 31, 2007

Business modelling with domain specific languages

If one wants to make business modelling effective it is often useful to use domain specific modelling languages. If for example one is modelling an airlines it may be useful to model with concepts such as: passengers, cargo, baggage, flights, tickets. One could of course use generic business/technology concepts for these e.g. organisations or people (customers), products and services (e.g. flights), contracts (e.g. tickets) etc. And people do try and use abstractions of abstractions e.g. actors, objects., tables etc.

Effective modelling in a business language is also necessary for the establishment of reuseable patterns.

The further one abstracts the more difficult it is for the people to understand, and to build the intrinsic knowledge of the domain into the model/artefact. This is why you won't see many good documents written by business analysts using overly abstract concepts (or any executive level documents) e.g. actors, objects, rows, tables etc.

What one needs ideally is an environment that allows domain specific semantics to be quickly instantiated - inheriting from abstract objects as appropriate i.e. passenger is a type of person (has name, address etc.), to be able to model using these semantics and relate all modelling concepts together when it is useful e.g. domain specific, generic business/technology, and various technology specific abstractions.

These domain specific languages are aimed at people interested in the domain (the business) i.e. business users and analysts. They would be used in preference to the "unified" and technology oriented languages foisted on the business by the development community.

Obviously design oriented languages should be used by systems' designers (e.g. UML, BPML, ER, XML etc.). As they form a useful common abstraction point between the technology specific languages used by developers (there will often be many of these).

These languages act as bridges between the business domain specific languages that most appropriate for business modelling and the technology specific languages that are used for construction. They provide an articulation point between the business domain and the technology domain. This articulation point is required: to allow design for construction with a heterogeneous/open technology set i.e. where there will be range of technology specific implementation languages (many of which may not have been selected/determined when the business modelling is undertaken) ; and to allow aspects of design modelling to transcend the specific technology implementation selected. Design involves decisions regarding what implementation technologies to use and therefore one does not want to prematurely lock the design thinking to implementation (unless one is a technology product vendor seeking to "capture" the customer). If one was designing a beam - one would often want to know the characteristics of the beam (by modelling) before determining if the beam should be wood, steel, concrete, a truss etc. or a particular brand of style of steel beam (i.e. in this case these are the implementation technologies).

Even organisations with a strong historical alingment to UML (and MDA whose current implementation is unfortunately predicated on UML) are moving to DSL to overcome the complexity (and unnecessary abstraction) that UML involves e.g. Borland is adding domain-specific language capabilities to Together package for application modeling to enable project teams to build model notations aligned with a business domain. This is not to say that UML has no place - it is fine for technical people to communicate amongst themselves - you just can't reasonable inflict it on non-technical people (or pretend it is well suited to capturing business requirements).

See: UML not suited to describing the architecture or an enterprise

No comments: