Composed services and the Blockchain, part 2 - Meutual searches explained

Index of priveus parts:
Part 1 - introduction

---

In this post, I will explain the operation principles of mutual search services, as they are implemented today. At the end of the post, I will explain briefly, how mutual search can be improved by introducing a currency into the mechanism. An idea which will be explained in more detail, in the next post in the series.

A very good example of a working mutual search service, is LinkedIn's job search. Job seekers can use a tool that looks at first like a standard faceted search engine, to get a ranked list of job offers. They can look at the job offers content, and apply to jobs they would like to be accepted to. The potential employers, on the other hand, get a ranked list of candidates. They can now look at the LinkedIn profiles of the candidates and choose the ones they would like to contact. LinkedIn does not display a rank score on job opportunities search results or on the candidates lists, but they are ranked lists nonetheless. The order by which the entries in each list appear, is not random.

Of course the job search service can be used in the other direction too. If the demand for employees in a certain field is higher than the supply, the employers can become the searches, and professionals in the relevant field will then be the ones who get a jobs offer list they can pick from.

A mutual search system then, is a system in which two groups of people, are mutually looking for a match in the other group. But the search is usually not symmetric. One group is the active searchers group. What an active searcher actually does, is to rank the entire passive searchers group by preference or likelihood of match, and then select some of the top ranking passive searchers group members, and request to negotiate a mutual agreement with each of them. The passive searchers can then rank their offers list and start negotiation with some of the top ranked requesters. The question of which group will be the active searcher and which the passive one, is usually determined by demand and supply conditions.

Although mutual search systems offer a great improvement over one sided search engines, their standard implementation is not good enough for the purpose of enabling better composed services organizations, because of two main reasons. The first is that the interdependent nature of the organization makes searches interdependent too, and the second is that each search operation may have an entirely different search and ranking mechanism. For example, it is possible that a lyrics writer and a music composer will work together while they live far away from one another, but if a certain project requires live music, recorded in a recording studio, then singers and musicians will have to actually meet in the same studio. So a search of a songwriter for a composer, may be less sensitive to location than the search of both of them (already in an alliance) for a singer or a recording studio.

One way to solve these problems is to introduce a new entity into the system: Search agents. Search agents facilitate and gradually optimize specific searches. They are designed and maintained by people with the relevant expertise. If these people are rewarded according to the effectiveness of the search agents they are responsible for then what it means is that the role of the all mighty producers and impresarios is decentralized, and that should greatly improve the fairness of the composed service organization's revenue scheme.

So in the next post in the series, we will look in some more details on the mechanics of a currency based mutual searches, in the context of composed services organization.

Disclaimer: This post series is given to you as food for thought. It is by no means a call for taking any actual steps towards the development of any software service, or anything else. Of course, I would be very happy if something real will come out of my ideas, but again, that is not my intention