What other blogs do I read?

I received an email from Fabrice Yans earlier this week asking about an article I had written on IBM developerWorks. He has an interesting blog that covers SCA and WebSphere Process Server.

I don't maintain a table of links on my blog (I never look at anybody else's blogrolls so just assumed nobody would look at mine). However, as I spot interesting new blogs I guess I really should be letting all my other wonderful readers (all seven of them....) know about them. Watch this space.

Welcome to 1999

I am taking a break from client engagements this week and investing in some education: I am learning about IBM's WebSphere Business Modeler (sic) product.

I must admit to having been somewhat cynical at the start of the week. I approached this class from the perspective of a middleware consultant rather than as a business analyst and that was my mistake. This was a course that showed how we could use the tool to help clients understand the problems in their business and understand how to solve them. The simulation and analytic capabilities in Modeler are astonishing.

However, that is not the purpose of this post. Rather, the purpose of this post was to point out that I have been staying in the "Holiday Inn Eastleigh" for a couple of days - since commuting to and from IBM Hursley from London every day for a week was too much. The hotel is nice - indeed, I've just had a most agreeable meal with two good friends - but... wait for it..... there is no wireless or broadband internet access anywhere in the hotel.

No. That was not a typing mistake; I'll repeat it in case you missed it. In 2006, the owners of Holiday Inn somehow believe it is acceptable to sell hotel rooms where the only access to the internet is via an analogue telephone (at 28 kbps!!!).

I will, of course, never stay here again until they get their act together but it did teach me a valuable lesson: one should not assume that such facilities will be available when booking a hotel.

Investment Update

I've been somewhat erratic in my investment updates of late.

In brief, Premium Bonds have been disappointing: my return after six months is 1%.

However, my investments in equities have been somewhat more successful: I am about 18% up on August 2005. Hurrah!

The Impatient Commuter's Guide to DLR Optimisation (part one of an occasional series)

My esteemed colleague Ben Thompson remarked in the comments to this posting that my blog lacks a visual aspect.

I think he makes a fair point.

Therefore, this article is brought to you through the magic of PowerPoint.

I am sure many of my readers often ask themselves: "Where should I stand on platform 9 of Bank station to ensure I will leave the train as close as possible to the exit at Westferry station"? Those readers should fret no longer for the answer is this:

Assuming you are entering platform 9 from the Bank side (rather than the end nearest Monument station), you should walk along the platform as far as the overhead matrix display. At this point you will have gone too far. Turn around. You will see a shiny line on the ground running from near the information desk to the platform edge. This is the Marker of Magnificence. Stand on it and use the door that appears immediately in front of you when the train arrives.

