OMG BPM/SOA Community of Practice sub-group meeting (2010-04-21) review

This post is some elaboration of topics discussed at the first meeting of the sub-group (Design Patterns / Integration Scenarios and Methodologies & Approaches) on 2010-04-21. In some cases, my comments are just to understand better the topics. Next meeting is planned for 2010-05-05.

Topic “Connecting business architecture to BPM/SOA/EA"

Within business architecture, there are patterns/templates which can be used to drive BPM/SOA

One of the patterns can be the following: the whole enterprise is usually presented by different levels of abstractions and for each level we have to be clear with the triple.
  1. WHY – A reason, an end goal or something you want to ultimately achieve (in functional and non-functional characteristics, i.e. including performance
  2. HOW – Activities (verbs) that help to achieve the WHY
  3. WHAT – Things (nouns) physical or non physical you use when performing the HOW

At the top level, we mainly deal with organisational artefacts: vision, plans, business models, etc. In deeper levels, WHY is a set of KPIs, HOW is a process and WHAT are different resources and assets. Here we deal with BPM artefacts: events, processes, activities, rules, roles, data structures, documents, audit trails and KPIs. Majority of these artefacts are implemented as services. At bottom levels, we deal with technical and physical artefacts.

HOW+WHAT of a particular level define WHY for next deeper level.

This structure and number of levels are unique for each enterprise.

Topic “BPM/SOA methodology and approach”

Should it be centralized to be successful? Design / Technical authority should be centralized and limited

Does the methodology differ based on the technology you have selected? You’d like to think so, but in reality it’s not.

Longer term objectives often exist in BPM/SOA projects which have to be considered in the kickoff of the project. Or – are we seeing a trend to departmentalized implementations.

Funding drives the level of departmental vs enterprise level approaches.

One of the main advantages of BPM is that it can be implemented step-by-step – different departments may start BPM at different time and advance with their pace. This advantage should be supported by a set of commonly-agreed guidelines which should help different people (in their creative work) find similar solutions for same problems and take similar decisions in same situations. This usually implies
  1. Common architectural framework (principles, agreements, know-how and models)
  2. Common business process modelling procedure
  3. Naming conventions for artefacts
  4. Catalog of available components
  5. Technology recommendations (just desired functionality, no tools)
  6. Open flow of knowledge and experience between central and departmental BPM projects
For items 1-3 find something existing and adapt for your needs. The central project should help a departmental BPM project be the best by learning from the rest.

As you can see, the central project proposes a set of technology-independent guidelines which streamlines the use of technology and tools. This approach allows even to start with a simple BPM tool to better understand needs, build internal competence, etc. and later to switch to a more powerful BPM tool.

Topic "All together"

How do we go from design to implementing into production (including maintenance and support).

I use a business process modelling procedure which delivers an executable process implementation that is simple (i.e. it is comprehensible by all stakeholders involved) and complete (i.e. it does something very similar to the final result).

The purpose of the modelling procedure is to analyse a building block (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 activities). It is an iterative procedure – we can apply it until we only have left indivisible building blocks (i.e. activities).

See slides 36-46 from http://www.slideshare.net/samarin/how-to-use-bpmn-for-modelling-business-processes which describe this modelling procedure.

This is a process-centric view; another useful view is a system-centric one – see http://www.slideshare.net/samarin/architecting-enterprise-bpm-systems-for-optimal-agility-presentation

Topic “Modeling for execution vs static documentation”

How do we define static documentation?
Now we are able to model strategy and execution – the gray line is leaning toward modeling more within the BPMS because it is “living documentation”.
Use living documentation as an example.

Not sure that that I understood the question. Below I provide a few examples of “unusual” use of BPMN diagrams.

1. Top manager’s view of an end-to-end process

2. Presentation of a manual process to find out potential improvements

3. Description of several inter-communicating automatic processes as documentation for an IT architect

4. Illustration of the coordination within a small servicing department.


Topic "Standards and Compliance"

Nothing yet.



Anonymous said...

Alexander, I have red a lot of your posts and writings lately. You seem to reiterate many of the things that I have been saying over the years, for example about the need to utilize a business architecture as a communication device.

Especially in your latest presentation you now also included all the things that I promote for ACM Adaptive case management, such as rules, content and goals.

While that is great that we share those opinions after I have been pushing them for ten years, could you be so kind and elaborate ON HOW THAT WILL ACTUALLY HAPPEN in a typical IT and business environment??? I cannot find anything in your writing that would in the slightest touch on that point. You ask for integration of EA and BPM --- good but how? Who does it? What does it mean in terms of technology. You ask for content integration and completely ignore the differences betwenn inbound and outbound content with embedded business data.

You ask for inclusion of GOALS and RULES and do nto discuss how that would happen in a BPMN environment.

So, please -- if you want your writing that mirrors what many other experts (who actually do it) recommend, then spend some time to elaborate how what you suggest can be done. Otherwise it is a completely fruitless exercise and purely theoretical masturbation of frequently used IT terms.

Thanks in advance and best regards, Max

Alexander Samarin said...

Thanks Max. The answers are in my book "Improving enterprise business process management systems" - http://www.improving-bpm-systems.com/book


Anonymous said...

Thanks, Alexander. I bought it and can't find anything that would qualify as practical 'that's how it works' advice. Can you tell me on which chapter/page?

Alexander Samarin said...

Thanks Max. The key part is 2.4 - make relationships between artefacts explicit and executable. Chapter 13 is about EA and BPM -- EA is good to provide nomenclatures of all artefacts and BPM is good to provide explicit and executable relationships between them. Together they make the whole system more flexible.

Of course, a process template is only a type of relationship. There are other types.

In practice it works as stated - many artefacts are made available and then they are "linked" by, mainly, processes.

Some practical cases are in http://www.slideshare.net/samarin/2010-03-09-omg