I am happy to report that as of September 2015 I have rejoined TIA Technology as VP Development.
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.
The TIA solution have evolved since then, and we are now finally having customers live on the brand new version 7.
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.
I will revitalize my blog with updates from my work at TIA, look for further updates soon.
Monday, January 11, 2016
Thursday, June 25, 2015
Moving LOB app's to the Cloud
Line 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.
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.
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.
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.
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.
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).
So what do vendors of LOB apps have to do. Well - in fact they have to rethink the customization story completely. This is what Salesforce has done and in a smaller scale danish vendor e-conomic 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.
I believe this is also what we will see popular ERP's such as Dynamics AX and Dynamics NAV move towards. Introducing an extension model which will replace the traditional customization model, where core business logic is modified per customer.
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.
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.
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.
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.
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.
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).
So what do vendors of LOB apps have to do. Well - in fact they have to rethink the customization story completely. This is what Salesforce has done and in a smaller scale danish vendor e-conomic 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.
I believe this is also what we will see popular ERP's such as Dynamics AX and Dynamics NAV move towards. Introducing an extension model which will replace the traditional customization model, where core business logic is modified per customer.
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.
Monday, June 1, 2015
What 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?
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!"
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.
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.
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.
let's start taking a look at some of the things a software development team is usually spending time on,
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).
High complexitiy in the solution architecture can be accompanied by high time consumption in stabilization and the examples goes on and on.
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.
Planning future work also gets a lot easier if you gradually develop rules-of-thumbs for your team based on historic performance.
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!"
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.
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.
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.
let's start taking a look at some of the things a software development team is usually spending time on,
- Administration
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. - Product Development
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... - Stabilization
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... - Maintenance and support
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. - Assisting others
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...
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).
High complexitiy in the solution architecture can be accompanied by high time consumption in stabilization and the examples goes on and on.
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.
Planning future work also gets a lot easier if you gradually develop rules-of-thumbs for your team based on historic performance.
Friday, January 24, 2014
#AXTech2014
The setting
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.
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.
The content
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...
However, for those of us who are heavily dependant on being able to look a few years ahead, the future is the interesting part.
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,
Keynotes
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.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 "yep - we'll auto convert all forms by the push of a button" (highly unlikely) to "sorry guys, you have to redesign all forms completely manual". Interesting stuff.
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.
Sessions
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,- Master data management
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. - Lifecycle services
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 (www.eg.dk) - 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 :-) - Service integration through Azure
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. - Advanced reporting solutions
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. - Dynamics CRM and AX Project integration
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. - Create Microsoft Dynamics AX builds using the new X++ server-side parallel compiler
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.
Wednesday, January 15, 2014
Microsoft PartnerSource under construction???
These days Microsoft is reconstructing their PartnerSource extranet for partners. And it also seems they are not doing a fantastic job.
At least I am having lots of diffculties accessing the website,
I'm sorry too, why is it so difficult for Microsoft to upgrade a website - hopefully not becasuse they are using Sharepoint!
I'm wondering if I am the only one having difficulties with PartnerSource?
At least I am having lots of diffculties accessing the website,
I'm sorry too, why is it so difficult for Microsoft to upgrade a website - hopefully not becasuse they are using Sharepoint!
I'm wondering if I am the only one having difficulties with PartnerSource?
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.
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.
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.
Subscribe to:
Posts (Atom)