Walk to the opposite set of doors and occupy the corner space (so that you don't block passengers getting on and off at Limehouse).

Thus:



Upon arrival at Westferry, use the door opener to your side, exit the train and scurry straight on to beat the other passengers who are heading to the exit that you have just arrived at. You should arrive there before everyone else. Ha! You win again.



Being the first passenger off the train, you have no slow-coaches ahead of you and so can descend the staircase at a pace that suits you. Truly you are a premier passenger.

Ben: Happy now?

Going to the movies on a Monday afternoon

For reasons I don't fullly understand, RSS Bandit insists on dumping "Fast Company" feeds in my "tecosystems" subscription. Most odd.

Either way, it has the beneficial effect of forcing me to read the occasional Fast Company article.

This is a fantastic first line for an article: "People who have learned to answer email on Sunday evenings also need to learn how to go to the movies on Monday afternoons"

Anybody flying between London and Manchester soon?

If so, take a look at this..... nice free train journey offer: http://forums.moneysavingexpert.com/showthread.html?p=1607521#post1607521

DB2 sucks

Not really, of course.... But I figured every time this blog posting appears in a google search, someone else's doesn't.

Stephen O'Grady at RedMonk linked to this post about one user's attempts to install a trial version of IBM's DB2.

It's worth reading in its entirety. He begins by describing in excruciating - and depressing - detail the problems he hit when he tried to get a trial download of the product to install on his UNIX box.

The thing that struck me was that it was yet another example of how a user's first experience of a product or service is of paramount importance. In my time at IBM I've been impressed at how far the development teams have come in this area. In my area of specialism, the installers for products like WebSphere MQ are fabulous. You immediately feel confident that the install will be easy and that you will do it right.

Posts like this one, however, remind me that one should never get complacent... there will always be an issue you didn't forsee. So it's gratifying that there was such a great support structure in place for him to turn to. I've worked with DB2 product support in the past on various client problems and have also been impressed by their abilities.... nice to see them get some recognition.

It's a pity that a couple of (actually very minor) gotchas made the experience harder than it should have been but I'm glad he took the time to get resolution and, importantly, to share that for others to benefit from.


[UPDATE 2006-05-24 11:20] A colleague (thanks Axel!) has pointed me to this detailed article on some of the cool stuff in DB2 8.2.

For your messaging people out there...

.... my colleagues Andy Piper and Ben Thompson (update your blog so I can credibly link to it!!) have also been published on developerWorks today. Ben and Andy are probably two of the deepest WebSphere Message Broker experts in the world. I always sit next to them when I go to Hursley so that I can stay current on that product by osmosis.

Hello to my readers from developerWorks

If you're reading this post thanks to my recent article on developerWorks, welcome to Gendal World!

I've been involved with IBM's WebSphere Process Server product for well over a year now - having worked closely with the development labs prior to release, consulted on some of our first engagements, contributed to our education materials and written various articles. One of the areas I focussed on was how to build applications that are robust against change. I recorded a PodCast on this last year.

If you're looking for more posts I've made about Process Server and related technologies, you might want to start with this Google Search which pulls up a lot of the articles.

It's OK to admit two words are synonyms

I hope I'm not about to expose my ignorance of the space in which I specialise.... but I'll take the risk. I'm going to admit that I don't know the difference between "orchestration", "workflow" and "choreography". There. I said it.

Actually, I'm not being entirely honest. It's not that I don't know the difference; I just don't think there is any difference.

I freely interchange these words when I talk to clients and I make no apology for it. I've seen no attempt to differentiate the terms that resonates with me and, until I do, I'll carry on doing what I'm doing. As far as I'm concerned, the concepts of orchestration, process choreography and workflow are the same thing.

You can try to tell me that it's all to do with granularity or that it's all to do with the life-time of a process or it's all to do with whether humans are involved or not. I don't care. I'm going to stick my fingers in my ears and yell "La La La! I can't hear you!"

Sure... different runtimes may be optimised for different kinds of scenarios (a BPEL execution environment may not be the place you transform 1000 messages per second as they flow between two systems across MQ) but that's orthogonal.

So, it was with highly sceptical eyes I read this post by Polar Lake's Warren Buckley. Warren appears to be their new blogger-in-chief after the departure of the impressive Ronan Bradley. He tries to differentiate "choreography" and "orchestration". I think he's guilty of verbal gymnastics that would shame a politician but don't let that distract you from his point. His discussion of Control Theory is most interesting. I *think* he's describing the same kind of thing we talk about with our WebSphere Process Integration story but I need to think some more about it. Either way, it was an interesting post.

So, hello, Warren. I look forward to reading more of what you write :-)

All Change!

Everybody's getting new jobs!

So... Rich Turner at Microsoft... good luck in the new InfoCard role.

And... Ronan Bradley of PolarLake... good luck in your new role too.

What with RedMonk hiring a new guy (hello!) and my favourite editor moving on to new pastures, you could be forgiven for believing the world wasn't static, after all. Who'd have thought it?

Pragmatism is a beautiful thing

I've been having an interesting (but ultimately unresolved) debate on the comments of my colleague Bobby Woolf's blog. I was trying better to understand the differences between REST and SOAP. I now realise that, although I thought I wasn't, I was actually conflating several themes. Thanks to this post by Don Box for helping me to cut through a lot of the debate.

Verdana is taking over the world

I've long had a vague feeling that all the "Web 2.0" websites I've viewed have looked the same.

I thought it might be due to the current fashion of making use of lots of white space and bold graphics.

But no.... they just all use Verdana. Every single one of them.

Examples:

Skype
Haloscan
Technorati

It was therefore heartening to discover the Service Component Architecture Portal (thanks for Jeff Schneider for pointing me to it in the comments of this post)

This website also uses Verdana gratuitously. Since I have established that Verdana = Web 2.0 = cool, I think we have conclusive proof that SCA is cool. Excellent.

As for the content... well, I have better things to do on a Saturday night than read it... that will be a task for the week. But it does have some interestingly titled articles. ServiceComponent.com could turn into a very valuable resource.

We need some better FLAs!

