Wednesday, November 13, 2013

Microsoft gets rid of stack-ranking

Just read this rather interesting article about how Microsoft is abandoning their rating system which has been around for quite many years.

Read http://blogs.seattletimes.com/microsoftpri0/2013/11/12/microsoft-gets-rid-of-stacking-ranking-review-system/

Although quite many MS employees probably like the fact that this is going away I also believe the system had some good traits.

One aspect is the difficulty boxing people in, but the calibration part of the system which the article doesn't really mention was in my opinion part of ensuring that people were treated fairly.  The fact that different managers had to defend their ratings towards their fellow managers was a good thing. It was not easy to favour a bad-performing individual just because you liked him/her - and the ones truly shining were also identified in agreement with other managers.

It will be interesting to hear how the new system will deal with the cross-team calibration aspect in the future.

Tuesday, November 12, 2013

Dynamics UX?

I was just checking out the new Dynamics CRM 2013 and some of the User Experience (UX) elements showing up inside the trial version of Office 365.

Please disregard the danish UI texts in the screenshots...


I am wondering if this is the first example of a new general thin client UX from the Dynamics suite of products - or in other words, will the Dynamics CRM, AX and NAV product teams converge towards the same UX...

At first glimpse the interface looks quite appealing with hints to the Windows 8 tiles used in the menu access from the top-bar. The top menu is multilevel with more tiles showing up below the first ones if you click the small drop-down arrow.

What strikes me though is that the UX is not exatly touch-friendly. I would have expected something which works better on the Surface or similar devices. The drop down arrows are quite small and it's a bit difficult to hit the right places on my Lenovo Tablet 2.

What I am also noticing is that the UI loads asynchronously in the different parts of the page and that the loading time seems a bit slow at some times. The customer contact page took around 6 seconds on my normal HP laptop and 12 seconds on my Lenovo Tablet 2. Not critical by any means but not exactly snappy either.

 
In general it seems the menu approach is changing from the traditional Office Ribbon  to a more flat Windows 8 look-a-like with action buttons below the top-menu. It's still not completely carried out - try for instance the "advaced search" feature and you suddenly notice a new browser window opening with the Office ribbon UI appearing (click the "..." in the actionbutton line).
 
A cool quick search feature is the horizontal a-z indication below list pages which enables you to scoll to the records quickly (although I have no data in the demo below).
 
 
There are many interesting aspects of this UI/UX - some problems have been adressed in a good way - others not so much. I like the feature of "latest shown" which is accessible under each main menu. I don't necessarily like the - at times - very busy UI  wich buttons all over to click on. I think I counted more than 50 clickable buttons on the customer contact page.
 
It will be interesting to drill further into the user experience and see how much of this will be taken up by the other product teams over the coming releases of AX and CRM. 

Friday, November 8, 2013

Leaving the comfort zone

I am betting that over the next couple of years quite many people will have to go through a significant learning curve stepping out from their current comfort zone.

I am referring to many of the technical people spending the majority of their time inside "MorphX" (Dynamics AX development environment) or the equivalent Dynamics NAV development environment, "C/SIDE".

So far quite many ERP developers have been living inside a fairly protected environment. They have been able to focus on datamodelling and business logic without worrying too much about aspects of software architecture, design patterns, security, authentication, performance, user experience etc. Things which developers working from scratch spend quite a lot of time on before they can get to actually write the app functionality. Good for developer productivity (let Microsoft worry about these things) but perhaps not so future proof in terms of having a career as developer.

This is my brain storm list of technologies which I would consider if I was an AX developer today. Simply because I believe this is where the AX direction is going. The good news is that there are even more developers out there which knows about where we are heading than developers knowing where we are coming from.
  • From MorphX to Team Foundation Server
  • From X++ to C#
  • From AIF to Webservices and WSDL's
  • From flat files to XML and SOAP
  • From SQL to SQL Azure
  • From Intellimorph thick client to HTML/Javascript/JSON/Entity framework
  • From manual test to Microsoft Test Manager/Lab Manager, coded UI and SoapUI 
  • From Word to on-line HTML documentation
