Strategy for building modern UX on WPF

Recently we were on an UX consulting assignment with a financial services provider in the east coast of the United States. The company had an application suite that was several releases old with monolithic user interfaces which needed whole lot of rethinking when it came to good design.
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:

Large Enterprise SharePoint(MOSS) deployment

MOSS has highly configurable and flexible architecture that can easily accommodate some of most challenging collaboration requirements in large enterprises. One of the biggest benefits to leveraging MOSS as opposed to developing your own architecture for portal/collaboration solutions is the prepackaged saleable design of MOSS that you get out of the box. However as with many large enterprises one of the more complex design choices is on how to make the collaboration solution available to its geographically distributed workforce . Broadly the choices would be to either adopt one of the following options

• Centralized solution
• Decentralized solution

In most cases a centralized solution would be recommended so that the operations, governance, High Availability(HA) and Disaster Recovery(DR) can be managed from a single location and a tighter policy can be enforced, however in some cases the network may not be as reliable or scenarios where centralization may have challenges with high latency between the branches and the central/ low bandwidth etc may cause the enterprise to adopt a decentralized solution. But how do you know which is the optimal MOSS deployment strategy in your case?

Last week we were working with a large financial service provider in North America to demonstrate the feasibility of deploying MOSS as a central solution, the strategy to improve the end user experience for a centralized MOSS solution was to:

1. Provide a highly scaled up + scaled out MOSS farm - Based on the role of the MOSS server i.e. Web Front End(WFE) or Index Server it can be either scaled up or scaled out only. Providing the right amount of scale ensures that the centralized solution can cater to the requests from users across the enterprise.
   
2. Optimal logical architecture and information architecture - the right design ensures that a single ContentDB is not the bottle neck for all requests.
   
3. Compression - compression improves performance over the wire
   
4. Caching - Caching can drastically improve the end user experience, a smart caching solution will ensure that only delta changes from previous requests are being sent over the wire.
   

Both 3 and 4(above) can be achieved by leveraging a SharePoint aware network accelerator such as Certeon, other general purpose network accelerators may be used as well, however leveraging a SharePoint aware one is always better.

As with any other large project undertaking its important to benchmark the system performance before rolling it out into production, metrics captured during the benchmark would help validate if a centralized solution would be the right choice, additionally it could provide metrics that can be used to decide if additional bandwidth needs to be arranged etc. The way we benchmarked end user experience before rolling the entire solution in production was by leveraging Shunra. Shunra can be used to capture the network conditions (latency, packet loss) between the various branches and central office, once the data is captured it can be used by the Shunra device to simulate WAN conditions in a lab. Additionally Shunra can be used to simulate what-if scenarios that may occur in your WAN. Running test scripts simulating end users and having Shunra simulate various WAN conditions can provide valuable metrics that can be used to make a more informed decision on MOSS deployment.

Performance tuning and benchmarking can be a complex undertaking, and many a times the interdependence of various network parameters during simulation and actual load on the MOSS box(es) can be confusing and perplexing, if not holistically viewed and planned it can skew the final metrics - the entire endeavor would be a waste of time if not panned and executed correctly.

Benchmarking the MOSS deployment and other design choices and rollout strategies can significantly contribute towards a successful enterprise SharePoint(MOSS) deployment. However at the end of the day its still the onus of the enterprises IT group to understand and execute the required tests prior to rollout to ensure the success of SharePoint solution. Its unfortunate that in many enterprises limited interpersonal dynamics within the IT group and lack of communication to the portal stakeholders leads to a less than desirable MOSS solution, IT group seldom looks into what the end users needs. No wonder IT is still seen as a "cost center" rather than a value center. " Technology produces its best results when an organization has the doctrine, structure, and incentives to exploit it" - a famous quote on a different context (the 9/11 commission report) however its applies to how every enterprise can strategically leverage IT.

Impact of Google Chrome Browser

Earlier this week, Google released the beta of their Chrome Browser, the browser wars have gone quite for while now and Chrome has rekindled it. Now the questions on everyone's mind are - what will be the impact of Googles Chrome browser? And why Google has released their own browser?

At first glance its seems that Google released Chrome just to get a slice of the browser market - No prize for guessing that Microsofts Internet Explorer will be impacted by Chrome, and Google vs. Microsoft rivalry is seen as the reason for Google releasing Chrome. IE may take a hit but keep in mind that Googles Chrome could take the steam away from FireFox, many of the FireFox user base would predictably move to Chrome. Chances are that even before Microsoft sees IE usage going down, FireFox usage might start dwindling.

So Chrome is set to disrupt the browser market share. Is that all? Hardly, the bigger picture is that Microsoft stands to lose much more that just the browser market share, the biggest jolt to Microsoft IMO, would be to their Software+Service (S+S) strategy. Microsoft Software+Service (S+S) strategy differs from SaaS cause Microsoft is promoting a rich client into the picture vs. SaaS which is primarily viewed as a browser only approach. Microsofts rational behind the rich client so far has been that you could not develop rich web applications (particularly business apps) using a browser only approach, and Microsoft is correct, if you had ever made an web application that extensively leveraged AJAX you would agree with Microsoft - your app would behave sluggish in both IE and FireFox. Microsoft continues to dominate the market with their desktop model and continue to promote their Software+Service model . Someone has a problem with this - that someone is Google. Google in the past has been trying to demonstrate that AJAX can be used to build very rich browser applications (such as Google Docs) and they have even built solutions like Google Gears etc to demonstrate that the pure browser rich application is very much possible. But these attempts from Google have fallen short of their expected goals - the culprit is - JavaScript . Actually it’s the implementation of JavaScript in the various browsers. Both IE 8 and FireFox have pledged to support faster JavaScript execution but Google had taken a different approach with Chrome: there is a JavaScript specific virtual machine(V8) in Chrome that manages JavaScript objects, memory and garbage collection. Chromes approach is vastly superior to how JavaScript is being managed by the other browsers like IE and FireFox. Chrome should be able to support very heavy AJAX driven application. Companies who have been shying away from building very rich browser centric application/ companies that have gone the S+S route would now look upto Chrome for a better experience and in process turn away from S+S. Thats not a good story for Microsoft.

Vendors like Adobe (with Flash, AIR) and Microsoft (with SilverLight, S+S) understand that you need to think outside the basic browser (DHTML) to build rich application, but Google is tackling the challenge from a different direction. How far can Google get with Chrome and how big a dent can Chrome make?

Big I would imagine.