Having exhausted the world of Three Letter Acronyms some time in the last millennium, the IT industry is currently working its way through the four-letter type.

The TLA crusades are over. TCP beat SNA.... The HDD outlived the FDD.... The discerning traveller will even agree that LCY is better than LHR.... But the four letter wars have barely begun....

I've been debating the nature of SOAP and REST with some commenters on Bobby Woolf's excellent blog. I'm still trying to get my head around the subtleties; I'd certainly appreciate other contributions to the debate (from either "side"). However, something tells me that, in the end, REST just sounds cooler.

Naming matters :-p

XMS

Microsoft's Omri Gazitt mentioned IBM's XMS technology recently on his blog. He argues, correctly, that interoperability between messaging systems is A Good Thing. However, as I posted in his comments, I think XMS is trying to solve a subtly different problem.

Either way, it's good to see that XMS is getting noticed; it deserves wide adoption.

How to avoid crashing into strangers without slowing down

When not visiting clients, I tend to work in IBM's office in Central London. The office is very near to one of London's busiest commuter stations so I find myself travelling in the opposite direction to most other commuters: I am using the London underground network to reach Waterloo station when most other workers are trying to leave Waterloo and vice versa.

This makes for a more relaxing journey (fewer people to compete with for space on the trains I use, etc, etc). But it does cause one problem when walking: there is almost always a wall of people hurtling towards me.

This problem is particularly acute near my home in Canary Wharf. There are lots of very modern office blocks in a regimented pattern, with blind corners.

This means that when I approach a blind corner I have to slow down to avoid the risk of bumping into the crowd coming the other way. This makes my life somewhat difficult as I don't "do" slow walking.

n the diagrams below, the blue blocks are buildings, I am the green path and the oncoming crowd is in black.

The first diagram below shows the problem: blind corner and oncoming crowd.

The second diagram shows my solution. As I approach a blind corner, I change direction and walk across the potentially oncoming crowd. If no crowd materialises, I am not really worse off. But if there is a crowd, I am walking perpendicularly to it and so have several precious milliseconds to find a gap between people to dart into.

This increases the distance I walk but means I have no need to slow down. Excellent!

Is polling always evil?

Microsoft's wonderful Raymond Chen discussed the evils of polling a few weeks back. He is, of course, correct that it's usually a bad idea. My rule of thumb when considering such scenarios is that if something intuitively feels wrong then it usually is. And polling feels wrong.

However, I think it's possible to be too disdainful of polling. In particular, I am increasingly of the opinion that it can be used in judiciously-chosen scenarios to help build significantly more robust systems than would otherwise be possible.

The example I have is from the Enterprise Application Integration world. Assume we have a monolithic application which is supporting some business function.

For whatever reason, we need to know when various tasks have been performed ("new customer record created", "purchase order modified", etc). When such an event occurs, we need to send the information to some other system. This is the bread-and-butter of integration. Call it EAI, BI, ESB, whatever.

Now, how do we detect such events? There are two broad approaches. We can configure the source application to notify the integration layer when something of interest has happened (e.g. by sending an event into the bus, by calling a web service, by placing a message on a queue... whatever). Or we can configure the integration layer to somehow detect the event.

The latter is most often achieved by configuring the source application to record than an event has occurred (e.g. in one of its database tables) and for the integration layer to periodically check this event store. i.e. we configure the integration layer to poll.

Who, in their right mind, would ever regard the latter as a reasonable approach?

Well..... me, quite often. And here's why.

The former approach has plenty of advantages: real-time notification of an event, no polling, the event flow is clear, etc, etc. But... it also has two potential drawbacks. The first is that the source application has to be configured to talk to the integration layer. In most cases this is no trouble at all but in some situations (especially with older, bespoke software) it is quite difficult. Worse, this approach has added a dependency to the source application. It now requires the correct functioning of (part of) the integration layer - or must have sophisticated error handling added to deal with the times when the integration layer is unavailable. So, high availability scenarios have been complicated. Considerations such as these can make achieving buy-in from application owners to an integration project much harder.

The polling scenario has plenty of obvious disadvantages (polling can be costly, polling can introduce latency, etc, etc). But it has a very nice advantage: we have added no dependency to the source system; it can generate events that the wider scenario requires without complicating its own operations. This is since the integration infrastructure (perhaps in the form of an adapter) is making a call to the application, rather than listening for a call from the application.

