Like so much acronym soup

When 'buy before build' goes bad

2011-01-20T10:36:00.001Z

It's pretty much a universal principle in a large enterprise: If you want something new, first you try to reuse, then you try and buy something, and only as a last resort do you build something yourself.

Sound enough, right? It ought to be cheaper to buy something from a specialist vendor than work it out and build it from scratch yourself. They get the economies of scale, you get a reduced price, everyone's a winner.

The only trouble is, sometimes buy before build sucks.

The trouble is that usually when you buy, you're making an often large up front financial commitment to something. Not only that, but often we buy something before we've had a chance to really work out what it is we need. So, we end up buying the uber product - something that delivers our every whim and desire.

Very often, when it comes down to it, we buy 100%, use 20%, and wind up bespoking the living daylights out of the rest. The Vincent van Gogh of our vision becomes more like an HR Geiger Alien. It costs as much to customise as it would have cost to build, and far from being a virtual utopia becomes the treacle holding us back.

So, how do you make sure this doesn't happen to you? Simple: Only buy what you're absolutely sure you need.

How do you know what you really need? Simple: Build it and see how your users use it, rework, repeat.

Sometimes life has its little ironies...

Werner Vogels on Amazon.com, AWS and SOA

2010-11-16T13:38:00.002Z

I am way out of date here, but I've just stumbled across an interview between Information Week and Amazon CTO Werner Vogels. The interview is from way back in 2008, but many of the things discussed are just as valid (and in some senses revolutionary) now as they were then.

Touching on a number of interesting bits of information about Amazon's architecture, the interview talks about how Amazon came to become the cloud computing 'thought leader' they are today.

Amazon have been doing SOA highly successfully for nearly a decade, and as demonstrated by their dominant position in internet retail (2009 revenues topping $24 billion and a market cap of over $70 billion at time of writing).

What particularly caught my eye about this article is how it aligns with my own views about what makes good SOA tick:

"It's not just an architectural model, it's also organizational. Each service has a team associated with it that takes the reliability of that service and is responsible for the innovation of that service. So if you're the team that's responsible for that Listmania widget, then it's your task to innovate and make that one better."

To me, making SOA work is more about people and organisation structures than it is about technology. Build the right teams and the technology will come. Focus on the technology and your organisation will just hold you back.

From there, Werner goes on to talk about how they evolved the AWS cloud computing platform out of their own need for highly resilient distributed infrastructure, and of course how they exposed this too as services. To put this in perspective, this 'spin off' is projected to earn Amazon over half a billion dollars in 2010. Not bad for a by-product.

Read the article. Even 2 years late, it's well worth 15 minutes of your time.

IBM UK Impact 2010

2010-06-11T18:06:00.001+01:00

On Tuesday I dropped in on IBM's UK Impact 2010 conference in London. UK Impact is effectively a pocket-sized version of the 5-day, 6000 attendee Las Vegas Impact event held last month.

The Conference was well organised, held in the (rather swanky) Grange Hotel St Paul's.

This was a one-day event, with the morning being single track, and the afternoon multi-track.

As you'd expect given IBM's recent 'Smart' branding (imitation is the highest form of flattery), the Keynote was a startlingly on-message presentation entitled "How your Organization Can Work Smarter".

