Process Is The Main Thing

@ Anatoly Belaychuk’s BPM Blog

The Border Between EA and BPMS Tools

There is confusion in the classification of software used to manage business processes:

  • Enterprise Architecture (EA) tools target the following aspects of enterprise architecture:
    1. Business architecture - business goals, organizational structure, functions, processes, roles, etc.
    2. Application Architecture - enterprise systems and interfaces
    3. Data architecture - logical and physical
    4. Technology infrastructure - hardware, software, networks
  • Modeling abilities of Business Process Analysis (BPA) tools cover a subset of EA: business architecture. But in addition to modeling BPA may include specialized tools like process simulation or statistical analysis.
  • Business Process Management Suite (BPMS) must include business processes modeling, execution (process engine) and monitoring/analysis. Optionally it may include simulation, business rules and much more.
  • Some vendors define their product as “BPM Software”. Usually this means that the system doesn’t fit into BPMS category - for example there is no engine - but marketing wants it to be labeled with BPM.

BPMS enthusiasts (including myself) believe in the power of executable business processes, in “what you model is what you run” principle. The process engine is a must for them so they can’t live with EA tools only.

On the other hand, enterprise architects have no idea how to handle business processes apart from the organizational structure, data and applications architecture. While many BPMS allow modeling the organizational structure, roles and external systems, it is fragmented to the level of “project” - that is, a logical business process (there may be several physical processes in the project) and do not cover the entire organization. Therefore BPMS doesn’t fit architect’s needs.

Now what shall we do about it? Maybe it’s a temporary issue and BPMS will eventually grow up to EA or EA will include the BPMS functionality some day?

I’d be glad to be wrong but I won’t expect this. Let’s forget about processes for a moment and look at the data architecture. DBMS is much more mature technology compared to the BPMS yet the divide between EA and DBMS is not going to disappear. Enterprise architecture deal with databases but their internal structure is modeled by specialized tools.

Getting back to the processes: they can be modelled both in EA and BPMS. As for today BPMN may be used in both. Typical business analyst knows EA/BPA tools better so the natural way to go for him is:

  1. Draw BPMN diagram within EA
  2. Two possible options:
    • If BPMS directly executes BPMN, export-import via XPDL
    • If BPMS supports BPEL, translate BPMN->BPEL

For example, model in ARIS and export to WebMethods. Or model in Casewise and translate to Oracle BPEL.

This workflow is simple, logical, but… not working well. Both options work only if we consider a single pass: draw - handover - execute. Yet BPM is not a one-time process automation excercise but management of ever-changing business processes.

What does it mean in practice? Once the model is loaded into BPMS, the developer edits it to specify certain details required by the execution engine. At the same time the original process model in EA tool doesn’t remain unchanged because analyst improves it continually. (I strictly recommend a series of posts started with “Model Strategy: Preserving vs. Transforming” at Keith Swenson’s blog to anyone interested in the matter.)

Now we must either transfer the details of physical implementation back to EA and find a room in the repository for them (so-called “round-trip” problem) or merge changes made in both models (like branch merging in version control systems). In theory the problem can be solved but as a matter of fact it wasn’t for years. Shall we wait more?

I propose to accept that:

  1. EA-BPMS divide exists and will remain for the foreseeable future.
  2. There will be no satisfactory automatic artifacts passing between them in the foreseeable future.

So where should we draw this division? There is certain freedom because the tools overlap. It’s better indeed to minimize the volume of information transmitted.

Suggestion: let’s divide at the level of a single process -

  • The value chain analysis and inter-process communication (via events and/or data) modeling is done within EA tool
  • The internal process logic is modeled within BPMS

This way only the list of processes and their interfaces will be transferred from EA to BPMS. Automatic export-import is not necessary for this task, we may utilize “export-import via the printer”.

Every business analyst should obey the red line: never use EA tools to model business process internals if BPMS is present.

There is better application for BPMN capabilities of EA tools. BPMS mostly focus on modeling the internal logic of the processes (orchestration), it’s poorly suited for interprocess communication modeling (process choreography). But the orchestration alone can only solve the tasks at the “office automation” level; as soon as you target the end-to-end business processes - i.e. the processes of real value - you can’t do much without choreography. (See process anti-pattern “End-to-End Process Orchestration”.)

