Sure so for the load monitoring they had a set of tools that where required to generate a new access solution, what this did was two things it set up logging and it would link the access front end to a Oracle backend, so they where really solutioning their data in a centralized DB as opposed to the Access database, but for the most part the users did not know or care.
I don't remember the exact load volume but once the logging hit a specific load volume that was when they app would be sent to development for an enterprise solution. monitoring the load happens via tracking the users that connected to the oracle instance and the application id that they where connecting with, also the amount of time used was tracked. Once the app passed the load tripwire we would look at the functionality of the app, turn each discreet piece of functionality into a service on our ESB and wire the access UI to the services, also views would be created in the DB to isolate the data structure that the users created away from the services being created. from here we delivered 1.0, which is basically the same app but now the all of the functionality is delivered via services and available to the wider enterprise, what would happen after this is that the developers would start to refine the data structure and clean it up, refining out duplicate data constructs and utilizing existing functionality where available. As well, a web UI would be developed an eventually the whole solution would be delivered via web technologies.
Now as for the revenue tripwire that was more of a mix of accounting and other variables they measured the amount of people that used the system to the revenue it generated, and based on a formula they would deem it critical, then same process would take place. If a system tracked the revenue that it generated, which most did, we would simply wire their Access solution to the revenue reporting service on the ESB and it would be automated, for systems that did not track their revenue, we would either try to develop a way in solution to track it, or the group would be responsible for reporting it. IF it was a pure cost center, they generally waited for the load tripwire.
I don't remember the exact load volume but once the logging hit a specific load volume that was when they app would be sent to development for an enterprise solution. monitoring the load happens via tracking the users that connected to the oracle instance and the application id that they where connecting with, also the amount of time used was tracked. Once the app passed the load tripwire we would look at the functionality of the app, turn each discreet piece of functionality into a service on our ESB and wire the access UI to the services, also views would be created in the DB to isolate the data structure that the users created away from the services being created. from here we delivered 1.0, which is basically the same app but now the all of the functionality is delivered via services and available to the wider enterprise, what would happen after this is that the developers would start to refine the data structure and clean it up, refining out duplicate data constructs and utilizing existing functionality where available. As well, a web UI would be developed an eventually the whole solution would be delivered via web technologies.
Now as for the revenue tripwire that was more of a mix of accounting and other variables they measured the amount of people that used the system to the revenue it generated, and based on a formula they would deem it critical, then same process would take place. If a system tracked the revenue that it generated, which most did, we would simply wire their Access solution to the revenue reporting service on the ESB and it would be automated, for systems that did not track their revenue, we would either try to develop a way in solution to track it, or the group would be responsible for reporting it. IF it was a pure cost center, they generally waited for the load tripwire.