My view is that polling can often be considered a transitionary state: get a project working and demonstrate value to the business sponsors and the application owners. Once the integration infrastructure has been proved (and has been shown to have higher reliability than the applications with which it integrates!), resistance to modifying the applications to call the integration layer often evaporates. Polling performs a valuable role in allowing us to get to that point and in solving problems where direct notification is unachievable.

So, no. Polling is not always evil. It is merely usually evil...

"The fear of getting it wrong was surpassed only by the fear of not delivering anything at all"

I overheard this comment on a train back into London a couple of evenings ago. Two young trainee lawyers were discussing their careers to date and comparing their workloads - and the high expectations that had been heaped upon their shoulders.

I tried to imagine the circumstances under which somebody in IT would find it credible to articulate a comparable fear. I'm not talking about the natural desire to do things right and to ensure one's deliverables are good quality. Rather, how often do we find ourselves in situations where our professional credibility, the wellbeing of our client (and our own chances of advancement) rest entirely on a single piece of work?

It's easy to think of examples in the "traditional" professions: if you put your name to a company's audited accounts, you'd better be sure they're correct. If you're playing with billions of dollars of your bank's own capital, you'd better be sure your trading strategy is sound. It's easy enough to think of examples from the worlds of medicine and law.

I'm interested in hearing my readers' thoughts on what the equivalents in IT are. I have a few ideas of my own but I was surprised at how few good ones I could think of. I'm hoping you can help me out. So, comments are open as always. I'm looking for examples from your IT career where the outcome of a single piece of work could have had truly serious effects had you got it wrong. "The patient either died or lived". "The defendent either went to prison for life or walked free". "The bank either went bust or made a fortune".... what do you think is the equivalent for a professional in IT?

Describing SOA with a famous brand of plastic building blocks

Jeff Schneider has a funny piece that puts SOA in an historical context.

Although the "famous brand of plastic building blocks" analogy is not new, it is very important. I get asked a lot why we need specifications such as the Service Component Architecture. "Why do we need another invocation mechanism?" The answer is that SCA isn't just an invocation mechanism. Rather, one of its key features is the ability to regard logical chunks in our infrastructure and applications as reusable building blocks. Blocks that both provide and consume other services. Jeff's piece illustrates that quite nicely.

Scandinavian Airlines

Does anybody understand Scandinavian SAS airlines' business model? They introduced a two-tier economy cabin for short-haul flights a year or so ago and I remember thinking it odd at the time (mainly because I had been booked into the lower tier and so was forced to pay for my dinner). If I have understood the offering correctly, they have an economy fare which offers inflexible tickets and requires payment for onboard refreshments. Economy Flex provides flexible tickets and an onboard catering service. This is in addition to their business class.

When I first noticed this behaviour, I thought it was just SAS being quirky. However, I read a remark in their in-flight magazine yesterday that suggested it actually has a history going back to the late 70s and was part of a strategy to innovate in a regime of heavily regulated fares.

It's still all a bit odd, though.....

Business-integration, Business-partners and Bandy

I have just spent an exhausting week in Stockholm discussing how WebSphere Process Server can solve some pressing concerns at one of our business partners. My time was split between teaching our standard introductory class and discussing specific problems they were trying to solve. It was a tremendously rewarding week: the pressing problems they had made them attentive students and they were extraordinarily talented.

Not only did they have to listen to my descriptions of a new technology and relate it to their existing technologies in real time, they had to do it in English (my Swedish skills being somewhat weak...).

However, an attentive, question-filled class is a demanding class and I was thoroughly exhausted every evening.

I did manage to take time out on Thursday evening. My colleague (who organised the class) took me to see a game of "Bandy". Those who know me well will know quite how low my interest in sport is but I'm always willng to try something once. Unless that "thing" is a roller-coaster that goes upside down but that's just good sense: if we were intended to travel upside down, our pockets would not be open at the top.

Bandy seems to be a cross between ice hockey and football. The game we saw was Sweden vs Norway and it attracted a good crowd. I'd recommend any visitors to a Bandy-playing nation take the opportunity to see a game.... just make sure you wrap up warm. Spectating is not an endeavour for the inadequately clothed.

The Impact of Paper Bond Weight on Design Quality

Oh dear..... it's probably very wrong of me to have found this site funny but still....



Hat-tip to From 9 till 2/

Llamas, Mousetraps and WebSphere Messaging

