The Business Process without orchestrator

In order to understand what you’re really obtaining from a BPMS, it is fundamental to see what the process looks like.

We illustrate here how an imaginary manufacturing company processes an order from a customer.

The company has 7 organizational units: Manufacturing (fabrication), Sales (ventes), Purchasings (achats), Marketing, Engine Certification, Certification of Technical Personnel.

Hey! I already started pouring some French here! Just as I had promised!

The company manufactures plane engines. Since this is a regulated industry, the engines must be tracked because of certification needs, and the personnel must also go through a detailed certification and tracking process.

• Everything starts when the order is received by the sales department. This is communicated the marketing deparment via the CRM.
• Once the deal is settled (price, quantity, discounts, etc.), the salesman checks whether everything that is required is already on stock.
• If it is not the case, the order goes to the manufacturing unit.
• First thing to do in the manufacturing unit: retrieve the Bill-Of-Materials and check that everything is ready.
• If some engine component is lacking, the purchasings unit should do what is required.
• Once all the components are there, the manufacturing can actually happen.
• The manufactured goods are packaged and put on the inventory.
• The sales department is notified that everything is ready.
• Shipping information is retrieved and confirmed with the customer
• For the transportation of goods, the purchasings department is called once more
• Once the negotiation with the provider of transportation is finished (weight, origin, destination, nature, price, delay, etc.) the goods are sent to the customer.
• After the goods are received by the customer, the Support Services (SAV-Service après vente) start. This service will feed the units of marketing with new statistics about problems, satisfaction, rate of failure, etc. This service also feeds the information required for the certification of each model of engine, and will help with all engine repairs (that can only be done by certified personnel).

This is illustrated in this illustration. It is an animation of the steps of the process.

It replaces and corrects this poor YouTube video. I will never put any other animation over there… it is quite un-intelligent to do what they did with my small example.

In a future entry, we will see what happens when this process is done via an orchestrator.

Process Logic & Process Data

When the modelers create a Business Process they must specify two things: the process logic and the process data.

The process logic is the description of the activities and events that take place during the execution of one instance of the business process. For example, for an imaginary BP:

when a fax arrives, the customer should be validated before going on. If the user is valid, then… ; at the end a fax should be sent back to the client.

In terms of executable business process, we should rewrite the process logic in a more structured fashion, as follows:

• when the event fax arrives is detected, then the process is launched.
• The first task is to determine what is the customer number
• then the customer number is used to validate the customer,
• then… ;
• at the end, a fax should be generated;
• the user must print it and
• sent the printed fax back to the customer.

Of course, the final form depends on the level of granularity and of detail of the (web) services that should be used, as well as of the information that the users of the system should introduce. In this case, the rewritten process logic can be easily translated to BPMN.

Ideally, the description of the process logic should satisfy the business needs. However, the resulting description cannot be executed because some elements are not there, as explained here. This is what happened with our first model. We must then complement this description with another layer of description.

The second level of specification is the process data. The current description of the process logic does not indicate more than the sequencing of both tasks and events. However, nothing has been said about how to use data for making decisions (if-else scenarios). Another important issue is data manipulation.

Nevertheless, in real life, every time that some event happens during a business process, some data is taken and sent to other systems, transformed into some useful result, and those results are communicated back to the process in order to use them some time in the future of the execution of the process.

This is what we do using forms, notebooks, post-its, IT systems. This information is resilient and many of the future decisions of how to handle the processing will be done on the basis of these data. That’s why they are called process data. In most cases, these data are simply transferred to a new system without any transformation.

Let us see un example of a very ordinary dialog over the phone:
- Carlos : Hi Susan, I just received a fax from a customer, could you help me validate him?
- Susan: Of course. Just give me the customer number, and the family name.
- Carlos: His customer number is: CN-CNCNCN-CN, and his last name is LNLNLN.
- Susan: OK. Give me a second. The customer FNFNFN, LNLNLN, identified with the number CN-CNCNCN-CN is valid. You can go ahead.
- Carlos: Thank you. Excuse me one more time, but: do you know how to make a claim in this new system?
- Susan: I’m not sure, but I think you should press the button “Customer Is Valid” in order for the system to know that I validated the customer for you.
- Carlos: Yeah, I see. Something new appeared on the screen. It asks me to print a response letter for the customer.
- Susan: Just do it. It will print a model reply letter with the reference number of the claim.
- Carlos: It’s done. But it’s also printing something on the sticker printer. It’s a sticker with the reference number and some barcode.
- Susan: You’re done. You stick the barcode to the incoming fax. Then you put it in the binder that is marked “Claims Dpt.”. The system will send them a message immediately so they know they have something pending in your office.
- Carlos: Yeah, I see. Before I had to call them all the time so they could come take it. It was not really effective with these guys.
- Susan: It’s improving. You’ll see. Don’t forget to take the other half of the sticker and put it on your logging book along with the date.
- Carlos: OK. Thanks for all your time and comprehension. Sorry if it took too long.
- Susan: Don’t care. Bye.