For many this will mean leaving the comfort zone. The ones being succesful are probabely the ones taking up the challenge.

Tuesday, November 5, 2013

Bill Gates - a role model to follow

I've had the pleasure of meeting Bill Gates on a few occasions when I worked at Microsoft. The first time was at an internal strategy workshop in Snowqualmie where Bill participated with a few other Microsoft executives and a bunch of us more "normal" employees. This was a fantastic inspiring couple of days and pretty awesome to see the dedication and engagement from the leadership team at Microsoft.
At another session I was participating in a so-called "Gates"review where we - as a product team - were presenting our new project to Bill and others. This was likewise a fantastic experience - although a bit more scary to experience the level of detail which he was capable of dealing with.

These days Bill Gates has dedicated his time to the Bill & Melinda Gates foundation where he is spending the majority of the money earned through Microsoft trying to improve health and fight poverty around the globe.

I just read a brillant interview with Bill Gates which I would recommend. It can be found here:

http://www.ft.com/cms/s/2/dacd1f84-41bf-11e3-b064-00144feabdc0.html#axzz2jkx7s3Hg

It's interesting to see that even though Bill has spent most of his life building technology he doesn't believe it in itself can save the world.

"I certainly love the IT thing,” he says. “But when we want to improve lives, you’ve got to deal with more basic things like child survival, child nutrition.”

As he also states in the interview [parafrased], "what is most important - internet connectivity or finding a vaccination for malaria". There is not doubt that these days Bill Gates prioritizes the disease challenges rather than bringing internet connectivity to everyone.

I'm not sure I've ever had a role model as such, but Bill Gates certainly could be one.

Read the article - it's truly inspiring.

Monday, November 4, 2013

EG aims to become the world's largest Microsoft ERP partner

After recently having been acquired by Axcel, the new board of directors have been formed. Check out the press release.

New chairman of the board is Klaus Holse, who some of us know from his past as Corporate VP, MBS Sales and Operations and later President Western Europe with Microsoft.

This is really good news which will help us in EG reaching our ambitions of becoming Microsoft's largest ERP implementation partner. I'm sure it will also help us grow our own portfolio of software solutions built on the Microsoft technology stack.

Wednesday, October 16, 2013

To integrate or not - thats' NOT the question

The real question is how to get integration done with a minimum effort and maximum future benefit.

Let me start by elaborating a bit on what I mean by integration.

Integration in my opinion the process of making two distinctly different systems work together in a well-defined, consistent and meaningful manner. For instance Dynamics AX and Dynamics CRM - or Dynamics AX and a vertical solution such as the Zynergy solution we are working on in EG Utility. By "different systems" I typically refer to different codebases which can be deployed and used independently in a meaningful way.

As noted before many people have for many years argued for all-in-one solutions like Dynamics AX. Many of them typically in order to avoid the frustration of integrations. The paradigm has been - let Microsoft worry about making it work. Why? Usually because integrations are difficult, cumbersome and provide less "richness" than something which is knitted tightly together.

But there are really just as many good arguments for why two integrated systems provide a better total solution than the all-in-one - even considering the trouble of integration. Take the example of Dynamics AX and Dynamics CRM.

AX is in my opinion (a little biased I admit) the worlds leading ERP solution. At some point some years ago some folks believed that it needed CRM functionality as well. However, that did not work out well - and later someone else invented Dynamics CRM. Which today provides much better CRM functionality.

Now, many mid-sized companies find themself in need of superb ERP functionality as well as superb CRM functionality and suddenly an integration project is born. If you then add a vertical best-of-breed solution to that mix you could end up with a three-way integration challenge.

The three-way integration project

For such project to succeed consider these aspects,
  • How often does the different systems change (think release cycle, patching etc.)
  • To which extent do upgrades impact the integration points
  • Which depth of integration is required
The total complexity of the project typically grows with each of these parameters.

Dynamics Connector
For the Dynamics product suite, Microsoft has released an extensible "Connector" which has some pre-defined integration capabilities as well as an extensible adapter framework (check out MS Partnersource for more details).

For simple integrations (such as synchronizing selected datasets) a pre-defined framework like the connector may be a good idea. It reduces the plumbing code - or rather makes it more a configuration issue - and it probably increases the quality.

