OK, so now you know my feelings about the way that some organisations look at implementing COTS solutions. Now, let me fill you in on another one of my pet architectural issues: the use of web broswers as a UI for applications.
I recall the history of the IT industry through the 90's well. There were three main factors at work - the growth of PC, the growth of Windows and the growth of everyone against Microsoft. Three periods existed, at least as far as client development was concerned:
-
In the early 90's most applications were accessed from green-screen terminals or terminal emulators (and this is still the case today for a lot of applications).
-
In the early to mid-90's the increasing popularity of the PC and Windows drove the use of the PC as a client, for both standalone and networked applications. Enter client-server computing, and all the problems that went with it for the brave souls that tried it. From a Microsoft architecture perspective client server was characterised, generally, by Visual Basic (or C++ for the hard-core) client applications with ActiveX controls and DLL accessed through COM on the client. The server would host more Visual Basic or C++ code using MTS. Communications between the client and server generally utilised DCOM.
-
In the late 90's people found ways to make use of the web browser, which had grown in use from the mid-90's, as a platform for hosting application user interfaces, driven by the issues with client-server (outlined below), the increase in the use of the Internet and a desire by some quarters to move away from the Microsoft platform.
Whatever the technical model used for the development of client-server applications a number of common problems existed:
-
Issues with deployment from a remote installation, remote management and bandwidth perspective;
-
Issues with versioning and conflicts with shared components (DLL-hell);
-
Issues with the use of DCOM through firewalls given its less than friendly use of ports; and
-
Issues with the performance of DCOM on the network.
Now, all of the above are good reasons for finding an alternative model, and in the 90's the browser was the chosen model because it provided some form of solution for each of the above issues. I, like a lot of Architects at the time, argued for why we should go from the more user-friendly client-server model to the more IT-friendly browser model and then set about building browser-based applications with CGI and ASP. The issue is that while the browser solves deployment problems for applications, from three important perspectives the browser is a huge trade-off:
-
From an end-user perspective browser applications are slow and screen refreshes are painful. Integration with Windows and with other applications is generally limited.
-
From an IT perspective browser applications are very expensive and time consuming to both develop and maintain due to the amount of code that is needed in each page to simply display and manage data.
The challenge of the above issues, of course, is that as more end user functionality that is delivered more code and therefore complexity is required. It is almost impossible to achieve a viable trade-off between usability, requirements, capability and the amount of code and complexity.
Logic would suggest that once the above issues with client-server had been solved we would all swap back to that model because it would be so much better for the end users, right? Well, for some reason this has not been the case. Most IT departments (and most architects) simply make a decision to use a browser model simply by not thinking about what other options might be available.
There are a number of technologies available today that have been available for some time that allow the development of user interfaces for applications that solve both the majority of problems with the use of browsers and at the same time provide answers for the problems that drove development to browsers in the first place.
These technologies include:
Each of the above are different in their approach and capabilities but each does offer:
-
Some form of smart deployment approach that avoids conflicts in its architectural design;
-
Some form of security mechanism to protect both the user and data;
-
A development model that makes UI development much faster and easier than browser development; and
-
Faster, friendlier and more integrated user experience than browsers.
This is an area that interests me greatly so I will be posting more in the near future. For the moment though, let me provide the following architectural principle:
All applications that are used by an end user for more than an hour per day (this includes all line of business applications) should be developed as some form of rich client. The form of client development technology used is dependent on a number of factors that I'll cover in a later posting. Browser development should be limited to occasional use applications, such as online retail banking, airline reservations, leave requests and so on.