All these data: fax, “Customer is valid”, sticker, reference number, customer number, customer last name, customer first name, nature of the fax(claim), date, etc. are stored temporarily in order to perform a series of tasks. Some of these are physical data, other are just logical data and data references. The most important feature of those is that they are local and private to one instance of the business process:

• The fax is unique (one instance in paper, received at a time/date),
• the reference number is unique (the system should guarantee a sequential number for each request),
• the validation is unique (the customer is valid at the date/time of the request, but it might not be the case before or after),
• etc.

Therefore, the process logic is now complete: We know what event to expect or what activity should take place, and also what it takes to perform each activity.

We didn’t have enough space to cover the manipulation itself, and how to transform data. This will be done in a series of entries labeled “Process Data”.

What the Intalio Suite provides to each Role

The Intalio suite is made up of 2 basic sets: the Intalio | Designer and the Intalio | BPMS Server.

The first one is the platform for modeling and preparation for deployment. The second is the platform for execution. I will now list very succinctly the features that satisfy the specific needs of each role, without being exhaustive.

(The roles and the general project approach –xPD– are explained here and here)

• The Intalio | Designer is intended to be used by the Business Analyst and the Process Assembler.
  • BA-oriented functionality:
    • Process specification (BPMN designer) and validation
    • Screen designer (XForms designer)
  • PA-oriented functionality:
    • Data mapper (connecting input/output messages to the Process Data)
    • Pool specification (internal or external to the system)
    • Process-role assignment (for interactions)
    • Generator of BPEL and BPEL4People
  • SD-oriented functionality:
    • Deployment server parameters
    • Target URL namespace

• The Intalio | BPMS is intended to be used mostly by the Process Assembler and the Solution Deployer.
  • BA-oriented functionality:
    • Portal-like interface (XForms, authentification)
  • PA-oriented functionality:
    • Administrator interface
      • Process administration
      • Instance execution debugger (data, events, correlations)
    • Interface for testing Web-services
  • SD-oriented functionality:
    • Administrator interface
      • Process administration (deployment/undeployment, archiving)
      • Instance execution debugger (data, events, correlations)
    • Other administration portals

I will soon explain the diversity of platforms that make up the Intalio Suite, in particular the forest on the side of the Intalio | BPMS Server.

Creating a first BP-model

Guten Tag,

Let us create a simple description of the process from the original one that the BA has before starting.

How? Well, you open Intalio Designer. Create a new Project, by selecting File->New->Intalio|BPMS Business Process Project; write down the name of the new project and configure the environment (by default, just say OK on this part). Then, you have an empty project with a single sub-directory named “build” ( “DO NOT TOUCH!!!” ).

In Intalio Designer you identify several zones of the screen: the menus at the top, the Process Explorer on the left, the drawing or working area (empty) at the center and up to the right margin; at the bottom you’ll also find two small windows with detailed descriptions, and at the bottom margin you’ll see the tabs chooser (on the left) and the status of the compiler/ deployer (on the right).

In each project, you can create as many process descriptions as you want. The idea is to create one diagram per process description, so let us do it: Right-click on the name of the project, and a menu will appear. Choose New->Business Process Diagram. Then, write down the name of the BP (it can be the same than for the project, no problem).

A new process diagram is created, opened in the drawing area, and a couple of default elements have been pre-built: a default pool, and a default task.

What is a pool? very briefly, it is the representation of the space of action of a given role/actor; it is used as a graphical container of all the tasks that are performed by such a role.

And, what is a task? well, a task is an action or activity performed by a role. It must be put inside a container (pool) in order to be assigned to that role. Tasks are what is listed in our original process description.

