Pioneers of "Agent Training"
A major player it the CRM space wanted a faster and more reliable way to build software. They had quality problems because their software framework was so big. The core business did not receive focus because of all the fires that must be put out.
A prominent company that builds web and Windows applications to monitor and train tens of thousands of agents needed a software framework. The database had hundreds of tables and was not perfectly designed (like most databases) and we did not have the benefit of redesigning it from scratch. We were able to make some improvements but in general it was what it was. Their people had built some very nice applications but were having problems when doing day-to-day modifications. Changes would need to be made in all the places that access a particular table, field, relationship, etc. As the application got bigger, it was getting more difficult and time consuming to make any changes to the structure of the application.
We reverse engineered their database into a Widgetsphere model. Once there, we generated the code for database access and began to retrofit their application with the generated objects rather than in-line SQL, datasets, and direct object manipulation. Instead of using a "Customer" datarow and performing all the checks and sets that need to be done, we not had the advantage of using a "Customer" object. As far as the developer was concerned, there was no knowledge of the database. He need not be concerned with the structure or the idiosyncrasies of database programming. As far as he is concerned he has a "Customer" (Order, Appointment, etc) object with a name, id, address, etc.
The real advantage of this is that all of the custom load and save code was in one place: the generated object. He never again needs to write any database connection code, selects, updates, etc. He could treat his new objects as if there were just normal C# classes.
Now changing the database was easy. We opened the model, added a table, field, etc and then regenerated. More importantly we could change something about a field, regenerate, and the application would not compile until we fixed the UI that referenced the generated object. We have turned run-time errors into compile time errors. It is always better to know your errors at compile time, unless you like flying to a customer site to be yelled at.
Now they maintain their existing application with far fewer developers and can concentrate on making more innovative products instead of maintaining an application they wrote two years ago.
|