When is good, good enough? Complex systems are tenously put together, keeping things properly balanced is never easy. This is no less true for computer applications than it is for any other system, in fact given the nature of how applications are built these days, with little or no overseeing of the solution (because individual, isolated, and uncoordinated groups are invovled).

I believe it is probably not feasible to list all of the "moving parts" or components in use at GATE Village, the technology relies upon so many 3rd party pieces like operating systems, networks, power and other infrastructure, to say nothing of the literally hundreds of modules in play on the Drupal system that is known as GATE Village. If you've not thought about it to date, however, consider that a system like GATE Village will have seen literally hundreds of individual designers and countless thousands of individual coders, testers, editors, and even robots involved.

My goal for GATE Village is one of "No Compromises!": the village needs to be easy enough for the novice while powerful enough for the expert. It needs to offer automation so that the difficult (or less well known) tasks can be taken care of yet provide a way out for those who feel comfortable providing their own direction.

Conflicting Requirements

The site needs to be the most functional community building site available (because EXPERTS are our target market) and yet, as the value of the village is for BUSINESS not social media, it has to be able to serve pages at lightening speed to consumers. Unfortunately, those two goals are orthoganal to each other. Every single technology added to the Village that increases functionality has a direct and negative effect on performance. And while Facebook has, I think, taught a new generation that "Google speeds" are not feasible for dynamic sites,
it also comes with VERY big pockets allowing for (expensive) hardware and caching servers to overcome some performance concerns.

Also, sites like Facebook really don't offer a lot of choices to members ... similar to Henry Ford who said "customers can have any colour of car they like, as long as it is black" ... well, members can make Facebook look anyway they like, as long as it adheres to what facebook provides. That is a reasonable position for a free service but it is untenable (in my opinion) for a service you pay a fee to use. So, we find ourselves between the proverbial rock and a hard place, needing to be both fast and super-functional. A challenge that few could master, but one that is right up my alley!

    For better than 10 years I was the de facto 'buck stops here' guy for all things architectural, security, and performance related for what many might claim to be the world leader in Enterprise Content Management...I'll humbly say that I can perform tasks for GATE Village that I spent many an hour convincing customers NOT to do. Why? Well, there are two main reasons:

1. The Business Plan: GATE Village members pay for a service and that service, therefore, can be provisioned with a model that is quite different than a typical internal deployment of an ECM system can be. The latter is almost ALWAYS done to improve ROI and has no charge back to the users ... thus the IT budget always factors strongly into the equation and "performance" only becomes a concern after it becomes a problem. In contrast, GATE Village will likely go out of business if it has any (sustained) performance problems and thus the system design must (and does) take that into account -- performance is managed proactively not reactively.
2. My personal expertise: in computer architecture plays a significant role as does my 10 years experience in ECM. I understand how the various components interact and will work together, often before I even read the documentation. I can, single-handily manage to work with and understand the interactions of hundreds of modules ... and while complete and perfect interaction with no errors is not even a reasonable goal, I am comfortable knowing that I can and will find & fix any issues that do appear. (And let me tell you that with over 380 modules installed on the system, each with their own development cycle, there are issues to deal with!).

I certainly do not expect that these two reasons alone are going to allow GATE Village to break every rule and be exempt from performance issues ... the very nature of the Village that encourages inventiveness almost guarantees there will be scaling and performance issues as time moves on. However I am convinced that the basic architecture of Drupal will allow those problems to be solved and the basic business plan of GATE Village will provide sufficient funds to ensure they will get solved.