Saturday, June 20, 2009
BP and the human factor
In Business Process Re-engineering you will learn that from an
organizational viewpoint, structuring your enterprise in functional
division is wrong, because there are so many breakpoints for the
business processes. And there is another reason for a process
oriented structure of your enterprise: the human factor. If a human
being is able to realize itself as an expert in some team, intrinsic
motivation will follow. There is another important aspect in
motivation there: with this kind of structure, it won't have to do the
same job everyday for anonymous looking parts of the company. The
more it changes, the more it is the same thing.
For structuring large entities of information e.g. programs, the
motivational aspects are not to be taking into account. At least for
the moment, we don't have to deal with AI, yet. But you have the
breakage of the process structure there. And if you think of this
weird thing modular programming, you certainly realize that it goes
against our thinking to built reusable parts. What we are really
trying to achieve is to implement some kind informatics aspect of the
business process at stake. Modular programming goes against this
human way of thinking. In the end are the programmers human beings,
too. The have to be motivated and will play in the future an
important part in every business process.
So how do we solve this problem? One possibility would be to the most
marketing like solution, too. Concentrate on your areas of expertise
and process oriented structure will follow. Our tools could have a
modular structure because they were built by entities that had this
task to do. This is explaining why we all are using more or less
standard libraries from someone outside of our own process.
Thursday, June 18, 2009
Mechanismen der Macht

Design patterns
Wow, one week without real Internet-access and straight thinking
returned back to me. Sometimes I have the feeling, that the internet
produces a real short concentration-time. I can't stay concentrated
on one subject for a long time if I have Internet-access.
I am in the wake of searching a place to live. After all my new job
is in a different city. And driving the whole day long with the
subway, I could observe myself to fall back into this state of deep
thinking that is normally the result of long learning sessions in the
library -- a state of meditation. I think most people forget, that
there is not just the Zazen, the sitting meditation, but also Kinhin,
the walking -- and searching for a new flat share is truely is. So I
was thinking lately a lot about automata and computational models.
This is a subject of great interest for me, because the depth of methods
provided at university is not that great for modelling complex
systems.
There are subsubjects in here, like do I accept UML as the lingua
franca of modelling. The obnoxious EPCs, ERDs are stuck into my
head.
But the real subject of this blog-entry is not the shameful being of
the Internet, but design patterns.
Design patterns are well-known in the developer community, but there
is a certain argument, that they are just poor hacks for a less
powerful language than say LISP.
Many patterns form a languageThis is the answer. The problem here is that many people see this from a too technical perspective. But CA was thinking about something else. The pattern is a means for formulating an idea. And after you have collected a lot of patterns it is natural that they are implemented as generic algorithms and such. I am very interested in travelling so this comes out naturally for me. Imagine the following situation: You visit a new country, say France. And you don't know the language, yet. So you use patterns. A pattern is the triumphirat of a problem, the context and the solution. Given the problem of starvation, you want to eat something i.e. the solution. The context is that you are a stranger with no money but good looking. I now will introduce the pattern Fancy someone for a meal. And now you can go on and describe an algorithm, a step-by-step instruction how to seduce someone in this special case. The next thing could be that you want to sleep in this country. Now it is possible to define the Fancy someone for a place to sleep. This could be a whole language for your state machine:
-- S = { hungry+tired, full+tired, hungry+awake, full+awake } -- E = { Fancy_someone_for_a_meal, Fancy_someone_for_a_place_to_sleep } -- T = { (hungry+tired X Fancy_someone_for_a_meal -> full+tired), (hungry+tired X Fancy_someone_for_a_meal -> hungry+tired), (full+tired X Fancy_someone_for_a_place_to_sleep -> hungry+tired), (full+tired X Fancy_someone_for_a_place_to_sleep -> hungry+awake), (full+tired X Fancy_someone_for_a_place_to_sleep -> hungry+tired), ... handwaving ... }A pattern is a relation putting a new dimension to algorithms and helps building a language. Quicksort for example is not the fastest algorithm for every case in every circumstance. To document this you can use patterns. Now my coffee is finished. Back to work.
Subscribe to:
Posts (Atom)