Silicon Valley Musings

I think it’s safe to say that all production software is “ugly.” It must evolve in response to aggressive delivery dates and ever changing feature requirements.

I am also sure all software would benefit from a redesign and second implementation. During my career with Reuters I was involved with several such efforts. I have some general comments on the subject of redesigns.

Redesigned software introduces some unique issues when it comes to deployment.

First, there will be a period of time when two systems would need to run in parallel, the existing system and the new redesigned system.

Second, there are also issues of version compatibility and customer migration. On most Web based applications, everyone receives the new changes at the same time (i.e. the next time they visit the Web site). This is probably okay when changes are minor or cosmetic.

When changes significantly alter the user experience or require user retraining, it is best to let users decide when they upgrade. It is also best to give them a way to downgrade back to their previous version if they find the new version unacceptable.

To provide this level of version flexibility, we would need a mechanism to move client information (e.g. user login, profiles, patient reminders, etc.) from the current database to the new database, and visa versa. This would need to be done in bulk for new version updates, but also on client demand when they upgrade or downgrade their user interface.

The cost of running parallel servers and maintaining version compatibility are usually underestimated.

From the pure design and development point of view, there would be less risk in building new user interfaces to the existing back end services. It is always best to minimize the number of simultaneous changes to a system. In practice, this is rarely possible. There will invariable be changes required to the back end to support the new user interface capability. The question is can they be made without breaking the current Web based interface?

Less risk, however, doesn’t mean it would be faster to do. Many times the effort necessary to support and existing back-end introduces additional complexity. While the back-end server is more stable and backward compatible, the new user interface may be difficult to build, debug, etc.

When trying to scale a n-tier system, there are two approaches: build several independent layers will message queues between them, or configure several parallel stovepipes.

Each layer would have one to many application instances splitting the work load. This requires provides fault tolerance and scalability. But the applications must coordinate load balancing and ensure duplicate work isn’t being performed (e.g. only one instance should deliver a reminder message for a given user).

Once these issues have been addressed, the cloud of applications needs will need to synchronize its efforts to downstream applications. This can be done with a message queue.

There are several standard message queue systems: IBM’s WebSphere MQ, Microsoft’s MSMQ, and Sun’s JMS. They provide for different levels of reliability, device independence, and allow multiple contributors and consumers attach to the same queue. Both Sun and TIBCO (partially owned by Reuters) have free download versions of their JMS servers. TIBCO, for example, provides Java, C, and C# API’s to their JMS queues. See http://wwws.sun.com/software/download/products/3fbd7b3e.html and http://www.tibco.com/solutions/products/active_enterprise/enterprise_for_jms/default.jsp for details.

While using ths n-teir cloud connected through message queues is very flexible and scalable, it has its downsides. With flexibility comes complexity in terms of developing, configuring, diagnosing, and running in the datacenter.

Another approach to scalability and reliability is to just replicate several monolithic applications as independent stovepipes. Monolithic applications are simpler to develop, configure and diagnose issues. Once a single instance is running well, there is duplication software that can do “reference” installations across several servers.

This “duplicate independent stovepipes” approach does suffer from having a single point of failure for each user (i.e. if the server with my user profile fails, my clients don’t receive their reminders), but again the service as a whole is fault tolerant.