Free DEVOPS Course

I’d thought I would share this DEVOPS link for those developers that might be interested.  If you were wondering where development might be headed beyond agile, this is a strong possibility.


Steve Noe

DevOps is a cultural shift that aims to leverage agile methodologies for software development. DevOps optimizes the time to deliver product value as a result of the collaboration between developers and operations. As defined by Jez Humble, author of Continuous Delivery, it is “a cross-disciplinary community of practice dedicated to the study of building, evolving and operating rapidly changing resilient systems at scale.”
This open, online, interactive course will expose learners to the value, opportunity, and insights that DevOps provides. Enroll now.

Posted in Development | Leave a comment

Entity & Field Design for charts in Microsoft Dynamics 2015

CRM entity or table design has evolved substantially overt the last few years, so I wanted to take a moment to illustrate how the CRM 2013/2015 releases have impacted how I design entities in Dynamics CRM 2015.

When I am designing a CRM relational database using entities & fields I focus heavily on ‘normalization’ of the data elements to minimize data redundancy.  There are a lot of reasons for this, so check this out here if you are not familiar with database normalization.

As with all development platforms, Dynamics CRM has it’s limitations, but the new features of Calculated and Roll-up fields helps user self-service requirements for Charts, Advanced find and forms.

Consider the following, users want a chart that is based upon data in an entity but want to group the chart data by a field in a parent entity. For example, to generate a chart of opportunity revenue grouped by Customer country, you need a field from the account entity which can’t be accessed via the charting tool. The chart tool can only reference fields in the entity it is associated with.

To build the required chart, you need to add the Customer country field from the Account entity to the Opportunity entity. Prior to CRM 2015, you needed code of some kind to make this happen (usually with a plug-in) and you needed to make modification to the forms to ensure this echoed field was read only to prevent confusion.  Not a quick change for the most part.

Fast forward to CRM 2015, and here is the quick customization no-code solution.

1.Add a calculated field ‘Account country to the opportunity entity to match the Single line of text field in Account, and select calculated as the Field type.    image

2.Use the following formula to retrieve the account valueimage

3. Build your chart.

Simple, no-code, and done. I really like the fact that I no longer have to worry about the data getting out of sync with this solution.

I hope this give you some ideas to think about.

Stephen V Noe
Application Architect

Steve 2015

Posted in Database Design, Dynamics CRM | Leave a comment

Tracking Certification Activities using a Rules Engine

In our last project for a medical certifying board, one of the challenges was to design a replacement for the legacy code that tracked the activities candidates were required to successfully perform to become certified. Certification related activities included many types, including: Training, Examinations Surveys, CME credits, attestations, work history and references.  There are different specialty certifications and cohorts (a group of candidates during a specific time frame), each with a different set of rules and activity types. The challenge was to support individual rule sets depending on a specialty and a cohort AND to be maintainable over time. 

We proposed a configurable rules engine that would be able to abstract the certification activities and store the rules as CRM data rather than code, using the data parameters to define specific requirements, time frames, prerequisites and the like. After

By the time the project was finished, we built three different engines: Training, Certification and Recertification using Microsoft Dynamics CRM as the data repository.  Each engine handles different kind of activities, supports multiple rule sets and versioning.

This was accomplished using Dynamics CRM C# plug-ins that are designed to fire on specific status of Certification activity records and apply the rules to the new activity and update the certification status.  This is much easier to write about than to accomplish; the engines were built over a 3 year period. 

Just as the first engine was initially delivered, an unexpected rule change was required. The new  rule change was able to be configured quickly, so quickly that it was apparent that the new rules engine was indeed up to the challenge.  No programming changes were needed and the board users were pleased. This validated our design, and we proceeded to design and build the other two engines.

Mind you, some new rules do require programming.   You can only build in so much at a time, but programming maintenance was reduced significantly. All three engines are now running in production successfully.

Here is an example of a certification status from the Training Rules Engine:


Here are some of the training rules:


For more information on our rules engine designs, please contact us via the contact page at

Stephen V Noe
Solution Architect


Posted in Certification, Dynamics CRM, Rules Engine | Tagged | Leave a comment

Lessons learned: Legacy Software Replacement using Dynamics CRM


For the last four or so years, I have been involved in a legacy (existing) systems replacement project for a certifying board. The legacy  software managed a database of information collected about constituent training, examinations, certification, re-certification and licensure. It involved over 400 SQL tables created over the previous decade or so. 

The prior software platform was old and no longer supported the organizations needs. Due to the tightly integrated nature of the systems it was difficult to isolate the individual sub-systems to allow a phased rollout, although we were able isolate some of the functionality for phased approach.

The tool chosen to build the new system was Dynamics CRM to facilitate rapid application development. The client team was not familiar with the tool prior to this project. We were called in about 1-2 years to work embedded with the client team.   Our roles included requirements gathering, database design , development, Microsoft Dynamics CRM training and mentoring. The project started with Microsoft Dynamics CRM 4.0 and was later upgraded to Microsoft Dynamics CRM 2011 for later phases.  I am happy to say the project has gone live and the bulk of the work is complete.  It has been an interesting journey.

Some of the “Lessons learned” include:

1. It’s all about the data! Redesign of the database should consider not only good database normalization (design to minimize data duplication), how the development tools (Dynamics CRM) consume data (in CRM for charts and views),  AND to ensure it is possible to convert from the old data format to the new data format verifiably.

  • Expect that historical data will be flawed, especially data converted in previous upgrades.
  • Use existing utilities (SSIS, Scribe, etc.) to address data migration and synchronization.  Home grown solutions always take much more to do even if it doesn’t seem so at the beginning– scope creep is a given here!
  • Create data maps to help specify source and target fields to assist the conversion team. Be sure to keep them up to date as changes will inevitably happen.
  • Keeping the old and new databases synchronized as you implement can be problematic and more expensive that you might think. Bi-directional synchronization is even worse. Organize your development to minimize syncing as much as possible and wherever possible, group modules around defined interfaces.

2. Training the team in a new tool is fundamental. Train & mentor the entire team to ensure good use of the tool’s supported features.  You will burn more in lost productivity then you will spend in training to avoid it.

  • The solution architect must be an expert with the tool to help guide the team as there are many ways to apply the tool set. If your team is new to the development tool, consider hiring or contracting a solution architect experienced in the tools to be used.
  • Business Analysts and the Quality Assurance team need to understand customizations and processes that can be done using the tool or the solution architect will need to vet their recommendations to ensure efficient use of the tool. One side benefit is that the BA’s can create prototypes for review by end users before any code is written, reducing development changes later.
  • Developers also need to understand the tool to ensure that they don’t code solutions already support by the tool and to ensure they do not code is such a way that they might. Training in both customization and development using the tool is critical.

3. Agile implementation is great, but….the overall database design needs a longer term view to ensure individual modules will interface properly before each sprint is defined.

  • Organize your development to minimize sync’ing as much as possible.
  • Wherever possible, group modules around carefully defined database interfaces.

4. When upgrading to a new version of the tool during a long term project, isolate the tool upgrade to a dedicated sprint and do not add anything else to that sprint.  After the upgrade is tested and validated, then continue with other development.


Thanks for reading!

Stephen V Noe
Solution Architect


Posted in Uncategorized | Leave a comment