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.
When architecting a solution, there are some patterns to be aware of. Patterns are predictable and recurring events. Once we learn how they come and go, we may be better at spotting them, and handling them accordingly.
Some of the bad patterns that Miha exposed in his presentation are these:
- McKinsey Sindrome: We know what they need, we don’t need to listen; they don’t know what they really want; we’ve seen it all, we have answer to all 17 possible situations so it’s just a simple redelivery. Have you met this one? Oh, I have. I’ve seen consultants knowing all about business processes, business problems and customer needs, configuring the application without really paying any attention to what the customer really needs. It’s so easy to fall into this trap with NAV especially if you are non-technical application consultant and if you are working in a vertical where you have a lot of experience. Watch out! Your one-size-fits-all solution may not be the best solution, or might even not apply at all, to the problem your customer is facing. The cure? Listen. Listen, then listen some more.
- Obedient Butler: This is the opposite of the above. The customer is always right, and it’s your job to satisfy them fully. Whatever they ask for, you deliver exactly as they asked for, no questions asked. You want an elephant? No problem. Do you want an African elephant, or an Indian elephant? Sir? If you approach your NAV projects like this, you will start developing, instead of implementing, and whatever you end up with will bear little or no resemblance to Microsoft Dynamics NAV. Ever seen those Sales Order forms with red, green, blue and yellow fields, intermixed between the tabs, with buttons and icons all over? These happen when you let your customer do whatever they want with standard application. It is impossible to maintain it and it’s a nightmare to upgrade it. It’s very easy to fall into this trap if you are highly technical consultant with can-do approach and genuine wish to satisfy your customer. This is great and noble, but you should be careful. How? Learn the standard application, the standard processes and why they work in practice, or why they don’t. When your customer asks for a pink button right in the middle of Customer Card form, explain to them why it is better to add a Functions menu item.
- Napkin Doodle: Ever attended a lunch with a customer, and they took the occasion to explain a new requirement to you? All of the documentation you got was a paper napkin on which your customer scribbled some “specification” of how what they need should look like. It was such a simple requirement – there was no need for in-depth explanation. You return to the office, and give the gist to your developer, then shoo them off to go code. When the developer is finished, not only you find out that it’s not what the customer needed, but you spend weeks tweaking, bending and tuning it to exact needs. How to handle this? With specifications. Document what you intend to do and how, then get the agreement from the customer. Then go and develop it.
- Documentation Overkill: This is the exact opposite of the last one. Let’s write a hundred and fifteen pages of specifications. For a lookup form. Oh my.
- Start Small, Grow Fast: Just a couple of users will work with this, if we need to scale later, we’ll add scalability. Oh yeah. NAV doesn’t really scale well. Developing new customizations over it, without paying attention to scalability, doesn’t really help. It’s much easier to think about scalability up front, and design the solution so it is scalable, rather than forgetting about it until it’s too late. The key? Design the solution before you develop it, while asking yourself how would it behave with 200 users working with it concurrently.
- Reinventing The Wheel: We can do it better; we trust our code, and our code only. This is dangerous. This can sink projects. I’ve seen a project where the consultant decided that Dimensions functionality in NAV doesn’t really work well, so they decided it would be better to rewrite them as they should be. The project was never finished, and the consultant went out of business. Those who don’t know NAV well, and are unsure about what they do know, are quick to fall into this trap. When a customer asks for something new, try to see whether it already exists in NAV, even if it is similar, but not exactly there. Work with your customer closely to see whether it will work for them anyway – sometimes it will.
- Sales-Driven Design: I sold it, now you just implement it. I adore these 🙂 These happen when you let loose the salespeople who don’t know list from card, and have them talk to customers. But of course, we have manufacturing module in NAV, we can handle all your book printing requirements out-of-the-box. Yep.
Simple and obvious as these may seem, these do happen. Being aware of these anti-patterns can really help you in implementing better solutions.
These are few of those that I remembered, that really reminded me of real-life situations I’ve seen. Of course, there was some talk about good architectures too, and how generic thin middle layer architectures (middle-out architectures) with no dependency on use and implementation can really do miracles. An example is TCP/IP which is now ubiquitous, and when it was conceived, nobody could have imagined what it will be used for. Unfortunately, these don’t really work with NAV, because of the simple fact: most of architecture is already there, and you can’t change it. So at the very least – try to avoid these bad and ugly ones.