There were some interesting gems in there: Did you know for example that certain electrical companies in the states give customers a circa $300 annual rebate in return for handing over the keys to their air conditioning to the electrical company? In times of peak demand (but not when it's health-threateningly hot), rather than power up another turbine, they'll start a rolling programme of AC shut-downs to reduce demand. That is smart.

A fun set of statistics for you: Among the businesses run by the top 500 CIOs, compared to other businesses there is:

double the usage of process modelling and automation technology.
3.75 times greater usage of collaborative workspaces.
9 times greater usage of SOA.

... of course, how you define 'top' CIOs or 'greater usage of SOA' is potentially subject to interpretation!

A key message, which I really buy into is that 'excellence is a moving target'. It's easy to be complacent when you're at the top of your game. What (arguably) separates the likes of Google and Apple from Microsoft is their ability to know what the customer wants, before the customer knows it themselves. Doing this, obviously, requires an ability to innovate at speed and change on a dime.

To me, the only way to achieve this is to keep everything as simple as possible at all times. If your IT is so complicated that your business can't wrap their heads around it, is it any wonder you struggle to keep up with their demands? Sometimes the best investment you can make is one that leaves you with less than you started with, particularly if it makes your IT look more like the business it serves.

Google Wave: Panacea or daydream?

2009-08-20T21:02:00.001+01:00

I finally got around to watching the Google Wave developer preview video last night. I'm a great fan of any tool that helps people work better together. If you've not heard of Wave, or not had time to investigate, it feels to me like a hybrid of e-mail, instant messaging, Wikis and SubEthaEdit. Users can create new waves (documents/conversations/communications), make them available to others, and work on them. Wave manages to (surprisingly elegantly) bridge the gap between e-mail, instant messaging and wikis. When you edit a wave, the other person can see your changes as you make them, one character at a time. On the other hand, if they aren't online, the next time they come back online, they'll see your wave waiting for them. This is pretty difficult to describe, but beautiful to watch, and it scales. Watch the video to see what I mean, but suffice to say something which starts off feeling like an e-mail can transparently become a discussion and the reverse is just as true.

There's no doubt in my mind that the technology involved is amazing, but from my perspective, the most interesting thing about the video is that it makes the scale of Google's ambition clear. Google are pretty openly hinting that this thing could become a rival to, or even replace e-mail, IM, Wikis and a whole bunch of other collaboration approaches with a single unified solution. Read that sentence again. A replacement for e-mail; a protocol and metaphor for communication that's been around in more or less its present form since 1982. That's 27 years. 7 years before Tim Berners-Lee wrote his first proposal outlining the workings of the World Wide Web. Google are either seriously confident, or seriously arrogant. Or both.

But. They might just succeed. Unlike many other Web 2.0 services such as Twitter, Google are (at least outwardly) trying hard to ensure that Wave doesn't become a walled garden. Even services such as Google Sites, which offer integration with the outside world using standard protocols (in the case of sites through HTML linking and RSS) don't provide the same level of integration seen in the standardised protocols that support e-mail, IRC and other 'old school' services.

So, what makes Wave different? Google have built, and more importantly released to the public a protocol that allows any old Tom, Dick and Harry to create and implement a Wave server. Moreover, because the protocol is not trivial, Google have open sourced reference implementations of the protocol, and in the video suggest that they're intending to open source the majority of the code-base of Google Wave itself so that competitors can download, tweak and run their own competing Wave services. These services will all federate, and make the experience broadly seamless regardless of which provider you choose to use. Like E-mail, USENET and IRC, information is only sent to the servers supporting users actively involved in the wave, opening the possibility of the (perhaps justifiably) paranoid running their own organisational Wave servers to ensure that content only leaves the corporate network when it is actively shared with a third party. This approach potentially eliminates a major barrier to adoption in the commercial world. Lastly, Wave provides support for Robots (intelligent agents) that can accomplish a multitude of tasks. Google demonstrated Robots that did things like integrating with Google's blogger service and it seems clear this technology could be extended to support integration with existing communication mechanisms, and in particular the big threat: e-mail.

How this all pans out remains to be seen. Google are not an academic organisation, and they must deliver value for their shareholders, but it's fair to say that they have a history of taking relatively large risks by taking on large scale projects with no obvious revenue model that would scare your average VC witless. Despite this, they're still here, and still profitable. I think it's reasonable to say that there's an excellent chance that Wave the product will be a success. I'm much more sceptical about Wave the global infrastructure, due in part to the complexity of the technology and consequent barriers to entry for competitors, but mainly due to something much more human: Inertia.

Regardless of the success of the Wave platform, the debate Wave is likely to stimulate can only be a good thing. The Wave preview opens its doors on September 30 2009 to the next 100,000 users. I have my fingers crossed.

Lies, damned lies and statistics

2009-03-20T16:55:00.001Z

A client I'm working with that the moment has been doing some work around calibrating an estimating model. This model is based on allocating deliverables passing through the project a number of 'points', based on their perceived complexity, and then creating a weighted estimate based on these points. We decided to calibrate the model using a more detailed estimate of a random sample of these deliverables.

A quick review of these figures yesterday revealed a strong correlation(around 0.85) between the number of points allocated to an item, and its resulting estimate. "Hurrah!", we said. Then we said: "This model is useful, and can give us a reasonable estimate of any given subset of the overall project and therefore in particular, of each of our planned iterations." Things were good. Then we twigged.

When we ran the calibration workshop, we asked people to estimate each deliverable. When we described these deliverables, we gave a brief description of the scope of the deliverable, and mentioned the number of points allocated to the deliverable. Nothing wrong with that, right? Well, we decided to do a little experiment, and re-ran the same test, with the same people, but a different set of deliverables. This time, we didn't tell them the number of points allocated to each deliverable.

The correlation was now 0.19. By most definitions, this means there is no correlation whatsoever. Our model is broken.

So, what's going on there? I think (and I'm no statistician) that we're seeing human nature at work. If you tell people something is twice as hard as something else, they're inclined to estimate it'll take roughly twice as long. If you estimate something is three times as hard, the estimate will be three times as long. When we estimate, we don't know we're doing this, as our gut (rather than our head) is doing the heavy lifting here - it's hard to apply a lot of intellectual muscle to something that's ill defined. Gut bases its decision on whatever information is easily available; in this case, someone just told us this thing is 'hard, twice as hard as the last thing', so the number we come up will start off roughly twice as high. If we get some information that makes us believe it's simpler than this, then we might try and adjust Gut's estimate downwards a little, but we'll likely never estimate it totally objectively after being told initially that it's 'hard'.

