I did an engagement recently where a client wanted to create a windows forms application from an existing legacy application. The existing legacy app was important but relatively simple in terms of architecture.
While the MVC can be a good choice as far as a general pattern goes, and the CAB a reasonable application block, in this scenario I thought it was quite a bad decision. The team responsible for development had no real idea how to implement MVC properly, had never done anything remotely like the CAB before. Patterns such as Inversion of Control / Dependency Injection were very new and complex to them. The recommendation was simply a formulaic response to a problem that did not suit the context.
In reality, the team could not have delivered the application in their required timeframe, with their current skillset.
What’s the moral of this post? Well, more as a warning. Standard patterns and accepted trains of thought are good in general, but don’t recommend or use architectures just because everyone else is, or they are the current implementation flavour of the month. As an architect, assess not just the technical details, and possible ways of designing the solution, but also how that fits in with current social issues such as team skillsets, experience, likelihood of success and current needs. In this example, the legacy applications architecture was very simple. The architecture I ended up proposing was in itself quite simple (in fact overly simple), but achieved the goals of modularity, loose coupling, expandability and ability of the existing team to deliver it. It also allowed further complexity and patterns to be introduced where necessary and as required, but it certainly wasn’t required from the outset. Small Steps.
Its easy to make a simple thing complex, but its a much much harder task to make a very complex thing simple.