IBM's Andy Stanford-Clark has an interesting account on "eight-bar" of the day the film-makers came to his home.

Back to Sweden

My team covers the whole of what IBM used to call EMEA (Europe, Middle-East and Africa). For reasons too dull to go into, we don't use the word EMEA any more but still.... Averaged across all our consultants in this team we have visited pretty much every major city of every country, multiple times over the time the team has been in existence.

But, it you study any particular consultant in isolation, you will find their travel patterns to be completely unique. I have some colleagues who spend their entire time on projects in the UK, others who seem to find themselves in Italy every week and others who dart about all over the place. There is no pattern to it and is a reflection of the different contacts we all have, our different skill sets and changing demand.

In my case, I seem to have spent a disproportionately large amount of time in Sweden. And, this afternoon, I fly back out there again.

This trip is to teach a class on WebSphere Process Server. I've taught this particular class several times before but I always get nervous beforehand. I've spent some considerable time reviewing the materials and practising the presentations but one can always do more.

When Economists Get Angry

I've just stumbled upon a new blog, Market Correction. It contains copies of letters sent to the press by a couple of economists who correct signs of economic illiteracy wherever they find it. As one would expect, some of the letters hit the mark better than others but there are some gems in there.

The Two Towers

I am not ashamed to admit that I am utterly perplexed by the massive interest people seem to have in elves, goblins, "Hobbits", wizards and other figments of Tolkein's over-active imagination. No..... Just NO.

However, don't let that put you off reading this interesting article by IBM's Michael Liebow. He talks about SOA from a business perspective ("not an end goal, but a means to an end") and gives good advice on how to ensure your vendor's interests are aligned with yours.

Kopying Kareem

IBM's Kareem Yusuf has a good piece on his blog this week. He's talking about the need to engage "small" developers and those testing the waters. It's a good point and I'm glad our leaders are continuing to focus in this area.

However, I was also taken by his Sudoku challenge.

I decided to take up the challenge. Having never used Eclipse's GUI builder before, I figured it would be an excuse to try it. I figured that if he's looking at Python, I'll take the Java route.

Writing the solver itself was depressingly trivial. I had all sorts of ideas in advance of how to optimise the problem (e.g. teaching the system strategies and heuristics, etc). However, I wanted, first, to get something working. So I wrote a trivial recursion. I expected some of the harder examples to take some time. Embarrassingly, no matter what I threw at it, I couldn't make it take more than a few tens of milliseconds.

Oh well.... I guess it proves, if more proof were needed, that premature optimisation is never a good idea.

Once this was done, I could bolt on a GUI. I was surprised by how nice the Eclipse GUI tooling was. But I discovered a nasty with SWT.... it doesn't let you do UI stuff on anything other than the main thread. I had plans for a clever solution where the solver ran in a separate thread and called back to the GUI to show the recursion in real time. No such luck.... I was being a little *too* naive with my implementation there.... more care would be needed. (It *is* possible to do what I want but requires a little more sophistication)

Of course, I've now ruined the magic of Sudoku for myself... but it was probably worth it for an excuse to do some coding for a change.

What is the difference between "Interoperability" and "Integration"?

In a comment to my posting yesterday, James McGovern proposed an answer to this question that was somewhat different to my attempt but observed that the interesting question is what others in the industry believe.

He suggested I throw this open to my wider readership.

So, is there a difference between "interoperability" and "integration"? If so, what is it? Can you provide crisp examples?

Comments, as ever, are open

[2006-02-07: Update] IBM's Bobby Woolf has some additional thoughts here.

Outstanding questions regarding BPEL and ESB

James McGovern has some excellent questions on his blog.

I could write pages on some of the questions but I thought I'd limit myself to just two for now.

"When should one use BPM with an ESB?"

I think this question probably reflects the multiple inconsistent definitions used by all the vendors and analysts out there. In my view of the world, the ESB is the construct that says to the world: "You need to send some information to an application? You need to invoke an application? I'm the man. Send the request to me - in the way that makes most sense to you - and I'll take care of making it happen, in the way that makes most sense to the target application".

So, by this 'definition' it exposes services deployed in the enterprise in a way that is independent of how the services are actually implemented and it does it in both synchronous and asynchronous cases.

By contrast, BPM is the orchestration layer that sits above this. This is the layer that says: "Great! All the enterprise services I may ever need to invoke are all easily accessible via the bus. Now I can deliver some extra business value by wiring some of them together to automate a business process. I'll involve a few humans here and I'll emit monitoring information there and the result will be an end-to-end automated business process."