Making the system more comfortable for Business Process Modelers

The default perspective in Intalio is the Intalio|BPMS Designer perspective, , that contains the detail needed by the IT specialists. In order to change it, please choose the view menu (top right corner, or go to Window->Open Perspective->Intalio|BPMS Modeling or Window->Open Perspective->Other->Intalio|BPMS Modeling ). This view will allow the BA to use the whole space for the process diagram.

Choose the Palette tab (behind the Project Explorer). The palette offers you the whole set of BPMN symbols you need in order to create your graphical process description. If you want to put a task symbol in the pool, then you click on the Task symbol, and then you click on the drawing (do NOT drag it, please). That’s it.

You must set a name. You may either double-click inside the task, or do the modification using the Properties tab (Click on Properties, then at each task in the drawing. You can edit the content of Properties->Process Execution->Label)

(If you want a full description of this step, please go and visit the Intalio Tutorials and Screencasts in order to understand how to introduce the symbols. My goal with this blog is not to replace the documentation that is already there.)

Specifying the causal relationships: what comes after what

Continue introducing as many tasks as you have in the list of the original process description. Put the next task always to the right of the preceding one. Try not to be too generous, since screen real-state is scarce. You can also zoom out from the menu bar (the only option with the % sign in it ).

You will get a long “chorizo” of tasks. They’re not a network of consecutive tasks yet. This is why a red error symbol appears at the left margin of the pool when you save the file (CTRL+S).

In order to connect the tasks, choose the Flow Connector from the Palette, and then draw it in the working area: click once on one task and click once on the destination task, the arrow will appear indicating the correct direction. The Flow connector is actually a transfer of the control flow among tasks, not a transfer of the data flow.

As you see, by default, the tasks are done in linear-sequence. However, most interesting processes are made up of a non-linear sequence patterns (parallel, one task-or-the-other, a-minimum-of-iterations-of-a-task, a-minimum-of-instances-of-tasks, etc.). For the moment, we will not address these issues.

Once you finish entering the tasks in sequence, we have a first version of the process. Isn’t it difficult to change the control flow later? NO!! That’s the good thing of BPMN and Intalio. It is actually pretty easy, as we will see in a future entry.

Now you’re notified of an error when you save the project. Mmmmmhh… if you put the mouse over the error symbol on the first task of your process, you should read “The first task of an executable pool must receive a message” … ? It is not that terrible, but we have to go back to the original process description:

• what is the event that can trigger this process? what makes the organization to launch a process like this?
  • Is it a request/claim made by the person herself or by indirect means?
  • If it is the person: can she do it by mailing a letter? can it be done by phone? by fax? by e-mail? via a form in a website?
  • If it is done indirectly: what is the kind of system and of information that is received? what are the rules that enable the detection of a certain condition?

Very often, we can represent the launch of a process as an event, one that arrives or that is detected. This is represented by a Starting Event. The Intalio Palette proposes three events: Empty, Message, and Rule. Please select the Message Start. Put it as the first element in your process timeline.

Specifying the causal relationships: connecting to an external trigger

As the message must come from somewhere external to the orchestrator, you should draw another pool. Select the Pool from the Palette, and then draw it in the working area. It should be a non-executable pool, as explained here, since it is an external actor or system the one who initiates the process. It is not an element under the control of the orchestrator. Click once with the right-button of the mouse, and choose the last option of the list, Set pool non executable. As a result, the left margin of the pool becomes dark.

Put a task in this new, external pool: choose the Task from the Palette, and then draw it in the working area. This time no error is notified, since the non executable pools do not require an external starter.

In order to connect the tasks from different pools, choose the Message Connection from the Palette, and then draw it in the working area: click once on the origin task (the new task) and click once on the target task (the message start event of your process), a dotted arrow will appear indicating the correct direction. The message connection is actually a transfer of the data among tasks that is used as a synchronization point by the control flow.

Save the project. Both the error symbol and the error messages have disappeared.

BPMN is very zealous about well-formedness: please close every opening element, and start and end every process explicitly. I know! I know! Intalio is not telling you anything, but it will surely if you don’t correct the situation early. Pls listen to me: avoid the problems and save time. In this case, the orchestrator should include an explicit termination, and End Event. Please select the Empty End from the Palette, and then draw it in the working area, at the right of the chain of tasks. Insert a Flow Connector from the preceding task. We’re done.

