Use of Object Orientation

Identifying static components of the business process

Often forgotten in BPR is modelling the business (and technical) environment. Business change is more than just process maps of as-is and to-be

A key part of BPR is in understanding the static model and also to try and find out the building blocks of the business (and IT) is. And also to question and try and make these building blocks as flexible within that business process (by understanding the right responsibilities). This allows the static environment (e.g. a specific department) to be more reactive to business change – i.e. to allow an area to be outsourced more easily or to expand into a different environment

Another aim is to make sure the building blocks (like Object Orientated Design principle) are decoupled with one another so they can exist in a novel (i.e. new) context

Choice in the use of models

The depth and style of modelling is largely driven by company environment – there is no point modelling, if they have no means of using it.

High level modelling, is normally a useful tool for defining the scope

For detailed modelling, can be a useful way of ensuring a robust process is developed. I show how UML can be used for this in my paper on Business Process Modelling

There is no contradictions in terms of methodologies here – that is the benefit of modelling – it can be as cursory or in-depth as is required and appropriate. Taking a purely model led approach is perhaps more useful where there established OO development in place or where OO is a recognized philosophy to an organization.

Owner led vs collaboration led: In less agile environments where ownership is more of an issue (i.e. everyone is less flexible) establishment of ownership is critical. Conversely if there is a history of cooperation between the business parties (and also between those parties and IT) a more collaborative approach can be taken and issues of ownership de-emphasised

Pragmatic way of modelling business rules

Elsewhere on this site I have defined a way of formalising business rules, the principles of which can be utilised readily within a business domain. If a formalised way of specifying business rules appears too much work, or is not appropriate to the user’s general understanding of modelling, then an alternative approach is to still identify and assign operations to the appropriate class, but instead of writing a full specification for each operation, simply collate a list of business rules most likely to serve the operation.

The developer will then be responsible for interpreting these rules within the context of an OO model.

This paper has been prepared by Codel Services Ltd to illustrate how structured business modelling can help your organisation. Codel Services Ltd is an IT Consultancy specialising in business modelling. If you would like further information, please contact us at: Deryck Brailsford, Codel Services Ltd, Dale Hill Cottage, Kirby-Le-Soken, Essex CO13 0EN,United Kingdom. Telephone: +44 (0)1255 862354/Mobile: + 44 (0)7710 435227/e-mail: info@codel-services.com