Adventures in systems land

Colin Renouf from Lloyds TSB bank in London and one of the more active and vocal AIX Technical Collaboration Center members, just wrote me an email with a proposal for a joint work effort on patterns for SOA. It’s a great idea.

While we are fleshing that out, I thought I’d highlight the fact that Steve and Tommy, with Johns project management, have been solidly delivering on the System p configurations for SOA Entry points.

There are currently five papers and an overview in the series. You can find the launch page here. The papers are

Process:

IBM System p Planning & Configuration Guide for SOA Entry Point — Process
IBM System p Reference Architecture for SOA Entry Point — Process

People:

IBM System p Planning and Configuration Guide for SOA Entry Point — People
IBM System p Reference Architecture for SOA Entry Point — People

Reuse:
IBM System p Reference Architecture for SOA Entry Point – Reuse

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”.

Well the wagon has wheels, one of the first visible results of the work I’ve been involved in System p was announced last week via press release.

The “System p Configurations for SOA Entry Points” are a collection of reference architectures, installation, system setup, configuration guides, as well as certification of the Software stack on System p, common integration patterns, best practices for problem prevention, role specific documentation, answers to common operational questions and appropriate customer-use cases. [BonusPak anyone?]

For me the benefit of a virtualised infrastructure to SOA and web services always seemed obvious and not just by virtualising at the middleware layer. Continue reading ‘System p Entry Points for SOA’