The first iteration of our BP-model is complete. It is not possible to generate an executable description from this first model. We will see why very soon.

Vaarwel !!

What is too often tacit and that should be know by both IT-guys and Biz-people

Konichiwa,

There are several aspects of the interface between the theory and practice of BPMS (and of the more general
workflow-systems) that are just never explained.

They are not necessarily present in the minds of non-specialists. I prefer to avoid the tacit understanding of such aspects. This often results in undeterministic and conflicting views of BPM, BPMN, and of the process descriptions that you create with it. It is also fundamental to grasp the essence of the architecture of BP-based systems (what is the place of BPMS and of workflows, of BPEL, BPEL4People, User Interaction, and others in the equation).

I won’t cover everything here but the main issues that help you understand the reasons that I consider most important to understand how to tackle a BP-project using Intalio and other BPMSs:

• The designer must clearly specify two logical sets:
  • the portions of the workflow (set of tasks) that can be performed automatically, and
  • those portions of workflow that require human intervention.
• The BP designer will generate an orchestrator that will be executed on a BPMS server. An orchestrator:
  • is an entity that guarantees that the execution of the business process follows the specification;
  • is external to the systems that will actually execute many of the actions, but it is the orchestrator who will command them to do those actions;
  • is not the owner of most of the information that is required for future actions, so it should grab and store that information for future use.
• The designer will then obtain two kinds of BP-pools (representing the coarse roles that participate in the process):
  • non-executable: each of the IT systems that the orchestrator must talk to, as well as every user interaction (web-based in most of cases)
  • executable: the orchestrator itself.
• The BPMS server:
  • provides an environment where to execute the orchestrator. Such environment is a virtual machine for BPEL and BPEL4People
  • provides a portal for managing the User-Interactions in synchrony with the BP-description
  • talks to security components, in order to authenticate and authorize BP-consumers

I hope this will make it easier to understand the structure of the resulting specification. More details on this subject will be discussed later.

Tchau!

Before you start creating the BP model in Intalio…

Bon giorno,

Most people find it difficult to start a business process modeling project with Intalio but when reusing examples. Consequently, I thought it would be useful to give a few hints of what it really takes to start from scratch. Of course, I’ll be as generic as possible and attempt to remain consistent with xPD, and we should address specific needs at some point in the future.

As I said before, the PD or BA is responsible for mapping the BP description by using Intalio Designer. Here, we follow a top-down approach where the specification comes from the business side; it may however remain still applicable for orchestration efforts coming from the IT side.

In order to model a Business Process, the BA should first have a model process, even a draft one. If it is not the case, she/he should create it, but this is a different issue we will talk about in a future entry. I will assume the BA has a list of the tasks that make up the process, and that YOU are the BA. Please, choose a simple process that is mostly sequential; we can add complexity later but the goal now is to understand.

The original model process is just a description. It does not posses several properties that are required to make it executable. So, we must transform this description (“AS-IS”) into the one you will obtain at the end of the modeling project (“TO-BE”) . What is the difference?

• Semantics (symbols used and grammar) of the description language are ad hoc.
• Data is not mapped: there is no way to communicate the context to the different tasks explicitly.
• Actors are often specified but in a physical/real environment, where paper & thick walls isolate roles, and where several specific IT systems/applications must be used.

We will write a new specification with more rigorous semantics by using BPMN. BPMN is a description language produced by consensus of a large community; it is a public standard, so people should be able to understand the BP-model 10 years from now, even in a different geographical area. That’s the good thing of this approach: it does not only facilitate reuse and maintenance, but also makes it possible to integrate the Biz-people onto the initiative.

Finally, before starting translating the description, please check first these points out:

• What is the event that can trigger this process? what makes the organization to launch a process like this?
• What is obtained as result at the end of the process?
• How many (coarse) roles/organizational units participate in the process?

PS: Because you should learn BPMN first; I propose you to download & read the Introduction to BPMN and to refer to websites such as BPM Initiative, BPMN.org, BPM Institute, and BPM Research. I won’t teach BPMN here, @ least not for the basics.

