On Escalating Communication

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

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.

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

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

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

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.