Dynamics AX: SQL Server Modeling - Formely Code name "Oslo"

Way back when, specifically about a year ago this month, I did a write up on Microsoft Project, code named "Oslo". A direct link to that post can be found here.:
Dynamics AX, SOA and Oslo on the mind...

From that post.:
"in the not to distant future Oslo (along with "Dublin") will be released from Microsoft as live products platforms / services, and they are already in the line up for Microsoft Dynamics AX roadmap.

The reason they are is that Oslo, Dublin and Dynamics AX with the help of SOA will become platforms that work together with the rest of the Microsoft stack, like office, to help deliver to business that make use of the Dynamics AX business platform, create and manage business workflows."

I went on to type.:
"Big deal huh? I mean this is already happenning right with the release of Dynamics AX 2009 and it's use of the .Net 3.5 workflow engine right? Technically the answer is yes. But... (and you knew there was a but) there is a lot of code that goes into these workflows, the designer is a tree down designer, and the flow of these workflows are not very flexible.

Enter WF in .Net 4.0. This will come into play, along with Visio like diagram ability to offer partners and customers to create workflows with greater ease soon, that are more flexible and less code."

Lets continue a little further.:
"A little later, enter Dublin + Oslo (along with the letter "M" [more in a bit about M.]) with WF 4.0 (and beyond) and you have the *desired* goal of creating business process workflows that are managed and created by users, with complex flows and use of logic, with 80%-90% estimated less code than currently exists with workflows in Dynamics AX 2009 and .Net 3.5."

Alright, now lets step back into the present. So a year ago, I was talking about Oslo, M, .Net 4.0 working together with Dynamics AX of the future, for doing basically Model Driven Development / Programming.

As defined by Microsoft's, SQL Server Modeling - Terminology page:

A software design approach that offers the same benefits of data-driven programming, but is generally a richer approach because it works not just from data values, but from model instances. Just as the term model implies more deliberate design than arbitrary data structures do, model-driven programming implies a more conscious use of models over mere data. In this usage, there is a strong implication that models are designed to be shared data structures, and do not result simply to provide an implementation.

So "Oslo" was turned into SQL Server Modeling in Nov. of this past year. Since then all the MSDN pages for Oslo now reference SQL Server Modeling. This is Microsoft's step into true Model Driven Application Design.

We have actually seen some of these basic principals applied with the MVC approach for ASP.Net and general .Net development. Which is: Model-View-Control. Well SQL Server Modeling, along with the technologies that help enable it, like the M language, will be a set of technologies and services that offer the ability for customers and partners to create Applications, Services and software through Model Driven Architectures, and programming.

This is a different way of thinking, than what most OO developers are use to. However, unlike a lot of people I have heard complain about MDA, or Model Driven Architecture. OO abilities, code, and principals can still be used when describing objects. Still the approach for how often, and when used changes when we basically take a step higher. Meaning we allow the code to be more generic and generated at runtime. Less compiling, less deploying, more flexibility, without having to code to gain it.

We have seen steps in this direction, and MDA is nothing new. However how it will be achieved with Microsoft SQL Server Modeling will be for Microsoft Customers, Partners and technologist alike.

So is this important for Dynamics AX? Now that's the question. Recently I had my 500th post, and in that I listed some of the upcoming technical based changes that are coming to Dynamics AX. That post can be found here.: Dynamics AX 6.0 (2011) and 500th Post!

In this post I talked about workflows, and functional consultants having the ability to create processes and process workflows without much code needed or developer help. How do you think this will be achieved?

My educated guess, is that SQL Server Modeling will be a base technology, along with .Net 4.0 Workflow Engine, .Net 4.0, the .Net SQL Server Modeling Class Libraries, etc. Now a full own use of SQL Server Modeling within Dynamics AX might not exist in the next release, but it for sure will be in Dynamics AX 7.0. However 6.0 will have something of these technologies to enable what I was talking about.

So the idea, is going to be that Dynamics AX Processes can be mapped, and modeled by business analysts, functional consultants. Cutting down on development by an estimate (last years blog post) 80-90% in some aspects.

This will offer ease of upgrading, and allow greater flexibility for a customer for his Dynamic business to be enabled and his Dynamics AX ERP will be flexible and dynamic enough to match his on-going business needs.

So for the cool technical stuff. Even if your not a Dynamics AX, or Dynamics Line ERP technical person. Knowing SQL Server Modeling, for custom, enterprise, ISV software development will be a key technology. That means you need to learn "M", and things like having the ability to create a Domain Specific Langauge (DSL).

I talked about this last year, and it's impact on Dynamics AX. Now here it is, and I am willing to bet we will hear about this at Convergence.

I will leave you with the following MSDN links, on SQL Server Modeling. I hope I have you thinking about this, and seeing how this can be used with Dynamics AX, and most likely will be.