Like all good enterprisey development organizations, Jerod’s has an Enterprise Architecture Group that’s responsible for maintaining the Enterprise Framework. And like all good enterprise frameworks, Jerod’s is several dozen megabytes chock full of helper classes like IEnterpriseAuthenticationProviderFactoryManagementFactory.
Jerod does his best to avoid using the Enterprise Framework, but sometimes enterprise happens and he has no choice but to include it. Usually, it’s not that big of a deal, but when he was tasked with building a Windows client application that would be frequently deployed to mobile employees over a VPN over a cell-phone data connection, he needed to find a way to trim the size of the framework.
He only needed a single class – an “enterprise configuration provider†that, essentially, was a shoddy replacement for DNS – and, in theory, he’d only need a single assembly and maybe the small handful it referenced. Of course, in reality, every assembly seemed to reference every other assembly, and Jerod couldn’t figure out a way to separate them. So he turned to a dependency-mapping tool.
And after that tool crashed under the sheer weight of the Enterprise Framework, he turned to another tool. After struggling for a bit, it finally produced a dependency diagram.
Although he was never able to simplify the deployment of the framework, he did find a new desktop background.