Thankfully, for us, this hasn't caused a problem. We're mainly interested in the overall averages rather than the specific estimates. We can still predict reasonably accurately the overall length of the project, even if we're a little out on the fine details. The lesson here is clear though: Be careful how much trust you put in these kinds of estimating excercise. They may not be as scientific or accurate a you first believe.

Can SOA governance technology be distracting?

2008-10-22T17:42:00.001+01:00

In a recent post, David Linthicum asks "Can SOA governance technology be distracting?". His answer is yes, and he offers the following sound advice:

First, only purchase SOA governance technology, if it's indeed needed, after you have a complete semantic-, service-, and process-level understanding of the problem domain. Never before.

Amen to that. In my opinion, for all but the most mature and involved environments, the procurement of an SOA governance platform should be well down the list of priorities. I'd add to David's list of things that need to be 'worked out' before you get that cheque book out:

What is your vision for governance itself? Do you want to adopt a 'iron fist' or 'hand in glove' approach? Is your registry going to be a mechanism for governing or a side effect of it?
Who's going to populate it? Have you got your analysis, design and development processes sufficiently honed that your repository isn't going to turn into a dumping ground of candidate services?
Have you actually got any services live yet? Governance is a whole lifecycle thing. Until you've worked out how you're going to deploy and manage services in the production environment and demonstrated that this works, how do you know what capabilities your governance platform needs to offer?
Most importantly: What are the use cases for your governance platform? Can you demonstrate that these use cases can't be addressed using your existing tooling (even if that's Microsoft Excel)? Be honest with yourself about when you're likely to implement these use cases. If the answer is further than one year away, then for the time, you might be wise to forget them. There is little point in spending good money on runtime governance or automated deployment technology when in a year's time you'll be able to get more for less.

A lot of projects using SOA governance tools at the moment treat them as glorified databases. If that's where you're at, consider using something less specialised that allows you to evolve your ideas, understanding and schema before you commit to something that will make this innovation harder and more time consuming. When you've spent six to twelve months getting your ducks in a row, so to speak, you'll be in a much better place to make decisions.

I'd really welcome stories from people about how they've implemented governance platforms in the past, whether they're informal (e.g. Wikis, bugtrackers, spreadsheets) or formal (e.g. IBM Websphere Registry and Repository, CentraSite from Software AG): What did you implement? What worked? What didn't? What would you do differently next time?

Choosing an Open Source 'ESB' technology

2008-08-10T09:22:00.001+01:00

I'm currently working to find the best Enterprise Service Bus for a project. Nothing unusual there. Something I've done a few times before. Except this time the requirements are a little more unusual than which kinds of transformation the tool supports.

Functional requirements:

The ESB must fit with Smart421's SOA patterns.
The ESB need not be a one-box solution. We're happy to mix and match tools around the outside. BPEL in particular is not necessarily a mandatory part of the core product.

On the face of it, not too tricky. In practice, maybe a little harder: In our view, the ESB isn't a piece of software in the first place, it's a collection of (continuously changing) standards and policies that govern the interactions that take place across the essentially empty void between two services, so we're looking for something that's compatible with that view, rather than something that wants to sit at the centre of the SOA universe (more on this later, perhaps). Let's look at the non-functionals:

The ESB must be Open Source, be based on an Open Source product, or there must be an Open Source version available.
The ESB must have an established presence in the market - the latest and greatest features aren't enough. We're looking for something that has some industry buy-in.
It must be possible to buy in support for the product from a third party, should we need it.
The ESB must support light weight development. We must be convinced that easy things are easy achieve, and hard things are proportionally (and not disproportionately) harder.
The ESB must offer a non-functional envelope that allows it to support a large scale enterprise application, preferably without restricting us to vertical scaling.

I'm intending to follow a fairly standard product procurement process to help select the technology, so the next step is to set some more formal selection criteria and identify some candidate products to form the ESB core.

At the moment, the obvious candidates for me are:

I'll keep you posted as I progress... Comments/suggestions/vitriol welcome!

Battery Statistics

2008-07-28T11:01:00.001+01:00

Simon Wilson recently explained that you can get information on the original and current capacity of your battery using the following command:

ioreg -w0 -l | grep Capacity

This works great on my machine, but just thought I'd mention that for those afraid of the command line, as I've previously mentioned, there's a great little utility called CoconutBattery which provides a GUI interface to all this. Try it, you might like it.

The start of a trend?

2008-07-08T09:37:00.001+01:00

From MacWorld:

Huge newspaper makes Mac switch move - Mac - Macworld UK:

One of Europe's largest newspaper publishers, Axel Springer AG, has announced plans to migrate its 10,000 employees and 150 newspapers in 30 countries to the Mac

Speaking in a video message that's now available through YouTube, company CEO Mathias Döpfner notes the following four reasons for the shift:

'Most of the company’s layout work was already being done on Macs

'Macs are more user friendly than other computers

'Apple creates the most elegant computers

'Macs are cheaper to buy and easier to maintain than they were in the past.'

