Comment 7 on "Anti-pattern: End-to-End Process Orchestration" comment 6

Anatoly,

I think that just having more than one pool within a BPMN diagram is not enough to consider it as choreography. My feeling: the difference between orchestration-dominant and choreography-dominant processes is in their behaviour. The former have “globally predictable” behaviour. The logic of templates (one pool implies one instance) is enough to implement such processes.

Diagram below (process for “selection of the best offer”, optimistic case) I would consider as choreography – its behaviour is less predictable. The logic of instances is required, because pool “VENDOR” actually implies many instances (one per each vendor involved in a bid).

Of course, in BPMN all vendors operate in the same way and that is perfect from the point of view of the company (i.e. pool “COOR”), because the company has to prove that all vendors are treated equally. In some sense, pool “VENDOR” acts as vendor’s proxy (or insulation layer). This allows us to make such coordination more explicit (easier to validate, control, monitor, certify, etc.)

Thanks,

AS

Comment 4 on "Anti-pattern: End-to-End Process Orchestration" comment 3

Anatoly,

I think, that diagramm is "process orchestration". 

Yes, I should use BPMN instead of English next time.

Thanks,

AS 

Comment 2 on "Anti-pattern: End-to-End Process Orchestration" comment 2

Anatoly,

More comments, please.

4) My point is that novice BPM desingers tend to use former model but the latter is more realistic.

My interpretation: they (novice BPM desingers) model the process from the point of view of one of the participants – “customer”; after they have to model from the points of view of other participants, e.g. “dealer”, “production”, etc., and finally, a common view should be synthesised. So, I would say that this is just uncompleted work.


5) Branches from a parallel gateway may go over other pools? I seriously doubt this. Not in BPMN. But you are right: parallel gateways do produce asynchronous threads.

Is illustration below “process orchestration” or “process choreography”?





6) My favourite analogy to process choreography is threads programming in java.
I would treat “process choreography” as coordination between threads from different java programs -- System.exit() at one pool should not stop a particular choreography.

Thanks,
AS

Comment on "Anti-pattern: End-to-End Process Orchestration"

Comment on http://mainthing.ru/item/131/

1) Definition:
“Enterprise Process” (equivalent term “End-to-End Process”) is a business process connected to external customer at both ends and going through more than one top-level company’s departments.

More fundamental characteristics of enterprise processes are: a) core business and b) value-added. Those are main reasons that “a BPM initiative would pay for itself”.

2) “Order-to-cash” process

Please, be more precise. If a company produces a service (an intangible product) then there is no manufacturing. Also, some goods, e.g. normal cars in customer’s configuration, will be produced only after the order from a customer!

3) “Process Orchestration” means tasks execution sequence and logic within a single process frame. “Process Choreography” means the logic of several processes asynchronous execution coordinated by data/message flows.

This separation is not clear. Assuming that “single process frame” is a BPMN pool then one can have “execution sequence” spread over many pools exchanged with “data/message flows”. Even more, branches from a parallel gateway are executed asynchronously (and they may go over other pools).
My feeling: orchestration is similar to normal programming with functions (subroutines), while choreography is more close to co-routines.

Thanks,
AS

Linkedin: Top Down or Bottom Up ?

<question group="BP Group">
Top Down or Bottom Up ?

Do we begin with a Top Down or Bottom Up approach when starting with BPM ?
Trying to figure out how BPM works is like solving a giant jigsaw puzzle. You can approach it in one of two ways. Using the “top down” approach (Process Architecture) , you start with the image of what the solved puzzle should look like, and use this to decide which pieces to ignore and which pieces to search for. The other approach is “bottom up” (Six Sigma), where you focus on the individual pieces themselves. You study them for unusual features and look for close matches with other puzzle pieces. If you don’t have a picture of the puzzle’s solution, the “bottom up” method is sometimes the only way to proceed. Lacking a good framework for understanding processes, organisations have been forced to stick with the “bottom up” approach. This tasks is Herculean if not impossible, with a puzzle as complex as an organisational structure.

