2011 is here, and the Clouds are still forming!

Last year, I wrote this article, to kick off 2010.: The Year of the Cloud: How Coming Microsoft Products Will Make Dynamics AX the Basis of New Solutions


In this article from the start of last year, I declared 2010 to be the year of the cloud. After years of talking and Microsoft as well as Google having 2009 filled with beta's and some releases, 2010 can for sure be marked, at least for Microsoft, the Year of the Cloud.

This can also be said, for other companies as well, as for the Microsoft 'All In' marketing tag line, I can bet more partners and customers of Microsoft learned about 'The Cloud' than in any other previous year.

Ending the year, Microsoft taclked the consumer end of the cloud, with commericals showing off Windows Live services and Windows 7 working together.

Also at the end of the year, there was this article wrote, that questions Microsoft's 'All in - bu Dynamics'. The arctile can be found here.:
Microsoft is “All In” for the Cloud, but What About Dynamics?

Also at the end of the year, there was an article by Richard Hunter, who writes at the following location.: A Buyer's Guide to Accounting Software - Online Accounting Software. The article questions Microsoft's 'All in - but Dynamics'. It can be found here.:
Microsoft is “All In” for the Cloud, but What About Dynamics?

In his article, Richard actually does a good job at taking and laying out why Dynamics ERP is not a true cloud solution yet. Such solutions, when looking at ERP, are smaller ones. Lower end ERP solutions, that don't have the deep product level that products like Dynamics AX has.

Also, for example, cloud based solutions like NetSuite, and others, are very scary solutions. What happens if NetSuite, and their *cough* single point of failure goes belly up? They don't pay their bills? Where do you think that customer data will be?

Getting taking out of the leased Datacenter space, and sold! Scary if you ask me for sure!

Beyond that however, and going back to the fact, that those who are demanding cloud based only ERP solutions are smaller shops. So when hunter points to this fact.:

""Most Importantly, if Microsoft did commit to moving Dynamics to the cloud, would the market be ready?""

He goes on, and I agree, to answer with a sure No! And this is the truth. Sure some companies are, but the fact still remains that trust is an issue with the cloud.

Taking to the point of Hunters post, he asked what is our take? Being involved deeply with the Dynamics Community, and have been writing about cloud computing for nearly 5 years now as it relates to AX, I have the following thoughts.:

Microsoft Dynamics ERP will be 100% cloud only, or on premise - and a hybrid mix of those offerings by choice of module.

Attending Convergence 2010 last April, Hal Howard, and Mike E., both stated in the Future on ERP, that Microsoft Dynamics ERP will be developed actually for the Cloud First. Just as Dynamics CRM is now.

What will run on Azure, and therefore take on the benefits of scale, will also run on-premise, or in a hybrid mode.

And that last peice, the hybrid clouds, where some things are on-premise while others are in the cloud, will be the normal selection for most companies that use the cloud and ERP, for the next 2-3 major release cycles of Dynamics.

Within the next 2-3 major releases, I am predicting that you will see a formal plan for Dynamics ERP.

That is a single source code, development, workflow, that takes and offers - depending on size and needs, the best of breed from all the current Dynamics offerings.

I believe deep now as well, that Dynamics AX, being the flagship of the Dynamics ERP brands, will be what Dynamics ERP mostly looks like, when that 2019-2021 release of Dynamics ERP takes place.

So yes, I am putting a year out there.: 2019-2021 Is when I believe that Dynamics ERP will exist.

By this time, what we know of cloud computing will be changed in a dramatic way. What we view the cloud today, is like viewing the internet now, compared to the dial-up days of the 90's.

In this area and realm, we will see were is truely does not matter to the end customer if it's on-premise or not.

Now take a step back and look towards Dynamics AX '6.0' and what we have been publicly told on this blog and other resources by Microsoft Dynamics Team. SOA within Dynamics AX. That means the ability to split out modules, which is a step to take and this module and that module on-premise or not.

The move for the kernel in AX '6.0' to be wrote in IL, or MSIL, which is to say .Net based kernel. This means, running on Azure, or services possibly running on Azure.

Now I am not saying AX 6, is the cloud version of Dynamics AX. That's never been said by anyone I have interview at Microsoft, and I doubt very seriously that will be the case.

Instead, we are seeing a move, along with the some rate of customer or Market readiness, that allows the creation of services in the cloud, that can be used with a Dynamics AX investment. As these Hybrid clouds build out, and the years go on, more and more can live in the cloud, vs. on-premise...

Still, and most important to understand, a choice will exists. Because even when Cloud Computing of the future, in that 2019-2021 time frame arrives, still then there will be plenty of companies that will not use the cloud as much as others.

Even with it's ability to scale, the cloud, like all ways of creating, consuming and serving software and services - has it's pros and cons.

