Frank Michael Kraft's Blog

Already in November the Wall Street Journal posted an article It’s a Free Country… …So why can’t I pick the technology I use in the office? that made me ponder.

I have come to the conclusion in the meanwhile, that the appearance of IT will change.

As noted in the article, there is a sense of IT limitation in the offices at the one hand and the reluctance to change in the IT departments. “Never touch a running system.” – an old proverb that contains much wisdom. Of course the problem is cost of change.

As noted in the article, everybody installs one or some forbidden tools on his office computer, much to the discontent of the IT departments. We can’t help – in the end we have to have the best tools for our work.

In the end the article shortly touches on cloud software, but does not elaborate its potential. But when I think of it, it overcomes many of the difficulties mentioned. There is nothing to install on the office computer. Just use the browser. Neither does it disrupt existing systems. There is no big change project. Just use it. Ok – if there is a project group or department they need to decide which one they would want to use and how they organize it.

I expect IT’s role to change over time. Instead of being responsible for making the systems run, they become the central point of governance which services are good to use and which they will veto against. They will have quality criteria that they will apply. This will relieve the IT department of much of today’s burden and let them concentrate on their core competency. Also it will release budget for interesting forward looking projects.

That’s not only, because individuals want to use the best tools possible. It’s also because other forms of work are strongly emerging, among which I want to emphasize Knowledge Work and Collaboration between organizational entities. More and more project groups emerge that work cross enterprises and organizations in non-standard – i.e. in unpredictable or only partially predictable processes and collaborations. Why is (was?) there such a hype about Google Wave? Isn’t that the reason? Google Wave is just a small forerunner of the tide to come. Completely new forms of applications will emerge that will offer functionality for organizing these new kind of processes. Multi-Enterprise Business Applications may be a good name for them.

And the processes they cover will differ from those processes that we know today and that are commodity. As I already stressed those processes will be agile, adaptive, unpredictable, partially predictable, collaborative, creative, knowledge oriented. I hesitate to call them processes, because “process” implies: First do that, then this. That is not the kind I am speaking of. A Knowledge Worker complies with such a process only in rare cases. Neither is it desireable. The Knowledge Worker needs enabling for the goal he wants to achieve and the he or she best knows how to achieve – and to have the freedom to try, to fail, to retry and to succeed. So we might call the new work pattern Workstream instead of Process.

So which IT department would be responsible for such a Multi-Enterprise Business Application? The natural answer is: It will be served as “Software as a Service” by an independent provider and the individual Enterprise will purchase users. That is another strong reason, why the IT will change – because there is practically no other way to address this emerging demand.

I was recently asked if I like this idea: Handle everything, that is coded in an ERP systems today as Process Patterns and instead design it as process models, that can be adapted to the requirements of the customer. The context of the discussion was if the combination of ERP/BPM/SOA would not have tremendous potential.

I aswered, that I have experience with that and that I agree that there is a tremendous potential with that. That really was an interesting discussion, because I did not hear such analysis before in the discussions in the public marketplace. I think this is the right direction to think.

I had already governed the design of the process of about 200 or more business objects, creating about 2.000 models including roughly about 5.000 web service operations. I didn’t use BPMN for that, because it was not flexible enough for this purpose, neither any of the existing languages. I used an own Domain Specific Language (DSL) for Modeling the behavior of those Business Objects.

My summary of that exercise is, that I agree to the original question. Only by modeling the process of Business Objects which are part of the ERP system, the ERP system’s web services will as a result have the right granularity. What is the right granularity for web services? Reusability. If web services are reusable, then they pay off most. In order for them to be reusable, they need to fulfil certain conditions. A web service operation should only do one thing at a time., i.e. not trigger an endless chain of activities in the system. It should have clearly defined preconditions. The effects and results of the web service operations must be clearly defined in terms, that can also be preconditions to other web service operations. That are the most important criteria in my view.

A system must be designed for this philosophy from the beginning. I strongly believe that adding web services to an existing system falls short of this goal. Even if it has some value, it would not use the full potential.

In general what I miss in the public standards is a language to describe the behavior of web services. Yes, BPMN 2.0 goes into that direction. But BPMN 2.0 still has to prove that it can fulfil the promise in practice. I think to a degree it can. It will turn out later, if it is possible to simplify the language or if it becomes an inspiration for other approaches (e.g. constraint based instead of workflow based).  And using BPMN 2.0 in itself does not guarantee the success. Additional guidance is necessary, certain quality criteria that each model must fulfil.

However, if the behavior of web service operations of an ERP system is defined, and if the granularity of the web service operations are so, that they are reusable, then the potential is very big. Because it means, that it is possible to attach own processes to that ERP service and even to interweave own processes in-between ERP processes. For example to add an approval before the release of an order under certain conditions, to add an own method of calculating benefits for the payroll and the like.

However as a limitation to the original question I would say, that not all of the processes modeled could be customized or changed arbitrarily. There are certain core processes, that the ERP system offers, that can not be changed without the danger of losing the consistency of the process. Therefore it is clearly necessary to describe which part of the process needs to remain stable and which parts of the process can change or are open for additions and interweaving. This of course must be part of the model.

I just took the BPMN Model understanding self test. It is a research project of Humboldt University of Berlin, that I can recommend. I was asked about 30 models and how I understand them. The test takes about 30 minutes and is a nice excercise.

http://www.bpmn-selftest.org/

I made it to rank 14 of 394. However I wonder who the 13 were, that were better . So give it a try, maybe you can beat me. The test is anonymous however.

Nevertheless I want to share what I thought when I saw the models. They were quite complicated. I think if models are as complicated in a real project as those in the test, then something went terribly wrong in the first place. I agree, that it is fine for a research project to use artifical complicated models, to find out more about human model comprehension. And I am very interested in the research result. But models must be much simpler than those.

Simpler models could be reached by limiting the scope of one model – i.e. splitting it up in different parts, using submodels for example. As far as I remember human comprehension can assess 7 items at once, not more. So in essence I think a model should not contain more than about 7 important steps.

Also it can mean to model only the most important cases and model the special cases in a different model.

And it can mean to question, if BPMN is the right model language for the purpose chosen. I know that BPMN is popular and becomes even more, because it is a standard. But in my eyes the question remains, if the task flow oriented modeling it does is really the best way to do it. In my eyes it should be evaluated as a result of this research project, if goal driven and constraint based modeling would not result in much easier models.