Imagine a jigsaw puzzle with several thousand pieces. Many of the pieces can be interpreted multiple ways, as if each had an image on both sides but only one of them is right. All the pieces are poorly shaped so you can’t be certain if two pieces fit together or not. Many of them will not be used in the ultimate solution, but you don’t know which ones or how many. Every month new pieces arrive in the post. Some of these new pieces replace older ones, as if the puzzle maker was saying, “I know you’ve been working with these old puzzle pieces for a few years, but they turned out to be wrong. Sorry! Use the new ones instead until further notice.” Unfortunately, you have no idea what the end result will look like; worse, you may have some ideas but they are wrong.



</question>


From my recommendations for building enterprise BPM systems
<quote>
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.
</quote>

I agree about the analogy with puzzle. I used it for my business process modelling procedure, see http://www.improving-bpm-systems.com/pubs/AS-BPMDS08.pdf

<quote>
In some senses, modelling is similar to solving a puzzle – everyone has his/her own way, but there are a few practical tips, e.g. make the edges first, group together pieces with a similar colour or pattern, collect them into clusters, use the latter as “centres of crystallisation” and then fill in the rest. But, there are a few real-life difficulties: you have to do many puzzles at the same time, to use pieces from other puzzles, to cut new pieces, to optimise the number of pieces, to transform some puzzles, etc. It should be a lot of fun!
</quote>

Thanks,
AS

Linkedin: I NEED INPUT ON A WHITE PAPER. CAN YOU PLEASE REVIEW THE LINKED ARTICLE?

<question group="Business Process Improvement">
I NEED INPUT ON A WHITE PAPER. CAN YOU PLEASE REVIEW THE LINKED ARTICLE?
.

www.OnTheSystem.com/everything

</question>

I like the idea of a simple theory which will help us to improve enterprises.

Some of my ideas from http://www.improving-bpm-systems.com/pubs/AS-AW08-keynote.pdf

An enterprise BPM system is a dynamic set of artefacts (or building blocks?)

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

Principles:
- All artefacts must be evolved to become digital, external and virtual
- All artefacts must be versionable throughout their lifecycle
- All relationships between these artefacts are modelled explicitly
- All models are made to be executable

Thanks,
AS

LinkedIn: What's your experience on failure of CORBA and EJB?

<question group="International Association of Software Architects">
What's your experience on failure of CORBA and EJB?
The Rise and Fall of CORBA

http://acmqueue.com/modules.php?name=Content&pa=printer_friendly&pid=396&page=1

</question>

I used CORBA successfully in Java, Unix and Windows environment. Still remember the IDL and simplicity of the naming service from Visibroker. Wish that modern tools would match them soon.

I didn’t write “nontrivial CORBA applications”. I used CORBA as a tool to connect distributed services -- similar to modern ESB. Together with service coordination (via a workflow tool) and implementation of services in dynamic language (Jython) this worked fine. Versioning was externalised.

Thanks,
AS

LinkedIn: What is the difference between Enterprise Architecture, Business Architecture and the various other "X Architecture" names, interpretations

<question group="Business Architecture Community">

What is the difference between Enterprise Architecture, Business Architecture and the various other "X Architecture" names, interpretations and approaches?
Q1
Is there a difference or is it just semantics, causing confusion because of different naming conventions and promotion of individual view?

I have personally used "Business Ecosystem Architecture" and "Symbiotic Architecture" to define through naming a difference in my own approach, always with a very heavy emphasis on it being a business (executive) driven requirement.

Following the above...
Q2
Should Business Architecture refer to:
- Business strategy dimension for EA
- Business processes that aligns with EA (TOGAF)
- Integrated operational ecosystem model
- Whole-of-Enterprise
- Symbiotic relationship design
- Your suggestion here…

</question>



From my definitions...

enterprise architecture, noun
coherent and proven set of principles, recommendations, rules, practices, and tools which provides guidance and practical help for the design and evolution of IT and business to achieve enterprise vision and strategy

Remark 1: Examples of business vision and strategy are a higher level of maturity, a greater agility, better collaboration, merging, cost cutting, modernisation of legacy applications, outsourcing of a business unit, etc.

