A colleague who works primarily in custom .NET app development made a comment to me the other day that made me reflect: "Wow, your Dynamics team really get close to the business problem don't you?".

I started my career as a software developer over two decades ago now. I've done everything from cranking out reports, supporting & enhancing existing systems to building completely new systems from the ground up in languages from Visual Basic, VBA to C# and more web stuff than you can poke a non-standards compliant browser at. I've been involved in Dynamics related projects since the CRM 3.0 days and what first got me hooked was the speed with which we could create solutions. Using a COTS product, a lot of the traditional questions (what will the navigation look like, how should we handle security, what about the forms) that would take months of analysis were answered for you already - for better or worse!

For the clear majority of us, software development or implementation of software systems is about solving business problems. As a Dynamics consultant we're not just solving coding challenges, and coding is something we do as a last resort. We're there to understand the business that we're assisting and how we can help them meet their goals. It's important for all the team members to get an understanding of the business processes and motivating factors. Are we trying to reduce costs, streamline existing processes, formalise existing ad hoc processes, creating a system for compliance sake, creating a competitive advantage or helping the business branch into a new area?

The interesting thing about Dynamics work is we then get different industry experience as we move across customers, and we can bring experience and lessons learned from these backgrounds to an engagement. We're not business consultants per se, but we're on the frontline solving business problems and that can lead to getting your hands dirty. Look away from the screen, look at the truck entering the warehouse and study the flow of activities that result. Is your software helpful, or slowing things down? Travel with the technician - what information do they need in the field, and how do you minimise the burden of updating the system for them, so they can do their job.

Another satisfying aspect of Dynamics work is getting to see different organisation cultures - do they trust their staff to pick their own queue items, or do they want a team leader / supervisor to spoon feed out particular tasks to work on? Is reporting about providing insights and empowering people, or is it about measuring performance of staff?

In the enterprise realm, software developers who specialise in custom apps might not always get this opportunity or clarity of business purpose. They build to the requirements, and their interface to the business is usually through a business analysts and solution architects. They might occasionally be customer facing, but often are in some back room or offshore. While this can happen with larger Dynamics projects as well, I find the ratio of customer facing team members is higher with Dynamics projects. Their pass mark is if the software meets the requirements - did the web service translate the XML document and put it on the ESB?

Ultimately, the pass mark of all enterprise software is about whether that software is useful. Dynamics or not, if the system isn't helping the users do their job then it will be ignored. Having the opportunity to understand your customers business and observe as much of their operations as you're able to is a marvellous use of your time and you should grab it with both hands.