Elementary Business Processes

I go a little crazy whenever I see most "process" artefacts. There's something about the wooliness of most models that drives me nut. This then gets justified with "Well, this only a level 3 process diagram, not a level 4" and then follows a long useless discussion about what Levels 1 through to N really mean.

At which point someone produces some consultancy's slide pack that include a formal defintion of levels 1-4 and everyone walks away thinking we all aggree; that is until you try and reconcile process artefacts from two seperate projects and you find you can drive a a truck through the ambiguities in most of these defintions.

So what's the solution? I don't claim to have anything definitive but I do think that by building models based on at least one well defined and understood idea, and defining further concepts based on that we can come up with something more useful.

In summary: Don't start with defining "Level 0" process is. Define the bottom level and let the concepts flow from there.

Elementary Business Processes

The only really firm defintional ground I can find in this domain are "Elementary Business Processes", these are defined as:

An elementary business process (EBP) is defined as a task performed by one person in one place at one time, in response to a business event, which adds measurable business value and leaves the data in a consistent state (C. Larman, Applying UML and Patterns)

This is happily a defintion that can be used for:

A task in a BPMN diagra

A single use case

A step in a "Business Use Case" (Using the term in it's proper sense, not just as a vague use case)

The atomic piece of your functional business architecture.

This is a well understood and generally aggreed piece of functionallity that can then be used as a building block for everything else. They provide the central tracing point between all your different views of the world. You can link them to:

Organisational Functions

Orinisation Units

Stakeholder Requirements

Systems

Events (I'll talk more about events and EBPs later)

Services they Produce/Consume (e.g Service Orientated Analysis)

Logical Entities (Through a CRUD Matrix)

Applications

Disaster Recovery Requirements

Support documentation and responsibility

And just about everything

EBPs provide yout the atmoic unit of functionallity while doing functional modelling in the same logical entities and screens do for data and unser interaction modelling.

This unit can then be used to integrate your functional requriements to the steakholder requirements, information arch, and application arch.