For more complex integrations the connector may not be sufficient. This goes especially if the requirement is integrating an end-to-end business process across different systems rather than merely synchronizing data. In this example it is preferred that the two systems already have some notion of business processes. Furthermore that the relevant entry- and exit points in those processes are exposed as web services and preferably supporting some kind of eventing mechanism.

Regarding the Dynamics Connector I have not heard of many projects using this. It would be interesting to get comments or examples from readers of this blog.

Service integration
Integrating two systems through web services is optimal if the two systems have well-defined interfaces with services which are designed with a business scenario in mind. Using a web service method forces the two independant systems to be designed to run both independently as well as connected.

The tricky thing is to design web services with the right granularity. They should be simple enough to be consumed (used) fairly easy, yet provide the right level of autonomous funtionality. If a system ends up with a service catalog of 5000 services it's either a really really large system or the services are too granular. On the other side if a system only has 5 services it's either a really really simple system or the services are way too generic.

Integrating different systems are in no way a simple job. If the end result make people swear and curse every time they are using it you've probably done a bad job. If the users don't know they are working with two systems you've probably done a really good job. In the latter I guess you can even talk about embedded systems. Two separate systems where users sees it as one embedded in the other is rarely found  - good examples can be dropped in the comments section.

Monday, September 16, 2013

The future of Dynamics AX - part III

This is the third part of my blogpost regarding the future of Dynamics AX.

Disclaimer: Since I am merely following the evolvement of Dynamics AX from a distance and not part of Microsoft, all of this is of course only speculation in relation to the market of ERP and line of business applications.

Third claim: Users expect more

When Dynamics AX (at that time Axapta) started it's life around the late nineties, Windows was definately the modern, fresh and market leading operating system. The team behind AX had a few years before worked on a OS/2 version but decided to ditch the dual-platform strategy and focus entirely on Windows.

One of the reasons was most likely the fast adoption of the Windows platform in the market and the future growth aspects. Much of this was driven by the popularity of Windows 95 and the consitent user experience it provided. Back then as I remember, some of the key new innovations were the ability to share data in a simple way between desktop applications and the quite stringent user interface across app's. Before Windows it was not alway clear how to open and close app's, files, share data (cut/copy/paste) etc. or simply just move around in the app.

The heritage of Windows and other MS app's
The Windows operating system and it's MDI (multi-document-interface) paradigm was the premise for the design of AX. During the first years we had to invent a new concepts suitable for an data-intensive global ERP system. One example is the socalled "intelliMorph" system (what a name) which gave the UI Forms it's ability to resize according to the content  - and was at that time quite unique in combination with the underlying feature keys and the dictionary model designer. The model designer ("MorphX") ensured a high developer productivity and a fairly consistent user experience across the application (although some parts went a bit astray over time).

In short - during the first 10 years of the life of Dynamics AX the user experience was in my opinion very modern and appreciated by the users - because the comparison to other solutions was so much worse.

From the mid 00's with the growing influence by the Microsoft ownership, the UX of AX aligned closer to that of Microsoft Office - not a bad thing, but quite difficult because there are still big differences from an ERP solution to Word, Excel, Outlook and Powerpoint. However, the users seemed to appreciate the familiarity with Office - and the market share of AX just growed.

Back to the future
Now, where do I want to go with this.... with the history lesson in  mind, my claim is that what users are really looking for, is some familiarity across the app's they use. They don't want to have to spend time learning lots of different complicated key sequences, menu structures, hover mechanisms etc. It's a bit similar to a car where you would really get annoyed if the car manufactures placed the pedals differently (as you probably have experienced they actually do that with some of the arms for turn signal, wipers etc. and that's bad enough).

Back then, Windows was setting the standards. I don't think this is the case any longer. With the proliferation of devices, the introduction of touch interfaces,  the internet browsers and not at least Facebook, the defacto standards are nowadays legio.

Users have over the years been accustomed to really simple user experiences (meant the positive way). Where they don't have to think too much about how to work the application. And new intuitive gestures have been introduced and adopted. Many times I still find myself trying to right-swipe on objects on my Windows 8 tablet becajuse that's how you delete stuff in IOS...