Could this be the start of a trend? I'm not expecting an avalanche of such announcements in the near future, but the world is changing. Microsoft seem to be suffering from horrendous PR problems at the moment, with people (regardless of the reality of the situation) starting to view them as dazed and confused. I saw a magazine cover the other day which posed (if I remember correctly) the question: "The end for Microsoft?".

The $64000 question for me is "are Apple really any better than Microsoft?" I think the jury is still out on that one...

Battery Woes & Coconuts

2008-06-27T08:43:00.001+01:00

Why is it that all laptop batteries eventually die?

Whenever I charge my MacBook Pro completely, the battery meter stops at 98%, and the battery says it's charged. I'd like to think this just means that I get 2% less charge than I used to, but the reality is far less appealing. When I unplug the juice, my laptop informs me I've got 1:33 to live. I used to get at least 2:30.

I know it's a reality that laptop batteries behave like this, and I'm aware that nothing short of a breakthrough in chemistry is likely to change this, but what I would like to see is some kind of transparency about the state of the battery - an advanced battery meter if you like. Something that shows the theoretical battery capacity, the charge attained last time it was full and it's current level. The meter could also show the number of 'charge' cycles the battery has been through to provide a view of the likely useful life of the battery.

I guess it would look a little like this:

Thankfully, someone's gone to the trouble of doing exactly that. CoconutBattery provides all of the above information at a glance, allowing you to understand exactly the position you're in. Which in my case is that I'm the proud owner of one of the oldest MacBook Pro's on the market (29 months? Has it really been that long?), and its battery is getting a bit weary. Perhaps it's time to buy a new one...

My other car's a jet powered wing-suit

2008-05-15T12:47:00.001+01:00

Dear Santa, please find attached a video of what I'd like for Christmas this year. I know at first glance it might look a little dangerous, but it'd be a hell of ride...

From BBC News: Rocketman flies in the skies.

Simulation based estimating

2008-05-01T17:44:00.001+01:00

I'm sat on a train at the moment, from Norwich to Ipswich. This train will take 39 minutes to reach its destination. It'll then take me 7.5 minutes to walk to the office, 1.3 minutes to make a coffee. I'll be ready to work at 08:17:48. Obviously, I'll stop to take a sip of coffee at 08:17:57, 08:18:20 & 08:18:50, and a large, cup emptying slurp at 08:19:20. Other than that though, it'll be working straight through 'till 17:30:00. I will not get peckish and stop to raid the snack machine. There will be no interruptions. Nobody will, at short notice, book a meeting or pitch up at my desk for an impromptu chat about the current status of Project X or Initiative Y. My fiancé will not send me an SMS asking me to pick up a bottle of wine on the way home, and absolutely no recruitment consultants will call. All my days are like this. I never have a bad day, never fail to get my head around the task at hand first time, never struggle to think where to start. All my tasks are predictable, have well defined goals and require no assistance from anybody who might be having a bad day. Of course, in this environment, I deliver what I said would, when I said I would with 100% certainty, every time.

Of course, I'm dreaming.

The reality is that nothing about the average day of the average employee is in any way precise. My train might take 39 minutes, or it might take 41, or if I'm lucky and there's a northerly wind, it might take 38 minutes and 59 seconds. My walk will be marred by traffic lights, and I (shock) will have bad days. If I were to use the fingers of every occupant of this rush hour train to count the number of times I've been asked by a project manager over the last 10 years "How long will this project take? How much will it cost?", I'd probably have no more than two fingers left to type the remainder of this post.

The trouble is, you see, I don't know.

Don't get me wrong, I can estimate things as well as the next guy - it's just counting widgets at the end of the day, but I know I'll be wrong. Of course, project managers are reasonable people, they say things like "Well, we have to be 100% confident in this estimate, so we'll add 10% contingency to your total, ok?" No. Not OK. The issue here isn't that I under-estimate routinely (although that might well be an issue), it's that adding ten percent will not make any estimate 100% confident, and nor will adding thirty, one hundred or even three hundred percent, regardless of how good an estimator I am.

Anyone who remembers the whale and bowl of petunias from Douglas Adams' Hitch-hikers Guide to the Galaxy will remember that according to Adams, the sudden appearance of flora and fauna in deep space is unlikely, but none the less has a real finite probability. Perhaps somewhat shockingly, this sort of thing is a reasonably well accepted side effect of quantum mechanics; this could happen at any time in any place. You could be just tucking into a medium (sorry, Grandé) cappuccino at your local Starbucks when something, anything, appears. House, car, cat, dog, frog, you name it. Now, just to stop you panicking over your caffeinated beverages, the chances of this happening are infinitesimally small, but it serves to illustrate the point that you never know what might get in the way of your project.

