I promised to myself not to post technical stuff on this blog. But as Seth Godin said not that long ago, never’s not such a long time. And also, why shouldn’t I share a piece of useful advice if I have it. So here it goes.
Have you ever started a lengthy NAV batch job, and then wondered how much longer it is really going to take? Me too.
I never really expected that my post about my laptop outperforming an 8-headed dragon of a server would draw that much attention: record number of first-day reads of any blog post on my blog ever (134), and record number of comments (11 comments, by 5 people, me included). Not a big deal, but I believe you deserve a conclusion, to know how it all ended.
To be honest, it didn’t.
Never trust the customer 🙂 We were sure that the server had last service packs applied, that’s the first that we asked of the customer IT, and got a definite answer that “But, of course!”. So we didn’t really think this might be an issue. Then we noticed that SQL Server build number was 1399, while my laptop was running 3042. This reads: customer’s top-notch server is still on SQL Server 2005 RTM, my laptop is on SP2. There may hide the culprit.
So – a lesson learned: check the versions yourself, check them first, no matter what they say to you.
BUT STILL – did SP2 really bring such a huge performance improvement? Any experiences anyone? I’ve found out that there are some improvements with performance, but on such a huge scale? I mean, it is still three times faster on four times weaker hardware. This should call for a 12-fold improvement in certain operations, quite a feat 🙂
I look forward to this evening, when we have SP2 upgrade scheduled – I really can’t wait to see if this helps. I hope so, otherwise, we don’t need technical consultants on this project – we need exorcists!
I had no clue how good my laptop was. Seriously. Today it kicked ass of an 8-processor server.
Tomorrow we have a go-live of a Microsoft Dynamics NAV deployment, with manufacturing customized to support configure-to-order functionality. Refreshing manufacturing orders now calculates dynamic BOMs and routings, and it takes time.
Four months ago I attended a conference, where I had a chance to listen to Miha Kralj, an architect at Microsoft, talk about architectures. It was one of the best presentations I ever attended, and ever since I had this topic in queue, but never really had chance to write about it. Most of the stuff he talked about reminded me of some bad experiences about architectures on projects I’ve worked on. Most of stuff here is also not my original contribution to the universal pool of knowledge, and I reuse it with the permission of the author, so Miha, thanks! What I did, however, is that I applied general principles to specific Microsoft Dynamics NAV situations.
The biggest jeopardies often lurk where we least expect them. When implementing an ERP system such as Microsoft Dynamics NAV, what should be one of our best allies, turns out to be our mortal enemy. It has a simple name: The Standard. Standard processes, standard functionality, standard documents, standard system. All these gizmos can turn into gremlins in a blink of an unattentive eye.
Standards are tricky. If during due dilligence, or diagnostic or analysis phase, we hear the prospect or customer utter the word “standard”, what do we instinctively do? Well, in a standard system, it’s pretty obvious what the standard is, and when the customer says that they “just have standard processes” it means that these processes are just covered with such a standard system, right? So we instinctively tend to skip the more detailed analysis of these, because after all, they are standard.
It’s a well known fact that IT projects fail every so often. Standish Group has been researching the success and failure factors of IT projects for a decade and a half, and they publish their results in their CHAOS report every two years or so. According to their 2006 report, only about 35% of projects can be categorized as successful, while 65% are declared unsuccessful. In this report, word unsuccessful can mean anything from exceeding time and/or budget (46% of projects) or failing altogether (19% of them). With such a huge proportion of projects going astray, maybe there was something wrong with these projects from the very beginning. Were the time and budget unrealistic? Were the project requirements, or even objectives, unrealistic? Maybe. Or maybe not. How can you tell?
[I edited this post once again. I see that it produces a lot of confusion, because people seem to think that this is what I claim, while I tried to convey that this is what some claim, but I think is false. Therefore, I strike this altogether, and redirect you to my original column at MSDynamicsWorld.com. Please, read that, not this. Thanks, and sorry for this mess.]
[I decided to edit this post and exclude all the argumentation it originally contained. There is no need for me to argue the same topics twice, and I really recommend that you visit and read my original column at MSDynamicsWorld.com]
Microsoft Dynamics NAV is soon to grow a generation older, when version 2009 is finally released. I already wrote about this version, and how it will come with all-new user interface, referred to as RoleTailored client. The best way to describe the changes in the interface in everyday terms, is that it is going through liposuction. The fat client we were so used to use is getting thinner. Not as thin as it gets, certainly not anorexic, but thin enough to introduce certain significant changes.
The biggest change is that, for the first time ever, the new client is not going to be an exclusive Microsoft Dynamics NAV client. The customers will be able to use the client both as a C/SIDE (good old fat) client, and new RoleTailored client. The and in the previous sentence is not really an and, and there is a big opportunity to really misunderstand the plans and strategy, and a huge opportunity (or better threat) to totally mess up the system during a 2009 roll-out. Let me explain.
WinDays 2008 are over. Somehow, this conference has become a milestone, in Croatian ICT community, in Microsoft community, even in my life. I met a friend there, one of those I only meet there, and realized just how quickly the year turned. Obviously, I contemplated too much, and partied too little, something to really get worried about.
Anyway, the presentations I delivered made me think about the future of this blog. It started pretty randomly, as a place where I simply dumped anything that crossed my mind, so you had all sorts of content, from programming, to development, to functionality, to theory. When I look at my blog to-do list, there is even more chaos to it, with topics ranging from SQL optimization all the way to business process reengineering. I realized I need more focus.