True Omni-Commerce with IoT

The changing face of e-commerce means that successfully buying a product is more than just a few clicks away. Today, with the widespread influx of communicative devices and advertisements, the customer is constantly bombarded with advertisements of interest right from the morning tea to the evening commute, everywhere advertisements try to sell different products. However, this might only affect the user decision, which might be in the favor of competitors of the advertiser. So the context of advertisement with respect to the end customer needs to be revised and the user needs to be engaged -  buy the product rather than just influence decision making. SAP Hybris is currently aiming towards creating the online storefront of the future and is tinkering with some of the things that I am discussing- but a lot needs to be done before things are

Internet Of Things

As defined in Wikipedia, "The Internet of Things (IoT) is the network of physical objects or "things" embedded with electronics, software, sensors, and connectivity to enable objects to collect and exchange data."
Smart devices/sensors are already increasing exponentially and are poised to make the next big change in everyday life since the rise of internet and by 2020, only the B2B based such devices would be around 5.4 Billion.

Applied IoT

We've all heard about Amazon drones but the ideas do not stop there; by making a user context aware, the e-commerce can jump out of browser to mobile notifications through NFC enabled portals in physical stores. On the other hand, the user based sensors could be used for kiosks and physical display stores, making them intelligent. Another scenario could be the use of RIFD enabled tags on consumables, which can enable gamification based points for repeating customers, leading to repeated orders. These ideas are dime a dozen, but it remains to be seen which technology and business goes all out to adapt them.

True Omni Commerce

Although this sounds good in theory, in real world things like scalability and security take precedence and instead of just improving the context, there is a need to provide actual sales through these additional channels, or in other words, creating a mashup involving existing channels to generate even more avenues. I am currently working as a Hybris developer and am hoping to see some positive influences due to rise of such a technology, which is currently in the playground stage.

My tryst with Hybris... continued

Rather than making a new post on my thoughts about development over hybris platform, I felt prudent to continue my older post about SAP Hybris and bring out some of the challenges felt and my take on this e-commerce platform.
Currently, I am still a newbie developer working on various features and parts of the platform.
My team is also in the young hybris phase as explained in detailed manner here ( http://time2know.net/young-hybris-partner ) and the knowledge sharing is limited and as frustrating as it seems, the development work is generally slow due to long list of assumptions that hybris platform assumes.

One example is in implementation of AdminCockpit - where all the fields in various editors are laid out in various xml files:

< editor >
    < group qualifier="General" visible="true" initially-opened="true" >
        < label >General< / label >
        < property qualifier="B2BRegistration.title" / >
        < property qualifier="B2BRegistration.name" / >

These files are editable, but changing them yielded nothing - and no suitable help was found in hybris wiki or experts forum. Next , I tried doing ant all and searching for generated files but found nothing of importance. Finally, I tried doing an initialization of cockpit and admin cockpit which made the changes appear - the amount of efforts that I invested were shockingly huge as compared to the actual work needed.
If some hybris expert/creator reads this, I hope my plead for greater technical and functional documentation reaches - debugging without a knowledge of how the APIs function is like learning to swim inside a boat.
Development and trying to appear for hybris certification remain my top priority missions for the coming month and I hope to be a hybris certified developer after then and work on this platform for the near future.

Using Hybris for e-commerce

Recently, I had a chance to work on Hybris, which is a private company (now acquired by SAP) offering an application framework with the same name, which is a customizable platform for handling e-commerce B2B and B2C needs. While I was initially skeptical of the framework in the sense that it is not apparently clear how to create an online store like Magento or Spree, but is much more than a CMS that creates a shopping front-end for the user.
Technically, hybris is a framework built on top of spring that runs on a customized tomcat or SpringSource DM Server and uses maven for build automation. While this architecture is carefully thought out, the problem lies with its openness- the community is quite limited and as learners, we are restricted to the hybris wiki and forums. Given the evolving nature of the application (different versions come frequent and fast), opening it up would make a lot of sense. As SAP recently acquired Hybris, it may provide integration with its tools and databases in future as well as provide forums and community support like other mainstream software.

Coming back to uniqueness in this framework, here are a few notable observations:
Open-Close model: While the software is not open source, the way of creating application on top of framework comes with least surprises and there is a lot of flexibility.
User oriented: Cockpits are specialized interfaces that power users/admins of the software can use to quickly access the information present in their application.
Thought out: Like a matured product, entire gamut of e-commerce application is present and one can not only provide the http based web solution but also plugin with an existing application.
Scalable: As jvm based approach is followed, it is quite scalable - though it requires an upfront resource allocation during development, it sure pays back to ensure the scalability of the website.
Performance: The customization comes at a cost of computing resources, as well as slow/complex process workflows. The overall performance of the application if compared against other ecommerce solutions is worse.
XML based: The configuration is mainly in xml and parts like the UI is built on custom framework, which is pretty restrictive. While these might not be the issues, but they stuck out like a sore thumb to me, which brings us to another conclusion discussed in the next point.
Old standard Architecture: Application development seems archaic on this framework as the choice of the technologies used as well as provided seems to be a decade old - and regardless of the things mentioned on the website, integration with popular technologies is quite hard.

As I continue my exploration into this framework while working on real world projects, the things gained so far would help me to compare this against both open-source and corporate alternatives and enable me to contrast the differences more accurately against each of them.