During my ongoing extended trip, I am often being asked the following two questions: where does your value proposition reside? and how is such value being protected?
These are very valid questions, and they often hide a genuine interest on the other end. As such, I tend to take them as seriously as possible.
Value proposition
Explaining our added value properly is key for us to face our bigger risk: misunderstanding.
Kitewalk is a cloud-based geo-intelligent communication platform which allows sources to get in immediate contact and interact with targets of their interest around their physical locations. Sources are typically users or devices. Targets are generally referred to as geo-contents, dynamic contents or simply contents, and they can be of any nature (other users, IoT devices, houses on sale, events, jobs, projects, you name it: anything which has a physical location and a lifetime is eligible for being a dynamic content). Kitewalk technology and its use cases are described in this video.
Kitewalk GEO API is the 2-way Web Services API which allows to have access to such functionalities, including:
To showcase our added value, I'll elaborate a couple of examples hereafter. While they directly apply to the Smart-City vertical, they can be extrapolated to any other vertical, from retail to housing to Blockchain platforms.
Example 1: Designing a Smart-City solution for a small geographical extension
Imagine offering a Smart City solution to the citizens and tourists of a small town with say, 10,000 hab. population. Such town will have about 20-30 restaurants/pubs, 5-10 shops, 2-3 schools, 10-15 clubs, 3-5 institutions, 10-20 points of interest, 100 parking places, 3 bus lines. Let's say about one hundred GPS locations to handle the town requirements altogether. Imagine that you really want to be get the smart2.0 label and wish to give the owners of such places the ability to publish messages addressed to citizens and visitors (meal offers, school activities, concerts, spectacles, sport events). Let's be generous, say we are able to get two hundred of such dynamic messages available to citizens and tourists in the forthcoming 15 days. In summary, 100 static points and 200 dynamic messages taking place or referred to some of such points every 2 weeks.
Let's create the mobile app allowing citizens and tourists to gain visibility on what they can get around when they move inside such ecosystem. There will be so few messages to be handled by the supposed platform that there is actually no need for a platform whatsoever: any app developer will be able to provide a lovely map or a list of forthcoming activities screen using hard-coded lists of sites and activities. The town extension is so small that there is no real need to correlate users positions and contents: simple ordering the contents by dates will make the communication job efficient enough.
In summary, if we set our short-term glasses on, solving this micro-problem will not require any geo-intelligence service at all. Classical App development skills will be a valid way to provide a short-term solution.
On the other hand, if an ambition exists to make such solution part of a bigger solution in the future, a solution involving Kitewalk would be recommended, as the next example will showcase.
Example 2: Designing a Smart-City solution for a big geographical extension
Let's become more ambitious. Let's imagine we move 3 years ahead and both cities and citizens extend their expectations. Indeed, it is very reductionist to believe that every single small city will have its own silos solution and users will need to change from one solution to another as they commute from one city to another just because the solutions do not talk among them.
In 3 years, Smart-Cities will be become Smart-Regions and Smart-Regions will become Smart-Countries.
On such scope, the numbers in Example 1 will become obsolete. The ecosystem will need to handle hundreds of thousands of restaurants, schools, sport clubs and bus lines. On top of the static pins in the map, such ecosystem will require the daily communication of thousands or millions of dynamic contents generated from such static places. We are no longer in the 200-300 GPS coordinates domain here...
Or, from a user/citizen/tourist perspective, we users couldn't care the less about the supposedly huge size of the ecosystem we are part of. We will not care if the ecosystem needs to handle and process 100 or 10,000,000 dynamic messages. We will keep wishing to discover the small subset of messages that apply to us for the specific location we will be located, whichever that one is.
Such difference is capital with respect to the Example 1. Here, in Example 2, there will not be room for "hard-coded" 5-minute solutions. Example 2 showcases a must-have need for a clearly designed, defined and implemented geo-intelligent platform which would be able to deliver in real-time and real-place just the tiny subset of elements of interest that will fit the specific user time, location and preferences. The user expectation is: "from those millions of possibilities and opportunities, please pick just the dozen which match the scenario I am involved in right now and make me discover them only... oh, and please do not toast my mobile device, thank you!". Correlating sources (the users) with potential targets of interest around no matter when nor where in a resilient, scalable, performant and high-available way is a matter of highly skilled precise back-end development expertise where app development is definitely not the core expertise required
Solving this macro-problem requires server-side geo-intelligence at its full level, and that is exactly where Kitewalk will outperform all competition and prove its genuine added value.
The good news is that choosing between App Development and Kitewalk is not exclusive. Actually, both choices are complementary: trusting on app development technologies for the client-side part and trusting on Kitewalk for the server-side can be a winner. Under such scenario, app developers will integrate Kitewalk Web Services into their app client interfaces in order to gain access to the geo-intelligent server-side features Kitewalk provides. This client/server ideal separation makes Kitewalk an excellent choice even for the scenario depicted in the Example 1 above, as Kitewalk technology provides the key to ensure a long-term strategy solution for any city no matter its size.
In summary: if you do not want to build a short-term silos which will only work under small-sized environment conditions, you'd better think big, think server-side, think platform. Think Kitewalk.
Protection
While it is fairly straight-forward to create "geo-intelligent" hardcoded designs which can scale to hundreds of contents and dozens of sites, it is extremely complicated to design algorithms which render such intelligence scalable to millions of dynamic contents and places simultaneously and build a universal platform to make such intelligence available to anyone. The entry ticket to compete in such space is very high and only at the reach of either big transversal players such as Google and Facebook or crazy start-ups ready to spend 4 years on the development of an equivalent offer without requesting financing.
Kitewalk chose the second path, an extremely uncommon one. Kitewalk core team has more than 150 years of experience in the architecture and implementations of highly distributed identity and billing network solutions which are running today at national levels inside companies such as in Verizon, AT&T, Cable&Wireless, Telefonica, BT or Vodafone. We made the explicit bet to create Kitewalk's geo-intelligent platform and not make it public too fast, having fun on the trip and not rushing for the salaries nor the finance rounds. Over time, such strategy has become our main protection.
We are virtually alone in proposing geo-intelligence services for third-parties as white label. Scarcity and thousands of engineer/hours of high-skilled server-side code creation, algorithm deployments and testing before reaching the first revenues and financing stages are our most solid unfair advantages. Summarizing:
Kitewalk geo-intelligence is accessible through a Web Services layer. From such Web Services, different Business models can be declined:
These are very valid questions, and they often hide a genuine interest on the other end. As such, I tend to take them as seriously as possible.
Value proposition
Explaining our added value properly is key for us to face our bigger risk: misunderstanding.
Kitewalk is a cloud-based geo-intelligent communication platform which allows sources to get in immediate contact and interact with targets of their interest around their physical locations. Sources are typically users or devices. Targets are generally referred to as geo-contents, dynamic contents or simply contents, and they can be of any nature (other users, IoT devices, houses on sale, events, jobs, projects, you name it: anything which has a physical location and a lifetime is eligible for being a dynamic content). Kitewalk technology and its use cases are described in this video.
Kitewalk GEO API is the 2-way Web Services API which allows to have access to such functionalities, including:
- WRITE/SET dynamic contents into Kitewalk Cloud -> Kitewalk takes care of all the business logic intelligence relative to each dynamic content added/imported through a WRITE/SET request: its visibility in the time, its visibility in the space and its category of interest
- READ/GET, up from a particular GPS position, all the contents around such position that match a particular time criteria (past, present or future), and a particular category of interest (typically mapping to user interests such as restaurants, concerts, electricity projects, houses on sale, football fans, free taxis, promotions, etc.)
- the retrieve time: we are able to provide back the closest X candidates that match a particular time/place/category request in a milliseconds base.
- the big-data statistics built on top of each dynamic content being published through the Web Services: we are able to provide heat maps on access to each dynamic content being maintained and retrieved, from where is each dynamic content being accessed from and at which times of the day.
To showcase our added value, I'll elaborate a couple of examples hereafter. While they directly apply to the Smart-City vertical, they can be extrapolated to any other vertical, from retail to housing to Blockchain platforms.
Example 1: Designing a Smart-City solution for a small geographical extension
Imagine offering a Smart City solution to the citizens and tourists of a small town with say, 10,000 hab. population. Such town will have about 20-30 restaurants/pubs, 5-10 shops, 2-3 schools, 10-15 clubs, 3-5 institutions, 10-20 points of interest, 100 parking places, 3 bus lines. Let's say about one hundred GPS locations to handle the town requirements altogether. Imagine that you really want to be get the smart2.0 label and wish to give the owners of such places the ability to publish messages addressed to citizens and visitors (meal offers, school activities, concerts, spectacles, sport events). Let's be generous, say we are able to get two hundred of such dynamic messages available to citizens and tourists in the forthcoming 15 days. In summary, 100 static points and 200 dynamic messages taking place or referred to some of such points every 2 weeks.
Let's create the mobile app allowing citizens and tourists to gain visibility on what they can get around when they move inside such ecosystem. There will be so few messages to be handled by the supposed platform that there is actually no need for a platform whatsoever: any app developer will be able to provide a lovely map or a list of forthcoming activities screen using hard-coded lists of sites and activities. The town extension is so small that there is no real need to correlate users positions and contents: simple ordering the contents by dates will make the communication job efficient enough.
In summary, if we set our short-term glasses on, solving this micro-problem will not require any geo-intelligence service at all. Classical App development skills will be a valid way to provide a short-term solution.
On the other hand, if an ambition exists to make such solution part of a bigger solution in the future, a solution involving Kitewalk would be recommended, as the next example will showcase.
Example 2: Designing a Smart-City solution for a big geographical extension
Let's become more ambitious. Let's imagine we move 3 years ahead and both cities and citizens extend their expectations. Indeed, it is very reductionist to believe that every single small city will have its own silos solution and users will need to change from one solution to another as they commute from one city to another just because the solutions do not talk among them.
In 3 years, Smart-Cities will be become Smart-Regions and Smart-Regions will become Smart-Countries.
On such scope, the numbers in Example 1 will become obsolete. The ecosystem will need to handle hundreds of thousands of restaurants, schools, sport clubs and bus lines. On top of the static pins in the map, such ecosystem will require the daily communication of thousands or millions of dynamic contents generated from such static places. We are no longer in the 200-300 GPS coordinates domain here...
Or, from a user/citizen/tourist perspective, we users couldn't care the less about the supposedly huge size of the ecosystem we are part of. We will not care if the ecosystem needs to handle and process 100 or 10,000,000 dynamic messages. We will keep wishing to discover the small subset of messages that apply to us for the specific location we will be located, whichever that one is.
Such difference is capital with respect to the Example 1. Here, in Example 2, there will not be room for "hard-coded" 5-minute solutions. Example 2 showcases a must-have need for a clearly designed, defined and implemented geo-intelligent platform which would be able to deliver in real-time and real-place just the tiny subset of elements of interest that will fit the specific user time, location and preferences. The user expectation is: "from those millions of possibilities and opportunities, please pick just the dozen which match the scenario I am involved in right now and make me discover them only... oh, and please do not toast my mobile device, thank you!". Correlating sources (the users) with potential targets of interest around no matter when nor where in a resilient, scalable, performant and high-available way is a matter of highly skilled precise back-end development expertise where app development is definitely not the core expertise required
Solving this macro-problem requires server-side geo-intelligence at its full level, and that is exactly where Kitewalk will outperform all competition and prove its genuine added value.
The good news is that choosing between App Development and Kitewalk is not exclusive. Actually, both choices are complementary: trusting on app development technologies for the client-side part and trusting on Kitewalk for the server-side can be a winner. Under such scenario, app developers will integrate Kitewalk Web Services into their app client interfaces in order to gain access to the geo-intelligent server-side features Kitewalk provides. This client/server ideal separation makes Kitewalk an excellent choice even for the scenario depicted in the Example 1 above, as Kitewalk technology provides the key to ensure a long-term strategy solution for any city no matter its size.
In summary: if you do not want to build a short-term silos which will only work under small-sized environment conditions, you'd better think big, think server-side, think platform. Think Kitewalk.
Protection
While it is fairly straight-forward to create "geo-intelligent" hardcoded designs which can scale to hundreds of contents and dozens of sites, it is extremely complicated to design algorithms which render such intelligence scalable to millions of dynamic contents and places simultaneously and build a universal platform to make such intelligence available to anyone. The entry ticket to compete in such space is very high and only at the reach of either big transversal players such as Google and Facebook or crazy start-ups ready to spend 4 years on the development of an equivalent offer without requesting financing.
Kitewalk chose the second path, an extremely uncommon one. Kitewalk core team has more than 150 years of experience in the architecture and implementations of highly distributed identity and billing network solutions which are running today at national levels inside companies such as in Verizon, AT&T, Cable&Wireless, Telefonica, BT or Vodafone. We made the explicit bet to create Kitewalk's geo-intelligent platform and not make it public too fast, having fun on the trip and not rushing for the salaries nor the finance rounds. Over time, such strategy has become our main protection.
We are virtually alone in proposing geo-intelligence services for third-parties as white label. Scarcity and thousands of engineer/hours of high-skilled server-side code creation, algorithm deployments and testing before reaching the first revenues and financing stages are our most solid unfair advantages. Summarizing:
- An average start-up could hardly handle such level of commitments, it is a big barrier to entry.
- An established company would require more money to copy our technology than to purchase ours.
- The engineering expertise required to build a server-side geo-intelligent platform is old-school, requires many years of experience in the development of massive distributed network environments handling millions of read/write transactions.
Kitewalk geo-intelligence is accessible through a Web Services layer. From such Web Services, different Business models can be declined:
- Web Services subscription models (PaaS). Customers use Kitewalk Web Services to create, complement, extend their own existing solutions, running on their own networks
- Solutions subscriptions (SaaS). Customers delegate to Kitewalk the complete implementation of their new geo-intelligent software solutions
- Kitewalk-embedded (IaaS). Customers OEM Kitewalk technology to install and manage Kitewalk platform inside their own private clouds / networks for their own business purposes
Comments
Post a Comment