When selling applications to new prospects, or enhancements to existing sites, I encourage sales people and technicians to speak about user and license counts in more general terms, emphasizing site-specific ratios rather than actually quoting numbers. If the numbers change after installation you’ll have a credibility issue. Once a client/prospect understands the factors involved they may start asking what your application-specific ratio guidelines are for specific modules. As in “how many licenses might an optimized site need to run 50 users on module X and 100 users on module Y?” Now this is a great question that can only be answered by someone who has seen the application performing in the field. Software developers would do well to embed logging into their application so that they can derive such metrics to answer these tough but valid questions.
So that ever-present "how many and how much" question can’t really be answered up front. (Sorry Sales guys.) During the sales cycle you may have no idea what kind of hardware will be used and there might already be issues on the server(s) which will affect the actual performance. (This is actually an opportunity for a performance review.) You don’t want to quote numbers without knowing the deployment topology, and then find after deployment that inferior hardware is being used with a saturated network and a DBMS that hasn’t been properly administered in years. Sites must start with some number of licenses and then work up to their comfort zone where there is little or no waiting for licenses.
Some sites might not have a problem with occasional periods of high traffic and “passable” performance. Others might insist on best-possible performance at peak times, and acknowledge that they’ll have a lot of unused licenses during off-time. These sites may be very inclined to add new enhancements to take advantage of the unused resources, or to pay for QoS enhancements. The best way to approach this is to understand your own application, gather metrics from existing sites, and use this experience to provide best-guess but realistic estimates which serve as a starting point for discussion and deployment.
Notes (1) Factors affecting web application performance include the following:
Notes (2) How does using less DBMS licenses help the DBMS companies?
Questions often come up about cheating the DBMS companies out of licensing fees. An application vendor with a GUI has a much higher chance of being able to sell software than someone with only a Character User Interface (CUI). If this vendor sells (as a low example) 1 site with 10 licenses in a year then the DBMS company gets revenue for 10 licenses. With a GUI and the economy of license pooling the vendor might be able to sell to 10 sites. The DBMS vendor now has 100 paid licenses rather than 10. It shouldn’t matter if 1000 people are using the software (10sites x 10licenses x 10:1 ratio) – the people who bought this software would not have purchased 1:1 CUI software anyway. Further, larger companies with thousands of users are much more inclined to buy GUI software with high N:1 ratios. These days a vendor has almost zero chance of selling a CUI app to sites like this, but has a very good chance of selling hundreds of licenses for a feature-rich, attractive GUI application. DBMS companies welcome such opportunities for the revenue and for the marketing benefits. So in all of this discussion about increasing users and decreasing licenses, just remember that better and more economical software sells to more sites than inefficient software with high per-user costs. The DBMS companies are still trying to survive with the decades-old per-seat model. We’re keeping them in business by using third-party tools to build infrastructure around them and make their software more marketable without them having to change the model.