So, finally, to the point of my post. I think it's time estimating grew up a bit, and stopped pretending that it knew all the answers. What's needed is a way of estimating the cost and duration of a project that softens the boundaries a bit, and gives a truer picture not of how long a project will take, but how long it might take. Imagine for a second that a programme manager knew that there was a 66% chance that the project would be in by Christmas, and a 88% chance it'd be in by June. He'd probably be much more likely to give the board a sensible message than if all he had was a vague message from you that it could conceivably be done before the turkey gets cold. Equally, those of us who sometimes work on fixed price contracts would have a much better way of assessing the risk of a given project, allowing us to reliably turn a profit while offering a good deal for the client.

It strikes me that there are two approaches that could be taken to this:

Use probability theory to attach a probability distribution to every input parameter in the estimating model, and then carry these through the model and give a final probability distribution at the end. Complex, nasty, not much fun unless you have a PHD in applied statistics.
Make the input parameters to the model fuzzy (more on what I mean by this later) and then run the estimating model over and over again, collect all the answers and build a histogram (chart) out of the results.

I've thought long and hard about this over the last few years, and frankly the former option is beyond the capability of my AS-level statistics. Even if it wasn't though, I'd be recommending the latter, and here's why: It's intuitive. What you're doing is running the project over and over again, and seeing how long it takes. Project leaders can be old and wise without being old and wise; they've already done this project 1000 times (albeit in the mind of a machine), so they've got a good idea how long it might take.

Using this approach, you could build absolutely anything into your model; Productive day averages 6 hours, but varies between 2 and 20 hours on occasion? Sorted. 0.04% chance of aliens abducting your senior developer? No problem, at least for the project. The options are endless.

Nicer still, because this approach uses simulation rather than algebra, we don't need to be too anal about how the parameters are set. If it's easier to say "95% of the time it'll take 5 hours, but 5% of the time it'll take a random value between 8 and 10 hours", then that's fine. We don't have to put together some strange combination of probability distributions that models this; we just run with it. Equally, if you have a set of example data to use as a basis (well, this system has N classes, and it took X long), then these values could be used directly, without having to build a complex model from them first. That said, if the guys doing the estimating do understand probability, then they can use a Poisson distribution to determine how many use cases will be delivered by a week next Friday if they so desire.

Equally, because we're actually running the project, we can apply all sorts of interesting things to the model that would be impossible using a purely statistics driven approach. For example, in an agile project, we can simulate the team size and length of sprints against the simulated sizes of the products to determine the optimum length of a sprint for the project. We could simulate the quality of deliverables based on whether code reviews are expected, and use this to estimate the impact on the length of the test cycle. Obviously, this stuff is a bit trickier to achieve than answering the usual how long/how much question, but it's always good to know there's scope to develop things further in the future.

The architecture underlying this kind of estimating machine is pretty trivial. I'd say, with 100% certainty, you could deliver the underlying engine in 27 hours, 5 minutes. Elephants and petunias not withstanding.

Martian Headsets

2008-03-27T10:20:00.001Z

A colleague just pointed out a brilliant article from Joel on Software discussing the upcoming release of Microsoft's IE8. If you care about the web, have a position on web standards, consider yourself an activist, pragmatist or martian, then read it. Now.

TimeMachine with AirPort Disk: Finally

2008-03-21T20:00:00.001Z

Apple yesterday released updates to their AirPort Extreme and TimeCapsule base stations and Time Machine which allows Time Machine to use an AirPort disk for backup (I have an extreme with about 1.5TB hanging off it). Finally. For those of you with a laptop like me, this means you can have a safe and secure Mac without living life in a bird's nest of cables and disks.

I configured it with a new disk yesterday, and it works great - just connect to the drive (by clicking on it in the left bar in Finder), and it appears in the Time Machine window and can be selected as the target for backups. The good news is that it seems very stable and happy - putting the laptop to sleep and waking it up again during a backup seems to have no impact, which is great. The bad news is that I started my first backup more than 24 hours ago, and it's still running. Whoops. Learn from my mistake: do your first full backup with the drive physically connected, otherwise you'll spend the next three weeks watching paint dry.

All in all though, it's great news that those of us that invested in AirPort Extreme base stations are being given the same privileges as those investing in brand new Time Capsules.

Oh Joy: High Court rewrites UK software patent rules

2008-03-19T18:19:00.001Z

From Computing:

High Court rewrites UK software patent rules:

"The High Court has passed a ruling that for the first time allows computer programs to be patented in the UK.

"The decision came about as the court upheld an appeal from Symbian following the rejection of an application the software firm made to the Intellectual Patent Office (IPO).

"Symbian filed for a patent relating to the way computers use a library of functions that can be accessed by programs."

I'm hoping this is a storm in a teacup. IMHO, software patents are a fundamentally flawed concept which I'd hate to be subject to. Patents were designed to protect inventors of physical products, for whom the 'invention' bit was just the start of an enormously expensive journey to success, which could be upset at any time by a competitor with better tooling or more staff. As I understand it, you wouldn't normally go and get a patent until you've created your first production prototype.

