All process modeling languages are wrong

Recently I wrote that:

• To develop sofwtare, a software development process is needed.
• A process is described by a process model.
• A process model is defined with a process modeling language.

So, the first step should be to define or to choose a suitable process modeling language. I like very much this cite from George Box: "All models are wrong, but some are useful". I think this sentence is great, think about it: every model is a representation of reality; they are an abstraction, showing details that are relevant from some point of view, and leaving apart information that doesn't matter. So, because they hide some information they are wrong, but the purpose is to be useful in a point of view. I think this also occurs with modeling languages: "All process modeling languages are wrong, but some are useful". Let's answer some questions about this topic, based on the paper by Tao Xie "A Linguistic Study of Process Modeling Languages".

What elements should a process have?

To answer this question, a Process Conceptual Framework is presented in the paper. It defines, in a conceptual way, what any Process should have: roles, activities and artifacts.

I don't know if you think that this is obvious or not, but I have known process models in which artifacts wheren't represented. Their templates (Word or Excel templates) were modeled instead, but not all the workproducts are Office documents (for example, an incidence registration is a workproduct without a document tempate), so they were forgiven in the model since they don't have a template. It's very important to represent the artifacts and give them a name beacuse all the stakeholders should know the more relevant workproducts in the process (documents or other kind of results). How do you define quality controls over artifacts if you don't represent them? (You can't).

How are process modeling languages categorized?

The paper explains the one process modeling language can be categorized into one or mor lingguistic paradigms. It alto describes them and gives some interesting examples on languages based on each of them (I recomend you to take a look). This linguistic paradigms are:

• Rule-Based Paradigm: do you know CLIPS (I'm preparing an entry related to this...) or PROLOG? These are rule-based programming languages. There are many process modeling languages based on this paradigm: roles are associated with rules; these are compound by a an action (what the activity does) and a precondition and a postcondition (the specification of the activity). Real world problems can be resolved by planning. Not good for expressing process topology.
• State-Based Paradigm: this is good for expresing process topology beacuse it's visual.. Many complex constraints can be represented (nondeterminism, concurrency...).
• Functional-Paradigm: complexity can be controled by hierarchical process decomposition. The paper mentions a example language, HFSP, which uses grammar rules to decompose activities; a very interesting approach.
• Procedural Paradigm: the control flow is specified like in common programming languages.
• Object-Oriented Paradigm: a process is a net of interacting objects. A language called UML is an example mentioned in the article... Object-Orientation is more appropiate for modeling artifacts.

How should a process be?
According to the paper, two words would summarize this: Evolution Support. This is essential; think about a static Business Process Model (BPM) of an Organization. The Organization will always stay the same? I think it won't... So a Process should evolve, allowing Business Process Reengineering (BPR). But, how can a process support its own evolution? There are four mechanisms:

Genericity

It should be easy to change a process in the future. A process is really a family of processes that must be refined or instantiated in order to evolve to an actual process. Functional paradigm gives genericity easily.

The paper propose a research about higher-order functions as the mechanism to allow modeling languages to support genericity. I would like to think a little about this... Think about a process called approve_requisites_document(reqDoc:Document); if we could use higher-order functions in the modeling language, we would be able to define this function instead: approve_document(doc:Document,approveFunc:Function), and this way it would be very easy to add or change documents and/or their associated approvements.

Reflection

The process may be able to change on the fly, to change itself by means of a built process or meta-process and meta-elements; the process should be self-adaptable. Think about using languages based on rule-based or functional paradigms to define a process with reflection support.

Take a look at the picture on the left. The process should contain a process that would transform the whole process; we could call it the "Process Transformation" process. So it's a meta-process (a process that knows, works with and operates with the Process). As we mentioned before, a process built artifacts; both process and its artifacts are supported by a set of process assets (procedures or document templates, for example) called a Process Assets Library (PAL). The "Process Transformation" process' artifacts may be a process or a process asset, so that's why we are talking about a meta-process. This way, the Transformation Process uses feedback from the whole process in order to adapt it.

Exception handling
Don't make the process so complex, define exceptions to handle abnormal cases that you can predict during process modeling. Exception handling mechanisms, as mentioned in the paper, can be block-oriented (frequently in languages based on procedural and object-oriented paradigms) and rule based (guess it...).

Deviation (first) and inconsistency (later) support

What about unexpected situations? The observed process should be able to diverge. Some inconsistencies may be created, so the process should allow to resolve this incosistencies and return to an adecuate state. The paper explains how an example modeling language does this. Languages based on the rule-based paradigm are more suitable for supporting this feature.

That's all for today

I think we've talk about many interesting things about modeling languages... Before start modeling the process, we should think about what features should the process model have according to the business domain. So, first of all, we should define or choose a process modeling language that allows us to build a process with such features. It's important to support Process Evolution by means of its genericity, reflection and exception handling, deviation and inconsistency support, so it's a good idea to choose the more suitable paradigms in order to provide this mechanisms.

Today's questions

What's your opinion? Do you think that it's important to care about modeling languages?
I'd also like to ask you about your experiences in process modeling. What languages / paradigms have you used? What tools for defining the process? What Process flow engine?

Once upon a time

Recently I realized that I'd like to improve my Adobe Flex knowledges but, I can't start coding... how do I do that? I like doing things in the right way, I mean in a formal and systematic way, with the rigor of engineering.... There is a step before... so I decided to start the Flex Development Guide. Well, I like doing things in the right way, but I really enjoy defining the right way in which things should be done.

So, which tasks should be defined in that guide? In which order? I can't start defining the guide... there is also a step before: I need a development process. I think we are on the right way; it could be a great to define:

• A generic, technology independent development process.
• Many development guides, one per technology. Each one would extend the development process to set and define the tasks for a specific technology.

OK, we can't start coding. We may start defining a development guide for a concrete technology, but it should be interesting to start defining a developmet process. So, we can start defining this development process, can't we?? No, we can't! How shall we do that? We need a process modeling language! So, let's start designing it.

If you ask somebody: "how would you start telling a story?" We're sure that he or she would answer "Once upon a time...". But, what about software development? Where do you need to start? Coding? Defining a development guide? A process model? A metamodel?

If you're interested like me in doing things in the right way and defining the right way in which things suold be done, I recomend you to read the paper by Tao Xie "A linguistic Study of Process Modeling Languages". It's an interesting study about process modeling languages paradigms and its features. We'll talk about it in detail soon.

Taking the process modeling concepts and phases in that paper, I'v just started writing a Procedure which intention is to specifiy the steps for process modeling, beginning with the process modeling language definition. You can find it in my personal site, at http://sites.google.com/site/josemartinezbenavides, in the IT > PM section. I hope you to take part!

"And they lived happily ever after."

Today's questions:

• How is your experience in process modeling? What steps did you follow? Did you begin defining the process modeling language?
• What do you think about defining a generic and technology independent development process? What do you know about MDA?
• What are the differences between a business and a development process?