CTO Articles

Home > News > CTO Articles

Published in IT World
November 14, 2006

Solution spheres and application cubes

Today I want to talk about the relationship between the word 'solution' and the word 'application'. A relationship that I think is key to understanding a key question in the world of IT, namely: 'How come solutions built with off-the-shelf application X are invariably nearly, but not quite, complete solutions to the original problem as expressed by the customer?"

What application am I talking about here? I am talking about every off-the-shelf application there is. Substitute 'X' for anything you like, Web Browser, Spreadsheet, Database, Word Processor, 4GL, ERP system...At the level I want to talk about, these things are all the same.

I have now painted myself into a corner and have some serious explaining to do. That's okay. I like a challenge. How to start...Let's try an analogy with spheres and cubes.

I sometimes have synesthetic moments with words. Moments when words become pictures and pictures become words. Sometimes these synesthetic moments lead to analogies I leverage in my day job. I intend to foist one of said analogies upon you now. Brace yourself.

When I think of the word 'solution' as in the much used phrase 'IT solution' or 'system solution' my mind's eye conjures up a sphere. A beautiful, smooth-surfaced thing about the size of a beach ball. (My one is silver. That detail isn't important though.)

When I think of the word 'application' as in the much used phrase 'application solution' or 'custom application development' my mind's eye conjures up a cube. A starkly beautiful, sharp edged thing a little bit smaller than a beach ball. (My one is pitch matt black. That detail isn't important though.)

Once I understand what a customer wants out of an IT system - the solution takes shape in my head as a sphere. When I look at all the applications I could use to build the solution, all I see are cubes - each of them slightly smaller than the sphere. Now, think of the area contained within a sphere as the overall solution space. Think of the area contained within a cube as the overall application space. No amount of manipulating a cube will make it occupy the exact same area as the cube. The solution space is annoyingly larger than the application space. The best you can hope for is to have the vertexes of the cube touch the sphere at 8 points [1].

Using an off-the-shelf application such as a database or a spreadsheet or an application server to build a solution is akin to grabbing a 'best-fit' cube to sit inside your solution sphere. The remaining gaps, the areas where the cube needs to be rounded out, are the areas where you will require custom coding and custom application development to do.

And finally we arrive at the heart of the problem. The better the initial fit between the required solution sphere and the available application cube, the harder it is to round out the latter to fit the former. Sad but true.

Example: 4GL applications like Database Forms/SQL allow you to build database-oriented applications very quickly. If your required solution sphere is primarily database-oriented then you can get most of what you want done very quickly indeed.

Example: Groupware applications like Lotus Notes, Microsoft Exchange allow you to build groupware oriented applications very quickly. If your required solution sphere is primarily groupware-oriented then you can get most of what you want done very quickly indeed.

Etc. etc.

The problem is that you pay a price for the initially maximal fit between your solution sphere and the application cube. Rounding out the sides of the cube will be, in the best case, very hard and in the worst case, impossible in my experience. Sure, there will be tools available to help you do the rounding of the cube. Custom 'plug-in' architectures, APIs for custom modules, built-in scripting languages and so on. However, in my experience you will find a nasty asymptotic relationship[2] between the solution level you want to reach and the development curve that is trying to get you there.

The alternative? Start with a much smaller cube in the form of a programming language and perhaps a bunch of developer libraries. Now you have much more control over the degree of fit between your application and the solution sphere. Of course you are now coding at a much lower starting point. The degree of fit you can expect to get in the end will be higher but it will take you considerably longer to get there.

So choose your cube size carefully! Rapid, visible progress is easily achieved by starting with big cubes but the price will be paid towards the end of the project. Painfully slow progress will result from starting with small cubes but you can get a better solution fit in the end. Neither approach is perfect. Neither can be 'fixed'. Spheres are spheres and cubes are cubes.

Deal with it.

[1] http://simianfarmer.blogs.com/photos/uncategorized/cube.jpg
[2] http://www.abcbodybuilding.com/hull.h1.gif