This simply doesn't apply in the software world - by the time you've implemented your production prototype, you're 60-80% of the way there: Functional, non-functional and user acceptance testing are the remaining barriers to distribution. You don't need to tool up a multi million pound factory, you don't need to employ 20 staff to work the machines. In the general case, there are no boxes to pack, no labels to print, no lorries or fuel to buy, no returns to process, no replacement goods to ship. What's more, someone with more developers or a more established shop often isn't better placed to produce your product than you, the inventor.

This is what is so beautiful about software. Some of the best software in the world was written by small teams of very smart people, who had a good idea and ran with it before anyone else got a look in. I'm sorry, but if the big boys can't keep up with two guys, one girl and a dog working in their shed, then maybe it's time to consider a divestment.

And Breathe. . .

บ้าน (home)

2008-03-14T03:48:00.002Z

I crawled into bed at 1am last night, no less than 25 hours after getting up. Paradoxically, I only got up at 7am. Aren't time zones wonderful? I've just got back from a business trip to Bangkok and thought I'd post some lessons learnt. In no particular order:

The weather in Bangkok is hot. Wear short-sleeved shirts. Don't wear ties. Wear a suit jacket when you go out in the evening, you'll look like an idiot. And I did.
Don't cross roads until you've looked left, right, up, down and have resolved any outstanding issues with your life insurance.
When you enter your airport taxi, note that it will take exactly 27 minutes before you realise you are not about to die. It'll take another three minutes before you take your hands away from your eyes long enough to notice that none of the cars weaving between lanes have dents, and decide that they are clearly made of reenforced diamond. Or decide that Thai drivers are considerably more talented than you, I or Jeremy Clarkson. Yes, really.
The people in Thailand are friendly, polite, and remarkably tolerant of our lack of aptitude for their language. Say "thank you" using the feminine version of the phrase for three days, just to keep them amused. We did.
You've not seen value for money until you've been to Bangkok. Stay in a hotel room as big as your house for £70 per night. Spend 45 minutes watching the meter in a cab slowly reach the £2 mark. Now try doing the same in Farringdon.
Towers in Bangkok are tall and numerous. Ours had 38 floors. Take pleasure as the high-speed lifts make your ears pop. Bring sweets. Yawn liberally.
The Starbucks franchise covers all corners of the earth. I strongly suspect they have spread to all nearby star systems.
Jet lag is a killer. As is the dawning realisation on your exit from Heathrow airport that the English weather is, frankly, rubbish.

More seriously, spending a few days talking to these guys taught us a thing or two about how to communicate with people when you don't speak their language:

Don't underestimate the people you're talking to - remember the issue is one of communication, not capability.
Explain things in simple, but not patronising terms - using colloquialisms or slang won't help. Remember that some phrases that are in common usage in the UK might well not translate: We spent two days using the word 'business partner' before realising that this had been misunderstood.
Use diagrams. "A picture is worth a thousand words" has never been truer.
Give it time: You might find you need to explore new ways to explain things in order to hit the right buttons. Talk around the subject a bit, go back to basics, find the hooks in their heads that will allow them to understand.
Find time to swap stories and compare cultures. Not only will this build rapport, but it'll help you to understand where your audience is coming from and what drives them.
Solicit feedback and encourage questions; you'll get a far better picture of your audience's level of understanding by allowing them to challenge and push back than you will by blindly blithering on at them for days on end.

So what is service reuse anyway?

2008-03-08T12:00:00.001Z

Just read an post over at InfoWorld by David Linthicum. The central point of David's post is that reuse shouldn't be considered or advertised as the 'core value' of SOA. I totally agree with that, particularly as often, organisations still insist on setting up SOA projects, rather than changing the mindset and method of working to encourage the adoption of SOA across projects.

To me, half the problem with the reuse argument is that people don't have a clear understanding of what is meant by the term. Often, people consider that reuse is only achieved when a service has more than one consumer within the SOA at a point in time, but (to me) that's missing the point. An SOA is not a static environment; in a well managed organisation, it'll change almost continuously. To me, you're achieving some level of reuse whenever you fundamentally change a business process without having to re-hash all of its services, or you don't have to bother re-testing every combination of parameters to a complex business process because you know already that the services that underly it, which make all the hard decisions about someone's credit worthiness have been tested thoroughly already. You even get re-use whenever you say "Ah, well, we'll apply our standard grade message integrity policy to that service, so we know how to achieve that".

