Posts in Category: architecture

Keys to Architecture Diagramming

I’m not a big fan on spending an inordinate amount of time on diagramming solutions or concepts down to the nth detail primarily because that level of detail will always, always, always change and you will be left with outdated diagrams that when someone goes to look at what they are will be confused.

I am a big fan of drawing out ideas on the whiteboard though (big fan) and do realize that these diagrams have their place in getting people on board to adopt a solution.

Hence, keys to putting together an Architecture Diagram that people will get behind.

  1. Make it Simple – if your diagram is overly complex with icons all over the place, simplify it, break it into multiple diagrams.  If you can’t understand it and describe what is going

    Read More


Patterns on Bulk Data Migration

No code in this most, well maybe a bit.

I’ve been working on a number of data migrations over the past few years using a variety of tools, from off the shelf solutions to home grown, I’ve run everything in between.

All of them have their hits and misses and this isn’t to harp on one over the other as I continue to refine my approach in getting data into Dynamics in the most efficient way possible.

My current investigation into how to optimize this process has lead me to consider what the most important pieces for a solution to work are;

  1. Make it As Fast As Possible.
  2. Being able to handle Concurrent Connections (i.e., multi-thread and parallelize it until the cows come home).
  3. Accessible in the environment that the user operates in (read: if you’re

    Read More


What a Concept?

If you’ve been reading my old blog ForgottenCoder for a while, you know the focus has been primarily on Dynamics and anything that breaks off of it.  Forgotten Coder was a fun experiment but I wanted to keep the focus going on Dynamics and what I learn through it and make that content a little more organized.

Hence, 365Concepts.com.

(that’s it, no other big reveal, thanks for reading, contact if you have questions).

Read More


Comments are King

///

That is all it takes to explain what you are doing, why you are doing it, how you are doing it and where you will do it.

It’s not rocket science, it’s not complicated, it doesn’t add hours to your coding effort and in some cases it has the potential to be an added dose of humour to your fellow colleagues as you work through a particularly stressful problem.

Comments were put to me in the best way possible years ago…

Imagine the person behind you is a Crazed Serial Killer and your lack of comments will be the tipping point for them.

Comment your code not only for your team, but for yourself, so you remember why you wrote it, what stress you were under and why it shouldn’t be refactored.

Dynamics Plugins and

Read More


Don’t use your Methodology as a Band-Aid

I can’t remember a time when software development methodology was not a hot, contentious topic of discussion.

“We need to be Agile, because that will make us go faster”

“Scrum will save us from everything we are doing wrong”

“Waterfall is the devil’s child”

“Design Patterns are the only way to go”

“Design Patterns don’t work for me”

The problem with every architecture style and delivery methodology (new and old) is the same as it was yesterday, last year, five years ago and most likely in the 80s.

We refuse to look at what the problem is that we are trying to solve and instead are content with slapping a band-aid on it and calling it “fixed, because we now have #INSERT FAVOURITE METHODOLOGY HERE#”.

If you are not will to identify what is wrong with your delivery

Read More