Relationship between #BPM and #SDLC and Software Engineering (SE)

In my experience, BPM and SE are very natural friends (with the help from SOA, EA and BA) which work well together within a proper architecture.

Some basics: Any complex system is a dynamic set of artefacts (or building blocks?), e.g. in case of a typical business system those artefacts are: processes, services, events, data structures, documents, rules, roles, activities, audit trails, KPIs. Artefacts are interconnected and interdependent. We have to anticipate potential changes: policies, priorities, compliance, technology, etc. Implementation of such changes necessitates the evolution of some artefacts and the relationships between them. It must be easy to modify all artefacts and relationships without causing any negative effects.

My main architectural principles for creating flexible systems:

• All artefacts must be evolved to become digital, external, virtual and components of clouds
• All artefacts must be versionable throughout their lifecycle
• All relationships between these artefacts are modelled explicitly
• All models are made to be executable

(See http://www.improving-bpm-systems.com/pubs/AS-AW08-keynote.pdf)

So, BPM (with the help from BA, see http://improving-bpm-systems.blogspot.com/2011/02/explaining-ea-business-architecture.html) can derive the artefacts. And SE is responsible for creating good services for all artefacts.

Then BPM, EA and SE have to work together to make explicit and executable models. The best example of executable models is executable business processes. Any business process is a relationship between many artefacts: who (roles) is doing what (business objects), when (business events), why (business rules), how (business activities or other processes) and with which results (KPIs). At the same time, such a process is an explicitly-defined coordination of services to create a particular result. So, there is a recursive relationship between services and processes:

• all our processes are services,
• some operations of a service can be implemented as a process,
• a process includes services in its implementation.

This is the base of a modelling procedure (the core of the SE) whose purpose is to analyse a building block (processes or just activities – what is it supposed to do and should it be considered as a whole?) and to synthesize its implementation (how does it carry out its function and should it be considered as a composite?) as the explicit coordination of other building blocks (processes or just activities).

It is an iterative procedure – it can be applied until we only have left indivisible building blocks (i.e. activities). During modelling it is necessary to collect and refine the different artefacts. To avoid getting bogged down in detail it is useful to construct building blocks recursively, like Russian dolls.

Of course, owing to very nature of modelling as a creative problem-solving human activity, each person does it in his/her own way, and for the same subject two different people may produce two different models. The proposed modelling procedure can’t change this, but it does help to uncover the same artefacts.

Mode details are in my book http://www.improving-bpm-systems.com/book

Thanks,
AS