I will just tell you that BPMN diagrams are like flowcharts and that you must recognize only four shapes. Each shape represents a main element in the flow: event (circle) that indicate that something happened, activity (rounded rectangle) that mean some work is done (internally or by an external actor), selector/gateway (diamond) for representing control flow (branch/join), and connection(arrow) that indicate control flow and communication. In addition, the roles are represented by swimlanes (pools and lanes).

Hasta la vista!

The pre-conditions for making BPM and SOA possible

Namaste,

Of course I won’t talk here about every single condition. I will discuss, however, two critical issues regarding motivation, technology, and achievement.

Why? In the last few weeks, I’ve had very interesting discussions with some architects and senior developers. They are part of bigger architect and/or development teams and had addressed me as a may-be specialist that could assist them on finding the sense of their lives I summarize the several interactions in three logical groups. They are NOT physical groups of people, and most of them qualify at least in two logical groups.

Actually, they did not find the approach of their teams very correct however not wrong either. It was just that some doubts remained in their spirits, relentlessly distracting them from executing the tasks assigned to them. They could not only follow the same savanna corridor drawn by others without much thinking about where they were heading to.

The first of this groups presented me the following scenario: for several years, they had been developing a number of applications and wrappers for other applications in a big, corporate-wide effort to create a Service-Oriented Architecture. This SOA grows incrementally, and each new service (and the refactored ones) is integrated some time later in workflows and portal that were used by one or more parts of their organizations. So, what? many more years coming…

This is a really critical issue. Actually, they did not really understand what they were doing. When looking back, they felt that the effort done for so long by so many people did not really pay back. The project was late, more costly… the same history than before. So what? All this SOA stuff was just a ton of mumbo-jumbo, a lot of marketing.

This is something to avoid: projects should be shorter, incremental, ROI calculated rapidly, process owner satisfaction should become an upfront issue. Of course, this is an enormous change as for the projects in the past this was the thing to avoid. Please, this is a critical issue for SOA projects indeed. People should perceive the added value. Technical folks should be able to compare the final result.

The second logical group, a bit smaller, was constituted by people who either:

• wanted to know whether it was possible to create geo-spatial applications, or
• wanted to know whether it was really useful to create such applications for, for example, do inventory management

As you can see, there is a problem understanding the scope of a) the technical side of the architecture, as well as of b) the project. Why were they attracted into the geo-spatial applications? why YYYY-maps or GGGG-maps?

Hey! this obsession with mashups and Ajax make the technology the only issue. BPM is not about that. SOA enables this, but you only need a couple of web services for many cases and not a whole architecture. BPM and SOA are about the essentials of enterprise applications, not about the accidental issues such as information representation and interactivity of the user interface (but for applications whose goal is this one). BPM and SOA are intended to reduce complexity and decouple the architectural components. The process-based view of the world allows to map the business activities. If your solution requires visual geospatial components, just use them. If not, do not do it. Don’t mix what is not mixable and don’t compare what is not comparable.

The final, third group is about people that struggle with too many technical issues. Is this really necessary? is it useful? why so much complexity added? wasn’t it supposed to be the contrary? Hey, that hurts!!!

These guys pass their time solving issues about XML binding by hand, XML validation, doing the right messaging implementation for the routing, writing components for authorizing access, … the terms changed, but the fashion did not: the same well-known, vintage approach to architectural design and application development. They did not understand when I talked about performance metrics, about ROI, not even about BPMS like the ones provided by Intalio or PegaSystems (or BEA or Lombardi or MS). They have a daily battle with BPEL coding, SOAP coding, XML validation: the IT view only. They’ll never speedup.

BPM and SOA are more than that: they allow integrating the Biz- and the IT-worlds. They put the IT to the service of Biz, as it was in the old days. The tools are essential, but also understanding what really has to be measured. But… how to continue if we’re not sure all the exchanged XML docs are completely consistent? Well, I think you’re completely missing the point!!! As for everything else in the universe, there are a number of basic preconditions: your computer has the virtual machine installed and working correctly, the application server executes, it reads inputs and writes outputs,… and the computer is ON. You cannot suspect & validate everything!! Nevertheless, if you’re binding XML by hand everywhere and creating sockets by yourself instead of using the appropriate tools for parsing & validating XML and for creating the web services, and you also have to take care of the 13×5 XSL Transformations since people in the 5 independent development teams do not agree on what the XML schema is and, in addition, everybody wants to manage the round-trip exchange and persistence, first re-think your project very seriously: this is neither BPM nor “managed” SOA because you positively missed something in the process of selling it.

