Yesterday I started by describing SOA and touching on part of it's goals to create an implmentation agnostic environment.  I then described an enterprise where instead of following the SOA, they were taking the parent WinForm model.  I said I would come back to their reasoning for this.... well the basic reason is that the organization doesn't trust their developer's skill set and thinks (incorrectly) that this model will force developers to build code that uses their services.

So the first thing to note is that the organization has services and in fact the applications need to use these services.  Unfortunately the services aren't well documented and the interfaces aren't always clean.  As a result their developers haven't always been consistent in using them.

Aside from the obvious issues with not being able to 'trust' their developers to do things correctly, the proposed solution doesn't actually solve the supposed problem.  For starters, if the work arounds that allow developers to access data directly or log incorrectly aren't resolved, then the custom code that is hosted in the form will still be wrong.  Next up part of issue is the amount of time to train developers to use these services.  So instead of spending time better documenting the services, this organization instead created another piece of software that they want developers to use.

The result is now developers need to learn how to interface to this common frame since their user controls will need to use a custom protocol to communicate with common elements such as the tool bar and the menu.  Thus instead of being able to work within the framework provided by Visual Studio developers need to spend time implementing to these custom interfaces.

Of course since this is a new set of 'interfaces' related to the common frame there is limited documentation and oh yeah you have to train developers to use this in addition to the existing interfaces that they still haven't documented well for their other services.

But my favorite claim was that since they had already taken the time to produce the windows frame project this model would reduce development time.  So let's consider this claim... for starters the savings don't start until after you make up for the time spent actually developing this project.... and since that required more then 1 engineer, plus design specs, reviews and other fun little tasks that add up to costs that is a really big hurdle.  But worse that's only if it works and well let's consider an example.

In our first review of this new framework a question came up about the fact that the toolbar in the new Whidbey based project would be dockable.  OOPS  dockable toolsbars? why who would've thought... so off went the development team to try and make it so that their custom framework woudn't remove a UI feature... the question of course - what other surprises await when we actually have to implement a system on this custom framework.