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 ]