Architecture: Multi-channel with WPF
As architects, we should see the world with tendencies oriented eyes, being aware of the different signals that the market shows behaving like explorers. Sometimes is a difficult task that demands us going the extra mile – I like to see a good architect as that one that can properly filter what is important and what is not. The latest trends on the consumer space are showing us that we should care about the multichannel experience. On this blog entry I am going to focus on the user experience and how affects the architectural decisions.
We should have a common programming model to develop user interfaces, but at the moment is a bit challenging with many technologies around, making very difficult to bring platforms and formats together maintaining the same consistent user experience. Some attempts using the web had brought some success but at a high maintenance cost with some unpleasant stories. This is one of the main reasons why I am a big supporter of WPF. Having a common language that can be rendered on different platforms and modalities is helping us to decide which next user experience technology we should include in our roadmaps. With a single Ux investment stream we can keep the developers team focused reducing the learning curve and optimizing the production, with the benefits of reducing cost when we need to bring a new channel into the equation. Remember that a good architect should look into this other factors that constrain the business, rather than the usual appetite for new technologies.
But nothing comes cheap; as Microsoft is pushing for these technologies we are facing challenges on the implementation side. The multiple channels today require a different sub-set of the render engine (embedded in a framework subset), making our jobs a little harder. The challenge is to find the thin line that divides the flexibility with the complexity, dividing what we share and what is custom code.
This is a good place to put emphasis in design patterns, those patterns mostly avoided not for the complexity but fear. If we put it in context is easy to separate the service layer from the user layer but things get a little more complicated when architects and developer needs to code the user layer. The most common approach is to build it as a monolithic application (from the VB times), as the separation has been done using the typical three tier model. Well, let me tell you that we are facing new challenges where this model is not applicable anymore. Consumers are demanding new ways to interact with the application; what is more, enterprises will come to you arguing why they should use certain platform to run your application. Your nightmare will not end there, operations - finally taking into consideration – will come to you demanding features to support and maintain the system that you are architecting. As I have introduced WPF as a convenient technology you still can shoot on your foot. This is where the patterns like MVP can really help you to separate the business logic of your user layer application.
A contemporary approach that I usually coach is the mindset of layer bubbling. This concept starts from the forest correctly dividing the layers, using maybe SOA approaches to promote reusability and stability (as many other qualities of service). Once you have finished the forest approach you should take each layer and treat them using the same pattern, this means that your user layer will have a view (Ux), a controller or presentation (App) and your model (Data), this approach will help you to reduce the amount of custom code that you will need for the multi channel approach.
With this type of approach you will be able to asses which parts of your applications and data will be stored where, furthermore, how the information is shared. In our specific case, the model will be the proxy interface that retrieves information from our services, then the user interface workflow will be coded separately, as it should not be compromised by the model neither the view (how is presented). In the past this model was hard to implement due the fact of the view code, coding in win forms, html, mobile was very expensive and hard to support. XAML comes to the rescue.
Another important task as an architect is to envision the future, how this architecture model will stand in time. Well, I can foresee the platforms coming together at some point, reducing the amount of gaps on the rendering engine. It will take longer to have a common framework for all these channels but at least a uniform WPF render engine will do the work. Today we have some items that are supported on SilverLight, others in WPF desktop and XBAP (and mobile quite soon), but I can see standardization in the near future.
This little architectural roadmap has shown as how important is the use of the two main architectural pillars: An explorer and an envisioner. Put them in practice!
