UI Clients for back-end business processes; Can they be avoided?

Although I have been guilty of such in the past, I have to come to the point where I will avoid creating a UI client for a business process if it is at all possible.

Back in February and March I was in the process of developing a back-end process to manage a certain subset of our company’s membership. The overall architecture used a web service to process each member so I could use the asynchronous qualities of web services and process multiple members at a time, in a pseudo-multi-thread manner. It was sleek, cool, and up to date.

So what is the problem(s)?

1. If I made an update to the program, someone would forget to install it.
2. Some people had older machines without the proper runtime environment.
3. Although the client made perfect sense to me (surprise!), user error caused alot of headaches.

So after I swallowed my pride, I redesigned the application form the ground up. The process would now run from a single batch file that could run without any parameters. Needed parameters could be pre-populated into a database table, and re-runs of the process could use the result data to control which members were re-processed. Progress could be determined by a simple database query. In a nutshell, if someone ran the process ten times in a day, they could not hurt anything.

What is it about UI clients that we so love to design? Is it some visceral need to leave our mark upon our business environment, or do we feel that our work is to complex to be simplified?

Not only do I wonder about why I like to do it, but I also started to realize that our company’s operations group (who run these processes off-hours) have way too many UI clients that all look different, with different design paradigms, and are written in different languages. What kind of maintenance nightmare are we creating for ourselves?

So before I go down the next back-end process design session, I will imagine the user-less environment, and keep it simple.

2 Responses to “UI Clients for back-end business processes; Can they be avoided?”

  1. Charles Robinson Says:

    I couldn’t agree more. I’m currently supporting what I consider to be a very poorly written ERP application that forces the users to be involved in many things they shouldn’t. It was definitely a case of developer arrogance. He knew what the users wanted, end of discussion. As I’ve pulled apart his applications I have reconsidered some of my own past decisions and I’m ashamed to admit I’ve fallen into the same trap.

    With age and experience comes wisdom… right? :-)

  2. Eugene Says:

    looking forward for more information about this. thanks for sharing. Eugene

Leave a Reply