You know? I feel just like all these people. That’s why I already saw, experienced, studied, and read about many cases just like these. I know what it is and I want others to avoid it. I saw a bit too many organizations investing money on things they did not really understand. BPM is finally there, and I invite you to make the maximum profit from it.

We can conclude, then, that the pre-conditions for making BPM and SOA:

1. Communicate well: correctly and timely; do not overstate what can be done, do not let people go onto technical issues only; put the business process as central actors; show the roadmap. Integration requires agreement.
2. Focus: Do not let people wander in the woods, having crazy ideas of what can be done; do not let them concentrate a bit too much on technology. They will solve the wrong problem.

Aloha!

Evaluating the need for BPM and for SOA

Ni Hao,

Standard approaches define two sources for initiatives of projects on this domain: the Business(?) and the IT(?).

This is just a simplification but –unfortunately– people tend to take it as “the reference”. This becomes, then, a reductionist view of the world that does not allow to understand correctly the real diversity of scenarios. You should create a less constrained view of the enterprise, their products and their services, in the way that the Systemic Enterprise Architecture Methodology (SEAM) recommends.

As the terms business and IT are too fuzzy, let us first establish more precisely what standard approaches mean:
* Business:
- Operations
- Higher Management
- Internal Control
- …

* IT:
- Architecture
- Infrastructure
- B2B
- …

If we create the extended view of the enterprise, then another trigger becomes evident:
* Industry regulators:
- Compliance
- Traceability
- …

Of course, each of these organizational actors aims to improve a specific area of the organization, or to make explicit some factor as an indicator. We will discuss this subject further in an entry some time in the future. For the moment, I propose you to read the Beer Game; a short introduction can be found here.

Now, what can you obtain from an initiative of this type? well, the idea is to change the organization (only that ). I consider that there are at least 3 different types of result that can be obtained:

• Business Improvement ( on revenue or on operational performance)
• IT performance
• Process transparency

Revenue improvement is the fact that the systemic qualities of the solution allow you can now sell more to existing customers or to new customers, or that you can create new products (as a mix of existing ones); a more classical alternative is to increase the customer retention. A different beast here is when your organization is able to integrate a newly acquired organization quickly, in a transparent way. Most of the solutions on this area require what is called agility, a combined result of BPM and SOA.

The operational performance can be improved when the system is able to do things that it was unable to do before, when the flow of the processing is smoother because many things have been either done automatically by a built-in set-of-rules, or done quickly because all the required information “is just at your fingertips” (not spread through a diverse universe of IT systems and physical archives). This is a direct consequence of BPM.

The IT performance can be seen as the reduction of the cost of infrastructure, maintenance or reduction in the cost of new projects. How can this be achieved? because the infrastructure allows to interconnect/exchange information more easily, or is decoupled in such a way that changes become less and less critical to the environment of the associated application. More SOA than BPM.

Finally, the process transparency is the possibility to track the evolution of a request, and also of finding the hot spots that make its performance slower than expected. Also, the fact that the person that has been designated a specific task can be determined easily, in order to correct/add information for the process that can help in the decision process (contextual help for beginners, for example). Of course, this is BPM.

In a future entry, I will present some arguments that talk more to practitioners.

再见

Is this BP-project proposal for real?

Kalimera,

I have received some feedback about my proposal, and I will try to address the doubts about it. The word simplistic means that it is reductionist: not all the elements are there. It makes it more understandable and crispy. Not doing so will add much further detail very quickly making complexity appear in the process.

If you read carefully, the entries say “simplistic view” meaning that the view is reductionist, not the whole approach.

Why a reductionist view?

As I talk here about a BP-project, I have chosen to retain only three roles. This might be inconvenient for large projects, since the Information Architect, the platform specialists, process owners and other people should participate. Let me say that I focus first on the essential roles only, and that I will introduce other people as soon as the basic model will be described completely. Secondly, the 3 essential roles we cover are the ones that allow to create the Business Process Model. Other roles will allow us to integrate it with the SOA via the web services, know all the details of the information to be exchanged, add the security constraints and the specifics of the exchange protocol, etc. but this is not the core of what we aim to do.

In short, I know no other methodology that can be explained without a basic model. I expect no to create something more complex.

Is it formalized or peer-2-peer?