We also must look at a product like Dynamics AX, which sits on the top of the Microsoft stack, and see that it must lag behind Microsoft's move into the cloud. Technologies must be developed, frameworks must exists and be tested, so that when released, a business system, or system of record like Dynamics AX, is released and it works!

When it comes to the CEO, the Product Manager, the Buyer, the CFO. Technology is great, but it better work. If it does not work, or is not trusted... it can be the best, but it will only be the best peice of crap that company will never use.

To finalize, Richard has a timely post, and one that I hope makes everyone question and think. However I do believe we know how this is playing out for Dynamics, and that Microsoft is doing this correctly. Building this out, as the rate the market is ready for it.

"Visit the Dynamics AX Community Page today!"

AIF Services and the .Net BC - Where and When?

One of the sessions I attended at Convergence 2010, was the AXUG Software Architect SIG. The initial coverage post for that session, can be found at the following link.: Coverage of AXUG Software Architect SIG at Convergence 2010

In this, a good bit of topics were on the minds of the people who attended. One of them was around AIF Services and the .Net BC. What a good bit of discussion for this surrounded, was where and when to use either?

As promised in the above post, this is a start into digging deeper into the topics covered during that session. So for this When and Where should AIF Services or .Net BC be used, when connecting into a Dynamics AX instance?

This is a valid question actually, as both offer the ability to interact with Dynamics AX. Both offer different pro's and con's as well.

Lets look at the nature of these two different paths for interacting with Dynamics AX from an outside application, service or other LOB application.

First AIF Services. AIF Services are targeted specific end points for document exchange in and out of Dynamics AX, on a transactional, one off level. These services are generated from an AOT Query element, and make use of Axd* Classes, which in turn AX uses to generate the WCF Services that end up being hosted in IIS.

These are WCF services, and so when consumed by a .Net Application, BizTalk, or other LOB Application, will interact as such. These services represent Dynamics AX "Documents". Which could be reading a customer, a sales order, creating a purchase req, or any custom AIF Service you create.

From looking at past use, and desgined nature of AIF Services, these best serve the one-off, transactional calls. Meaning, if the nature of your integration is calling to create a Sales Order, or lookup a customer, then AIF Services are best suited for this type of interaction. Notice the key on "a" meaning singular interactions, with distinct returned result sets.

Moving on to the .Net BC, it offers a different type of access than the AIF Services. With the .Net BC, you get direct access to AOT objects. So you could in theory, access the Query object that a given AIF Service is created from, directly. Not sure why though, other than to look up information. :-)

With this direct access, that means you have direct access to X++ classes, tables, and business logic directly.

So the nature of the .Net BC, is meant to expose to .Net based code / assemblies, the AOT, for working with the AX AOT objects and business logic, directly from .Net.

AIF Services, there is a layer of Abstraction, and therefore a layer of possible extra validation, and context control over data, that would not actually exists through the .Net BC.

Looking at these two options for working with Dynamics AX, still we have the question of Where and when? Since we have a base understanding of the nature of these two choices, lets move forward in answering this question.

Since AIF Services are meant to act in the "a", singluar transactional nature, consuming a AIF Service is best for when you have calls in the nature and context of creating, reading, updating or deleting (CRUD) data, in the form of "Document" based information. This could include creating a sales order, a purhcase req, looking up information on a item, or a customer.

Comparing AIF Services, to the .Net BC for achieving this same need, I have seen the AIF performs better, and is best suited for this. Also using the AIF for these needs, you end up having that layer of abstraction that enables control of the how data is accessed, and the shaping possibly of that data in a uniformed control fashion.

The other benefit for using AIF Services, is was generated, enables the creation of composite applications, that include AX with an SOA type of architecture in mind.

Moving to the where and when for the .Net BC, lets say you have a need for pushing in a massive amount of data? Or you want direct access to maybe having a complex LOB application workflow, that is deeply tied to the business logic in Dynamics AX, that might actually live in X++, and want to expose and reuse that.

Then .Net BC is best suited for this type of integration, and performs better. It performs best with larger amounts of bulk data, or the need for exposing possibly complex workflows, or deep X++ business logic, or custom X++ business logic, and having that tie in with other LOB applications or Enterprise needs.

I hope the above helps answer some of this, and I welcome any comments from anyone on their own thoughts for this topic.

If we look forward with Dynamics AX, take a look at some of my past post. AX internally even will be making use of AIF Services for "document" level integration and data flow needs. Also AX moving forward is turning into a true Managed Code, at the kernel ERP package. This means tighter integration for the AOT into .Net, in a more native fashion will exists.

That's all for now, but check back soon, and again feel free to leave comments on this topic!

"Visit the Dynamics AX Community Page today!"

Dynamics AX 6, DotNet 4 and the WF Designer

