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. I also realized that there are many blogs covering technical stuff, and not too many covering the business part of the Microsoft Dynamics NAV. The true value of a business management system does not come from how technically perfect it is. There is much more to it. And there is so much more to implementing a solution than just programming, coding or hardcoding, pick your fancy.
There are three areas that I will try to focus on:
- Implementation. What does it take to get from a problem to a solution? Many things. Implementation is a lengthy process involving many different people, who all need to work in concert towards the goal, which better be a common one. Has it happened to you, or was it only me, that people involved in an implementation didn’t really have a common goal?
- Architecture. This one is often out-of-office when systems are built. Instead of giving them a proper thought up-front, many systems just go next-next-next-finish before they let programmers in to finish them off. Sure, you can build a shed with no planning. But when building skyscrapers, you architect them first, so they don’t collapse at the first breeze. Or any breeze. Or a hurricane, whatever. But when building ERP systems, the no-architecture is more common than any other, and non-out-of-the-box architectures are often frowned upon. You can’t build a system for 1.000 users the same way you build it for 10, you simply can’t. No wonders why we have all grown so numb to software being unstable, and why it is OK for an application to crash occasionally, and it’s not OK for a house to do so.
- Methodology. It is funny (or is it grim?) how many projects trip over this one. Again, when building skyscrapers, people adhere to best practices, and proven methodologies. But when building ERP systems, for one reason or other, people sometimes tend to reinvent the wheel. Probably all previously built wheels weren’t round enough or something. Scary stuff.
These three can be easily put under a common denominator: best practices. I hope this blog grows in that direction.