As many have already understood, this methodology is neither completely RUP-like, nor totally eXtreme-oriented. This attempts to be just a
good, effective combination of both; our goal is to remain eclectic, open to both improvements and customization.

Why RUP? Because it merges the best practices that have been compiled in many years and with experience accumulated in different domains, people know it, and even if the name is as generic as to mean nothing in particular, it also sells because it is as generic as to mean many things –including quality– to many people (It is just that I’m tired of meeting people that demand RUP, and later they show they know not much about it… but the word makes people calm… wow!)

Why eXtreme? Since we want models/code to be executed and validated in short loops, and to think about testing even before modeling, and to guarantee the quality during the execution… there is no other choice.

How many other roles, then?

Each role can be split onto 2-3 roles each, that may be often performed by 1-5 persons each. In really small projects you can find all three roles made by a single person. Of course I will talk about this in a future entry. Please be alert.

Arrivederci

A BP-project model… what for?

Hola a todos,

One of my goals for this initial period is to create some a number of “chunks of information” that should make more understandable the workflow and dataflow that occur in a BPM project done with Intalio. Why?

• Because it is a model (by itself) that can help managers and project managers grasp the main concepts and steps
• For ROI to be computed (it should be, anyway), then first a cost model must be established
• Because by formalizing it, we can explain it to other members in the team what a BPM project really takes
• Why not? even if the approach is pretty eXtreme-like, the idea of BPM cannot easily enter into the minds & souls of non-specialists
• No project manager is going to assume a project where the risks cannot be modeled (and dealt with) **
• The BPM model offered by Intalio is not the same offered by other BPM platforms that are either a) more oriented towards the Business-Analysts or b) more technology-oriented, making BPEL-like reasoning explicit and where SOA is mostly the piping among applications. Consequently, the project model cannot be the same.
• Finally, it is sure that people are smart and will eventually propose something else, either for enhancing
  this proposal or –let’s hope– for replacing it completely for something less absurd. However, a first step is required.

** Some people have not understood what eXtreme really means

Many decision-makers find extraordinary the idea of BPM, but they cannot see what it looks like. Then, they see it, and they don’t assimilate it. Even after a custom-made demo, the paradigm-shift is so strong that the audience is unwilling to think about actually adopting it internally. Afterwards, convincing the decision-makers to go further, spend money and resources (and time) is… just out of question!

(Don’t care. Every paradigm-shifts make all companies, organizations and societies go through these sort-of-”usual” crisis)

The normal workflow, where each guy does its own stuff: business people just describe fuzzy things & functionality, IT people work on this problem and produce a solution… and then nobody is really satisfied… it just doesn’t work as it should, but it’s known and it works.

The Agile Processes, where the tools and the code are “the thing” is not very tranquilizing for people used to create solutions in a certain way for already a number of years. Yes, agile approaches have made their way and are “tendence” but in BPM the abstractions are much higher… and doubt creeps into the scene…

Do not point at these reluctant guys with your finger: THE critical business data is exposed to us via the BPM, and the complex business logic of each of this bricks is huge… remember that similar projects, such as data-migration, are tackled with extreme prudence.

Any reason for this? well, problems like accessing a database and all the transactional-related conflicts are just a simple issue when compared to the conflicts we can have nowadays in BPM: the bricks are ERPs, CRMs, Financial applications, the Accounting system, among many other sparse and dense constituents… therefore, the ramifications of any underspecification or any misconception will be broader than with a single database. The constituent systems of an SOA have been created, developed, maintained and used mostly as separate entities, because the semantics of any composition are not necessarily well-known.

As the abstractions of BPM are more general, the transactional contexts and business logic are much more powerful… for the good and for the bad.

If the IT applications were created (“by God”) as individual applications, and they are each so complex, how can you guarantee (you, little human ) that no mistake will be introduced? An error in the semantics of the composition can become a real disaster for the target organization. Why do you think that just by putting BPM on-the-loop the world will certainly become simpler?

Of course, the BPM on SOA can be applied without much consternation in most modern companies, small projects, etc. However, in order to make this a really transcendental approach, what we should try to change is the mindset and development approach in BIG organizations, mainly in government, in the management of critical resources (food, public services), in the fundamental services for economy, etc.

My thoughts are getting a bit too wild. May be I’m tired, or may be it is time to continue the technical discussion.