Background
We are a B2B company with no in-house developers. We're current outsourcing all our development work to a small software company. They've built their own custom CMS, which we are using.
At the moment, we're in a redesign phase where a new website is being build by this same software company, again tailored to work with their custom build CMS.
At the same time, we are planning to have a webshop, which is going to be built by a different company, a big E-Commerce software company.
What we need
In the end it should be one website, on the same domain. Where content and commerce should go hand in hand. Everything should be seamlessly integrated with each other, for example the search function (they both offer their own search engine), content and products.
Wouldn't it make more sense to let one company build everything instead of two different companies? What are plus or downsides to work with one or two companies in this case? Where could it go wrong?
I'm a bit scared when we work with two partners, that the total cost of ownership is going to rise to the moon. That it will bring a lot of inefficiencies with it and we're hindered when it comes to further scaling.
P.S. I'm not a final decision maker within this company, but I'm looking for input in order to change the current plan (which is working with two partners).
An interesting scenario that you are in here.
Wouldn't it make more sense to let one company build everything instead of two different companies?
Based on your description there is nothing in this that is particularly out of the ordinary. A website for your company with an online shop. There is no good reason why you need two contractors. What I mean here, is that there is no reason why one company cannot provide the expertise to deliver both parts. Adding a second company / contractor will add more complexity to the situation and therefore breaks the generally good rule of keep it simple. (More on this later).
What are plus or downsides to work with one or two companies in this case?
The positive of working with two companies is that you can get experts in the different areas. For example if company A is an expert in one part of the solution and company B is an expert in another you get the combined expertise. However, in this case there doesn't seem to be a need for this.
Where could it go wrong?
This is very much the downside of having two companies working on this. The two companies will need to work together to provide the solution. This is likely to require some management from you (or your company) which you correctly identify the cost of ownership can significantly increase. You run the risk of both of your contractors pointing the finger at each other when things go wrong.
I would strongly recommend at least considering using a single company for the whole project delivering a combined website and online shop.
Related
I'm searching for a shopping cart or web store framework that supports multiple vendors.
There are many, many shopping cart frameworks out there: that page lists couple of hundred. In spite of the comparisons on that page, supporting multiple vendors isn't a comparison item, probably because it's a rare requirement. Separate to that page I have evaluated a few of what appear to be the top frameworks, and none that I evaluated supported this feature. Which carts would you recommend?
Commercial is okay, although I would prefer open source.
Platform (Windows, Linux, ASP.Net, PHP, Ruby... Minix, Fortran... :)) doesn't matter.
A system
where I manually add vendors who request it (instead of them freely
being able to sign up) is also okay, if there's a store where that's
possible but freely joining up isn't built in yet.
Rationale: I'd like to create an app-store like website. "App store" is a close analogy: it won't sell apps, but it will sell digital goods and I'd like anyone to be able to sell their item on the store. It's this second requirement, multiple vendors selling through the store, that I'm finding hard to satisfy.
I've used multiple shopping cart frameworks (a lot of them broken), and my favorite (which just so happens to support multiple vendors) is PrestaShop. It's free, open source, and suppports all that you asked for. Is this the framework you were looking for?
-JXP
The Wikipedia page you cited lists multiple vendor support as a column in Other Features, along with features that are pertinent to your search.
This question otherwise requires domain knowledge and likely requires multiple answers. The best I can do is offer the bounded set of software that competes directly within this space, at least according to Wikipedia.
The easiest solution for achieving your stated goal of allowing multiple people to sell on your site while exercising fine-grained control of who can and cannot do so is perhaps using WPMU's MarketPress in tandem with BuddyPress or WordPress Multisite. I'm not a die-hard fan of WordPress, per se, but that might be an expedient way for you to get to a minimal viable product and to validate your idea before shelling out the time and/or cash to custom build it from the ground up, and/or labor ad nauseam with tweaking an existing framework. MarketPress is a good plug-in that'll give you many of the features of a full-fledged e-commerce framework... BuddyPress, of course, will allow you to set up individual vendor's with their own sites under your brand. The two work together. More on MarketPress at:
http://premium.wpmudev.org/project/e-commerce/installation/
Another alternative is Jimdo's PagePartners. I haven't used it, but it looks intriguing. I like their design sensibilities, and their stated business ethos. This might be a viable option, too. The caveat being: it's not white label. More info about Jimdo's PagePartners here:
http://www.jimdo.com/pagepartner/faq/
Finally, another interesting CMS to explore is SetSeed. I think it'll allow you to launch multiple sites for each vendor via a central hub you control, and will allow you to maintain your branding within each. How, the,n any sort of renumeration would flow back to you for setting up an individual vendor's store would be up to you to figure out... This is a fairly new CMS and it looks like it's evolving smartly and rapidly. If you require some customization of it, to approach more specifically what you ask for, now might be a good time to reach out to the developer...but you might be able to think of an effective way to adapt it for your use right out of the box.
http://setseed.com/multi-site-cms/setseed-hub/
Unfortunately, none of the above is open-source--but, again, the ease by which you could get to a functional site approximating your idea may off-set that drawback. Jimdo is an open-source contributor, however. So, maybe even an e-mail to them might be a fruitful dialogue to begin. If anything, check out each of the above, and it may influence how you search for other solutions, and will at least provide some models in your own thinking or with other developers. The shopping cart is an integrated feature, I believe, in all of the above cases. With regard to giving your vendors the capacity to deliver digital goods (e-books, mp3s, etc.), check out Fetchapp.com. Very cool app. Very easy to set-up...could probably be rolled into one of the above frameworks. The frameworks would handle the issue of individual vendor profiles and/or sub-domains.
I'm currently working with a tool that over the years has evolved naturally from a number of perl scripts accessed through an apache web server, to a huge collection of tools using a common database and web site (still running apache, but using catalyst instead of CGI).
The problem we're having is that different departments have done local branches from the common main branch for implementing their own new functionality and adaptations.
We're now charged with the task of deciding how a common platform can be made available where certain base functionality is made one track instead of having all these different branches.
These kind of problems must spring up all the time so I'm hoping someone have a good strategy to offer as to how we should continue from here. Any thoughts would be appreciated.
In general, make sure you have buy in from everybody involved. Trying to do this kind of project without having people on board will just make your life more difficult.
Look for the quick wins. What functionality, if it changed, would have the fastest and clearest beneficial effect across all departments. If it takes you three months to get some good out of it, people won't rate the good results very highly.
Break functionality down as far as you can. One of the biggest problems in forked legacy systems is that a seemingly innocuous change in one place can have huge ramifications elsewhere because of the assumptions made about state. Isolating state in different features should help you out there.
At this point we are developing Sitecore websites and we are gaining experience every day. This means that we know how to adjust our approach to different types of customers and that we are able to build our applications quicker every project we do. Of course Sitecore is not the only W-CMS around and we have looked into other W-CMS's.
What are the pro's and the con's for a company to offer solutions in different types of CMS's and what would this mean for the programmers that are working with this CMS?
Would a choice to offer solutions in more CMS's automatically mean that the global experience per CMS will shrink relative?
Hope there are some people around with experience in multiple big W-CMS's (Sitecore, KEntico, EPIServer, etc.. etc..).
If you truly enjoy working with Sitecore than maybe consider Umbraco. Umbraco is very similar to Sitecore and cheaper (I believe former Sitecore employees may even work there). It might be nice to offer a high-priced CMS (SC) and a less expensive alternative also built on .NET (Umbraco). I would say don't try to support tons of CMS's since there are so many. Keep a focus on a select few. Maybe consider selecting others based on the market for them and how their partner programs work (i.e. like Sitecore will recommend you as a solution partner and help you with sales).
Are you prepared to keep your programmers skills on top of each of the different CMS solutions you'd offer? That can be a high cost if you offer a number of different solutions based on different platforms,e.g. if you have programmers that have to know C#, Java and PHP because in this is what the various CMS support development be done. Thus, you may want to stick to .Net CMS rather than go venturing too far into a different stack as that can carry the challenge of maintaining skills.
Basically my project is product based.
Once we developed a project and catch the multiple client and deploy the application based on their needs.
But We decided to put the new features and project dependent modules are as component.
Now my application got many number of customer.
Every customer needs a different features based on the component.
But we have centralized component for all client . we move the components additional feature to client specific folder and deploy.
My problem is , I am unable maintain the components features for multiple client.
My component feature code is increased and I am unable to track the client features.
Is there any solution for maintaining the multiple component features for multiple client ?
I've worked for a couple of companies in a similar space - product software but very heavily customised.
Essentially there is a decision the company needs to make - are you a product company (that is you ship broadly the same to every client) or are you a bespoke company. At the moment it sounds like they're between two stools and wanting the economies of being a product company with the ability to meet specific client demands the way a bespoke software company can.
Assuming the company wants to be a product software company, unless there are specific technical reasons why you can't, you need to move to a single code base with the modifications for each customer being handled through customisable options (i.e. flags saying how this particular situation is being handled, whether this feature is available and so on).
These can be set at run time (so they can be changed as the client wants - think options in Word or Excel), or build time (so code is included / excluded when you do the build), but the key things is that every client has to be pulled from the same code base.
But this needs to be agreed with the business as it limits what they can sell - every change they sell has to fit into an overall vision which can be accommodated by the single product.
The alternative is that you're essentially producing bespoke software for each client (that is coded specifically for what they want) but using many common libraries. That's fine and allows you to produce something which is exactly what they want but in the end it is going to be more work and the business needs to understand and cost for that.
We actually do a bit of both - there is a server product which is identical for all clients, and then web and mobile clients which are specific to them (in the case of mobile you can't have lots of dead code on the device - the web stuff is historic and will be moving to a standard product for all clients).
Good luck though, it's a difficult problem with no easy solution.
You are essentially talking about software product lines (SPLs): variations from a common base. Since you already package your features as components, you need a specialized tool to manage such variations.
You can then build a complete custom application based on a configuration that is unique to any given customer. Easier said than done, of course.
A model-driven software development(MDSD) approach can help a lot on this task. One such system that can support this development setup is ABSE, an emerging MDSD approach that among other things, can implement a software product line (info at http://www.abse.info - Disclaimer: I am the ABSE project lead). There is no product yet though. An alpha preview is coming.
Again, I know some companies that, using an MDSD coupled with code generation, have achieved what I understand you want: products that are half pre-packaged, half custom.
I was trying to analyze the trend about companies leaving their own custom built solution in favor of the standard CMS solutions such as Drupal, Joomla and DotNetNuke etc. While I can find many stories about medium and large organizations leaving their custom solution for Drupal/Joomla etc, I cannot find any reference where organizations are leaving prebuilt CMS's/Frameworks to go custom again. Is this not happening at all or it's just a matter of not being properly documented?
Thank you.
Imran.
I can't think of a situation where a company has abandoned an in-house developed CMS in favor of re-developing a CMS on their own.
Everything I'm familiar with involves leaving a hand rolled CMS solution in favor of a commercial/open source solution.
Well i can imagine that while most companies prefer homebrewn solutions for some of them or in certain scenario's an open source or commercial alternative might fill their needs.
In case we at our work need to set up a blog we'll most likely choose wordpress, we know it, it does what it needs to do and does it good. Customization isn't a big deal but out of the box it works too.
For larger projects we always use our own CSM built with our own framework, that is what we know best.
So to answer your question, I still have to see the first company going from existing CMS to custom built but i'm fairly certain there are alot doing both.
Looking at it just from an engineering standpoint -- a commercial CMS company, with 50 full time engineers, puts in about 100k hours of engineering effort annually into managing and developing products. A homegrown solution typically has a small team of engineers assigned to manage and develop it, often also balancing other projects & responsibilities. Let's say the homegrown solution has a team of 4 people, working part time (20 hours) a week, which is about 4k hours annually into managing and developing the product.
That's 100k vs 4k hours of engineering in 1 year.
Also consider, for the homegrown solution, most of the first year's 4k hours will be spent recreating basic content management that has been written 100 times over, e.g. permissioning, workflow, approval processes, etc.
From a business standpoint, businesses want to focus on their core competencies. Unless your core competency is content management, makes no sense to build a homegrown CMS from scratch, and companies largely are not doing this, or moving away from them if they have in the past.