"When everyones tools are hammers how you can explain that not all problems are nails?"
Right to the point! We programmers build our "Business Applications" the way we do, not because that way is required by this type of science and professionalism but because those are the capabilities of out tools. Limited!
In case you are interested for the proof of the above argument and the introduction of a new revolutionary tool, then I believe it is worth to read further!
Now lets go to the ground...
Every time a new application requirement exists, the good programmer (2) has to take the requirements analysis from the customer. After the first or second interview with the customer, the good programmer (believing that has a basic understanding of the customer's business) rushes to the ...database in order to map as tables the "objects" that "discovered" during the interview (3). The rest of the application is some forms on the tables., some code into the forms, some reports, some query filters and a good packaging menu. The application is almost finished!
But unfortunately this final application does not follow "exactly" the customers business but is rather an interpretation, of what the customer said, to the "language" of the tools the programmer has in his hands! The application is rather an approach to the customer's business concept and not a "live automation" of his business.
Our tools, until recently, are a database and a "procedural language" (objective or not). The first tool, the database, can make the "business objects" persistent and that is what we need. The other tool on the other hand, the programming language, its not any "procedural" at all. In reality is a "language to describe computational procedures". This means that is an ACE in algorithms, but is completely DUMP in "business processes". To put it in a different way: "is dump in procedures that involve human activities and cooperation".
...but, I think that all of our customers describe just that: "Business Processes"
In the case the supposed customer is a "car service facility" owner he could said the following (I use this example to show how easily and naturally, kosmos AutoPilot, can follow the procedure that the customer describes)
"I want from you to automate my business. In a few words the job that we do is the following: Everyone of our employees can take calls from customers in order to arrange a service appointment. The customer gives a name and the car number and model. A date and time are provided from our employee. The customer arrives at the facility's gate at the specified date and time. The gate personnel gives him the permission to enter. The customer goes to Chief Mechanic. Here the Chief Mechanic defines who is going to disassemble the car's engine, what are the required parts and who is the Reassembling Mechanic. After that the Disassembling Mechanic work's on the car while at the same time the personnel on the warehouse collect's the required parts. After both of the tasks are finished the Reassembling Mechanic starts to put the parts and reassemble. While the technical personnel takes care of the customer's car he can have a coffee at the facility's cafeteria. After the customer finishes his/her coffee and also the car is serviced the customer goes to office in order to pay and have a goodbye. That's all."
If the programmer had a programming language in hands, that was really "procedural", he could write word by word (while hearing the recording of the interview):
The above text is the "exact" interpretation of what the customer said. Nothing less!
You can see that the above code in AutoScript has the intention to use the human activity and not simply wait to used by humans. This code starts by letting the "__activation_user" (any employee) to put the request. The code "waits" from the "__activation_user" to finish and does not proceed further (usual programming languages can not wait for nothing!). After the "__activation_user" finishes the procedure continues with a message to the "GATE SECURITY" employee(s), that a customer with his car is expected. This may occur five (5) days later or a moth! (usual programming languages can not hung execution for a moth in order to execute the next line of code! - in contrast proudly expose their speed of execution!).
You may ask now "Where is the user interface? What the user sees?". The answer is that the "new service request", "service appointment", "service estimation", ... are user activities and must be described separately. Those user activities contain (in another part of code) the description of the forms that open and provide data (directly to the database - so as you can see the database always needed without loosing its value).
You can see also that user activities can be assigned not only by name: "__activation_user", "Ron", "Rafael",... but also by position, following the organogram of the company: "GATE SECURITY", "CHIEF MECHANIC", ...
The lines of code that follow have some "split_in_branch" commands. That means that the execution of the business procedure proceeds in parallel, as many parallel branches of execution as the number of "and_branch". When all the activities of the branches are finished they join to the "join_branches". (usual programming language can not split execution even in the case the business process requires it! Also they can not wait until other activities finish in order to proceed to the next one!). To display visually the procedure path, the kosmos AutoPilot can give it automatically:
Have in mind that the:
callwait bpm_assign_job ( activity_name, user_name, user_role, when, prameters )
can be called simply by "call" instead of "callwait" so the code has not to wait for the user to finish for the procedure to proceed.
The above procedure is the "SERVICE_MANAGER". The "coordination agent" that coordinates the "car service procedure". This agent runs on the server and stays there as long as the procedure runs (for days). After finishing it dies! (freed!). ...this software is smarter so it has humanoid characteristics! This is not the complete code of the agent. The human activities are described also into the agent and are small parts of code that are executed on the client machines.
When you create your next application using this approach, your customer will love you! Really! The above AutoScript agent leaves trails to the database. Questions like the following, that your customer could ask, have a direct answer in kosmos AutoPilot:
Now about the mapping of the business objects into the database. This can be achieved by analyzing each one of the user activities that the coordination agent calls. Generally we can see the data as "control data" (data that have a role in the path of the procedure like when the car owner will arrive to the facility or who is the reassembly mechanic) and "production data" (all of the rest). We group them as usual "objects" mapped to database tables. There is no need for "event tables" or "transaction tables". The execution path of the agent leaves its trails to the database and all the records of the database that have a role in the execution of the procedure. ...Reporting is straightforward.
What do you think my friend? Do I made my point clear? The programming aprorach that I suggest gets right to the point our customers want, not where the capabilities of the programming tool lead us.
Now, I believe, you can see the demo applications in a different way. First look at:
and after that the applications:
If you are not bored by my "accusations" against the "procedural languages" see this also:
Regards
Rafael Pavlides Programmer rafael<at>kosmosbos.com
PS.
(1) Can you imagine then how imperfect can be a "programming language"?
(2) I don't exclude myself, until recently, from the company of "good programmers"!
(3) You must have also discovered, that all "techno well informed" customers prepare in advance the list of "objects involved" in their businesses, to pass it to the programmer! (imitating the way professionals do wrong analysis!)
|
