The Right Hammer

  • Edit

 

"When everyone's 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 our tools. Limited!

In case you are interested in the proof of the above argument and the introduction of a new programming tool, then I believe it is worth to read 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 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, it is 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 a 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 say the following (I use this example to show how easily and naturally, Mykosmos, 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 by our employee. The customer arrives at the facility's gate at the specified date and time. The gate personnel gives him 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 the 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):
 

  {(1)....any user can put a new service request}

 

   callwait bpm_assign_job ( "new service request" , __activation_user , "" , 0)

 

  {(2)....at date (app_date) the GATE SECURITY waits for the customer to come for the appointment}

 

   callwait bpm_assign_job ( "service appointment" , "" , "GATE SECURITY" , app_date_num , serv_id )

 

  {(3)....the CHIEF MECHANIC makes the first estimation of labor and materials, assigns a mechanic}

 

   callwait bpm_assign_job ( "service estimation" , "" , "CHIEF MECHANIC" , 0 , serv_id )

 

  {split activities....at the same time, the warehouse prepares the materials,}

   {       the mechanic starts working, the cafeteria hosts the customer}

 

   split_in_branch                                 {parallel split....the technical department does the job while in...}

 

      split_in_branch         {parallel split...(4) the warehouse prepares the required parts while ...}

 

          callwait bpm_assign_job ( "collect parts" , "" , "WAREHOUSE" , 0 , serv_id )

 

      and_branch               {(5).... the assigned mechanic disassembles the engine}

 

          callwait bpm_assign_job ( "disassemble" , disas_mechanic , "" , 0 , serv_id )

 

      join_branches

 

    {(6).... the assigned mechanic puts the parts and reassembles the engine}

 

      callwait bpm_assign_job ( "reassemble" , reass_mechanic , "" , 0 , serv_id )

 

   and_branch                                     {(7).... the cafeteria the customer takes a coffee}

 

      callwait bpm_assign_job ( "host customer" , "" , "HOSTESS" , 0 , serv_id )

 

   join_branches               {...the customer finished his/her coffee and the job has been done}

 

   {(8)....the customer goes to the office in order to pay}

 

   callwait bpm_assign_job ( "payment and goodbye" , "" , "OFFICE" , 0 , serv_id )

 


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 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 cannot 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 month! (usual programming languages cannot hang execution for a month 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 the 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 losing 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!

Have in mind that the:

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

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 "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 the 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 Mykosmos/BOS:
 

What 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 a user has completed in a given period of time? (employee evaluation)

 

What is the mean time of execution for a specific user activity?

 

How I can implement the organogram in my company? (the customer asks)

 

How I can convince my employees to follow procedures? (...but are compulsory by the coordination agent)

 

How I can implement my company's ISO? (the procedure's plan is already written. Take the procedures one by one and build the corresponding "coordinator agent")

 

How I can achieve Total Quality Management? (write every procedure as a Mykosmos/BOS agent. Have each activity in your company recorded, because: "If you can not measure it you can not manage it")


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 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.

Now, I believe, you can see the demo applications in a different way. First, look at:

AutoServices

and after that the applications:

AutoAppointments

 

AutoOrders

If you are not bored by my "accusations" against the "procedural languages" see this also:


Tell a story

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 the wrong analysis!)