Background:
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