If you take this broader view (let's call it long-term reuse), then long-term reuse and agility become somewhat interchangeable concepts - you get agility through being able to reuse a service across two versions of the same process, by knowing that you've already tested a given service to death, and by not having to make complex technical design decisions each time you create a 'new' service.

So. I agree that the reuse should not be used as an advertising 'headline' for SOA, because in an advert (be it literal or spoken), you don't really have the time or bandwidth to get some of the subtleties of the above across. But in reality, over the medium term, I think we will find that the long-term reuse achieved (assuming for a moment you buy into my definition) is significantly higher than people currently expect.

The last point I'd make is this: If you design your services for immediate reuse, you will likely fail to achieve that re-use. If on the other hand, you design your services for change, and aggressively factor new functionality into them as new consumers require it, I suspect you'll find even 'point in time' reuse increases dramatically over the medium term.

iPhone Killer App: OmniFocus

2008-03-07T10:51:00.001Z

I've been putting off buying an iPhone for months, as I've already got a mobile contract with Vodafone, and funnily enough, they're not too keen to let me out of it so that I can defect to the competition. However. But. My resolve is failing...

The Omni Group have just announced on their blog that they're intending to release an iPhone version of OmniFocus.

Despite my resistance, there is a 97.4% chance that on the day OmniFocus for iPhone is released, I'll be in the queue in my local O2 shop to pick up an iPhone. My life currently resides mainly within the Mac version of OmniFocus, and my main gripe with it is that taking my laptop out on the road is a real pain. What a joy it would be to be able to leave the thing at home and not forget to breathe in and out.

I'm practically salivating with Getting Things Done goodness, can you tell?

On Escalating Communication

2008-02-26T13:18:00.001Z

Just read a good article from Jeff Atwood over at Coding Horror, On Escalating Communication which discusses the need to communicate not only the right message, but through the right medium. Amen to that.

I had an experience yesterday where I found I was writing an e-mail on a politically sensitive issue which had the potential to blow up in my face (personal situation, I hasten to add - nothing to do with work). Now, there are two approaches people take when writing an e-mail like this. 1) The Grenade: Don't worry too much, toss it over the wall and apologise afterwards. 2) The Gold Brick: Contextualise and rationalise your argument to the point where it is seemingly incontrovertible, but consequently also impenetrable and arrogant, then toss it over the wall and knock the poor recipient out. I'm generally in the latter group.

I went ahead and began to contextualise & rationalise my key message: "I won't pay XXX for YYY, try again." By the time I finished, the e-mail was 7 paragraphs long, explained my full life story, described my rationale for believing that XXX wasn't the right price for YYY, justified it to the 359th degree, turned around and touched its own toes, but didn't really send the right message. Why? It was too inflexible a communication mechanism for the circumstance. There could be any number of reasons why YYY was overpriced, or XXX was too much. Sending the e-mail as it was could potentially have blown the whole situation out of the water, disenfranchising the vendor and leaving me without my YYY.

In the end, I saw sense and 'phoned the vendor and sorted things out. They're still mulling things over, but I'm confident there's a much better chance of getting the right answer than if I'd hit them on the head with a gold brick.

How do you tell when you're trying to use e-mail to do something it shouldn't be used for? I suspect the answer is simple: If you feel you're having to cut corners in your communication, or you feel like you're trying too hard, then you're probably using the wrong medium. Time to upgrade to a phone call or, heaven forbid, a meeting.

Risk Management Faux Pas #374: Pilot sacked after fly-by stunt

2008-02-25T20:21:00.001Z

Andrew just pointed me to a rather amusing article documenting the impending career failure of an over-excited Cathay Pacific pilot, who decided that performing a fly by in a brand new Boeing 777 at an altitude of - wait for it - 28 feet would be an excellent career move.

Two facts strike me as interesting about this. The pilot was (a) 55, and therefore presumably aware that this kind of behaviour was unlikely to be well received, and (b) flying a plane containing 69 senior Cathay Pacific staff, including their UK chairman. Maybe he thought he'd sneak it under the organisational (or real?) radar...

IBM WAS: Fast? Yes. Central to SOA? Only in marketing.

2008-02-24T10:53:00.001Z

IBM recently issued a press release stating that "WebSphere Application Server, a key building block for services oriented architecture (SOA), shattered a popular industry benchmark for scalability and performance by more than 33 percent using technology that costs half the price of the competition".

First of all, Kudos to IBM for continuing to improve the performance of WAS. Anything that drives the performance of key bits of infrastructure has to be a good thing. However, that's not the thing that caught my eye about this article. Instead, my eye was drawn to the statement that WAS is a "key building block for services oriented architecture". Let's consider where IBM was coming from when they wrote this:

IBM WebSphere Application Server forms the foundation of IBM WebSphere Process Server, IBM's middle of the road (as opposed to specialised) 'SOA Platform' offering.
IBM WebSphere Application Server is the leading (in terms of sales, at least) J2EE platform.

Maybe this is where IBM were coming from. It's true that WPS has significant take up in the market, usually within SOA projects, so I guess you could argue that WAS is the foundation to something which acts as part of the integration infrastructure underlying SOA projects. Alternatively, perhaps they're considering WAS in its own right. It's certainly an excellent platform for building and deploying the business logic which drives the behaviour of service implementations.

