A one-size fits-all solution for an enterprise E-commerce solution

Today enterprises have different models to choose from when it comes to implementing e-commerce solutions. The choices vary from a buy model, a build model, a hosted build model or an SaaS model, better know as a software service model. For small to medium sized organizations, and for non-profit organizations the choices are quite often more limited to either an open source hosted model or an fits-all SaaS solution.

I will elaborate on each of these models and develop their pros and cons, and also develop the levels of skills you need within the enterprise to implement these delivery models.

When you are evaluating models and vendors within the different models, it is important to first have a solid look at your requirements, your budget, the level of risk you want to take and also your IT skills altogether.

It is also in a first instance more important to evaluate what model is best suited for your enterprise or organization, and then choose a suitable vendor within this model, and surely not the way around.

I will cover 4 delivery models and elaborate on their pros and cons:

The first delivery model is the buy model, whereas the customer is actually buying an e-commerce software and buying the licensed software that goes with it.

A licensed software is usually Feature-rich, is robust and well tested and has some pre built integration tools available. There is a continuous investment done by the vendor on new features and enhancements, although they might come at a steep additional cost to the purchase price.

Your time to market will be relatively slow, but faster then the build model, which will be discussed later. Most likely there will be sufficient system integrators and developers available to help you with all integrations with needed with internal systems.

On the negative site of the buying model, you have:

• the difficulty of choosing the right product for your requirements. Quite often you end up with a software that you only use half of a quarter, but you of course pay for the entire application

• most of the software's are stand alone and difficult to integrate with existing systems

• future enhancements and updates might not be useful for your particular needs

• it will always be an expensive solution compared to the hosted or SaaS solutions

• the IT skills required to implement the solution might not be in house, so your cost will be augmented

• your switching cost is very high, so your risk will be higher then with other models

• and last this is not a fits-all solution as you will need to host the software in your own or in a hosted data center.

The second delivery model is the build model, whereas the customer is building its own e-commerce application in-house and integrating this with the existing ERM, CRM and other applications.

In favor of this model are: you can build exactly what you need, you can take full advantage of your internal systems and your internal IT competencies, you can be unique in the marketplace with a unique solution, and you can tie all your e-commerce channels to market together in one system that fits it all for you.

The minors of this model are:

• it's a risky and expensive model, which is using highly competent and skilled staff at a high opportunity cost and with a risk of losing these assets to companies for which IT is a core competency, not an add-on business.

• Time to market can be long and even too long as you want to build a completely integrated and unique system

• cost of maintenance and upgrade could be become prohibitive, as you need to employ the same skilled people as the ones who build the system

• build solution can become obsolete, technology wise as the project needs to stick to its technology choices for too long to justify a return on investment

The third delivery model is a platform model, that is a kind of hybrid between buying a software license and building an own platform. This is the open source world, whereby there is a platform that can be designed and enhanced by an internal IT team, system integrators or vendors that are familiar with the open source platform. The source code is available, API are developed and services are to a certain extend reusable and you have a community of developers readily available to give you a hand. There is the flexibility of ready made volumes that if needed can be adapted to your needs, and existing applications can be integrated more easily then within the build model.

Although this model is relatively risk free and easy to control budget wise, it still requires a solid IT skills sets, ideally internally or sourced through a vendor that has good knowledge of the open source platform and the internal e-commerce requirements. It will overall cost more time to implement then a straightforward SaaS model, described hereafter.

The fourth and by far the model that has the most appeal and traction lately is the SaaS model, whereby the E-commerce application is sold as a service and whereby the software is provided to you as a one-size fit-all solution.

There is first no customization needed, as everything is out-of-the-box and all data input can be done via a standard browser and Internet connection.

Your time to market can be counted in days, not weeks and certainly not months. Whatever your input is, can be in your e-commerce application almost immediately.

There is literally no upfront cost and there is no scaling issue, as the application will scale with the growth of your e-commerce application.

Updates and upgrades are part of the contract and included in the monthly or yearly service fee, so no extra hidden cost for that.

There is no hardware investment needed, as the service is hosted on the servers of the software vendor.

And most importantly, you do need to have an IT staff to run your e-commerce application, you can leave it in the hands of the business people making commercial decision, not technical decisions.

There are very few negatives for the SaaS model, but a few objections could come from:

• customers that have security issues as they share a platform with other customers

• the pace of innovation and new features that is not fitting with certain customer's requirements

• difficulty of integration, although the application can sit alongside other web applications.