Blog: Process Anti-pattern: “One Man Show”

<discussion ref="http://mainthing.ru/item/166/" />

I think that both Anatoly's diagrams are anti-patterns. Previous comments gave a good explanation about the second case. Also, there are many different considerations (e.g. be ready for future changes, avoid mixing of added-value and mechanical activities, etc.) to present some work currently done by the same "person" into a set of activities.

I would like to use the first diagram as a "stress test" for BPMN - how a middle-man management can be expressed as a process. This pattern (called MMM) is an example of decentralised coordination. There are four participants who/what share the coordination: buyer(B), manufacturer (M), middle-man (MMM) and a common-sense procedure for mutual agreement (AGREE). Each participant has his/her/its own pool which contains participant's view of this process.



From the picture, it is obvious that MMM does no useful work -- just dispatching events+data others.


Thanks,
AS

Blog: Architecture Frameworks Don’t Make Architects

<discussion ref="http://jpmorgenthal.com/morgenthal/index.php?entry=entry090630-151756" />

Sure that classic EA frameworks create some kind of “enterprise genotype” (a full nomenclature of enterprise artefacts) which is not yet well connected to “enterprise phenotype” (a set of observable characteristics such as performance). This is one of the reasons for current difficulies with the construction of business systems which match clients' expectations. (I would like to have EA as good as an applied science).

I think that a formal link between enterprise genotype and enterprise phenotype can be done via “enterprise executable model” – EA enhanced by BPM and SOA (see http://www.slideshare.net/samarin/architecting-enterprise-bpm-systems-for-optimal-agility-presentation )


Thanks,
AS

ebizq.net: Join the Debate: Business Process Management or Business Process Automation

<discussion ref="http://www.ebizq.net/blogs/bpminaction/2009/06/join_the_debate_business_proce.php" />

To debate efficiently, I would start from definitions of three different concepts under BPM "umbrella" (see also http://improving-bpm-systems.blogspot.com/2009/04/should-we-consider-third-forgotten-bpm.html)

BPM discipline, noun
discipline which allows you to model, automate, execute, control, measure and optimise the flow of business activities that span the enterprise’s systems, employees, customers and partners within and beyond the enterprise boundaries

Remark: At present, the BPM discipline is the best way to implement process-centric enterprises.

BPM system, noun
portfolio of the business processes as well as the practices and tools for governing the design, execution and evolution of this portfolio

Remark: Any process-centric enterprise has its own enterprise BPM system. The enterprise BPM system may not be perfect (e.g. some processes may be only documented on paper, some details are only “located” only in the minds of certain people, etc.), but it does exist.

BPM suite, noun
coherent set of software tools for facilitating the implementation of a BPM system


So, in accordance with these definitions, business process automation (BPA) is an integral part of the BPM discipline. We implement BPA within enterprise BPM-systems with the help of BPM suites.

Thanks,
AS

ebizq.net: Are Organizations Developing BPM Solutions From a Top-Down or Bottom-Up Approach and Which is Best?

<discussion ref="http://www.ebizq.net/blogs/ebizq_forum/2009/06/are-organizations-developing-bpm-solutions-from-a-top-down-or-bottom-up-approach-and-which-is-best.php" />

From my recommendations for building enterprise BPM systems

4.6 Avoid the trap of the selection of “top-down” vs. “bottom-up” – use the “pinball” style

Another typical symptom of getting stuck in the design phase of your BPM system is the existence of endless discussions about the necessary “granularity” of the services:

“If we select a top-down style then we will create coarse-grained business-related services, but we are not sure whether such services are implementable or reusable. If we follow a bottom-up style then we will implement too many fine-grained services for which the business value is not obvious.”

Actually, any such discussion is misplaced at this stage. What should be discussed is how to build future flexibility into the enterprise BPM system which will allow the rapid and painless adaptation of services to increase or decrease their granularity. Small and agile improvements may be required in different layers – rather like the multiple refinements of a ball trajectory in a pinball machine.

This pitfall is extremely common, so take care! We think its root is in the traditional (vs. agile) development practices which aim to provide a perfect system straight away – in such a system all services shall have the “right” granularity.

Thanks,
AS

Blog: Carthago delenda est!

<discussion group="BP group" ref="http://wrivkin.wordpress.com/2009/06/30/carthago-delenda-est/" />

The classic EA is some kind of “enterprise genotype” (a full nomenclature of enterprise artefacts) which is not yet well connected to “enterprise phenotype” (a set of observable characteristics such as performance).

I think that a formal link between can be done via “enterprise executable model” – EA enhanced by BPM and SOA.

Thanks,
AS

Linkedin: BPM and SOA - looking for your opinions

<discussion group="BP group" ref="http://www.linkedin.com/groupAnswers?viewQuestionAndAnswers=&gid=1062077&discussionID=4610507&sik=1246123336638&trk=ug_qa_q&goback=.anh_1062077.ana_1062077_1246123336638_3_1" />

I think some definitions should be stated explicitly at the beginning....

service, noun
explicitly-defined and operationally-independent unit of functionality

process, noun
explicitly-defined coordination of services to create a particular result

Remark: Services and processes can be considered to be intimately related since in real terms
• all processes are services,
• some operations of a service can be implemented as a process, and
• a process includes services in its implementation.

BPM discipline, noun
discipline which allows you to model, automate, execute, control, measure and optimise the flow of business activities that span the enterprise’s systems, employees, customers and partners within and beyond the enterprise boundaries

Remark: At present, the BPM discipline is the best way to implement process-centric enterprises.

BPM system, noun
<enterprise> portfolio of the business processes as well as the practices and tools for governing the design, execution and evolution of this portfolio

Remark: Any process-centric enterprise has its own enterprise BPM system. The enterprise BPM system may not be perfect (e.g. some processes may be only documented on paper, some details are only “located” only in the minds of certain people, etc.), but it does exist.

BPM suite, noun
coherent set of software tools for facilitating the implementation of a BPM system

SOA, noun
architectural approach for constructing software-intensive systems from a set of universally interconnected and interdependent services


The relationship: SOA provides recommendations for the implementation, execution and governance of services. The BPM discipline, by revealing the artefacts (roles, events, rules, object, KPIs, etc.) and the relationships between them, provides the necessary context (e.g. granularity) for the definition of services.

You are right – BP modelling is important. Obviously, each person models in his/her own, but a good modelling procedure can help different people to find out same artefacts which will be implemented via reusable services.

I believe that with a good architecture it is possible to archive optimum flexibility (see http://www.slideshare.net/samarin/architecting-enterprise-bpm-systems-for-optimal-agility-presentation )

Thanks,
AS

Blog: How to Extend PLM Reach – Process vs. Content?

<discussion ref="http://plmtwine.com/2009/06/22/how-to-extend-plm-reach-–-process-vs-content/" />

I think that content and processes are complimentary:
- processes help to generate better content (integration, security, collaboration, SLAs, quality, etc.) and
- content help to make better processes (serving needs of a person who is carrying out a particular task, smart routing, KPIs, etc.)

What mixture of content and processes you need in each particular case -- all depends. And this is a very dynamic balance - each time the point of most leverage may change.

I think that a properly architected BPM can significantly improve PLM.

Thanks,
AS