But (and in my opinion, it's a big but) the key to SOA is hidden cunningly in the name. It's Service Oriented Architecture not service oriented application-server, service oriented platform or service oriented infrastructure. SOA is about structuring your solutions according to service oriented principles, governing these solutions to ensure that they all contribute to an enterprise-wide ecosystem of services. To me, a key SOA principle is to be globally independent of any one third part product, and understand before you start how you can migrate away from the platform in the future. Therefore, to state that a product is a central component of SOA as a whole is misinformation at best, and could if taken literally be very dangerous for the ongoing health of your company.

I know that sounds melodramatic, but there's method in my madness: If SOA really is The One True Way, then it'll outlive any product (and possibly several of the vendors) currently in the market. If you couple your SOA vision to an individual platform, then you risk creating yourself a huge migration issue, comparable to nothing you've seen previously when the market inevitably moves on to new products in the future.

Annoying issue with Maven Archetype plug-in

2008-02-21T18:15:00.001Z

I've just spent an annoying fifteen minutes battling with trying to get Maven to download and use one of the ServiceMix archetypes. After some battling, it transpired that there's a bug in version 2.0-alpha-1 of the Maven archetype plug-in (or at the very least, there's a change in there that upsets the apple cart as far as the current repository goes). The solution seems to be to force Maven to use version 1.0-alpha-7 of the plug-in by either manually running:

mvn org.apache.maven.plugins:maven-archetype-plugin:1.0-alpha-7:create ...

... or if you're using ServiceMix like me, editing your smx-arch.bat or smx-arch.sh file to include a similar change. This does all rather make me think that the Maven guys need to concentrate a little more on governance of change to their plug-ins. Replacing a plug-in that works with a plug-in that doesn't, and making the whole world adopt it by default is not a good way to make friends and influence people.

Web Service Threats

2008-02-20T10:35:00.001Z

I've been doing some work recently that involves enumerating the potential threats faced by SOA implementations. To help Google, here are a few of the resources I've found useful in doing so:

ZapThink - XML Threat Management: As you'd expect of ZapThink, a good high-level description of XML threats in general, but no specific terminology for individual threats, and no categorisation of threats.
Forum Systems - XML Threats: Forum Systems sell XML/web service security products, so as you'd expect they're hot on illustrating the risks associated with using Web Services to customers. Nothing like a rainstorm to sell umbrellas. This page provides a very high-level summary of the types of attack vectors used by malicious service consumers; a companion white paper, "Anatomy of a Web Service Attack" provides a lot of additional detail explaining these types of attack.
ZDNet - Five things you need to know about Web services threats: A useful article by Scott Morrison, Director, Architecture and Security at web service security firm Layer 7. Gets away from talking about specific threats, and talks more about the goals and high-level approaches used by attackers. Well worth a 10 minute read.

Interestingly, there doesn't seem to be a consensus over a taxonomy (categorisation system) for these threats. Possibly the closest we get is in Scott's article, where he suggests that all web service threats can be put in three categories: API, Infrastructure and Transaction attacks. Sadly, Scott doesn't go so far as categorising the threats identified by the other vendors. Hopefully when this picture emerges, it'll represent industry wide consensus. This should allow vendors such as Layer 7, Forum Systems and IBM (with their DataPower range) to communicate with customers in a consistent manner, and allow them to sell their wares based on customer need and product capability, which after all is the key to long term relationships and repeat business.

HTML Tip: Coloured bullets using CSS

2008-02-06T19:20:00.000Z

In a bit of a departure from my normal work, I've been putting together a set of HTML templates and screen designs for a prototype. The company I'm working with has a very strong brand, and the standard text-coloured bullets just weren't quite right. I did a bit of googling for approaches to making this work, but most of them involved wrapping the 'text' part of the bullet in an HTML element:

<ul>
  <li><span class="text">Bullet text</span></li>
</ul>

ul {color: red;}
ul .text {color: black;}

I don't particularly like this approach, because it involves adding additional markup to deal with styling, which is bad news. Instead, I came up with the following approach:

<ul>
  <li>Bullet text</li>
</ul>

ul {color: red;}
ul li:first-line {color: black;}

This approach works because it asks the browser to render the first line of the bullet in black, and most browsers don't consider the bullet itself part of that first line. Sadly, almost inevitably, this doesn't work on Internet Explorer. Sigh. None the less, if you're looking for a clean way to deal with this that works with most browsers, and you're not too worried about the dwindling numbers of Internet Explorer users, then this approach is worth a look.

Runtime SOA Governance

2008-01-22T15:54:00.000Z

I've recently been asked to define Runtime SOA Governance in the glossary of a project, and having looked high and low, have come to the conclusion that there is no widely accepted definition of the term, which is somewhat surprising given the number of product vendors who mention the term. Despite the risks to my personal safety of doing so, I have come up with my own, which I am only vaguely happy with: Runtime SOA Governance provides a mechanism allowing information about the operation of a running SOA environment to be fed back into an organisation’s SOA governance function. The information gathered may include:

How often each service is invoked.
Which services each service invokes.
Whether services are meeting their service level agreements in terms of availability, reliability and performance.

This information helps to support investment and change decisions by giving the governance function a better understanding of the runtime behaviour of the services. If you have a better definition, do let me know...