When a new version of one of my favorite products ships, one of the first things I do is open the online help and read "What's New in This Release." I usually look at the new features from two levels. First, I don't install much software that I don't use, so I'm always keen to see what the new features can do to make my life better, my time more productive, my computer faster, my kids behave better, and so forth.
(You can read more about my first impressions of SQL Server 2008 R2 at https://www.dbta.com/Articles/Columns/SQL-Server-Drill-Down/A-Look-at-Upcoming-Enhancements-in-SQL-Server-2008-R2-55131.aspx. To read about the new features in R2 directly from Microsoft, go to http://www.microsoft.com/sqlserver/2008/en/us/r2.aspx.)
I also like to look at a product's new features from another perspective, analyzing them as major drivers for new licenses and, hence, market growth and profits. In other words, why would Microsoft (or any software manufacturer) spend a lot of time and money building a new feature if it didn't improve their prospects for selling more licenses?
Mainstream Features to Fringe Features to Anti-features
Many new features in R2 simply make the product better. For example, the new multi-server management features make perfect sense. With the number of instances a typical SQL Server DBA has to administer, any new capabilities for multi-server management are most welcome.
Similarly, support for hardware enhancements is logical because hardware has scaled so high on every front in the latest designs. Geospatial features, long extant in competing products, also make sense in our increasingly connected, socially networked world. Likewise, the features of PowerPivot open up the world of Business Intelligence (BI) to hundreds of thousands - if not millions - of Excel users around the word.
Adding features like these makes perfect sense because a vast number of users can immediately take advantage of the offering. A few features fall into the middle ground - they make sense for certain niche cases, but don't have broad appeal. Good examples are Master Data Management (MDM) and SteamInsight. MDM enables enterprises to keep one centralized data hub, against which all other taxonomically related data can be verified. It typically is only used by large enterprises with mature data management infrastructure and strong BI investment. So, for approximately 5 percent of the overall market, it's a very important feature.
StreamInsight, which is similar in its overall reach in the market, enables the user to process a continuous deluge of data as it streams into the database, without first saving the stream to a database. That means users can act rapidly upon incoming data without any of the overhead of a standard transactional RDBMS. Again, StreamInsight appears useful for certain large IT customers, but the average IT shop has no need for it today, or any time soon. In short, deep pockets drive the middle ground features.
Following middle ground features are fringe features, some of which make little sense at face value. Hierarchy ID data types, used only by SQL Server trainers and writers, are an example. I frequently ask myself whether a feature that's not quite useful today is actually a down payment on something much bigger for the future because, in many situations, what appears to be a fringe feature with minimal utility turns out to be essential plumbing for version X, expected N years in the future. Fringe features frequently are a hedge against futures, whether that's planned new technology, a buffer against competition or simply a way to determine where customers want the product to move.
Anti-features (my own term) are features or ideas found elsewhere, which are conspicuous by their absence. When you examine a product for its gaps, you also get a good idea what features and priorities are at the top of a vendor's pecking order. For example, as the author of "SQL in a Nutshell" (O'Reilly & Associates), I know that SQL Server lags somewhat behind other DBMSs in terms of ANSI SQL compliance, but is light years ahead in management tools and developer integration. So, you can reasonably guess the company prioritizes writing applications and managing the servers above overall interoperability or transportable code. (Not a bad strategy, in my opinion.)
What do you think? Have I missed the mark or have I helped explain why some features ship today, but others features (possibly your favorites) languish? I'd love to hear your feedback here, or at my personal website, http://KevinEKline.com. Please feel free to also follow me at http://twitter.com/KEKline.