A big difference for web technology startups that provide services that may have to scale to millions of users versus companies that provide consulting services is that the thought process for designing has to be radically different or you can easily end up failing to solve your customers' problems.
We have firsthand experience in anticipating these kinds of problems as our business straddles both enterprise customers in the Fortune 500 and government worlds to web technology products. In the enterprise world, our focus has to be on technologies that have clear support models and enough market penetration to assure our customers that there will be a long term availability of engineers over years or decades. Rarely do enterprise customers want to be the only ones able to support a given technology. They only want to pick winners with a broad appeal, ironically, especially when their competitors pick them.
This contrasts with the web technology world where we have the ability to select products on the cutting edge and build in-house support if needed. That doesn't mean you want to pick technologies that the IT market is moving away from, but it does mean you can look at a wider range of technologies, many at the beginning of their life cycle. We have to make an analysis on the likelihood that a technology will be supportable either in-house or externally and if the benefits outweigh the costs if we foresee doing most of the support. We can also look at the Open Source world to see what engineers are interested in working on, even when they aren't necessarily being paid. This helps us understand the trends in the technology space in a transparent way and offers a way to contribute back where we feel we can help mature a technology.
Because one of the luxuries of the enterprise market is that you can generally predict the number of active users, picking technologies is more a matter of finding existing solution architectures we have experience with, which may come with a set of components already tested at the active user count we care about. This makes designing systems more about historical knowledge of components and their associated architectures than about pushing the bleeding edge. In fact, years ago I mentioned to a colleague that, generally, in the government space, "boring was good." What I meant was that it's a market in which to use tried and true systems.
However, with a web technology product, you may not know if you have built a product with a small community of users or a huge user base until you launch and get things moving forward. As such, if you try to apply the enterprise model for a web technology product, there is a chance your architecture will hit a massive breaking point. Twitter hit this because they had a growth curve that blew past their architecture (though in this example, their architecture probably did not have the standard enterprise Java/.NET and Oracle model).
One of consequences of thinking about enterprise versus web scale systems is that you have to trade certainty versus scalability. With web scale systems, our experience as of date has been that you have to throw out key concepts in the enterprise realm such as counting on data to rarely have duplicate information and letting components disambiguate data without us having to program software to manage the process.
We also have had to remove the idea that we can be certain when data will be available at the latest value, whereas, in the enterprise world, we typically design systems that have strict control on what data looks like at any moment in time and if something changes under the covers, the components will tell us. Instead, in the web scale architectures, we have to manage data more closely.
If you are a consulting company or a web technology company (or a company like us that works in both spaces), it will makes sense to think in advance about what skills and technologies you will need if want to be successful in your space and not look for one size fits all choices when it comes to your staff or your technologies.
