After a conversation with a friend of mine and some people at work, the question intrigued me, on how to extend the sales of product owners on the one hand and those of web shops owners on the other hand (see my last blog entry on that topic).
During the following days and weeks, a lot of concepts and ideas kept floating through my mind, never knowing how to canalize it in a suitable way. Some of them are so far from the edge that even pros in this field throw a squint on me. Therefore I decided to write them down and see what you people think about them.
The core idea behind it, I have already outlined in my previous post, can be summarized best by the term Crowd Commerce. It all dates back to a book I once read: The wisdom of crowds by James Surowiecki. I got intrigued by the idea that the crowd is one of the most powerful organizational forms and that the crowd is more knowingly than its highest rated member. It is nothing really new, but someone wrote it down in a noteworthy book and people became aware of it.
So, I started to ask myself the question, what would happen if product owners would mainly focus on what they are good at: obtaining products at the best price and handle the sales process. And what would happen if web shops or website owners simultaneously would focus on what they are good at: presenting and recommending products to their customers. Obviously, there would be a gap between both as the product owners miss a suitable way of presenting and selling products whereas the shop owner lacks the ability to buy products at best rates from their producer.
That automatically led me to the question on what needs to be done in order to close that gap and what would happen then? I guess that we would see lots of (small) web shops popping up, having a quite specialized product portfolio they (might) enhance with additional services like suggestions on how to use a specific product or provide construction services.
There are indeed some open questions left to answer, like the handling of delivery costs when odering products belonging to different product owners. Although they were ordered from within a single web shop the customer has to pay each product owner for shipping its product. But from my point of view, that is just a minor problem to solve.
A major topic might be to answer the question if product owners and web shop owners are really willing to give up the area the other part is responsible for: buying products and selling products. But in doing so both contribute to the crowd and therefore to crowd commerce as they do what they are best at. Depending on how their cooperation is defined, the overall crowd leverages its possibilities at its best and all participating parties will win.
As described in the previous blog entry, the iServices platform is a technical approach to translate the ideas of crowd commerce into a platform.
Stay tuned for more information....or get in contact with me, if you are interested in participating ;-)
Thursday, March 21, 2013
iServices - Enabling Crowd Commerce
My last blog entry discussed the different options on how to define functional processes within the iServices application. As I have been too vague on the context the application will be implemented for, this article gives you a rough overview on the ideas, concepts and features thought of so far.
It all started with a beer and a discussion with a friend of mine about an idea for a web shop. At its core heart it was quite the same where the products would come from as the set of services surrounding the product portfolio were its unique selling point. One approach provided that we would use one of the several affiliate services and assemble the product catalog from it. This was accompanied, however, that we had to stick to the rules of such services, eg. forwarding the customer to the product owning shop for closing the ordering process (see shopping24.de for example). But that was not we were looking for, we wanted to have an independent shop where the ordering process would be transparent for the customer regarding the product owning web shop or the deliverying party.
The following days the idea intrigued me further since it seem to be an interesting approach for product owners and web shops (or alike) equally. Product owners, even small ones, could provide their catalogs along with any additional information to an arbitrarily large number of web shops/sellers, whereas web shops/sellers can select products, even those they would probably have no access to as their purchase quantity would be far to small, from a large unified catalog. For both it would be somehow a win/win situation.
In my mind, these thoughts formed the picture of a busy bazaar or hypermarket where participants trade with each other equally. Due to the concentration of supply and demand, all participating parties benefit from this setup. While thinking on how to summarize this picture at its best, the term Crowd Commerce came to my mind.
As I still was searching for a context that I could use for showing that asynchronous architectures are suitable for ecommerce systems as well, it was quite obvious that the scenario described about would be the perfect match. It was then that the idea of something like a bazaar or marketplace connecting product suppliers and sellers in n-to-m relationships for increasing sales numbers for both participants was born.
The core features of the concept are described further below, split up into different two view points: product owner view and web shop view.
Product Owners
Web Shops
There are some more ideas and visions but it would lengthen the blog entry unnecessarily.
It all started with a beer and a discussion with a friend of mine about an idea for a web shop. At its core heart it was quite the same where the products would come from as the set of services surrounding the product portfolio were its unique selling point. One approach provided that we would use one of the several affiliate services and assemble the product catalog from it. This was accompanied, however, that we had to stick to the rules of such services, eg. forwarding the customer to the product owning shop for closing the ordering process (see shopping24.de for example). But that was not we were looking for, we wanted to have an independent shop where the ordering process would be transparent for the customer regarding the product owning web shop or the deliverying party.
The following days the idea intrigued me further since it seem to be an interesting approach for product owners and web shops (or alike) equally. Product owners, even small ones, could provide their catalogs along with any additional information to an arbitrarily large number of web shops/sellers, whereas web shops/sellers can select products, even those they would probably have no access to as their purchase quantity would be far to small, from a large unified catalog. For both it would be somehow a win/win situation.
In my mind, these thoughts formed the picture of a busy bazaar or hypermarket where participants trade with each other equally. Due to the concentration of supply and demand, all participating parties benefit from this setup. While thinking on how to summarize this picture at its best, the term Crowd Commerce came to my mind.
As I still was searching for a context that I could use for showing that asynchronous architectures are suitable for ecommerce systems as well, it was quite obvious that the scenario described about would be the perfect match. It was then that the idea of something like a bazaar or marketplace connecting product suppliers and sellers in n-to-m relationships for increasing sales numbers for both participants was born.
The core features of the concept are described further below, split up into different two view points: product owner view and web shop view.
Product Owners
- product owners provide their product catalog along with media, availability and other information possibly required by web shop
- they decide where the products are allowed to be incorporated into: theme shops, special shops only, all shops, shops requesting a specific compensation at maximum ....
- they receive orders from an arbitrary web shop for their products and fulfill them
- fulfilling orders might be done in their own name or with a special label of the shop that forwarded the order
- provide the platform with updates on order states as well as product availabilities
- might change the availability of a product between different web shops incorporating the product due to compensation or selling rates in order to max. the numbers
Web Shops
- select and consume products from the platform catalog if they were cleared for it by the owner
- use the platform processes to place orders for products belonging to the product
- use the infrastructure to handle payment processes
There are some more ideas and visions but it would lengthen the blog entry unnecessarily.
Defining and Handling Functional Processes
My last blog entry gave a broad overview on what I am currently after in my sparetime. One core question that plagues me for quite a while now, is on how to define functional processes within the application: incorporate the process definition into the messages or describe it explicitly within the application architecture?
Application Architecture
Messages
Hence, the main question - as always in computer science - is to answer wether to have a known structure which is easy to monitor and maintain but difficult to extend or to have a highly flexible application which allows the product owner to quickly respond to customer requirements.
In a generic approach, achieving both targets is difficult (or near to impossible), but as I know about the context the application will be deployed within, there is a chance to nail down some basic structural aspects which ease the pains of the operations and support team while maintaining maximum flexibility within that borders.
Therefore the application is structured into so-called domains which handle specific topics, like orders, customers, payments or recommendations. These domains are pre-defined and receive messages dedicated to their specific topic. Within a domain, eg. order, the messages tell the processing components on how to handle them. This allows the product manager to offer max. flexibility to the customer when it comes to the specification of a certain behavior within a domain. This approach is outlined in the iServices wiki.
Finally has to be said, that the messages floating around in the system as well as the provided domain interfaces follow a functional approach instead of a technical one. This particularly refers to the way how these artifacts are designed: they try to map the functional context instead of its technical implementation.
The next blog entry will discuss a concrete application context as I have been too vague on that topic so far :-)
Application Architecture
Describing functional processes and the depending data flow explicitly within the application architecture has two major benefits
- Known structure and data flow eases the pain of extending the application according to customer needs
- Predictable behavior due to known structure and data flow eases the pain of monitoring and managing the application in operation mode
Messages
Incorporating the functional process description into the messages being passed around has one major benefit
- Flexibility of application reconfiguration enables the application management to quickly react to changing requirements
Hence, the main question - as always in computer science - is to answer wether to have a known structure which is easy to monitor and maintain but difficult to extend or to have a highly flexible application which allows the product owner to quickly respond to customer requirements.
In a generic approach, achieving both targets is difficult (or near to impossible), but as I know about the context the application will be deployed within, there is a chance to nail down some basic structural aspects which ease the pains of the operations and support team while maintaining maximum flexibility within that borders.
Therefore the application is structured into so-called domains which handle specific topics, like orders, customers, payments or recommendations. These domains are pre-defined and receive messages dedicated to their specific topic. Within a domain, eg. order, the messages tell the processing components on how to handle them. This allows the product manager to offer max. flexibility to the customer when it comes to the specification of a certain behavior within a domain. This approach is outlined in the iServices wiki.
Finally has to be said, that the messages floating around in the system as well as the provided domain interfaces follow a functional approach instead of a technical one. This particularly refers to the way how these artifacts are designed: they try to map the functional context instead of its technical implementation.
The next blog entry will discuss a concrete application context as I have been too vague on that topic so far :-)
Subscribe to:
Posts (Atom)