OK, time to wave the white flag... I'm a former developer, and while it's been over six years since I've written a line a code, I couldn't resist spending an unhealthy amount of time today wading through the 30,000 new pages of APIs and interoperability documentation on the MSDN site.
In particular, I'm looking for solutions to our "Top 5" hitlist of interoperability challenges, as measured by customer feedback during last fall's customer forum series. My fading developer skills must be failing me, or call me an old fogey, because I'm simply not finding what I'm looking for. Rest assured I'm not trying to express skepticism in a back-handed way - Judging from the announcements and resulting coverage, I really believe this is there - or soon will be there. Perhaps it's staring me in the face, but am just not recognizing it. So, a little help, please? If you find it, please reply to this blog or email me directly!
#1. SQLServer internals
Use case: Porting open source applications that used MySQL, PostgreSQL or even Oracle over to SQLServer. Somehow it just doesn't perform as you expect, or may not even work at all. There is tacit knowledge that you lack, regarding parsing/unparsing SQL statements, managing result sets, or whatever, and just reading the driver interface specs isn't helping. You need better understanding of how SQLServer interprets SQL, optimizes for performance and memory management, deals with the network traffic, and so forth. Heck, maybe you have a specialized high-performance app and want to write your own database driver to better manage resource utilization.
#2. Windows desktop protocols
Use case: Internet Explorer runs well on Windows. Very well. Performance, direct use of device drivers and OS libraries, and so forth. You want your own application to enjoy the same level of access, and you don't get it through Visual Studio.
#3. C# Runtime Internals
Use case: There are a lot of custom .Net applications out there, written in C#. Actually, many customers we spoke with have two standard technology stacks, one Java-based and the other Microsoft-based. Inevitably, applications need to be integrated across these two stacks, requiring development of adapters and plug-ins in one or the other environment. Or, one needs to port an application from one to the other - Standard Java to C# (and vice versa) converters exist. However performance is often an issue. Sun has (finally) gone open with its JVM, and even before that, one could license the technology, so that one can understand threading, classloading, garbage collection, and so forth. Would love to find the equivalent for C#.
#4. Sharepoint data structures and storage
Use case: Of course, it's been possible to share data with Sharepoint in a loosely-coupled way for some time, e.g. WebDAV and web services. However we are seeing higher and higher load applications that store and update vast quantities of data, both structured and unstructured, often with high concurrency. We are also seeing many different kinds of applications using Sharepoint as a back-end - Wikis, blogs, customer records, email, document storage, all banging against the same Sharepoint instance. Similar to the SQLServer issue above, at some point you need to tune for performance or create policies regarding what kinds of data can be shared when, and this requires lots of tacit knowledge regarding Sharepoint's internal behavior.
#5. Plug-ins for Granular Data Access in Office
Use case: It's surprising how much business-critical data is stored in Excel, Access, and other Office products these days. As an example, I once encountered a billion-dollar-per-year manufacturing company that did its MRP and closed its books entirely in Excel - No kidding! This is an extreme example, and in many cases, a forklift operation to a more scalable business application isn't necessary. However integrating into that data often is. Import/export, or "Save As..." isn't practical, and you really want to avoid DLL hell. What's needed is simple real-time programmatic access to individual data points, wherever and however they may be stored. Again, the same issues of performance tuning some into play as well.
Anyhow, these are one former developer's "Top 5", and yours may differ. But a little help is more than welcome!
