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…
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.