A fellow blogger, Anass, over at AX4All.blogspot.com sent me a recent blog post he did, covering the Channel 9 video of Josh Honeyman (Principle Development lead for Dynamics AX workflow), that walks through the use of .Net 4.0, the Workflow Designer, and how it will be used in Dynamics AX 6.

Anass write up about this video can be found here.: Dynamics AX 6.0 and WF4

The video, can be seen here:


In this video we get to see Dynamics AX 6 in action with the .Net 4.0 Workflow designer being used to help create and manage business process workflows. This is highlighted to help reduce the need for code, and the transition into a more model drive development approach.

I first covered this in the following post.:
Dynamics AX, SOA and Oslo on the mind

" In the very near future, [Dynamics AX] will be improved with .Net 4.0 and WF, along with a new designer for the workflow that will be Visio like. The workflows will be easier to manage and offer more flexibility, with less code."

That was over a year ago that I first wrote about .Net 4.0, WF and the Designer, and how it will change the way Dynamics AX processes are created and controlled, with the goal of less code. That same post also talked about Olso, now SQL Server Modeling.

So we can see all these technologies coming together, and how Microsoft leverages research in other products groups, to help Dynamics AX.

This was actually a big topic at Convergence 2010, how Microsoft Dynamics AX team gets to leverage the research in .Net, Office, SharePoint, SQL Server, and beyond.

The idea, as pointed out, is to make Dynamics AX deployments, use, modifications, upgrades, the entire ownership lifecycle of a Dynamics AX investment, for agile, and bottom line being.: Better, Faster, Cheaper

I would like to thank Anass for the post, and his insight, coverage of this video. This is also a topic well covered in the interview I held with Microsoft's Mike Ehrenberg.: Interview with Microsoft Distinguished Engineer - Mike Ehrenberg


The above is from the video, that is the Business User interface. That is not the developers interface. And it's the out of the box DSL, or Domain Specific Langauge (Ref: SQL Server Modeling).

This is some powerful stuff, and can't wait to see how this speeds up deployments of Dynamics AX 6 and beyond!

That's all for this post, however this still part of the coverage from Convergence, in which I have a lot more to post about, including another interview, focused on Dynamics AX team that I did while at Convergence.

Check back tommorrow, as more great post are coming!

"Visit the Dynamics AX Community Page today!"

SQL Server Modeling - Coming to a Dynamics AX near you!

Last week, I ended my post with an interview with Microsoft DE, Mike Ehrenberg. A direct link to that post can be found here.: Interview with Microsoft Distinguished Engineer - Mike Ehrenberg

There was a lot covered in this interview, and I plan on diving deeper into each section with details, that help fill in the vision and path that was laid out by Mike during that interview.

So with this in mind, I wanted to jump right into the "Oslo", or now know as SQL Server Modeling. I wrote about this topic actually before I had the interview with Mike. I made an educated guess, after reading Mike org. executive insight blog post that SQL Server Modeling would have an impact on Dynamics AX vNext versions to come.

Just to back up a little bit, I first starting writing about, then, Olso in Feb. of 2009. In the following post, Dynamics AX, SOA and Oslo on the mind... , I wrote.:

"In the next release of Dynamics AX (based on current road map) Oslo + Dublin, along with the modeling language "M", yes a new language that we will explore here, will be used by normal super users to create, manage and maintain business work flows and processes, without the need of much coding in X++ or C#."

Now lets fast forward to my next post about Olso, now SQL Server Modelings, SQL Server Modeling - Formely Code name "Oslo"

In that post I list a good amount of helpful links, to help you dig into SQL Server Modeling (SSM), and also stated the following.:

"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... ...I am willing to bet we will hear about this at Convergence."

So the past post I have been doing for over a year, talking about Oslo / SQL Server Modeling, has been correct and verified, as seen in the recent interview with Mike.:

"Yes, definitely. Dynamics AX has always made a big bet on modeling. The metadata accessed through the AOT is a core part of what makes Dynamics AX development highly productive. Our evolution points to more and more done through declarative modeling instead of code – making it both more efficient and more resilient through upgrades over time. In Dynamics AX ‘6’, all of this metadata moves from the file system to the SQL Server database. This is a deployment simplification and one that moves towards the capabilities of SQL Server Modeling – our roadmap and the result of what was “Oslo”."

It makes sense now why one of the reason's MFP's post highlighting the move of the Application Files, to be stored in the database, is taking place.

Like I said, above, this helps verify my educated guesses, and also helps give us direction that SQL Server Modeling is on it's way to Dynamics AX.

So here we are, Convergence just around the cornor, deep into Dynamics AX 2009 and Dynamics AX 2011 set for Q1 release of next year. This means we have roughly 6-8 months to really start looking into what SQL Server Modeling will bring to the Dynamics AX table.

