THINK

Meetings, Planning, and Corporate Process Can’t Build Better Systems

IBM used to make extensive use of the simple catchphrase “THINK”.  

Wikipedia : At an uninspiring sales meeting Watson interrupted, saying The trouble with everyone of us is that we don't think enough. We don't get paid for working with our feet — we get paid for working with our heads. Watson then wrote THINK on the easel.

Too often we act as if process is a substitute for thinking.   The response to a tricky problem is often to call a meeting.  While discussion is essential, the best discussions are preceded by and followed by periods of thought.  

This blog will strive to redress this balance. The posts here will represent principles, attitudes and practices that are the result of experience, followed by analysis, reflection, thoughtful design, implementation and testing.

No claims are made that these will all be final answers, or beyond the scope of change: after all, these are "Working Propositions". I will write about things that on balance, on the basis of experience and THINKing, seem to work.

Building Enterprise Systems that Last, that Improve With Age

I come from a background of financial services and specifically insurance systems.  It is a world of frightening levels of compromise and muddle.  Once (50 or so years ago) it was this industry that led computerisation. Now after generations of mismanaged solutions, bewildering requirements change, and growth in technological possibility it is struggling to even achieve stability in a changing world.     It is a world where every decade or so, a new layer of technology gets overlaid on what went before, a layer that typically is out of date before it is fully implemented.

The plight of the industry is made even more apparent when compared to the astonishing rush of new consumer computer technologies that put the equivalent of a supercomputer in everyone's phone or tablet, which has capabilities that Science Fiction writers would have scarcely dreamed of a couple of decades ago.

The purpose of this blog is to explore why enterprise systems in financial services companies is in such a poor state, and to offer some alternatives.

Let's do a thought experiment.  Cast your mind ahead 20, 30, even 50 years ahead.  What will the financial services architecture of the mid 21st Century look like?

On a bad day I can imagine it looks a lot like today's, just with more layers of failed solutions, new languages, hugely faster computers running the same bodged set of applications, messing things up more thoroughly than ever before.

On a good day I can believe that today's mess is a sign of immaturity:  that 50 years is an awfully short time to progress from Assembler through COBOL and PL/1 to Java to {insert whizzy language of choice here}. We have been learning, all this time.  Maybe it would be useful to see what we have learned.  Maybe it would be useful to think about what system design / architecture principles we can articulate that we can believe will still be valid in 50 years time.

As computerisation / automation / data processing / information technology reaches maturity, I can hope that we can stop reinventing the wheel.  This is not to say that the pace of change will slow: rather, as the ground firms beneath our feet we can hope to run faster and faster.

This blog will focus on the principles, attitudes and practices that I think stand a chance at the 50-year survival criterion.  The lessons that we think will stand the test of time.  Some of them will be wrong: that's why I call the blog "Working Propositions".  True for now, but not guaranteed for all time. Still, solid enough to build on.