More on complexity, configurability

One of my first posts in this blog, was on the subject of complexity. James Governor of Redmonk weighed in today on complexity with a trackback post called “What SOA needs to learn from Ruby On Rails“.

I noted, that while our software, and often our systems were complex, that was because our customers are, not because we design them to be complex. Our customers run a vast array of machines, in widely different environments, supporting a broad range of applications. Of course, this is chicken and egg, and is a difficult tightrope for established solutions to walk. We could just remove most of the configuration options and in a generation or two the complexity would have gone, but what about the customers?

Forced into a straightjacket of “our way or the highway”, would you take the later?

It’s easy for the new kid, in this case Ruby on Rails to come out and offer little or no configuration options, side files etc. It doesn’t have to, it has never made a significant change it what or how it does things. The same isn’t true for the old-timers. Comparing SOA to Ruby, is like comparing a transport system to a footpath.

It is a subject important to me though. At the moment I’m carefully trying to marshal the merger of the function in the System p Hardware Management Console with that of IBM Systems Director and Director console. My desire is to make one simple management platform that acts both as the local platform director, managing configuration, hardware and service management etc. and at the same time providing a set of programmable, function services based interfaces to provide both remote access, and remote management.

So, I’m all for simplicity but it has to be thought through. We are doing this with the System p Configurations for SOA Entry Points. The original SOA Entry points were pure software plays divided into five categories, People, Process, Information, Connectivity, and Reuse. We are taking the entry points one step further and mapping the software onto System p removing another layer of complexity by showing how they work, how you can configure them and testing them as a total solution.

You can read the System p Configurations for SOA Entry Points overview here, via FTP

John Lennon once sang “It’s been too long since we took the time, No-one’s to blame, I know time flies so quickly” … “It’ll be just like starting over, starting over”.

1 Response to “More on complexity, configurability”


  1. 1 james governor August 6, 2007 at 3:59 am

    I didn’t argue for a lack of configurability- I argued for a greater understanding of conventions and defaults. why make an exception? whats the out of the box experience like and how can it be improved? if you really want to kick ass with system p i would say package management probably needs to be completely overhauled. driving simplicity into complexity is really hard, but can pay amazing dividends.

    Look at service desks- in many organisations 80% of the queries they answer are password resets. what’s wrong with that picture?

    Shouldn’t you be consulting with us on this stuff, or something? You have the hours… :-) )


Leave a Reply




About & Contact

I'm Mark Cathcart, Director of Systems Engineering and a Distinguished Engineer at Dell. I was formerly an IBM Distinguished Engineer and member of the IBM Academy of Technology. I'm an information technology optimist.

Subscribe to updates via rss:

Feed Icon

Blog Stats

  • 34,881 hits