Blog

It has been a while since I was here, and I will not try to make any excuses. I could say that I have been busy (which would be true), and that I have a family that I love spending my time with (which would also be true), but true reason is the one you all know: I have been lazy.

Last time I promised to say a word or two about convergence once. Let me do it this once.

What is convergence when we speak about Microsoft Dynamics? To put it simply, it is Microsoft’s strategy to direct the development of every single version of separate Microsoft Dynamics products (AX, GP, SL and NAV) towards a single product, containining all of the functionality of previous systems.

The convergence plan goes in several steps. First step has already occurred, and it was the re-branding itself. What Microsoft has achieved with this is a creation of a very strong brand, with a solid customer base. By very strong brand I mean a single name for a line of separate products, which are now far more readily recognized as a single brand.

During Microsoft Business Solutions era, all that was available was a suite of different products covering similar business needs. Not only each of the product was different in name and functionality, they were all completely different in the terms of technology. Each of them had its own development environment, totally different from every other, none of them on .NET, and data engines, relational models and architectures were light years apart.

Apart from technology, there were market problems. Not all MBS products were offered in all markets. Where they were, it was a nightmare for customers to choose the right one. As each MBS product was technologically completely different from all the others, the expertise required to implement these solutions was also very different, and most implementing partners had expertise only in one of the products. This could result in different Microsoft partners approaching the same customer with several totally different solutions. This was confusing, and repelled customers, instead of attracting them.

There was a light at the end of the tunnel, though, and it was called Project Green. At that time, it was only a barely know cryptic term describing something which nobody really knew what it was all about. It was suspected that this would be a product which would replace all others, that would be based on a revolutionary technology yet to be seen, and would have all the best from each of the products. How exactly? That was a million dollar question. At least for the general public. But Microsoft knew.

With advent of Microsoft Dynamics the things have finally been made clear. What has been known as Project Green has now gotten its full and final name, but there was more. The whole strategy has been made public, and it was now know how exactly Microsoft is going to converge all those different products into a single one, yet maintaining (or at least targetting to maintain) the customer base.

What most of the people I’ve talked to fear, however, is the future. Customers like to keep their investments safe, and have them bring the return, and it is something you can hardly expect from an ever-changing product line. With a strategy that says that all of the products in the line will be replaced with a single product in the future, and given that these products currently have almost nothing in common but the name and purpose, those who fear, fear rightfully. Or do they?

The single most scary thing with the fact that all of these products will once become one is the prospect of having to change current systems. The fact is, however, that companies change their information systems every few years anyway. They start with a simple accounting package, which allows them to grow. Then they grow. Then they need something bigger. Then they implement an ERP. Then they need bigger ERP, and so on. So, they do change, and what they mostly do is change between vendors, which usually means change of platform, and considerable investments in terms of infrastructure, hardware and licensing, plus learning and adapting to the new system. Migrating from anything to SAP, for example, may take few years, cost millions and have every single user change his ways upside down. Not an insignificant change, if you ask me. Yet companies do this all the time. On the other hand, changes within a vendor, are normally much easier to handle, because sometimes most of infrastructure can be kept, license upgrade costs are much lower than purchasing new software, and users normally don’t have to change their habits too much.

Whatever Microsoft Dynamics will look like in the future, worst case scenario will be that it will be a typical cross-platform system migration, where new system is implemented, and the old one is completely replaced. If this will be necessary, because of technology differences, one component still remains the same, and it is the most important one from the ROI perspective: user interface. So far, Microsoft has made it perfectly clear, not only in theory, but also in practice, that user interface is going to be the same for all the products even before the final convergence occurs. NAV, GP, AX and SL already have interfaces extremely similar to each other, with new versions promising even more similarities. Whatever the technology lies beneath, users aren’t really working with technology, they are working through it. Therefore, if the user interface is the same, users can work and be productive no matter which Dynamics flavor runs underneath, which is extremely important from investment perspective: users don’t have any learning curve whatsoever to adapt to the new system. They can start using it productively from day one, which spells faster and certain ROI. And this is the worst case scenario. Let’s have a look at better ones.

More likely scenario is already happening. In a year or so, Microsoft is going to publish Microsoft Dynamics NAV 5.1, minor version by number, but nothing short of a revolution from convergence perspective. While previous releases of NAV, and other products as well, were mere functionality and look-and-feel upgrade over existing technology and architecture, Microsoft Dynamics NAV 5.1 will come completely rearchitectured. Instead of a fat-client two-tier architecture we have been used to with NAV since the dynosaurs, it will finally come as a SOA, with user interface completely stripped-off of all business logic, which will be moved to a middle, web-service based layer. This middle tier will run the logic previously contained in the NAV client, and will communicate with the database. If NAV has made something good in the past, it was clear separation of business and database layers, and that’s something that will stay that way. So, new architecture will look like this: a thin client (although not as thin as it can get), connecting to a web-services tier, connecting to the database. Since the client consumes the web services, and as long as web services consumed follow the same standards, what will soon be NAV 5.1 middle tier may as well be AX, or SL, or GP, what basically means that when AX, and SL and GP are next upgraded, their user interface will be exactly the same user interface as that of NAV, only the underlying technology will be different, and users won’t feel it at all. From user perspective – there is no difference. Now, how difficult can it be, and how big an impact on upgrade will it have, to migrate a middle web-services and bottom database tiers from NAV 5.1 to full-blooded Microsoft Dynamics in a few years? From user perspective – it is almost no change, and the only change most users will feel will be seing outside guys spending a month or two with the inside IT guys discussing some databases and servers and mumbo-jumbo. Then one Monday they will be gone, and the system will display a new logo. That’s the best case scenario, and as of now, one more likely.

I am not trying to deny the fact that there will be problems, specially with migrating customized business logic from old systems to new technology and architecture. There are several approaches to this issue, and NAV 5.1 for instance will effectively addres it. Since most important part of the system, from functionalty point of view, is the middle tier which runs the business logic, what first wave of technology upgrade will bring is a business-logic execution layer, that will be executed by web services. So, the Microsoft Dynamics NAV client calls the web services, which call business logic still contained in all C/AL objects. This way, most of custom business logic can be retained. Most problems with business logic upgrades will occur with the logic contained in forms, and reports. Since NAV was a fat client, tons of logic were contained in forms and reports, which are primarily user interface objects. These will have to go, and anything that relied on forms or reports will have to be rearchitectured. But whoever did their architecture right will have little to worry. Yet, this single issue will incur most of the upgrade costs to customers.

The final important point of convergence is that customers will retain their license investment in the way that no functionality they have purchased before the convergence has occurred will be lost. Microsoft calls this Transformational Assurance, and it means that no matter which Dynamics flavor customer used before, whatever functionality (e.g. manufacturing, sales orders, warehouse management…) was used before, will still be available in final Microsoft Dynamics solution.

Personally, I see much more troubles at partner side than at customer side. While partners so far have been relying on the technology they were familiar with, and knew it inside-out, they will have to migrate their skills towards .NET, which was mostly of no interest to them before. Whatever the single business-logic development language will look like, it is more likely to be .NET than any of the bunch that exist today in specific Dynamics products. This means partners will experience far steeper learning curve than customers, which in the end might or might not reflect on consultancy fees – partners also need to seek the ROI, and investments in technology readiness can be returned either directly by raising fees, or indirectly by lowering the margin. I’d opt for the latter, but I reckon no one will ask me.

I rest my case now, and let convergence stay for a while, until some new actual steps are made towards it, but I must say that I can hardly wait the moment it finally arrives.