Things you need to consider before initiating your social commerce project
Project initiation is one of the key phases in the project’s life cycle which if done in the right manner will help to reduce the overall time and cost of the project considerably. I would like to share some of the learnings achieved through key decision making during the project initiation phase of a recent B2B social commerce project.
Background
Typical of projects we do at Kuliza, this project too had quite an aggressive deadline and features to the likes of Ebay and Amazon. Unknown technologies in an unknown domain with unrealistic deadlines quite obviously a lot of nigh-outs, felt just like home for us. The project was very challenging since it had a lot of use cases on store management and workflow management with integrations with web services from who’s who of online payment and shipping industry. Time to market was the key for the client .We soon realized that to build project of this complexity with such time constraints we would need a very strong core capable of having a robust workflow management and being able to integrate with a lot of third party modules.
Here are some of the key things to remember when it comes to project initiation for social commerce tools and platforms:
- Avoid dwelling on an alien land
We had to evaluate a first attempt at implementing the project from another company. We had to see if we could salvage some of the code to reduce our implementation time. We came to the decision that we would not be able to leverage much due to the poor standards and architecture employed.
The conclusion was that using this code would only add to the long list of unknowns we already had. Criteria used to evaluate were coding standards, ability to integrate with third party modules, scalability of existing architecture.
- Build a strong workflow management (for your social commerce platform)
In order to build a robust engine to drive workflow we needed a good eCommerce platform. After evaluating some B2C implementations we concluded that Ubercart would ideally serve our purpose.
There were a couple of criteria that we kept in mind for choosing the right ecommerce platform. We wanted the platform’s architecture to be flexible enough for us to use it as a development framework rather than a out of box solution, that the framework had the right coding standards employed, availability of third party modules for integration and overhead in understanding and modifying Ubercart to implement custom use cases.
- Choosing the right CMS framework (to build your social commerce site)
The framework of our choice –Drupal, was primarily a CMS. Hence some of its core concepts like content types, cck etc were written from a CMS perspective. While implementing these data models seemed to be an easier approach and conforming to Drupal’s standards, we felt the architecture of content types and cck were very inefficient and inflexible for customization. These models were written with an intent that anybody interested in CMS need not have to code to achieve simple data structures.
Criteria used to evaluate these modules were scalability of application, flexibility offered by these models for customization, third party modules which would directly integrate with these modules. Based on these criteria’s we decided to employ data models like content types and cck selectively wherever the use cases were typical of CMS.
- Getting the application security right
User access framework was one of the basic building blocks needed for the project. The access framework had to be robust and flexible to accommodate a hierarchical set of access rules based on organization roles, membership levels and organization status. We decided to modify the access framework offered by Drupal which was primarily built for individual users rather than for organizations. This approach was taken against implementing from scratch because Drupal’s access framework was already being employed by Ubercart and a number of other Drupal’s core modules. This meant that we could leverage the access enforcement from it reducing our implementation time significantly.
Criteria used were ease of modifying existing framework, access enforcement effort, effects of custom access framework on Ubercart and on core Drupal modules.
The decisions that we took during the initiation of the project have helped reduce the overall development effort and time and have also helped to us to build a strong core. The important learnings have been to objectively establish criteria to be considered to make decisions and leverage available options effectively to achieve the objectives.