Interprocess communications can be modeled by EA tools using the so-called “black box BPMN diagram” - modeling technique presenting each process as a blank BPMN pool. Communications through messages is modeled by message flow, communications through the data is modeled by associations.

BPMN diagram of interprocess communication (black box diagram) produced by EA tool may look like this:

For each process of the above diagram a BPMN diagram is created in BPMS. It deals with the internal logic of the process (white box diagram):

04/13/10 | Articles | , ,    

Comments (8)

  1. Scott 04/13/10 08:12 PM

    This is a fantastic write-up, sir, and captures exactly why the divide exists and why it is unlikely to go away, regardless of what we’re promised :)

  2. Anatoly Belychook 04/13/10 08:36 PM

    Thanks Scott, without your and other bloggers’ support I wouldn’t dare to make such bold statements.

    But I prefer “comrade” if you don’t mind :)

  3. Максим Смирнов 04/18/10 12:59 PM

    Желание провести такую границу абсолютно уместно. Невыполненных обещаний архитектуры предприятия, BPM сообщество просто не потянет. С другой стороны, накопленный Enterprise architecture опыт реальной деятельности в компаниях тоже не стоит сбрасывать со счетов. Тем более что ошибки у корпоративных архитекторов и специалистов по управлению бизнес процессов одинаковы:
    1. Top-down approach преобладает над bottom-up.
    2. Учет и моделирование остается уделом отдельной группы. Основной слой менеджеров, осуществляющих реальное управление, с моделями не работают.
    3. Графический инструментарий существенно затрудняет работу с данными.

  4. igor Fiodorov 04/28/10 05:57 PM

    Dear Anatoly,

    Thank you, wery good writing.
    Let me share some comments to prove your main message.
    1. Import-export to-from BPA-BPM is not working. Not because it is technically impossible (I tried it works fine) but because most of BPA diagrams can not be executed in BPM without reengineering. One of our mutual colleague said that it is easier to redraw a diagram in BPMN then to refurbish it in BPA to be executable. So I think that such option is useless. Funny IDS-Scheer first announced the option to export EPC to BPMN via XPDL in 2005. Nowadays they try to sell it again for WebMethods.
    2. It is a pity that BPM tools support only BPMN. I feel a strong need for multilayered modeling tool for BPM. It should allow modeling:
    a. Conceptual models
    b. Process logic
    c. Execution details of activities
    3 The first one who did a step in this direction is Lombardi Blueprint. They added a conceptual modeling to BPM. Great. May be I did not investigate Blueprint deep enough and I see a lot of things to be improved, but they are on the right track.
    Summing up:
    I do not expect that BPA vendors will make a step to integrate BPA and BPM. SAG having both BPA and BPM can really benefit out of this integration but I do not see any indication from their side.
    Big BPM players are busy to integrate BPM in to a huge product stack. First they have to buy BPA expertise.
    I more rely on pure BPM players. Unfortunately only few survived after acquisition wave.


  5. Bruce Silver 05/28/10 11:59 PM

    Great piece (sorry I am just reading it today). I have been trying to get BPMS vendors who have good BPMN tools to add more BPA-like functionality - notably a business-oriented repository of modeling artifacts: organizations/roles, goals and metrics, rules, data, etc… with no success, largely for the reasons you state. And one you don’t state… That is, BPA vendors are in the tools business. They know how to sell software to an elite few for $5000 per seat. BPMS vendors are in the runtime business. If you can buy the tools at all without the runtime, they are essentially free. I think BPMS vendors know how to make a good BPA tool worth $1000 per seat (with excellent roundtripping to the BPMS)… but they don’t know how to make a business out of it.

  6. Спасибо Автору за великолепный блог!

    Небольшой комментарий по поводу “водораздела в обозримом будущем”.
    Единый репозиторий EA и BPMS - уже есть (ARIS - WebMethod), демонстрацию показывали еще в июле:

    На рынке появится в Q1.2011

  7. arafique 06/10/11 07:31 AM


    Can you please suggest me any BPMS which is capable of importing / exporting XPDL 2.X files.


  8. Anatoly Belychook 06/10/11 08:06 AM

    Most of them do, please refer to The list isn’t complete e.g. it misses BizAgi which does support XPDL.

    The quality of the implementations is another story though: generally speaking, a model exported from one tool may look awful in another.

What do you think?


Copyright © 2008-2016 Anatoly Belychook. Thanks to Wordpress and Yahoo.  Content  Comments