I’ve always been a little confused about where Data Access fits into the bigger picture of organizational structure. Even when I speak at conferences, nobody knows where to put data access talks. Smart Client? Web Development? Architecture? Database? It covers all of these areas. At DevConnections, the Microsoft talks about the Entity Framework were in the SQL Server track. So basically developers weren’t aware of the talks because the SQL Server schedule was on a different chart than the schedule for ASP Connections and VS Connections.
This is happily fixed for November since we have our very own Data Access track!! I’ll write more about that another time, but you can find the talks listed in both the ASP show and the VS show. 🙂
I also never was really clear on where the ADO.NET Team fit into Microsoft. I know they are in the same building as the SQL Server team. But I always think of ADO.NET being more closely tied with Visual Studio since that’s where I do my data access coding.
In this introductory post for the Astoria Team, Mike Flasko clarifies the relationship, even though he just did so in passing. He refers to the Astoria team as:
part of the “Data Programmability” (DP) team within the SQL Server organization at Microsoft
… “within” …
So, SQL Server owns data access. Interesting. I never really realized that. But it makes sense.
I have always referred to anyone working in data access as the ADO.NET team. That’s wrong. There is a team that is specifically for ADO.NET, but that is within DP. So DP encompasses ADO.NET and Astoria. What else? Digging back to the initial post in the Data Programmability blog (blogs.msdn.com/data), Sam Drucker describes the umbrella of the DP team. Note that this was before Astoria and Jasper so they go under there as well, though Jasper is still an incubator project, not a product.
Sam said (back in June 2006). The highlights are my own so I can count the list.
We have a lot of technologies under our umbrella and no matter what part of the Windows platform you use we’ve got you covered. The team has been building solutions for data programmability for many years, from the early formation of ODBC, the advances of OLEDB, core XML processing support with MSXML, ADO with Visual Basic, TDS and SOAP access to SQL Server, JDBC connectivity, working with Visual Studio on XML editing, XSLT debugging, and of course the new wave of productivity with the .NET Framework with ADO.NET and System.Xml. We also have been a big part of the WinFS project. The main way to get all the details is to visit our MSDN sites: msdn.com/data and msdn.com/xml.
ADO.NET and XML are siblings!
Hey, this is starting to look like the beginnings of one of Roger Jennings’ historical analyses! 🙂
Sign up for my newsletter so you don't miss my conference & Pluralsight course announcements!