The browser user experience is in my view probably the most common user exprience paradigm today. This includes much more WYSIWYG than the original Windows experience and it is in nature an SDI (single-document-interface) paradigm rather than the MDI of Windows.

The UX is not just editing the datamodel
ERP solutions and business applications in general have to be designed simpler. Even if this means we have to design eight simple pages instead of one complicated form. The reason being that users expect more (simplicity!).

For quite many business applications (including Dynamics AX) this basically means giving up on the idea that the application is nothing more that a forms representation of the data model.

App's need instead to be designed to the purpose they serve. For some years Microsoft has talked about role-tailored user experience for Dynamics AX. This is in fact absolutely the right way to go, but the fact is that very little have happened. Introducing a ribbon and some role centers does not make it at all.

Process is king
We have to get away from the data model and into the seats of the users. I know why it's difficult - it requires someone from the development teams in detail to understand the business processes and not just the underlying data model. It is hard work and on top of it all it needs to be designed to be customizable and flexible. This means it is not enough to create applications which can support a given process - it should be able to accommodate process variations as well.

In a solution like Dynamics AX with thousands of data tables and forms it's a very big task to make that switch - even for Microsoft. Nonetheless I believe that the solutions to rule  the future are the ones truly embracing process from the very beginning. And then working on which data to store afterwards.

The two keywords to look for are Process and Simplicity - two words quite hard to link to Dynamics AX these days. Let's hope there are some goodies on the way we don't know about.

This concludes my postings for now on the future of Dynamics AX. Feel free to object or comment as you please.

  

Tuesday, August 13, 2013

The future of Dynamics AX - part II

This is the second part of my blogpost regarding the future of Dynamics AX.

Disclaimer: Since I am merely following the evolvement of Dynamics AX from a distance and not part of Microsoft all of this is of course only speculation in relation to the market of ERP and line of business applications.

Second claim: All-in-one (single instance) is NOT the future
For the last 15 years (at least) Dynamics AX has evolved under the mantra "all-in-one" - meaning that all functionality was built in the same codebase and exposed in the same rich client (enterprise portal excluded). Over the last years there has been some expections to this, for instance the use of Reporting Services for reports, Windows WF for workflow and other core Microsoft tecknologies, but overall AX is still built as a single ERP with a single codebase on a single database on a single release schedule.

The question is whether this all-in-one approach makes sense in the future. There are certainly a number of pro's and con's,

Some pros:
  • consistency and quality across application functionality
  • predictable release cycle
  • known and consistent technology framework
  • developer productivity
  • consistent user experience. 
Some cons:
  • unable to release and have customer adoption for new features fast enough
  • unable to leverage new technology advances and platforms fast enough (e.g. cloud deployment)
  • unable to have seperate release cycles for different parts of the solution
  • quality issues due to too many ripple effects across the application area
  • difficulties keeping the technology platform "fresh" (think MorphX versus TFS)
As the solution grows in size and complexity it has to be questioned whether the pros outweighs the cons or vice versa.

Quality issues?
Even for Microsoft it seems the size of the code base and the business logic and the churn we have seen is impacting their ability to deliver the right quality at the right time. I think the AX 2012 release showed that it has been difficult for them to ensure the right level of quality in all aspects. I am wondering if this could have been managed better had the solution not been all-in-one but a number of independant solutions working together through well-defined API's. At least then, customers would have the option of gradually migrating to new versions for part of the suite and not having to go through a big-bang upgrade scenario impacting all of their business.

In my current role as head of product development I am responsible for a (BIG) add-on solution for the Uility business built on AX 2009. What I hear from some customers is a wish to be be able to take advantage of new features in different parts of the application at different times. Or in other words, if a Production Manager wants new features in the Production application the CFO may not be interested in upgrading the Financial application - or vice versa. The broader footprint the ERP solution gets the bigger the problem. With the current all-in-one solution the entire company has to agree on upgrading to get new features...

