It is interesting to see such an article published on a home grown process framework.
What is interesting to me is how close this solution is to the one I've developed independently, improved and been using for the last decade.
When I have presented this in the past to SQL user groups the SSIS question has often come up. My answer is that it can be used both independently and in conjunction with SSIS.
In general SSIS is processed RBAR, Row by Agonizing Row. There are times this is necessary and possibly beneficial. However, a process framework makes it very easy to process sets of data using stored procedures.
In my experience the performance and flexibility of a process framework far outperforms SSIS. It is easier to maintain, easier to have reusable components, easier to make dynamic and flexible processing rules. Please do not confuse this with me saying that these things can't be done in SSIS.
My advice to ETL developers is to look at this article and if appropriate try using a process framework. It is another tool in the tool box.
First, if you've had something that long that works so well, why aren't you trying to monetize it and make yourself some money? Myself, and I'm sure others, would be more than willing to check it out and if it works that well, pay accordingly.
I'd really be curious to see some benchmarking done with your framework versus a similar implementation with SSIS. I've used SSIS for the past several years to fairly decent effect on large data sets, but I'm always open to learning new things. My viewpoint tends to be a little skewed towards using SSIS because of this. Yes, there are things that I'd much rather do using T-SQL, but in most of the environments that I've worked in, SSIS tends to be the more "acceptable" approach.