Microsoft's vision for this is it will allow for Domain Specific Languages to be created, and used by Functional Consultants and Business Users to create their processes with. Allowing for a Model Driven approach to the business system development, that would cut out 80-90% of the code that is currently created today.

Does this mean C# or even X++ is going away? No! It's and impossible task to have software, in which zero development takes place. However, with Model Driven development, the business process can be defined, in a Domain Specific Language, that shapes the process and workflows, where the remaining needs are filled in with code at given points in those processes and workflows.

Quote from Mike's responses.:
"Our evolution points to more and more done through declarative modeling instead of code"

To me that statement says a lot. Declarative Modeling instead, or in place of code. This is the direction, and if Dynamics AX is in your future, then Declarative Modeling is in your future with SQL Server Modeling.

I plan on doing a deep dive into all of this. Getting into Domain Specific Languages, M, what SQL Server Modeling will look like, along with the rest of the topics covered in the interview.

That's all for now, but check back soon!




"Visit the Dynamics AX Community Page today!"

Microsoft .Net 4.0 - Parrellel Computing Platform

Recently Microsoft released .Net 4.0 RC, along with Visual Studio 2010 RC. With .Net 4.0, there is a lot of improvements. One of the things I have found very interesting is the move for more native support in managed code to create and make use of parallel computing.

With .Net 4.0, Microsoft has released it's "Parrellel Computing Platform (PCP)".



With this, some very interesting new developments exists, including PLINQ or Parallel LINQ. The following link, is a MSDN resource for samples that can be downloaded and studied for how to make use of the new PCP.: Samples for Parallel Programming with the .NET Framework 4

From the link.:
"The .NET Framework 4 RC (Release Candidate) has been released and is available for download at Microsoft .Net 4.0 Framework Download. .NET 4 includes significant advancements for developers writing parallel and concurrent applications, including Parallel LINQ (PLINQ), the Task Parallel Library (TPL), new thread-safe collections, and a variety of new coordination and synchronization data structures."

Now lets put this into some meaningful scope for Dynamics AX. With Dynamics AX 2009, LINQ was really first being used and introduced, through the use of .Net 3.5 framework with Dynamics AX. This includes the enablement of Reporting Services reports, accessing Dynamics AX data and usage of the .Net BC.

The next release of Dynamics AX 6.0 or Dynamics AX 2011, set to be released now in the Q1 of 2011, will be more and more .Net native and enabled. And in actual it will be .Net native because the kernel of Dynamics AX 6.0 is being recompiled to IL or MSIL, which is what all .Net laungages are compiled down to and executed via the CLR.

With the upcoming Dynamics AX 2011, .Net 4.0 is going to be the .Net Framework of focus and use, and the ability to do Parrellel development in Dynamics AX, custom at that, is going to become more and more a need.

Just go back to a recent post of mine, focusing on Threads in Dynamics AX 2009.: Dynamics AX 2009 - X++ Thread Development

In that post I talk about how Threads can be used in Dynamics AX 2009 today, and give example of how, and what to look for in developing such threads. As we push further and further in Dynamics AX vNext versions, including Dynamics AX 2011, such technologies as .Net 4.0 and the Microsoft Parrellel Computing Platform (PCP), will become ready for use.

This means that the Entity Data Frameworks, LINQ, now PLINQ, and the alike will be possible for use with your given Dynamics AX solutions.

Now lets think about some examples in Parrellel needs? MRP? Forecasting? Data Imports? MDM? CPU, Disk and RAM heavy processes that could be developed with Parrellel Processing at the heart to take full advantage of the hardware of given Dynamics AX instance is on.

Of course this is just scratching the surface of the ability such a platform is going to offer Dynamics AX customers as we move closer and closer to Dynamics AX 6.0 and beyond.

Business needs and processes across multi-sites, locations, timeszones, all the processes that make a business run, will have a new tool to help make those processes possibly run faster, connect faster, interact faster, and overall be faster. (I think I said faster right? ;-) )

I will note that this Parrellel Computing Platform was first really spotted in the Microsoft Robitcs SDK, and that was one of the reasons that SDK got so much attention. Now we have this, and I recommend checking it out, and start thinking in terms of what this will and can offer for Dynamics AX business needs.

That's all for now, but check back as more to come!

Update:
I wanted to give a quick update. After looking at some of the sample applications, I was able to see, that for the babies example, if you have a quad core machine, executing the standard seq. LINQ query, and run a query that takes 5 seconds for example to return.

If you notice only a single core is used for this processing. Now if you run the same query, except it uses PLINQ for example, the same query takes only 1.5 seconds. That's a 70% improvement! And guess what? The code is nearly the same, and same amount of lines.

This is an amazing ability for code performance, and I can't wait to see how this might can be used and affect Dynamics AX 6.0!




"Visit the Dynamics AX Community Page today!"