localising software Part 1: retrofitting adaptive behavior

Sooner or later, a modern software app will need to spread its wings and go global, making itself available everywhere – or failing that, at least available in lots of different countries. Or failing that, available to lots of different regions. Or clients. No matter what the type of spread is, the inevitability of catering to different sets of end-users means that software needs to be built with some kind of customisation in mind right from the start.

But what if you you’re retrofitting such adaptive behaviour to an existing application? Before you get bogged down in the quagmire of international language codes and glyphs from utterly alien fonts, understand the larger picture (adaptation) that your efforts need to be a part of…

Adaptation is not change.

a) A change is something that is introduced into a software application and which remains there, for all instances of the application at all times and in all environments until that change/feature is removed. Adaptation implies that, under certain circumstances or in certain environments, that item / feature is not available – for the same application. Therefore the effort to introduce adaptation is two-fold: the required adaptation should come into effect as prescribed, but equally importantly it should be inactive in all other circumstances.

b) Adaptations are normally regressive / “backwards-compatible”. Changes don’t have to be. In other words, new adaptations should normally leave all existing adaptations and changes unharmed.

Levels/types of Adaptation

Usually adaptation at the presentation layer requires, as you can imagine, less effort than behavioural or structural adaptation. If you simply have to change some colors for a new rollout of the same application, it should cost you less in terms of development effort than it would to rip out the guts of the application so that it supports an entirely new way of doing things. (And if the above isn’t true for your app, there is something wrong with it).

So there is a sort of scale of adaptation, going from ‘easy’ to ‘hard’, roughly along these lines:

1. Skinning  (presentational)
2. Localisation  (presentational)
3. Customisation (behavioural)
4. Structural

Think long and hard about where on this scale adaptations for your app are going to occur. Also bear in mind that from an end-user perspective, all adaptations appear to be level 1 (presentational). If your clients think something is just a skin job, they might lull your organisation into actually believing this, when in fact it’s a knee-deep-in-the-architecture job.

Adaptation Persistence (for want of a better word)

This is a bit of an upside down / inside out concept. The persistence of a particular adaption does not vary directly with how desirable it is. Generally, the less persistent the adaption (during the lifetime of the application), the more flexible it is.

So again there is a sort of scale moving from more persistent modes of adaptation to more flexible ones, as follows:

  • compile-time adaptation : adaptations made at this point occur once, and persist for the lifetime of that software build. I can’t think of any advantages of this, other than a one-off job or branch that will never be revisited.
  • startup/instantiation-time adaptation : adaptations made at this point can occur as often as the application is started up. While the distinction between at-instantiation and at-compile-time adaptation is moot for most standalone/desktop applications, it is definitely relevant to services (which eventually are restarted every so often) and they are *definitely* relevant to online / Web applications, where instantiation occurs practically with every http request.
  • realtime adaptation : in this scenario, an application constantly re-adapts to the environment. While the most flexible approach, it also may incur the most overhead in terms of communication and time lags (fetching data, repainting and re-rendering etc).

So based on the needs of your application, you should choose wisely. The second option (at-startup adaptation) is a good middle road.
Final points and some gotchas

Confusing the levels of adaptation with each other generally leads to loss of time and money. There need to be some good clean lines in each organisation as to what constitutes a reskin, support for a new locale, customization or ripping the guts out of the application. There also needs to be a thorough understanding of how the different types of adaptation are related.

An application which has a very hierarchical, compartementalised architecture allows a simple chain of complexity (increasing from presentational to behavioural to structural adaptation). This simplifies estimation, project managment and development tasks that relate to adapting a software application to a new environment.

An application which is structured otherwise may have more of a planar relationship between the different types of adaptation. Support for a new locale might involve heavy customisation, for example, The nature of the application directly impacts adaptation, so no two adaptation projects are the same.

In the next post on this topic, I will talk about presentation-level adaptation and how to manage that effectively.

Leave a Reply

Your email address will not be published. Required fields are marked *