The Right Hammer

“When everyone‘s tools are hammers, how can you explain that not all problems are nails?“

Right to the point! We, programmers, build our “Business Applications“ the way we do, not because this type requires that way of science and professionalism but because those are the capabilities of our tools. And I mean limited!

If you are interested in the proof of the above argument and the introduction of a new programming tool, then I believe it is worth reading further!

Now let‘s 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 he has a basic understanding of the customer‘s business) rushes to the database 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. Finally, we have almost finished the application!

But unfortunately, this final application does not follow “exactly“ the customer‘s business. Still, it interprets what the customer said to the “language“ of the tools the programmer has in his hands! Thus, the application is 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, which we need. But, on the other hand, the other tool, the programming language, is not “procedural.“ In reality, it is a “language to describe computational procedures.“ That means that it is an ACE in algorithms but is completely DUMP in “business processes.“ To put it differently: “it is a dump in procedures that involve human activities and cooperation.“

But, I think that all of our customers describe just that: “Business Processes.“

In this case, the supposed customer is a “car service facility“ owner, and he could say the following (I use this example to show how easily and naturally, Mykosmos can follow the procedure that the customer describes)

“I want you to run a car service facility. So the job that you have to do is the following: Everyone of our employees can take calls from customers to arrange a service appointment. Then the customer gives a name and the car‘s number, and the model. After that, our employee provides a date and time for the appointment. Finally, at the appointment‘s date and time, the customer arrives at the facility‘s gate at the specified date and time. There the gate personnel permits him to enter. After that, the customer goes to Chief Mechanic. Here, the Chief Mechanic defines who will disassemble the car‘s engine, the required parts, and who the Reassembling Mechanic is. After that, the Disassembling Mechanic work‘s on the car while at the same time the personnel in the warehouse collect‘s the necessary parts. After both tasks, our employees finish, 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. Finally, after the customer finishes the coffee and our employees service the car, the customer goes to the office to pay and have a goodbye. That‘s all.“

If the programmer had a programming language 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 human activity and not simply wait to be used by humans. This code starts by letting the “__activation_user“ (any employee) submit the request. Then, the code “waits“ from the “__activation_user“ to finish and does not proceed further (usual programming languages cannot wait for anything!). After “__activation_user“ finishes, the procedure continues with a message to the “GATE SECURITY“ employee(s) about a customer with his car. That may occur five (5) days later or a month! (usual programming languages cannot hang execution for a month to execute the following line of code! In contrast, they 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 we must describe them separately. Those user activities contain (in another part of the code) the description of the forms that open and provide data directly to the database.

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 the execution of 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 finishing, they join the “join_branches.“ (ordinary programming language can not split execution even in the case the business process requires it!

Have in mind that the:

callwait bpm_assign_job ( activity_name, user_name, user_role, when, parameters )

The above procedure is “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 more intelligent, so it has humanoid characteristics! That is not the complete code of the agent. The human activities are also described in the agent and are small parts of the code 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 Mykosmos/BOS:

Which car service procedures are running now?
What are the user activities (by name or role) now?
What is the complete history of a specific car service step by step? (Who, Where, Date, Time, Start, Finish)
What is the visual representation of a procedure now?
What activities have a user completed in a given period? (employee evaluation)
What is the meantime of execution for a specific user activity?
How can I implement the organogram in my company? (the customer asks)
How can I convince my employees to follow procedures? (but are compulsory by the coordination agent)
How can I implement my company‘s ISO? (we have already written the procedure‘s plan. Take the procedures one by one and build the corresponding “coordinator agent“).
How can I achieve Total Quality Management? (write every procedure as a Mykosmos/BOS agent. Have each activity in your company recorded)

Now about the mapping of the business objects into the database. We can achieve this 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 at 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 make my point clear? The programming approach that I suggest gets right to the point our customers want, not where the capabilities of the programming tool lead us.

Rafael J. Pavlides
Programmer
rafaelkosmosbos.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 the wrong analysis!)