The applications had thick and thin clients with related functionality built using Delphi and VC++. ActiveX controls were used to provide rich functionality inside thin clients.
The company was facing problems in key areas:
Upgradeability - This was a major challenge with clients using different versions of the applications and turned into a nightmare when considering client specific customizations. It’s not uncommon for an upgrade to bring down the entire system.
Manageability – Custom formats, policies and use of certain terminologies made the applications very hard to manage. There was a sore need for standardization across the system.
Interfacing - Use of several proprietary protocols for communication was a priority issue. It was not an easy task for a third party to sync up with the applications.
Reuse – This was a major pain point with duplication of modules and controls across product lines. The sheer vastness of the codebase aggravated the problem. A careful look leaves one with an impression that things could be lot simpler.
Due to budget concerns, there was a crying need to get out a minimal set of functionality that would make the necessary difference. Hence it was out of question to make server side changes or modify the existing communication strategies.
After some discussions we were able to buy agreement across all quarters to base the entire application suite on thick clients and build them using WPF. XBAPs (WPF application hosted inside a browser window) were considered but sidelined, as the limitations weighed down on everybody.
Fortunately, we had a functional consultant working with us, who made life easier by addressing the need for reuse in the user interface and raising a clarion call for standardization.
On the technical side, couple of things were evident. There was a huge potential for identifying common behavior across applications and putting them into well defined silos. There was potential to turn the monolithic user interface screens into composite ones through use of frameworks such as composite WPF (aka Prism). However considering the limited budget and the significant analysis effort that is a norm for turning a massive monolithic application into a composite one this idea was dropped. However we decided to take forward the patterns & techniques that inspire composite applications such as MVC, dependency injection etc in principle into the proposed solution.
We spent time identifying the “commonality” in UI behavior across several applications. We could notice exceptions but there was a significant amount of functionality which could be considered identical/related if only we could externalize the “difference”. For example the data load operation would be identical if we could account for the difference in terms of target controls, and the query used to pull the data. Same with the lookup operation. We had our laundry list ready.
We went one step further with the MVC pattern by suggesting a generic controller for all common operations apart from application specific controllers. The generic controller could be driven by rules that could be externalized. This would significantly reduce the client’s code base and vastly improve maintainability of the system. We recommended ClickOnce as the distribution strategy for solving the problems associated with upgradeability. Initially we were toying with idea of keeping the XAML (a language for defining the user interface in WPF) loose by bringing it into context only during runtime. This idea had to be dropped as it addressed the distribution problem which was not a high priority thing for our client.
After that it was more of identifying “modules” for various elements in the presentation layer architecture. We considered using Enterprise Library for the infrastructure part (logging, caching, exception handling etc). Finally we identified a layer for interfacing with the application suite’s core services and a library for defining common types.
A sample architecture diagram below:
Posts
