Is SQL Server Modeling (nee “Oslo”) only for SQL Server?
When we announced at the components of “Oslo” would ship in a future version of SQL Server, a common question was “Does that mean that I can only use these components with SQL Server?”.
I know it is hard for some people to hear the name “SQL Server” and think anything more than “relational engine”, but it is so much more.
The reality is that SQL Server, for lack of a better brand, is our overall data/information management offering that spans more scenarios than you can shake a stick at.
In addition, this offering is used through the entire Microsoft platform, from Windows, to SharePoint, to System Center, to Dynamics.
If there is data involved, you can bet components of the “SQL Server” are being used.
What does this mean for our modeling technologies? Only good things.
This means that our approach to modeling will get widespread adoption throughout the Microsoft internal and external ecosystem that uses SQL Server.
Want to see an example of an end-to-end scenario?
Go http://microsoftpdc.com/Sessions/KEY01 and jump to 1:57:00 in the presentation.
That is SQL Server Modeling in action.
Visual Studio and System Center working together over a common model (written in “M”) in stored in SQL Server Modeling Services.
This capability will add tremendous value to customers and it is brought to you through SQL Server and our investments in “Oslo”.
Want to see another example?
Go watch the video for The ‘M’-Based System.Identity Model for Accessing Directory Services.
Again, this is going to add tremendous value to customers and it is brought to you through SQL Server and our investments in “Oslo”.
To but a bow on this, go read: Oslo transforms into the underlying application model of the cloud.
At PDC, after I explained the above, most people understood what we were doing with SQL Modeling, but two questions seemed to remain.
First, “How do I use these technologies in my application?”
Second, “This seems like a bunch of Microsoft internal stuff, can I just get the DSL stuff? Oh, and please don’t say SQL Server around me”.
The former question is straightforward to answer.
If you use a database or XML to drive your application, our modeling technologies can help you a great deal.
Most ISVs that we talk with are already “model-driven” using either a database or XML files, but they effectively roll their own modeling platform.
SQL Modeling provides modeling capabilities that these ISVs can leverage, just like Microsoft “ISVs” are doing today.
These same capabilities that make model-driven applications possible, also help with applications that deal with lots of operational data.
This is one of the core reasons that we have brought “M” and EDM together and started to leverage the Entity Framework and Data Services.
You can model your application’s domain in “M” and get a wonderful conceptual model that you program against in VS/.NET.
The latter question is straightforward too.
Ignore the name SQL Server and check out the bits.
If we are doing something stupid and we are blocking you from using the DSL part of “M” in the way you want, send us the feedback.
I think you will find that enabling a DSL ecosystem is an important aspect of what we are trying to do.
“M” is a language for data – and we ship our implementation language with the Microsoft data offering – which for better or worst, we call SQL Server.
Lars is after me to come up with a better name for SQL Server/SQL Azure – which I am working on…
Nice post! I’m happy I waited for PDC before posting myself. I’ll even wait a couple of more days.
This time my goal isn’t to be amoung the first critizising micrsoft, but rater have the highest quality content.
I think “ignore SQL in it and get the bits” is a good advice to the DSL/MDD commnity reading this blog.
And by the time you have a better name, we’re all happy and Oslo will receive the Nobel award in Oslo for bringing peace to the world.
Lars Corneliussen
20 Nov 09 at 23:38
Doug, you say…
“I know it is hard for some people to hear the name “SQL Server” and think anything more than “relational engine”, but it is so much more.”
In the next sentence you call “SQL Server” a brand. Have you listened at all to what people outside the company are telling you? To so many of them the SQL Server ‘brand’ is the “relational engine”. How long do you think it will be, and how much effort do you think it will take, to transform the actual, real-world brand recognition to what you claim it should be? 5 years? 10 years? Do you have any practical plan to do this? Is it something the SQL Server team is investing in? In any case, why do you want to change people’s perception of the brand after so many years? What advantage will it be to you, let alone your customers?
I always believed there were three important constituencies that needed to ‘get’ Oslo for it to be widely accepted. a) ISVs. b) the general development community. c) Microsoft product teams.
So let’s look at what you say and how it applies here…
ISVs? You say “Most ISVs that we talk with are already “model-driven” using either a database or XML files, but they effectively roll their own modeling platform. SQL Modeling provides modeling capabilities that these ISVs can leverage, just like Microsoft “ISVs” are doing today” OK. So, many, many ISVs support the SQL Server database to store and manage data. A smaller number use Analysis Services to store and manage aggregated data. But how many build their products over SQL Server Reporting Services? How many use SQL Server’s analytics models? How many built their products on SQL Server Notification Services before it was pulled. How many built their products on the SQL Server Metadata Repository before that was pulled? How many do you think will build their products on SQL Server Modeling before that is pulled? The SQL Server ‘brand’ has history.
My prediction? You won’t find much interest in the ISV community.
Let’s move on. The .NET development community. They want tools and technologies that make their lives easier. They want the technologies to be ‘part of the platform’, which for them is NOT SQL Server, but rather .NET running on Windows. They want the tools to just be there in Visual Studio. You say ““M” is a language for data – and we ship our implementation language with the Microsoft data offering – which for better or worst, we call SQL Server.” This seems to confirm our worst fears. Yes, you really do foresee that ‘M’ will be tied to the SQL Server license.
My prediction? Developers won’t touch this now.
One constituency to go. Microsoft internal product teams. Frankly I couldn’t care less what internal technologies your product teams use to implement their technologies. That is a matter for them and not for me. I’m a customer (obviously not one of the ones you ‘listened to’, though) and I only care about what they ship. I note that Oslo hasn’t made any obvious impact on the DSL story in Visual Studio, and I also observe your obvious relief at finding some home for yourselves in Microsoft which suggests that you have been struggling with this for some time. Is anyone in Microsoft, beyond your immediate team, really interested in Oslo? I hope so, but I’m not confident.
My prediction? At best, a couple of teams may use Oslo to implement some functionality.
I was so excited by the Oslo vision a year ago. This is me now signing OFF. Best of luck for the future.
jedR
21 Nov 09 at 20:03
@jedR
As I have said previously, SQL Server and lots of our other products provide .NET and VS programmability. Windows does this. SharePoint does this. The list goes on and one.
Just because something ships with SQL Server, does not mean that it is not part of the .NET Framework or available with VS.
As for the licence, we are still working through all that — but we know that broad availablity of developer technologies is important.
I find it interesting that not a single person has cared if we required a Windows or VS licence to use these technologies — which I find strangely ironic — particularly as I know what licencing options are available and the way that most developers get licences to our software.
To add to that, when I say “SQL Server” — I am including “SQL Azure” in that platform — and that further changes the licensing conversation.
Net: If you are worried about licences, I think you are focused on the wrong thing. I encourage folks to get a lot more focused on value these technologies can bring. If you don’t see any value in what we are delivering, regardless of the name & imagined licencing scenarios, I would be a lot more worried.
Lastly, every single one of these comments give me more data in a series of conversations we are having around the name we use for the data/information platform, so I welcome the feedback.
douglasp
22 Nov 09 at 03:53
>> Just because something ships with SQL Server, does not
>> mean that it is not part of the .NET Framework or
>> available with VS.
Doug, do you guys understand anything about software architecture?
You had the choice to embed SQL Server in a modeling platform or embed a modeling platform in SQL Server. There is an obvious rationale for the later, right?
I have a suggestion for a new concept that you could try to push: “Heap-Oriented Architecture”. It seems to be a perfect fit for your product “stack” .
Jean-Jacques Dubray
22 Nov 09 at 18:09
@Jean-Jacques
The .NET Framework is not a platform, it is a development framework for our products, such as Windows, Office, SQL Server, etc.
We had a decision to make on what product we were going to ship our modeling technologies in — Windows, SQL Server, Office, etc.
We selected SQL Server as it is most aligned placed to do it and it used by most of the other products.
That doesn’t mean that is the only place that we are going to ship it — but it is certain where folks are going to see it first.
douglasp
22 Nov 09 at 19:13
@Doug,
.Net developers >>>>>> SQL Server Developer.
Once you tag “SQL Server” in a technology, the number of people that pay attention to it shrinks dramatically.
You must have read the common reactions around the web to the decisions and I bet people are mostly disappointed. That must count for something.
Now that M is relegated to SQL Server, I am waiting what the C# thing is doing with C# 5.0. I heard rumors that they are working having C# compiler as services. They might be finally solve the desire for DSL toolkit in the .Net developer space.
Dody Gunawinata
23 Nov 09 at 16:59
@Dody
It my job to make the value of SQL Server/SQL Azure (the broader data platform) important and meaningful to developers.
That is an uphill journey, but I am committed to getting to the top.
Could you tell me if the DSL functionality that we have in our CTP meet your needs?
If not, what do we need to add in terms of features?
You could watch http://microsoftpdc.com/Sessions/FT34 and tell us if we are missing something you need.
douglasp
23 Nov 09 at 19:11
[...] [Updated: Last follow-up post with pointers to PDC videos] [...]
From “Oslo” to SQL Server Modeling at Douglas Purdy
23 Nov 09 at 23:36
As an ISV the question of runtime license and deployment pre-requisite is extremely mportant to our evaluation of a new technology. We can certainly evaluate the technology on its merits, but if even if we do like it there are considerations for what kind of runtime dependency and licensing we will need to convey to the customers of the apps we may use that technology for. In our case our latest generation of apps depend on SQL Server 2008 so we already have that pre-requisite in place. However, we probably won’t be able to dictate that customers adopt newer SQL Server versions at too fast a pace so going forward our customers will demand that our requirements be ‘SQL 2008 or later’ for the next several years. So if there is something in the licensing/runtime deployment that depends on a later versoin of SQL it will be hard for us to adopt that due to the upgrade requirement it would convey to our customers.
I think a good example of the ideal ship vehicle/runtime requirement for us is how the .Net Sync Framework has been handled. Sure, it is included with the SQL 2008 setup and has tight integration if you are using SQL 2008, but the Sync framework itself is its own redistributable that does not absolutely require SQL 2008. We know that when we take a dependency on Sync Framework its lifecycle does not depend on the relatively mild release pace of the SQL Server product (2-3 years between releases), and we have some confidence that future enhancements to Sync Framework won’t necessarily require us to adopt a future version of SQL Server just to get those enhancements.
It would be useful for me if you could compare and contrast the way that the Sync Framework is being ‘productized/delivered’ with the plans for M, the Repository, and Quadrant. The way I am interpreting your current plans it sounds like these Oslo technologies are closer to Report Services and SSIS (tightly coupled to SQL ship schedule) whereas the Sync Framework is only loosely coupled to the SQL ship schedule. I suspect some of the frustration you are hearing about the tie-in to SQL is from people like me that don’t understand why it has to be such a tight link (or maybe we just are misunderstanding what the link is exactly).
PaulG
26 Nov 09 at 01:18
I’m not sure you need to change the name of SQL Server or even SQL Azure. But it would be nice to have another name for the vision that is Oslo. It’s clear, when looking at all the demos, that where you’re going is much larger than just SQL Server Modeling. The core technology and concepts will be used in other contexts.
It would be nice to have a common name for that broader vision, now that the name Oslo is being retired. It’s not that SQL Server Modeling is a bad name in and of itself, for what it does — but that name can’t carry the banner for what has been and will continue to be the Oslo vision. No one knows what to call it now.
JeffS
8 Dec 09 at 07:13