Now, a particular vendor's product my conflate the two worlds but, at an architectural level, they are very different.

ESB is about exposing services

BPM is about chaining them together (and more... true BPM involves people)

ESB is worried about technical details

BPM is worried about business process, key performance indicators and monitoring.

So, I would argue one implicitly uses an ESB whenever one is doing BPM.


"What's the difference between Interoperability and Integration?"

Excellent question. I agree with James that there is a difference but until now, I, too, had never tried to articulate what it was.

Here's my first stab (and I stress that this is a first pass.... I'm not totally happy with it)

If two systems are interoperable, we mean that they are capable of working together. Consider SAP: two SAP systems are interoperable.

However, two systems being capable of working together is merely a statement of fact. It says nothing about how you do it.

Two SAP systems can be integrated by configuring them to fire IDOCS at each other (or in one of all the other possible ways). Moreover, to achieve true integration, you may require the assistance of some extra technology (home-grown code, an EAI product, an ESB, whatever).

So: I would say that interoperability is a statement of the possible. Integration is how you do it.

Tim Harford is just brilliant

As I've blogged before, I'm a big fan of "The Undercover Economist" by Tim Harford and his column in the Financial Times is most fun.

Here's this weekend's take on how a single restaurant can successfully charge two prices for the same food. Fantastic stuff.

Would you take the $1?

EconBrowser talks about the Ultimatum Game.

You are given $100 and can offer $0 to $100 to a second person. If they accept the offer, you give them what you promised and keep the rest. If they decline, neither of you get anything.

I've seen this problem several times and have always enjoyed the fact that the rational thing to do is offer your opponent a dollar.... they're better off than they were so should accept it. But, of course, if you did this in real life, they'd get more pleasure from denying you the $99 and so say no.

James Hamilton talks about this in the context of the assumption of rationality that economists use when reasoning about people.

It's an interesting article. I'm not sure the experiment proves we're irrational; I think it just shows that people do derive pleasure from "sticking it" to someone when they think they've been treated unfairly. There are no doubt good evolutionary reasons for this.

SOA-chology

Phil Wainewright writes about an excellent SOA success story at Verizon wireless. The project itself sounds interesting and I congratulate the team (it'll be just my luck if they turn out to be a reference customer for one of my competitors but still....). What I found most interesting was the emphasis on the non-technical aspects. This is absolutely spot on. This is a very different way of working and, as with all attempts to introduce change, you ignore the human aspects at your peril.

Correctly identifying those entrenched behaviours that imperrilled the project and putting in incentives to change them (peer recognition counts for a lot) was a smart move.

The full InfoWorld article is here.

BusinessWorks

No... I'm not about to write about that fine product from the lovely people at Tibco.

Rather, I was reading this article by James Governor. He observes that Lotus' VP of marketing is blogging on developerWorks. On one level, my thought is: so what?! But as soon as you try to leave a comment you'll see the problem: it does seem slightly odd that a marketing blog requires you to get a user ID on a developers' network in order to comment... I'll drop him a note to find out why that is. Now, I should add that developerWorks is a fine, fine site. Indeed, they did me the honour of hosting my first ever PodCast and will soon be running an article i've written for them. So a solution to James' dilemma may be for the whole world to migrate to developerWorks :-)

However, I was more taken by James' perfectly reasonable question of why we have a developerWorks but not a productionWorks or even a businessWorks.

I think Sage may also be upset if we launched businessWorks. But, who knows.... maybe when they and Tibco realise they share a trademark, they'll get distracted by each other and not notice what we do :-p

New newsgroups for WebSphere Process Server

There are two new newsgroups on nntp://news.software.ibm.com for anyone interested in WebSphere Process Server and WebSphere Integration Developer.

Point your favourite newsreaders at ibm.software.websphere.process-server and ibm.software.websphere.integration-developer and start asking your questions :-)

I'll be keeping an eye on those groups and will chip in with answers whenever I see something I can help with... but remember that they don't replace the regular support processes, etc, etc, usual disclaimer, etc.

Show vs Tell

Redmonk's Stephen O'Grady has a perceptive piece on product demos.

He makes the reasonable observation that, when trying to understand a new technology or new product, it's much easier (and fulfiling) if you can get your hands on it and play with it for yourself.