Module granularity
I think a better approach for the future is smaller independent application areas capable of being upgraded independently on separate release schedules. I believe it will be very hard but not impossible to achieve this with Dynamics AX. My guess is that Microsoft is heading in this direction - but if so - the end result won't be the Dynamics AX we know today.

For solutions like the ones we do in EG Utility we have made a bet that this is what will be happening - and by the way, the right way to go. We are developing Zynergy with standard Microsoft technologies (.net, HTML5/Javascript) based on Windows Azure. We believe this will enable our customers to evolve their mission critical utility solutions separately from Dynamics AX whilst maintaining a close and tight integration. For the same reason I believe that in the future AX will be split up under the hood into smaller independent "modules" or application areas working seamlesssly together. Should you start from scratch building an ERP today I also think this is the way you would do it - since everything anyways would be built for the cloud there is no way you would want to have to upgrade everything at the same time.

The trick will be not to lose the pros listed above while gaining from the cons. In my head, even for Microsoft, the benefits of the cons outweighs the cost of ensuring the pros. 

Wednesday, July 17, 2013

The future of Dynamics AX?

As I am getting ready for my vacation later this week I decided to invest a bit of time starting up my blog again.

For those who may have read some of my previuos blog posts through my employment at Microsoft, TIA and ScanJour, this time around I will try to take a broader and more personal approach to blogging.

Although I am now in a position as Head of Product Development at EG A/S this blog will represent my personal opinions and viewpoints. I will still try concentrate on the professional aspects of my job and life (all the rest I guess is more appropriate for Facebook...)

For this first post I am asking a fairly broad question which I think is highly interesting these days. I will not claim to know a lot about all of the ERP's of this world, my primary experience being with Dynamics AX. However, I do think the future of Dynamics AX the coming few years are about to change significantly. Obviuosly - it's hard to try predict the future. Accidently, I stumbled across an artice from 2009, which claimed that the traditional ERP approach is dead (http://www.infoworld.com/d/applications/future-erp-why-big-erp-approach-dead-047).

For all of us working with ERP, we know the last 4 years have shown that it was hardly the truth - so what will be different the next 4 years? Well, I do not believe ERP will be dead, but I do believe the business model around implementing and deploying ERP systems will change significantly. I have three claims which I believe support this,

First claim: Customization is going away

Ouch - being employed at a company which makes it's living partly by implementing and customizing ERP's this is a tough thing to realize. And of course this will not happen tomorrow. But it is my true believe that the level of customization which have happened to ERP's such as Dynamics AX over the last decade will vanish during the next decade.

Reasons:
  • Standardization
    Dynamics AX now contains so much functionality that enough is enough. Most companies could choose to "live" with the standard solution and instead get the benefits of continuous improvements without the upgrade nightmare.
  • Accessibility
    In order for the systems to be accessible across geographies and different user groups (roles) the architecture of Dynamics AX need to be changed drastically. The three-tier architecture implemented in the beginning of the 00's is not how you would do it today. The best way to achieve this is making the functionality available through a thin client web based experience. The optimal way to achieve this is a cloud based deployment. Microsoft is probably working on this already, and it will mean a lot to the customization capabilities of the solution (as in "they will not be there")
  • Competencies
    It is my impression that the average age of people working with Dynamics AX implementations are increasing. Or in other words, those who have worked with this product since we invented it in the mid 90's will continue, but what is the incentive for young people to enter the business? I predict that there will be a significant lack of AX skilled resources in the near future. Simply because the original technology of AX is begining to show sign of age.
  • Cost reductions
    Companies are beginning to realize that having their own iron in the basement and the people above them to service it may not be sufficiently cost efficient. Especially in the mid-market it is problematic for companies to keep staff with the competencies needed to support the traditional on-premise solutions. Thus, solutions will slowly move to the cloud.
  • Upgrades are becoming too costly
    As Microsoft continues to speed up the release cycles and amount of innovation put into the solution, it's getting harder and harder to keep up for partners and customers. The trick will be to isolate customizations as much as possible from the standard solution in order to upgrade them swiftly at a low cost. This means customizations will gradually change into add-on integrations instead only leveraging (more stable) API's.
To be continued in following posts...
Second claim: All-in-one (single instance) is NOT the future
Third claim: Users expect more