Remark 2: Some parts of enterprise architecture are dedicated to different stakeholders.

Remark 3: To guarantee the desired outcome, enterprise architecture needs to be as good as applied science.

enterprise business system, noun

top level view of an enterprise as a system for conducting the business

Remark 1: This top level view may concentrate on how the business is structured, what it does and what it needs to do to meet its goals.

Remark 2: The issues of greatest importance for enterprise business systems are the following:
• the core end-to-end business processes (also known as value streams);
• the governance structures;
• the core business information (semantics);
• the communication with the core business partners.

business architecture, noun
that part of enterprise architecture concentrating on the conceptualisation and evolution of the form and structure of the enterprise business system


Thanks,
AS

LinkedIn: The Nitty Gritty: Can you explain to a CEO what makes an architect different?

<question group="International Association of Software Architects">

The Nitty Gritty: Can you explain to a CEO what makes an architect different?
Well we've been at this for some time and over the last few years have been able to answer this with more and more certainty. However before I post it I want to get some feedback from all of you.

CEO walks in to your office/cube/etc and asks,"I know why I hire good developers/PMs/BAs/IT Ops/etc, so why do I hire architects? What makes them different than other staff? And dont give me any of those mumbo-jumbo technical answers. Just boil it down to one sentence why I should let you keep your high-salary job." What do you say?

Try to answer in one sentence. Try to make sure the answer is VERY clearly differentiated from other roles. For example, "Developers write quality code based on business requirements.", "PMs deliver projects on time and under budget."

...And yes I will post the answer that has come from our research in the next couple of days.

</question>

An architect is someone who translates wishes, expectations, and dreams (e.g. survive in this financial crisis) of a client (you, Mr CEO) into a workable plan and guides others (developers/PMs/BAs/IT Ops/etc) in executing that plan.

See as well https://improving-bpm-systems.blogspot.com/2008/10/discussionenterprise-architect-user.html

In my experience, enterprise architects work simultaneously in the following positions :

• Scribe who keeps up to date the documentation about EA artefacts and the relationships between them. This is the traditional role of an enterprise architect.
• Scout who brings new technologies into the enterprise.
• Salesman who finds good arguments for investments in not-so-obvious improvements.
• Superman who is usually asked to provide a quick rescue for a rotten IT project, often by completing during the weekend work that should have been done over many man-months!
• Sociologist who has to understand the concerns and fears of everyone in the enterprise.
• Servant who is at the service of all others in the enterprise.
• Scientist who uses scientifically proven methods in his/her work.
• Student who is ready to learn quickly new technologies, new tools and new business domains.
• Shepherd who can guide others.
• Secretary “de luxe” who helps others to do some work (although this may be considered as a rather low qualification, it is nonetheless important to achieve the common goal).
• Skipper who can lead complex projects.
• Swiss-knife which can solve any problems.

See also http://improving-bpm-systems.blogspot.com/2008/11/linkedin-is-it-fair-compare-business.html

Thanks,
AS

Linkedin: Future of BPM. Your take on this?

<question group="Business Process Professionals">
Future of BPM. Your take on this?
http://www.aiim.org/ResourceCenter/AIIMNews/PressReleases/Article.aspx?ID=35328
</question>


My observations about BPM:

- no commonly agreed terminology (what does “BPMS” stand for?)
- no commonly agreed reference model
- no proper system of standards (BPMN, BPEL and XPDL have been developed by different groups for different purpose; these standards are not complimentary)
- current discussion about BPMN 2.0 is a battle between BPM vendors; BPM customers are forgotten
- there are many BPM vendors (it seems that BPM is good business)
- everyone does BPM right now (even people who don’t know the difference between process template and process instance)
- potentials of BPM/SOA are huge
- each BPM project is re-inventing the wheel
- no organisation which protects BPM customers

My conclusions:
- future of BPM is bright – maybe not for BPM customers yet
- the main challenge is how to turn BPM from being vendors-driven to become customers-driven? (good example is a set of W3C standards around HTML – each Web browser vendor compares its product against the ACID3 test)

Thanks,
AS