Quite rightly, he argues that slideware is far from convincing and managed demos (where you don't get to actually poke it yourself) are little better.

On one level, I have to agree with him: I spent several years travelling the world performing pilots, proofs of concepts and live demos of IBM's middleware products to potential customers. It was hard work, stressful, the hours were long and I lived with an ever-present fear that a mistake I'd made when developing the demo would cause the whole thing to fail when we presented it to the CIO.

But it was an extraordinarily exciting time and there is no better way to help people understand what you're offering them than letting them try it for themselves.

However, I think his call for vendors to "ship him the bits" could perhaps be worded a little better. Shipping working demos is the key. Just shipping the product and telling someone to install it and figure it out for themselves is probably not a good use of their time. Sending them a pre-configured scenario - with the ability for them to play with it and make changes - seems far more valuable to me.

Regardless, he has touched upon a key aspect of human nature: we tend to be far more visual than we would like to admit: a well-drawn diagram can obviate the need for three PowerPoint pages of text yet I - and many others - are guilty of ignoring this in almost every deck we produce.

SOA, Web Services and hard-coded XML strings

The "Does SOA = Web Services" discussion has kicked off again.

Joe McKendrick has an interesting posting about the role of Web Services in Service Oriented Architectures. He links to Amir Shevat's piece on whether SOA and Services are synonymous. Amir has correctly observed that synchronous request-reply (in the form of SOAP over HTTP, say) is not always the best choice. Indeed, they seem to be in broad agreement that, as an architectural approach, SOA is entirely independent of invocation mechanism. However, Joe counsels that we shouldn't take this too far: you can build an SOA with other technologies (even home grown ones), but why take the effort when there are all these lovely industry-proven specs available?

I have sympathy with this opinion but we need to be clear when we're talking about these kinds of issues.

No client I have ever visited has been building their SOA in a vacuum. They have existing systems - on more platforms than one could possibly imagine - and usually have some integration solutions in production already. You can be pretty sure any serious SAP shop will be firing IDOCS left, right and centre between their machines, for example. There's likely to be some JMS (most likely MQ) in there and they may have a bunch of web services. Those web services, incidentally, will be on a variety of platforms and some will be home grown. Some will be from the early-adopter days and not conform to any known WS-* spec. You can also be sure that there's no way they're going to change them :-)

So, what's the answer in these real-world situations?

My view is that these problems become soluble when we intermediate the service requester and the service provider. The architectural construct used here is increasingly known as the Enterprise Service Bus (ESB) and I wrote about how I thought it fitted here briefly in November.

The inclusion of a conceptual ESB makes the solution clear: existing systems can continue to run unchanged. They can expose the services they offer in whatever way makes most sense to them. On the invocation side, however, you should consider mandating a standard. This could be MQ, JMS, SOAP over HTTP, whatever (perhaps a choice depending on context). The point is that we provide a simple, standards-based way for new applications to invoke existing services. The ESB is the facade that takes these requests and forwards them to the appropriate provider.... making any necessary conversions along the way.

The ESB can be as heavy-weight or as light-weight as you like or as you need. In some cases, you may have no specific implementation at all - it will simply be a guiding architectural principle. The point is that in the real world of existing systems, something like an ESB allows you to build up the ESB without having to tear down all the work you've already done and allows you to square the "SOA must be Web Services" argument with the "We're not going to redo everything!" camp.

[Update 2006-01-12: Ronan Bradley has also spotted Amir's article and writes about it here. He has also spotted that it is making an argument for an ESB]

David Chappell on SCA

David Chappell has written a piece where he compares the Service Component Architecture (SCA) to Windows Communication Foundation (WCF). For those not familiar with WCF, Microsoft's chief raa-raa man for WCF (Rich Turner) is on a mission to explain and is a prolific poster to his excellent blog; it's well worth a read.

David's article gave me pause for thought. I hadn't thought of SCA as playing in the same space as WCF until now. In my mind, I have (perhaps naively) considered WCF to be Microsoft's new plumbing for web services, messaging, remoting and the rest. By contrast, I picture SCA as a way to describe, invoke, package and compose services in a location, implementation and runtime-transparent manner (simplifying gratuitously, of course). I intend to re-read David's article with the WCF FAQ open at the same time. My first impression is that he may have downplayed the importance of WebSphere Process Server - as a shipping implementation, it suggests answers to many of his questions about how SCA may support JMS, security, transactions, etc.

I think one of the potential similarities between the two models (if WCF does what I think it does) is the deliberate blurring between "programming in the small" and "programming in the large". That is: SCA can be used as a component model for building a regular application. And the exact same technology can be used to build a highly-distributed composite serivce-oriented application. This encouragement to think about services in everything we do is crucial. The SCA (and WCF) applications of today must not become the monolothic legacy apps of tomorrow... we're not just consuming services; we should be exposing them, too.

I need to give this some more thought and do more reading on WCF. Microsoft's WCF FAQ is good.

David blogs here. I can't believe I've only just found it... it's fascinating. However, there doesn't seem to be any way to comment or fire trackbacks, which is a shame.

Perceived Complexity

Don Ferguson (IBM's Chief Software Architect) blogged over Christmas on the perceived complexity of our WebSphere integration products.

He's done a good job of explaining how they fit together and why they exist. That second point is the key: not all clients have the same needs or are starting from the same place.

It was good to see him mention a few of the new services in our Process Server product and what they're for. Selectors, for example, are key to our "versioning" and "dynamicity" stories - an area I spoke briefly about on this developerWorks PodCast.

New Year Resolutions

I have a patchy record of making resolutions - and an even patchier record of sticking to them. Nevertheless, I think I may have one or two that are specific, measurable, attainable, realistic and tangible so why not document them....

• Become actively involved in my local community


• Become actively involved in politics (not necessarily party-politics, however)


• Decide on my career-goals - and then work harder than I've ever worked before to make them happen.

OK... so perhaps they're not all totally specific or tangible but they'll do for now.

The "local community" one is an interesting one. I originally formulated that as "get involved with charity (above merely donating money)". However, I'm not sure that is necessarily as altruistic as it sounds. Two hours spent stuffing envelopes could have been spent earning extra money (e.g. achieving one of my bonus objectives) which could then have been donated. This is likely (not definitely!) to be more than the cost of hiring somebody to stuff envelopes for two hours. Thus, I could provide more value to a charity by simply giving more money (with appropriate boxes ticked to allow them to reclaim tax, etc, etc).

I'm not entirely convinced that my argument is sound... and I may be discounting the value of being physically present (both to me and to those who have to put up with me). However, it was enough to convince me to phrase the resolution as I did.

The politics resolution was driven by my increasing interest in the role of economics and the effects of various governmental policies (past and present).

As for the career-goals... I envy those who knew, at an early age, what they wanted to do and how they worked unceasingly until they had achieved it. The rule I've set for myself is that I should think about what I would like to be doing if I didn't need to earn money. It's an obvious qualification to make but one that I hadn't made until now (which probably explains more about me than I would care to admit).

Right... I'm off to find some competitors to bash... normal service will be resumed shortly.

Back to work

Today was my first day back at work after the Christmas break. It was good to see my colleagues and sobering to realise that the world didn't stop when I was away. Darn.

In non-work news, my investments have been doing rather well of late. I'm up 13% on my original investment - which I made in August (I think). So, I'm quite happy at present. Of course, I will lose everything before I decide to sell, no doubt. But it's a nice feeling while it lasts.

I made a deliberate point of staying away from the IT industry over Christmas. Instead, I indulged my interests in economics and politics (as well as visitng family and friends and partying, I should add... I'm not entirely strange).

In particular, I have been reading

• "The Undercover Economist" by Tim Harford. It was every bit as good as I expected it to be. I wish I could give a copy of that book to everybody who tries to tell me how high gas prices are all British Gas's fault or why lowering tube fares is the right thing to do.... or one of a million other annoying things people say when they are in need of a good economics primer (not that I know much more than them, I hasten to add)
• "The Wealth of Nations" by Adam Smith (don't click on his name if you're expecting his blog. He died some time ago...). I'm finding this heavy-going but am making slow but steady progress
• "Why Most Things Fail" by Paul Ormerod. I'm about half way through this and am finding it educational.
• "The Economist Style Guide". This is not, as my parents thought, a tutorial in how to dress like a mathematically-inclined social scientist but, rather, a book that tells you how to write clearly.
• "The Road To Serfdom" by Friedrich A. Hayek. (I haven't actually started this yet, I must admit.... but it's on my list).

As I hinted above, I deliberately avoided almost all IT-industry-related thinking and reading so now have an enormous RSS feed backlog to clear...

[EDIT - almost immediately after posting to correct formatting ]