2008-12-30

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.)

2008-12-24

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.

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.

2008-12-23

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!

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.

2008-12-13

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&gt4.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&gt

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&gtIn 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&gt

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

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.

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.

enterprise architecture, nouncoherent 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, nounthat part of enterprise architecture concentrating on the conceptualisation and evolution of the form and structure of the enterprise business system

2008-12-05

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.

From http://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 enterprise artefacts and relationship between them.

- Scout who brings new technologies into an enterprise.

- Salesman who finds good arguments for investments in non-obvious improvements.

- Superman who is usually asked for a quick rescue of a rotten IT project by completing during week-end some work to be done during many man-months.

- Sociologist who has to understand concerns and fears of everyone at the enterprise.

- Servant who serves all others at the enterprise.

- Scientist who uses scientifically proven methods in his/her work.

- Student who is ready to learn quickly new technology, new tool and new business domain.

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

- 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)