tag:blogger.com,1999:blog-39878476193392030162024-03-20T05:04:35.881+01:00Flemming's blogFlemming Louw-Reimerhttp://www.blogger.com/profile/02781594043400306522noreply@blogger.comBlogger14125tag:blogger.com,1999:blog-3987847619339203016.post-60630198185870491222016-01-11T11:11:00.002+01:002016-01-11T11:11:09.378+01:00Back to the futureI am happy to report that as of September 2015 I have rejoined TIA Technology as VP Development.<br />
<br />
After having spent more than three years in EG A/S working within the Utility and the Microsoft Dynamics business, I am now back in the Insurance business working with the TIA solution. It's a bit like coming back to the future, since this is where I also spent time from 2007 to 2011.<br />
<br />
The TIA solution have evolved since then, and we are now finally having customers live on the brand new version 7.<br />
<br />
It is certainly exiting times for TIA, with a strong, modern and up-to-date product offering and a significant number of insurance companies either running the new solution live or in progress of implementing it.<br />
<br />
I will revitalize my blog with updates from my work at TIA, look for further updates soon.<br />
<br />Flemming Louw-Reimerhttp://www.blogger.com/profile/02781594043400306522noreply@blogger.com0tag:blogger.com,1999:blog-3987847619339203016.post-577697547622556812015-06-25T09:58:00.001+02:002015-06-25T09:58:07.850+02:00Moving LOB app's to the CloudLine of business (LOB) applications are typically characterized as the mission critical IT part of a company's business. This could be the ERP or the CRM software, the MES (Manufacturing Execution System) in a production company or the project management system in a construction company.<br /> <br />
In other words - if the LOB app doesn't run, the company typically won't invoice, produce, plan or sell anything - and thus quite quickly lose a lot of money - or even come to a complete halt.<br />
<br />During the last decade we have seen more and more software solutions being programmed or re-programmed for the cloud. This exercise typically involves considerations like user interface (thin client), responsive design, latency, multi-tenancy, scale-out, database architecture, service orientation etc. Just to mention a few.<br />
<br />All topics which are core to the design of a software solution. Which is also why it is hard work for a SW vendor to get a traditional LOB app to run truly in the cloud. I don't necessarily buy the argument that since customers won't like their mission critical software to run in the cloud their LOB app is not yet there. Most often this argument is put forward by software vendors who at the same time have real difficulties transforming their 10-20 years old LOB application into a cloud solution. Simply because the LOB application was never designed with that in mind. In many cases, customers would even prefer their LOB app running in the cloud as long as it's doing what it is suppose to do and the performance and security is adequate.<br />
<br />The real obstacle for moving a LOB app to the cloud lies in the core of the design. If the LOB app is designed as a monolith, perhaps even with a proprietary thick client, and even worse - with a lot of business logic in the client - it's tough to reap the benefits of a true cloud solution - such as scaleability, sharing of resources (database storage, processing power, accessability etc). not to mention the most problematic aspect - that many standard LOB apps are customized by customers. <br />
<br />The customization aspect is in fact perhaps the greatest barrier for moving a LOB app to the cloud. Simply because the promise of the cloud is somewhat lost if each customer still needs a dedicated enviroment (= private cloud). <br />
<br />So what do vendors of LOB apps have to do. Well - in fact they have to rethink the customization story completely. This is what <strong><a href="http://www.salesforce.com/">Salesforce</a> </strong>has done and in a smaller scale danish vendor<strong> <a href="https://www.e-conomic.com/">e-conomic</a></strong> is trying to do. Inventing a "simpler" or more structured customization model, where the core design of the LOB app is not really changed but instead "pluggable" and extendable through wisely designed interfaces. <br />
<br />I believe this is also what we will see popular ERP's such as <strong><a href="https://www.microsoft.com/en-us/dynamics/erp-ax-overview.aspx">Dynamics AX</a></strong> and <strong><a href="https://www.microsoft.com/en-us/dynamics/erp-nav-overview.aspx">Dynamics NAV</a></strong> move towards. Introducing an extension model which will replace the traditional customization model, where core business logic is modified per customer.<br />
<br />In conclusion, if you are to build a new LOB or are looking into redesigning an existing, you should probably think hard about which parts are truly required to be customized per customer and then concentrate on enabling an adequate extension or plug-in model to support those differencies. And then start designing/re-designing the rest of the LOB to take advantage of the true promise of the cloud with topics such as elastic computing, sharing of resources, multi-tenancy, one-click deployment - or in other words - remove the need for dealing with IT completely for the customer.<br />
<br />Flemming Louw-Reimerhttp://www.blogger.com/profile/02781594043400306522noreply@blogger.com0tag:blogger.com,1999:blog-3987847619339203016.post-73057118763161464672015-06-01T12:55:00.000+02:002015-06-01T12:55:15.844+02:00What is your software development team spending time on?Let's face it - many software development teams gets really annoyed when asked to register their time on a daily basis. But how do you know if they are working efficient if you don't know what they are spending time on? And - how do you know what they are spending time on if they are not registering it?<br />
<br />
Ok, I get all the arguments against not doing time registration; "It's too cumbersome", "It takes too long", "Don't you trust me", "We've never done that and we're doing ok!"<br />
<br />
I have been running development teams both with and without time registration and in general I agree that both approaches can work. But - it depends a lot on the situation.<br />
<br />
The key point is that as a software development leader you need to know what your team is spending it's time on. And you need to find a good way to obtain this knowledge.<br />
<br />
For smaller teams - and/or if you are doing part of the work yourself - it becomes easier since you can be very close to each individual in the team. If you have largers teams or multiple teams it gets a bit more complicated to understand the details of efficiency.<br />
<br />
let's start taking a look at some of the things a software development team is usually spending time on,<br />
<ul>
<li>Administration<br />You don't necessarily want them to spend much time on this but it is unavoidable. You decide yourself what to categorize under administration, but some common activities can include vacation, sickness, department meetings, celebrations, education etc, career dialogs etc. Some of these you may want to detail out separately.</li>
<li>Product Development<br />This is where you want your team to spend their time. This category will typically include aspects like gathering requirements, writing spec's, design, coding, test, documentation, sprint planning, retrospectives, project management etc. All the things that are absolutely necessary in order to get the software done. If you are very specific you may want to drill down into the ratios between the different aspects...</li>
<li>Stabilization<br />Your team is writing the last bit of code before all features are finally complete for the next release. However, for many good reasons you need a bit of time to test and fix the last bugs before shipping. For some teams this becomes a never ending death march...</li>
<li>Maintenance and support<br />The version you have released to your customers may have flaws...they need to get fixed. Bugs are found, incidents are logged. In general time spent on this should be minized. Some teams have found they spend as much as half their time on fixing old stuff...not optimal.</li>
<li>Assisting others<br />So your team is incredible knowledgeable. In fact, sometimes they are the only ones who knows and can answer questions from others in your company. So they spend a lot of time on this. Time, which is taken from the time they could have developed the next version...</li>
</ul>
For all development teams the objective has to be to get the most output with the least effort. With that I do not mean that more is better. This assumes the team is doing what is right for the user and the customer considering functionality, quality, usability etc.<br />
<br />
Understanding how time is spent is a pre-requisite to understanding how to optimize. You will often find interesting correlations. As an example low customer satisfaction is often correlated to either low time consumption in the requirements, speficication and design phases (pre-release) or high time consumption in maintenance and support (post-release).<br />
<br />
High complexitiy in the solution architecture can be accompanied by high time consumption in stabilization and the examples goes on and on.<br />
<br />
If you have been tracking time spenditure for some time you will eventually be able to start optimizing the different aspects of software development and at the same time monitor whether the changes actually works as intended.<br />
<br />
Planning future work also gets a lot easier if you gradually develop rules-of-thumbs for your team based on historic performance.Flemming Louw-Reimerhttp://www.blogger.com/profile/02781594043400306522noreply@blogger.com1tag:blogger.com,1999:blog-3987847619339203016.post-24686288160990576412014-01-24T15:53:00.003+01:002014-01-24T15:53:39.506+01:00#AXTech2014<div style="clear: both; text-align: left;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEg9OyogR-fzx4MvAVJXYoqhtfdgxb4XljeRhyPZAPyZrT0ZSg2IuhadV6BPfaqBSY1yd-fyMlamiQqqjFhtNbWp3nmnzKvKdi961Np5H7Y-FuQrxac8C495jeW0GUdbzQXEs3cdxOYJvn0/s1600/AX+Tech+conference+2104.JPG" imageanchor="1" style="clear: right; float: right; margin-bottom: 1em; margin-left: 1em;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEg9OyogR-fzx4MvAVJXYoqhtfdgxb4XljeRhyPZAPyZrT0ZSg2IuhadV6BPfaqBSY1yd-fyMlamiQqqjFhtNbWp3nmnzKvKdi961Np5H7Y-FuQrxac8C495jeW0GUdbzQXEs3cdxOYJvn0/s1600/AX+Tech+conference+2104.JPG" /></a></div>
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEg9OyogR-fzx4MvAVJXYoqhtfdgxb4XljeRhyPZAPyZrT0ZSg2IuhadV6BPfaqBSY1yd-fyMlamiQqqjFhtNbWp3nmnzKvKdi961Np5H7Y-FuQrxac8C495jeW0GUdbzQXEs3cdxOYJvn0/s1600/AX+Tech+conference+2104.JPG" imageanchor="1" style="clear: right; float: right; margin-bottom: 1em; margin-left: 1em;"><div style="text-align: left;" unselectable="on">
</div>
</a>With just a little more than a week to go before the AX Technical Conference kicks off in Bellevue, I am considering what I will learn there and what I should be looking for.<br />
<br />
<span style="font-size: large;"><strong>The setting</strong></span><br />
As usual Microsoft seems to have put together a comprehensive agenda. These guys definately know how to plan a conference and you are poised to get bang for your buck if you put in the effort. A bit of planning is advised since there are many sessions and so much to learn that you can get lost if you're not careful.<br />
<br />
In my experience the cool thing about the technical conference (compared to Convergence) is that it's held near Redmond. This means that MS typically brings many more of the real experts (not the marketing guys) from the dev teams since the overall cost is much lower. So the chance of getting to talk to some of them who actually creates the product is a lot higher.<br />
<br />
<span style="font-size: large;"><strong>The content</strong></span><br />
As a generalist (I'm not into any specific part of AX) I will be focusing on getting as much information as possible about the future. This in itself can be a bit tricky since it's much easier for the MS people to talk about what's there now rather than what they think will come...<br />
<br />
However, for those of us who are heavily dependant on being able to look a few years ahead, the future is the interesting part.<br />
<br />
So - I have tried to look into the agenda and session catalog for interesting stuff which points a bit ahead. With those glasses on I've tried to combine the agenda with my own reflections on what may become important. Doing this I have noted the following,<br />
<br />
<h3>
Keynotes</h3>
It's always interesting to listen to Hal, Mike and others to hear their view on the latest release and sometimes even a hint about what's next. You can be sure that if there are any important radical changes or news, the keynote sessions are where they will be flashed - so don't miss them.<br />
I'm especially interested in hearing more about the progress on the new user experience for the "Rainier" client and the impact it will have for all our industry modules, customizations etc. I guess right now it can be anything from <em>"yep - we'll auto convert all forms by the push of a button" </em>(highly unlikely) to <em>"sorry guys, you have to redesign all forms completely manual".</em> Interesting stuff.<br />
The other part which I will be listening for, is MS thoughts on workloads. How do they see workloads (and "apps" for them) playing together and how do they see the interaction model between workloads supported by standard AX and industry specific workloads made by partners. I have no doubt that the model used through the last 15 years (layered source code modification using MorphX) is changing significantly - but the question of course is what the replacement model is and how fast it can/will be introduced.<br />
<br />
<h3>
Sessions</h3>
So far I have picked a few of the sessions which I will try to attend. There are plenty others that are also interesting but browsing the session catalog, these ones stood out for me,<br />
<ul>
<li><span style="color: blue;">Master data management</span> <br />Why? well I think this topic in many customer projects becomes a need-to thing. The days where AX was the only solution in the mix are gone. Today there is often a Dynamics CRM, a best-of-breed industry solution or something else which needs to be held synchronized with data in AX. Interesting to hear what they are thinking about this.</li>
<li><span style="color: blue;">Lifecycle services</span><br />MS has definately not nailed this yet. There are may issues still with the current offering, but in general I think it's an important topic. In EG (<a href="http://www.eg.dk/">www.eg.dk</a>) - as a large AX partner with many customers - it's a nightmare (and quite costly) to manage deployment and upgrades etc. per customer. It needs more attention (Sri - I hope you are reading this :-)</li>
<li><span style="color: blue;">Service integration through Azure</span><br />This is going to be part of the future. I need to understand more about where this is going. We probably need this for our state-of-the-art industry solutions in EG when they are not developed in AX but still needs close integration. </li>
<li><span style="color: blue;">Advanced reporting solutions</span><br />MS has a real serious challenge with reporting. What I am hearing is that the old reporting engine inside MorphX was not good - but the new reporting services based engine in some cases is worse...I'm looking forward to hear about improvements and possibilities.</li>
<li><span style="color: blue;">Dynamics CRM and AX Project integration</span><br />More out-of-the-box integration between AX and CRM is always interesting. CRM is enjoying tremendous traction in the market and closer ingration will be needed.</li>
<li><span style="color: blue;">Create Microsoft Dynamics AX builds using the new X++ server-side parallel compiler</span><br />As head of a dev team which are gradually switching into using TFS for all projects this is interesting. I'll try to understand where MS is heading with AX versus TFS - could be the most interesting session in the conference.</li>
</ul>
See you in Redmond!<br />
<div align="right">
</div>
Flemming Louw-Reimerhttp://www.blogger.com/profile/02781594043400306522noreply@blogger.com0tag:blogger.com,1999:blog-3987847619339203016.post-72619348165703340562014-01-15T08:45:00.001+01:002014-01-15T08:45:07.396+01:00Microsoft PartnerSource under construction???These days Microsoft is reconstructing their PartnerSource extranet for partners. And it also seems they are not doing a fantastic job.<br />
<br />
At least I am having lots of diffculties accessing the website,<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEg9yF2LGg-6WR65JC50X6ZXM7-6k6BXzCX1mrTvgHSzrgTt7KwZzJD-zf-b-vG9olWRE8_8dOBRJkyZUCtejHVkSoGR4R8HsIme-SkoYtrYrk-weQ0aci8pwdG0UQAMDxbUps0UYCDUgqw/s1600/Page+not+found.JPG" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="55" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEg9yF2LGg-6WR65JC50X6ZXM7-6k6BXzCX1mrTvgHSzrgTt7KwZzJD-zf-b-vG9olWRE8_8dOBRJkyZUCtejHVkSoGR4R8HsIme-SkoYtrYrk-weQ0aci8pwdG0UQAMDxbUps0UYCDUgqw/s320/Page+not+found.JPG" width="320" /></a></div>
<br />
I'm sorry too, why is it so difficult for Microsoft to upgrade a website - hopefully not becasuse they are using Sharepoint!<br />
<br />
I'm wondering if I am the only one having difficulties with PartnerSource?Flemming Louw-Reimerhttp://www.blogger.com/profile/02781594043400306522noreply@blogger.com0tag:blogger.com,1999:blog-3987847619339203016.post-4132231434256565032013-11-13T08:40:00.002+01:002013-11-13T09:42:52.336+01:00Microsoft gets rid of stack-rankingJust read this rather interesting article about how Microsoft is abandoning their rating system which has been around for quite many years.<br />
<br />
Read <a href="http://blogs.seattletimes.com/microsoftpri0/2013/11/12/microsoft-gets-rid-of-stacking-ranking-review-system/">http://blogs.seattletimes.com/microsoftpri0/2013/11/12/microsoft-gets-rid-of-stacking-ranking-review-system/</a><br />
<br />
Although quite many MS employees probably like the fact that this is going away I also believe the system had some good traits. <br />
<br />
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. <br />
<br />
It will be interesting to hear how the new system will deal with the cross-team calibration aspect in the future.Flemming Louw-Reimerhttp://www.blogger.com/profile/02781594043400306522noreply@blogger.com0tag:blogger.com,1999:blog-3987847619339203016.post-53769724195535175222013-11-12T15:03:00.001+01:002013-11-12T15:04:42.533+01:00Dynamics 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.<br />
<br />
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjL-w9dX00_fcyRxABRskjhbnianUxjzBLkqrm8oBUIzDVeTCIsE7q17918-Y4U5OPwJe-gqyEtSMSu1bWHvAMr1HYnRTOcET3vZYequi6SRROR68507ntYXAqOcR4RZEm2TztIYbn7FnM/s1600/CRM_1.png" imageanchor="1" style="clear: right; float: right; margin-bottom: 1em; margin-left: 1em;"><img border="0" height="101" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjL-w9dX00_fcyRxABRskjhbnianUxjzBLkqrm8oBUIzDVeTCIsE7q17918-Y4U5OPwJe-gqyEtSMSu1bWHvAMr1HYnRTOcET3vZYequi6SRROR68507ntYXAqOcR4RZEm2TztIYbn7FnM/s320/CRM_1.png" width="320" /></a>Please disregard the danish UI texts in the screenshots...<br />
<br />
<br />
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...<br />
<br />
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. <br />
<br />
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. <br />
<br />
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.<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgM42OEuisf0hWmySxPVr4g1lJH2NeIuEIhq-3Jf_DHfXhj9XycEcNCWwOyyoP2HeYqE5EMV3aFJGIGJyMPqJf6Mqj70pc2CeL22VOoCdAIO3kQFrGuTQ2_Iw577oKoR0mo3Tc8QXpKquA/s1600/CRM_6.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="232" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgM42OEuisf0hWmySxPVr4g1lJH2NeIuEIhq-3Jf_DHfXhj9XycEcNCWwOyyoP2HeYqE5EMV3aFJGIGJyMPqJf6Mqj70pc2CeL22VOoCdAIO3kQFrGuTQ2_Iw577oKoR0mo3Tc8QXpKquA/s400/CRM_6.png" width="400" /></a></div>
<div class="separator" style="clear: both; text-align: center;">
</div>
<div class="separator" style="clear: both; text-align: left;">
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).</div>
<div class="separator" style="clear: both; text-align: left;">
</div>
<div class="separator" style="clear: both; text-align: left;">
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). </div>
<div class="separator" style="clear: both; text-align: left;">
</div>
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEi4tnrWosdRt01lMXVS9-qF75eeEWOcvK2YflVVAIl16pbZvrfOU0NwKK9ibxDVvi5lXINGsr7vvFNC2fMOcAes6y6uMcY9Q-KMfYlBiEYoqOIvUQU3ZjMmKQkeEcxs4_yMDpvGzXemSS4/s1600/CRM_7.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="259" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEi4tnrWosdRt01lMXVS9-qF75eeEWOcvK2YflVVAIl16pbZvrfOU0NwKK9ibxDVvi5lXINGsr7vvFNC2fMOcAes6y6uMcY9Q-KMfYlBiEYoqOIvUQU3ZjMmKQkeEcxs4_yMDpvGzXemSS4/s400/CRM_7.png" width="400" /></a></div>
<div class="separator" style="clear: both; text-align: left;">
</div>
<div class="separator" style="clear: both; text-align: left;">
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.</div>
<div class="separator" style="clear: both; text-align: left;">
</div>
<div class="separator" style="clear: both; text-align: left;">
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. </div>
Flemming Louw-Reimerhttp://www.blogger.com/profile/02781594043400306522noreply@blogger.com0tag:blogger.com,1999:blog-3987847619339203016.post-29059141135684729492013-11-08T13:37:00.001+01:002013-11-08T13:37:08.897+01:00Leaving the comfort zoneI 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.<br />
<br />
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".<br />
<br />
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.<br />
<br />
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.<br />
<ul>
<li>From MorphX to Team Foundation Server</li>
<li></li>
<li>From X++ to C#</li>
<li></li>
<li>From AIF to Webservices and WSDL's</li>
<li></li>
<li>From flat files to XML and SOAP</li>
<li></li>
<li>From SQL to SQL Azure </li>
<li></li>
<li>From Intellimorph thick client to HTML/Javascript/JSON/Entity framework</li>
<li></li>
<li>From manual test to Microsoft Test Manager/Lab Manager, coded UI and SoapUI </li>
<li></li>
<li>From Word to on-line HTML documentation</li>
</ul>
For many this will mean leaving the comfort zone. The ones being succesful are probabely the ones taking up the challenge.Flemming Louw-Reimerhttp://www.blogger.com/profile/02781594043400306522noreply@blogger.com0tag:blogger.com,1999:blog-3987847619339203016.post-29195539468930711782013-11-05T10:50:00.000+01:002013-11-05T10:50:04.824+01:00Bill Gates - a role model to followI'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. <br />
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.<br />
<br />
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.<br />
<br />
I just read a brillant interview with Bill Gates which I would recommend. It can be found here:<br />
<br />
<a href="http://www.ft.com/cms/s/2/dacd1f84-41bf-11e3-b064-00144feabdc0.html#axzz2jkx7s3Hg">http://www.ft.com/cms/s/2/dacd1f84-41bf-11e3-b064-00144feabdc0.html#axzz2jkx7s3Hg</a><br />
<br />
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. <br />
<br />
"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.”<br />
<br />
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.<br />
<br />
I'm not sure I've ever had a role model as such, but Bill Gates certainly could be one.<br />
<br />
Read the article - it's truly inspiring.Flemming Louw-Reimerhttp://www.blogger.com/profile/02781594043400306522noreply@blogger.com0tag:blogger.com,1999:blog-3987847619339203016.post-82368964432940787712013-11-04T16:11:00.001+01:002013-11-04T16:12:03.568+01:00EG aims to become the world's largest Microsoft ERP partnerAfter recently having been acquired by <a href="http://uk.axcel.uat.fonqi.com/frontpage.aspx">Axcel</a>, the new board of directors have been formed. Check out the <a href="http://global.eg.dk/about-eg/latest-news/news/2013/oct/klaus-holse-new-chairman-of-the-board-of-directors-of-eg">press release</a>.<br />
<br />
New chairman of the board is <a href="http://www.linkedin.com/profile/view?id=110661&locale=en_US&trk=tyah2&trkInfo=tas%3Aklaus%20holse%20%2Cidx%3A1-1-1">Klaus Holse</a>, who some of us know from his past as Corporate VP, MBS Sales and Operations and later President Western Europe with Microsoft.<br />
<br />
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.Flemming Louw-Reimerhttp://www.blogger.com/profile/02781594043400306522noreply@blogger.com0tag:blogger.com,1999:blog-3987847619339203016.post-4115595356786186642013-10-16T15:10:00.000+02:002013-10-16T15:10:08.141+02:00To integrate or not - thats' NOT the question<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgjSeGCLp1q_lQBGswjHVzeS6qrcr66YFA5GN4AbvTWbscCAXP89uOvLRtP2Z2BtiGPOCxOWfOxd_szA_Dk_Mn41gPXIMm5Z4HFEOQVYtTtJOTxbqp3pUQnGJBqSEnPXNPTUYj_YQs0Drc/s1600/Integration+logo.png" imageanchor="1" style="clear: left; float: left; margin-bottom: 1em; margin-right: 1em;"><img border="0" height="181" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgjSeGCLp1q_lQBGswjHVzeS6qrcr66YFA5GN4AbvTWbscCAXP89uOvLRtP2Z2BtiGPOCxOWfOxd_szA_Dk_Mn41gPXIMm5Z4HFEOQVYtTtJOTxbqp3pUQnGJBqSEnPXNPTUYj_YQs0Drc/s200/Integration+logo.png" width="200" /></a></div>
The real question is how to get integration done with a minimum effort and maximum future benefit.<br />
<br />
Let me start by elaborating a bit on what I mean by integration. <br />
<br />
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. <br />
<br />
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.<br />
<br />
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. <br />
<br />
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. <br />
<br />
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. <br />
<br />
<strong>The three-way integration project</strong><br />
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEi0eDZ80oda2WtUb3YnmwcnphF4y3mEUneroJfYWTPKXgkdqVEIgJhzPfFiSsydY50edphXeJEWAhuNBvGu-N6FP8nSwmc6u7Z2Y8Ens5Yp_NV6YBHht4trdXXdXxUOV2hRZL8rmrBufzk/s1600/shutterstock.jpg" imageanchor="1" style="clear: right; float: right; margin-bottom: 1em; margin-left: 1em;"><img border="0" height="165" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEi0eDZ80oda2WtUb3YnmwcnphF4y3mEUneroJfYWTPKXgkdqVEIgJhzPfFiSsydY50edphXeJEWAhuNBvGu-N6FP8nSwmc6u7Z2Y8Ens5Yp_NV6YBHht4trdXXdXxUOV2hRZL8rmrBufzk/s200/shutterstock.jpg" width="200" /></a><br />
For such project to succeed consider these aspects,<br />
<ul>
<li>How often does the different systems change (think release cycle, patching etc.)</li>
<li>To which extent do upgrades impact the integration points</li>
<li>Which depth of integration is required</li>
</ul>
The total complexity of the project typically grows with each of these parameters.<br />
<br />
<strong>Dynamics Connector</strong><br />
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). <br />
<br />
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. <br />
<br />
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. <br />
<br />
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.<br />
<br />
<strong>Service integration</strong><br />
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. <br />
<br />
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.<br />
<br />
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.Flemming Louw-Reimerhttp://www.blogger.com/profile/02781594043400306522noreply@blogger.com0tag:blogger.com,1999:blog-3987847619339203016.post-60513530180866845492013-09-16T09:30:00.002+02:002013-09-16T09:30:48.109+02:00The future of Dynamics AX - part IIIThis is the third part of my blogpost regarding the future of Dynamics AX.<br />
<br />
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. <br />
<br />
<strong>Third claim: Users expect more</strong><br />
<strong></strong><br />
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. <br />
<br />
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. <br />
<br />
<strong>The heritage of Windows and other MS app's</strong><br />
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).<br />
<br />
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. <br />
<br />
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.<br />
<br />
<strong>Back to the future</strong><br />
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).<br />
<br />
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. <br />
<br />
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...<br />
<br />
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.<br />
<br />
<strong>The UX is not just editing the datamodel</strong><br />
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!).<br />
<br />
For quite many business applications (including Dynamics AX) this basically means <strong>giving up</strong> on the idea that the application is nothing more that a forms representation of the data model.<br />
<br />
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. <br />
<br />
<strong>Process is king</strong><br />
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. <br />
<br />
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.<br />
<br />
The two keywords to look for are <strong>Process</strong> and <strong>Simplicity</strong> - 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.<br />
<br />
This concludes my postings for now on the future of Dynamics AX. Feel free to object or comment as you please.<br />
<br />
Flemming Louw-Reimerhttp://www.blogger.com/profile/02781594043400306522noreply@blogger.com0tag:blogger.com,1999:blog-3987847619339203016.post-55292718669571264022013-08-13T14:49:00.002+02:002013-08-13T14:49:51.966+02:00The future of Dynamics AX - part IIThis is the second part of my blogpost regarding the future of Dynamics AX.<br />
<br />
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. <br />
<br />
<strong>Second claim: All-in-one (single instance) is NOT the future</strong><br />
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.<br />
<br />
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,<br />
<br />
<em>Some pros:</em><br />
<ul>
<li>consistency and quality across application functionality</li>
<li>predictable release cycle</li>
<li>known and consistent technology framework</li>
<li>developer productivity</li>
<li>consistent user experience. </li>
</ul>
<em>Some cons:</em><br />
<ul>
<li>unable to release and have customer adoption for new features fast enough</li>
<li>unable to leverage new technology advances and platforms fast enough (e.g. cloud deployment)</li>
<li>unable to have seperate release cycles for different parts of the solution</li>
<li>quality issues due to too many ripple effects across the application area</li>
<li>difficulties keeping the technology platform "fresh" (think MorphX versus TFS)</li>
</ul>
As the solution grows in size and complexity it has to be questioned whether the pros outweighs the cons or vice versa.<br />
<br />
<strong>Quality issues?</strong><br />
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.<br />
<br />
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...<br />
<br />
<strong>Module granularity</strong><br />
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. <br />
<br />
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.<br />
<br />
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. Flemming Louw-Reimerhttp://www.blogger.com/profile/02781594043400306522noreply@blogger.com0tag:blogger.com,1999:blog-3987847619339203016.post-12635012992084775612013-07-17T14:28:00.000+02:002013-07-17T14:28:45.127+02:00The 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.<br />
<br />
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. <br />
<br />
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...)<br />
<br />
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 (<a href="http://www.infoworld.com/d/applications/future-erp-why-big-erp-approach-dead-047">http://www.infoworld.com/d/applications/future-erp-why-big-erp-approach-dead-047</a>).<br />
<br />
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,<br />
<br />
<strong><span style="color: black;">First claim: Customization is going away</span></strong><br />
<strong></strong><br />
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.<br />
<br />
<em>Reasons:</em><br />
<ul>
<li>Standardization<br />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.</li>
<li>Accessibility<br />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")</li>
<li>Competencies<br />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.</li>
<li>Cost reductions<br />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.</li>
<li>Upgrades are becoming too costly<br />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.</li>
</ul>
<em>To be continued in following posts...</em><br />
<strong>Second claim: All-in-one (single instance) is NOT the future</strong><br />
<strong>Third claim: Users expect more</strong>Flemming Louw-Reimerhttp://www.blogger.com/profile/02781594043400306522noreply@blogger.com0