• silicon.com
• Management
• CIO Insights

By Martin Brampton, 10 January 2006 07:00

COMMENT

Finding a simple solution to a complex problem is never going to be quick or easy, says Martin Brampton.

There are some perennial topics in IT and one of them is complexity. One feels that King Canute would have been at home with many of the arguments. We hear that chief executives will no longer tolerate complexity, as if it were something introduced by the self indulgence of delinquent techies.

Recalcitrant facts unfortunately intrude here. With so much emphasis on time-to-market and cost cutting, the pressure is on faster results. Yet creating simple solutions is harder work than creating complex solutions. All but the easiest problem will, if tackled in a rush, lead to a messy solution that is anything but simple.

Maybe we could get smarter, so that what once seemed complex will be revealed as quite simple after all? But that is liable to go the same way as most self-improvement projects. How many New Year's resolutions are already dust, let alone if we wait for the summer?

No, a simple solution generally comes about through a lot of hard work. And when it is finished, the solution might look very little for the amount of effort it took. While it is likely to be more expensive and take longer in the short term, if it has a long life it will almost certainly prove cheaper and better over its whole lifetime.

Sometimes the complexity can be managed by containment. If a project can be kept inside a boundary that presents a simple interface to the outside, then the solution will seem simple. This is one of the factors in the success of mobile phones. It is easy to expose complexity to the user but the best designs seem intuitive in use and people like them better as a result.

I'm working on a problem that faces this issue at more than one level. The Mambo web content management system needs a new mechanism for handling access controls. As websites grow, webmasters often want to serve special groups with exclusive access to material; the number of groups and the nature of what they can do easily becomes complex.

There are several layers to this problem. First of all, there is a need to decide who the actors are in this scenario. One might think that users are involved but developing on that basis misses a significant opportunity. There may well be situations when the bearer of access rights is another website, or a centralised administration server.

So the first issue is to define the problem in terms that have as much flexibility as can be accommodated in a way that avoids undue complexity. The next step is to design an implementation of mechanisms to store the information and to answer questions about whether to permit requests or not.

Up to now, the issues are relatively simple and current thinking is commonly spoken of as role-based access systems. The data needed to define access permissions that can easily be stored in a couple of database tables and the questions and basic administration operations handled by a modest amount of program code.

Unfortunately, the nature of the problem is such that there turns out to be another issue where the complexity is liable to explode. The basic mechanism is easily flexible enough to handle a very wide range of requirements - but finding a simple user interface for managing the permissions turns out to be difficult in all but the most straightforward situations.

This is typical of IT problems. Handling complexity is one of the various trade-offs that have to be made. There is no more a general solution to the problem than there is to persuading people to always be nice to each other.