Customers Typology: The Good The Bad and The Ugly Part 2: The Bad

 Image source: Wikipedia

The first part of the trilogy was about the Good Customer. This post is about the Bad Customer.
No, the Bad Customer does not shoot the Consultant like Lee Van Cleef in the picture appearing in the beginning of the post. 

The Bad Customer could be The Customer who Knows Everything or The Self-deprecating Customer or The Captive or The Paralyzed Analyzer.

What differentiate The Bad from other Customers?
Usually, The Bad Customer does not know what he want to achieve and how he would achieve it. He is not able to define the Consultant's products.

The Bad Customer could ask Strategic Consultant to code programs. He may ask a Consultant who is a DBA or an Application Programmer to build an Enterprise Architecture, Infrastructure Architecture or even Business Architecture. He could as well, ask for Strategic consultancy from an ERP Consultant. 

The Bad may change the Consultant's assignments, every week or every two weeks, even if no product was yet completed.

maybe the Consultant will earn money, but if he is thinking of helping a customer to build effective IT systems, he should look for another customer. 

In addition for lack of satisfaction, the Consultant face another Concern: Should the Bad client be named as a reference? well even if he will praise the Consultant, it is a bad idea to name him as a reference. 
If the potential client will ask: What Value was provided by the Consultant's work? the Bad Customer will remain silent.

Cooperating with The Bad Customer?
 In many cases it is impossible to change The Bad operation mode and his attitude.
In that case the choice is between adapting to his way or stop working with him.  

The third choice is to avoid of doing anything out of the Consultant's expertise.
The Bad Customer probably will fire the Consultant, but he will not, the Consultant could provide some Value to the Bad Customer's organization.

Changing the Bad Customer's approach may require skills in Psychology or Training, which are outside of most Consultant's expertise.

Reuse: Myths and Reality

Ten years ago Reuse was the promise of SOA.
Almost 15 to 20 years ago Reuse was described as main benefit of Object Oriented. 

SOA Reuse is Easy to say and hard to do. 100% Reuse was an unrealistic target. However, even 30% Reuse ratio could provide significant Business Value. 

There are Systems or Systems Components, which you can not break into Services reasonably, e.g. Batch Systems or Legacy Systems.

People tend to ignore systems that do not fit well to the Service Oriented Architecture due to lack of Reuse or insignificant Reuse. They should not. Instead of ignoring them by fitting them into Services Framework and Architecture, they should accept the reality, that building Services for these Systems is wrong. 

Douglas Adams's Last Chance to see
Douglas Adams's most famous books are The 
Hitchhiker's Guide to the Galaxy books. However, Adams's favorite book was: Last Chance to see which was written together with Mark Carwardaine.

Most of the books written by Adams are Science fiction books.
Last Chance to see is an exception. It is a book about animals which almost become extinct.

Mark (a Biologist) was the expert, Douglas wrote and a BBC representative photographed and recorded. They traveled to various countries such as China, Zaire, Madagascar, Indonesia and New Zealand in search of rare animals which almost become extinct. 

The marvelous book is about those animals as well as about people trying to preserve them or trying to kill them or trying to document them (including Adams himself).       

Adams and Improper Reuse
If you wonder why I wrote about a book on Biology in a post about Information Technology concepts, the answer is: Reuse when you should not, i.e. building for Reuse that probably will never occur.
Adams wrote about two related ridiculous Reuse cases. 

The first Reuse or actually lack of Reuse is performed by a bird similar to a chicken, which unlike a chicken, can fly. The bird built a very complex and very large nest. 
The bird dug 3 meters in the ground. It filled the large hole with plants and added earth above the plants in order to verify that the nest's temperature is not too low. It continuously added earth, to verify that the temperature would not be lower than it was before.  

The problem: It is used only once for a single egg. It could easily get the same "Business" results of growing a young chick, by building a simple and smaller nest.  

The second Reuse without Reuse Case is Douglas Adams writing a Computer Programme to calculate the size and structure of the nest. Such a program could save the need to measure the nest  physically. However, Adams travelled to this country only once for few weeks, to search for another animal. 

The required Computer Programme is complex, but the probability that it will be used again is extremely low.  

Conclusions
Adams's examples are clear and could be generalized to SOA.
There is overhead for building Reuse Service. The overhead is in Planning, Architecting and Building a Service. 
If the Service will never be Reused or will be seldom Reused, consider other alternatives which are not Service Based.