I knew things were bad in the NHS right now (for my non-British readers, the NHS is the publicly funded and publicly provided health care system we have in the UK). However, I didn't realise we were treating our old people quite this badly :-(
[UPDATE: 20060314] I should have added a warning: I suggest you read the full article when you're not eating.
Tuesday, March 14, 2006
Monday, March 13, 2006
Be afraid
It's bad enough that they bred. Now they're trying to evolve. Before even my song and podcast collection is dry on my replacement iPod, they release THIS. I'm happy with them breeding and a bit of evolution is OK. But let's hope this is the end of it. Opposable thumbs really would be too much.
Now, the problem is this: I'm in Hursley tomorrow (to learn all about AlphaBlox) so I'll be commuting for almost four hours, there and back. Unfortunately, I haven't even started this week's Economist, I have a pile of email to reply to, more unread RSS items than I care to admit to and I'm only halfway through this strangely fascinating PodCast about the Economics of Virtual Worlds. I say "strangely" because I have zero interest in gaming.
I thought I had this "information backlog" problem solved earlier today when I tried reading last week's Economist obituary and listening to the "virtual worlds" PodCast at the same time. Sadly, I failed after a minute or two. Intriguingly, I was managing quite well until then but then the difficulty of concentrating on two verbal stimulants at once proved too much. Shame.
Now, the problem is this: I'm in Hursley tomorrow (to learn all about AlphaBlox) so I'll be commuting for almost four hours, there and back. Unfortunately, I haven't even started this week's Economist, I have a pile of email to reply to, more unread RSS items than I care to admit to and I'm only halfway through this strangely fascinating PodCast about the Economics of Virtual Worlds. I say "strangely" because I have zero interest in gaming.
I thought I had this "information backlog" problem solved earlier today when I tried reading last week's Economist obituary and listening to the "virtual worlds" PodCast at the same time. Sadly, I failed after a minute or two. Intriguingly, I was managing quite well until then but then the difficulty of concentrating on two verbal stimulants at once proved too much. Shame.
Sunday, March 12, 2006
Design Patterns for Modern Life
For reasons that are not totally clear to me, my postings on the optimal way to walk around corners and where to stand to board a train for quick disembarkation have attracted more interest than my musings on Service Oriented Architectures. It's most perplexing. Nevertheless, there's clearly a market for it. So (with a hat tip to Lee for the name), I present: Design Patterns for Modern Life!
Thursday, March 09, 2006
Blodget is dangerously compelling
I wish I had even 10% of Henry Blodget's talent. He's been posting about Google repeatedly of late and every single post he makes is a lesson in financial writing. He has a style that not only makes you believe you understand everything he's talking about but makes you believe that any other interpretation must obviously be wrong.
An extraordinarily talented gentleman.
An extraordinarily talented gentleman.
Wednesday, March 08, 2006
Sound Advice
Bill Higgins offers some good career advice.
I particularly like his "work with smart people" rule. It's sometimes difficult to follow that mantra in my role as I work on a lot of different projects over a year and rarely get time to spend a lot of quality time with the people I'd like to. However, Scoble offers a neat workaround in this post: reading smart people's blogs makes you smarter :-)
I particularly like his "work with smart people" rule. It's sometimes difficult to follow that mantra in my role as I work on a lot of different projects over a year and rarely get time to spend a lot of quality time with the people I'd like to. However, Scoble offers a neat workaround in this post: reading smart people's blogs makes you smarter :-)
Oh. So *that's* what it's all about!
I was recently involved in a somewhat lengthy discussion in the comments of my colleague Bobby Woolf's blog. I was trying to understand the ideas behind "REST". I'm not sure why I didn't just turn to wikipedia. Anyhow, their definition is actually quite good. I think I understand this a bit better now.
Good blogging platforms
I have no reasons to complain about Blogger. I'm, mercifully, free of comment spam and I have no complaints about their reliability, etc.
However, they get a lot of bad press. I'm assuming this means that those who have tried other platforms have found them superior.
I am about to start up a couple of other blogs - one to capture my deep insights into efficient commuting and one to allow me to speak more freely about politics - and so this is a good time to consider my choice of platform.
Thoughts?
However, they get a lot of bad press. I'm assuming this means that those who have tried other platforms have found them superior.
I am about to start up a couple of other blogs - one to capture my deep insights into efficient commuting and one to allow me to speak more freely about politics - and so this is a good time to consider my choice of platform.
Thoughts?
Friday, March 03, 2006
The Impatient Commuter's Guide to Tube Optimisation (part two of an occasional series)
There are so many great opimisation techniques if your journey begins or ends at Tottenham Court Road tube station that it's hard to know where to begin.
For the sake of brevity, I will restrict myself to techniques that work on the Central Line and will offer only two techniques.
Technique One
Observe that the best platform exit when alighting from westbound trains is at the very end of the station - near the back of the train. Accordingly, one should travel in the last carriage.
Technique Two
When beginning a Central Line journey at Tottenham Court Road, regular passengers will have noticed the excessive distance one must walk. Moreover, you must sidestep a busker at the end of a particularly long corridor. There is a better way, Ladies and Gentlemen.
Specifically, when on the last long walk to the Central Line platforms, observe that your journey takes you through a circular chamber. Upon leaving this chamber, the path ahead is split into two: you will be encouraged to walk on the left, to leave space for those leaving a train to walk on the right.
Don't be fooled!
Observe the diagram below: if you follow the signs you will be forced to walk along a long corridor before passing the busker, and finally getting onto the platform halfway along.
You should, instead, ignore the signs, and follow the rightmost path. Provided you choose your timing correctly (fighting against the disembarking passengers would not be an enjoyable experience), you can get onto the platform at least twenty seconds quicker than everyone else. You win again!
For the sake of brevity, I will restrict myself to techniques that work on the Central Line and will offer only two techniques.
Technique One
Observe that the best platform exit when alighting from westbound trains is at the very end of the station - near the back of the train. Accordingly, one should travel in the last carriage.
Technique Two
When beginning a Central Line journey at Tottenham Court Road, regular passengers will have noticed the excessive distance one must walk. Moreover, you must sidestep a busker at the end of a particularly long corridor. There is a better way, Ladies and Gentlemen.
Specifically, when on the last long walk to the Central Line platforms, observe that your journey takes you through a circular chamber. Upon leaving this chamber, the path ahead is split into two: you will be encouraged to walk on the left, to leave space for those leaving a train to walk on the right.
Don't be fooled!
Observe the diagram below: if you follow the signs you will be forced to walk along a long corridor before passing the busker, and finally getting onto the platform halfway along.
You should, instead, ignore the signs, and follow the rightmost path. Provided you choose your timing correctly (fighting against the disembarking passengers would not be an enjoyable experience), you can get onto the platform at least twenty seconds quicker than everyone else. You win again!
Other blogs I read (part 1 of many)
My RSS reader is broken down into various categories ("friends", "enemiescompetitors", "economics and politics", "IT industry", "London" and so on).
Here are some of my favourite "London" feeds....
Going Underground's Blog. This, and the somewhat more hyperactive Londonist blog are just full of interesting news articles, rumours and ideas for things to do about town. If you were wondering why all the chocolate machines on the tube were out of order or why there's an erratic red line of paint running from the river to near Euston, these are the places to find out.
The SE1 blog does what it says on the tin. My London office is in SE1 and it's an area I pass through regularly.
The Criminal Solicitor, Policeman, Magistrate, Tube station manager and Paramedic are well known but still worth reading.... it's great to get an insight into other people's lives.
However, I do have some sympathy with Stephen O'Grady's plea here. So, in the spirit of posting links to good content and not just entire blogs, I offer this solitary link. It answers the question of why the choccy machines are turned off. Who'd have thought it?
Here are some of my favourite "London" feeds....
Going Underground's Blog. This, and the somewhat more hyperactive Londonist blog are just full of interesting news articles, rumours and ideas for things to do about town. If you were wondering why all the chocolate machines on the tube were out of order or why there's an erratic red line of paint running from the river to near Euston, these are the places to find out.
The SE1 blog does what it says on the tin. My London office is in SE1 and it's an area I pass through regularly.
The Criminal Solicitor, Policeman, Magistrate, Tube station manager and Paramedic are well known but still worth reading.... it's great to get an insight into other people's lives.
However, I do have some sympathy with Stephen O'Grady's plea here. So, in the spirit of posting links to good content and not just entire blogs, I offer this solitary link. It answers the question of why the choccy machines are turned off. Who'd have thought it?
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.
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.
Thursday, March 02, 2006
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.
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!
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!
Friday, February 24, 2006
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?
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"
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.
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.
Thursday, February 23, 2006
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.
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.
Wednesday, February 22, 2006
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 :-)
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 :-)
Tuesday, February 21, 2006
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?
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?
Monday, February 20, 2006
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.
Saturday, February 18, 2006
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.
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.
Monday, February 13, 2006
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
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.
Either way, it's good to see that XMS is getting noticed; it deserves wide adoption.
Saturday, February 11, 2006
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!
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!
Wednesday, February 08, 2006
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...
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?
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?
Tuesday, February 07, 2006
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.
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.
Saturday, February 04, 2006
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.....
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.
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.
Monday, January 30, 2006
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/
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.
Sunday, January 29, 2006
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.
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.
Thursday, January 26, 2006
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.
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.
Wednesday, January 25, 2006
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.
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.
Tuesday, January 24, 2006
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.
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.
Monday, January 23, 2006
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.
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.
Friday, January 20, 2006
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.
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.
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.
Subscribe to:
Posts (Atom)
