majority report

you’ve seen it, i’m sure. and you thought “wow! this is the future!” and then “i want one of those!” i’m talking about a type of computer that appears in the 2002 science-fiction movie Minority Report. infact i’m talking specifically about the mind-blowing interface to that computer. if you haven’t seen (or somehow you’ve forgotten it) this youtube vid should give you an idea.

as you can see, the user interface just rocks. frankly though, isn’t it about time the way we interface with IT moved on? the two-dimensional pointing device we call a mouse is around 30 years old already. the keyboard with its QWERTY layout dates back to the 19^th century. and more recently motion-sensing controllers like the Wii Remote have revolutionized the way people play games (and the people who want to play them!)

when i watch the vision of the future of computing portrayed in Minority Report though, something isn’t quite right. something about it doesn’t seem so cool and advanced and futuristic. infact something seems rather silly, old-fashioned and lame. it’s not the cool UI that’s bugging me. if you check out the youtube vid i referred to, you’ll see it 44 seconds in. it’s the bit where a character removes a transparent card shaped like a SIM-card from one machine and inserts it into another.

presumably these cards represent some futuristic form of data storage akin to a USB memory key. see-through memory keys? cool! two futuristic computers that can’t automatically exchange data files without requiring a human to move the data between them? not cool! is this the way we’ll be sharing data between IT systems in 2054? i sincerely hope not.

the computing interface in this movie is seen as revolutionary and many pioneering innovators are desperately trying to make it a reality (Oblong is one of those). but what about the future of integration between those IT systems? should we aspire to a future where we need to manually eject and re-insert transparent discs between computers then? no. clearly not. this primitive form of integration has been called “swivel chair” integration, refering to the way that humans have to swivel back and forth between machines, rekeying data, and has been universally derided as error-prone and archaic since at least the late 1980s.

so why on earth should “swivel chair” integration appear in a vision of the future over 40 years from now? perhaps there’s a good reason. so much manual, swivel chair style integration is still going on today decades after better solutions had emerged and even amongst the most technologically advanced and progressive organizations. it’s not the minority. today archaic, unreliable forms of data movement between IT systems makes up the Majority Report.

the proliferation of USB memory keys is just one example. how often have you had to resort to this method, even though it can be inconvenient and quite impossible to secure and audit? how easily could those transparent memory cards from Minority Report go missing or get duplicated even though these contain very sensitive information about past (and future) criminals? like Cruise’s character, John Anderton, we now live in the world of “pre-crime”. auditors that want to be convinced that our organizations won’t break compliance in the future, in addition to checking we haven’t in the past. how we move data between IT systems is a crucial part of that analysis.

if Minority Report showed us the future of the computer user interface that we now aspire to, what is the future of integration, of file transfer between systems? well, i’ve seen it, and it’s not an illusion created by Hollywood’s green screens. it’s real and it’s emerged from only slightly less glamorous origins – IBM’s Hursley Labs in Winchester, UK.

the future is managed file transfer. and we’re helping companies around the world realize their aspirations right now. meanwhile it’s time for me to slip on some gloves, connect a bank of flat screens up to my Thinkpad and pretend i’m fighting pre-crime from my desk in hursley.

less is more

ni hao! one aspect of my job i enjoy most is talking with customers. whilst i relish the chance to get on the road and visit our clients in their own environment, it’s not practical to do this every month. and teleconferencing has its limitations, especially when you’ve not already met face-to-face already at a trade show. fortunately we have the luxury of an executive briefing centre in hursley, one of many in IBM labs across the world (the most recent to open being in Krakow, Poland). this means a steady flow of clients come and visit us, and the relaxed atmosphere is really conducive to digging into what our clients’ needs really are, as well as being able to tap into the expertise of the whole lab at a moment’s notice.

i quickly began to realise how much more effective these sessions could be – both for me and for my clients – when i gave the powerpoint a rest, and stopped doing all the talking, started asking questions instead and got my ears really working. to start with, the folks that organize these sessions looked at me oddly, as though i’d forgotten to prepare a slick pitch whose success was gauged by how few questions it evoked at the end. but i’ve found you can’t start presenting what you have effectively, until you know who your client is, where they are now, and where they want to go. over the past few years, i think we’ve all come to appreciate that two-way discussion beats one-way instruction.

today, i had a new experience in terms of presenting to clients. and it’s helped me do something very important when explaining the value of messaging and connectivity software – presenting via a translator. i came away convinced that anyone in product management, marketing and sales should seek opportunities to present to people who do not speak their own language. it’s all too easy to rely on 45-50 slides to convey the value, benefits and features of your offerings. why? important decisions in life can be made without so many words. and most communication is non-verbal anyway. with a bit of effort, and with a bit of distance between you and the medium of powerpoint, you can create “big animal pictures” that convey more thoughts than 20 densely bullet-pointed lists. Case in point here, is that most interest and questions in this case were generated by my “big animal pictures” about the new high availability features of WebSphere MQ V7.0.1 and another on the role messaging can play in enabling a Smarter Planet.

but most importantly, presenting with translation forces you to say less and to say it slower. rambling is out. asides are out. to be effective you have to condense your entire value proposition into two or three sentances. cutting out of the fluff like this is refreshing. and not just for the clients who don’t speak your language. presenting in this more thoughtful, concise manner means your message is no longer implied. it’s not in the slide somewhere. your message has to be lucid, direct and explicit.

if you present at all, i seriously recommend setting yourself the challenge of finding an opportunity to present through a translator to a team who don’t speak your language at all. you’ll learn a lot from just preparing with the translator anyway about how to simplify your messages and get to the point. (don’t present without  preparing with your translator!) i promise you’ll learn a lot about streamlining, condensing, communicating your messages. and if you come away from the experience as i did, you’ll be thinking seriously about honing the presentation you give to your English-speaking clients too. meanwhile i look forward to my next opportunity to present via a translator again, as i start trimming my presentations down to the raw, core message – here at my desk in hursley.

break it down

it took me almost 2 hrs to get into work recently. “so what!” you long distance commuters might exclaim without a trace of sympathy. however, usually my pleasant drive to work can be executed in less than 15 minutes. so that’s an 800% degradation in the efficiency of my morning commute. and given it made me very late for an important meeting with a client, had an adverse effect on my stress levels and a knock-on effect on the rest of the entire day, making me subsequently late for most other appointments spreading, sharing this inefficiency with everyone else my day brought me into contact with. big deal. why the rant many days later? was the main reason for this inordinate delay to my journey due to certain bottle-necks in the route i take from the maybush area of southampton to ibm hursley? perhaps. or was the actual main cause on this particular day the dreadfully inclement weather? – the heavy rain pummelling the roads and severely reducing visibility? possibly.

but i’d like to argue for another root cause. a different ultimate reason to the road chaos. it might seem too obvious to be profound but here goes: the rush hour. the simple fact that in that short window of time, everyone had simultaneously brought their cars onto the road to fight to get to work. stand back for a moment and think about it. we synchronize our daily commutes for maximum disruption. we batch up all the day’s traffic to try and execute it all in the same small slice of time. is there a solution? my usual habit is to begin my working day early, checking email, planning the calendar, determining whether i’ll be more effective getting things done at my desk in hursley or at my home office. as a result, when i do commute into the office my day- and journey – starts a little later than most. this does mean i park further away from my desk than i otherwise might, but on the other hand my commute is stressless and traffic-free and above all efficient. in short, i’ve learned how to un-batch myself from the rest of the traffic and improve my efficiency.

can IT learn a lesson here? does it needlessly batch data processing, unnecessarily synchronising network traffic and processing? yes. i see it all the time. in every size of company, every industry, every geo, every stage of IT sophistication. batch transfers. overnight updates. regular, daily tasks. all coordinated simultaneously so that one little hiccup causes gridlocked chaos. one large financial company operates this way even today, batching up its over night updates to transfer from each region to head-office. it has a window of, say, 6 hours to transport all these batch updates so that come the morning all the head-office systems are synchronized and up-to-date. the batch takes 4. a hiccup (on the network for example) that can’t be detected and resolved less than 2 hrs into the batch transfer is not going to finish in time and will cause major headaches when the next day begins. [incidentally, the process for detecting a problem in this case involves an application whose algorithm for sensing a fault is dubious and inconclusive and that is intended to alert the night security personnel(!) hardly a bullet-proof solution].

but the main issue i want to focus on here isn’t the reliability – it’s the scheduling. businesses need to get away from the batch mindset. it’s synchronising things for maximum fragility and minimum efficiency. “overnight” doesn’t exist in most industries anymore. doing things in little batches – micro batches if you will – rather than in one big job, must be the way to go. spread the tasks across the day and night. stream updates continuously. turn the tidal wave into a swell. the flood into the flow. the tsumani into the constant trickle. take that big batch job – and in the words of MC Hammer – “break it down”.

infact, even this blog entry is another example of micro-batches yielding greater efficiencies. if i’d sat down to write this in one go, i would have had to carve out a lump of interruption free time. but i’ve discovered that never happens. instead i write my entries in micro-batches. a few lines at a time. so this entry really made no major hole in my week, just snatches and snippets here and there. just a thought, if you’re struggling to find enough time to craft entries, just as i did when i began to blog from my desk in hursley.

minor leak

is there ever such a thing as a minor leak? for example, my plumber detected a minor difference in gas coming into my house and the amount reaching my appliances. in short a very minor, barely detectable leak. infact, one that is apparently within the legal limits for such “differences”. so it’s minor and legal. but is it acceptable? nope. because no one wants ever a minor leak when it comes to something as vital as a gas fault. life and death. that’s why later today my plumber will be round to fix it. meanwhile i’m in hursley, but away from my desk. frank kenney from gartner research is over this week. and we’re talking about all things relating to governance. not just of SOA, but of how governance will extend to cut across IT and business, with touch points to B2B, BPM, Cloud, Integration, Collaboration and even Application development.

but back to plumbing for a second. i always think of WebSphere MQ, our family of messaging transports, as plumbing. a conduit for business data, just as plumbing routes and delivers a constant flow of valuable resources on tap. for us, minor leaks have never been acceptable. business data today is just too valuable to loose. whether it’s a customer’s order which if lost will turn them to your competitors, or it’s an interaction with a partner which will eat your profits if mishandled, or sensitive personal information that will embarrass the company and hit your stock or even land you in the stocks. obviously a key leak can come from data theft, and we provide security mechanisms in the pipe (in transit) like Secure Sockets Layer, and also for where the pipes connect to systems (at the application layer) like our Extended Security Edition.  recent surveys suggest that these malicious thefts of information are far less frequent than alarmist reports suggest, and that actually most data losses are accidental and as such are probably not detected quickly if at all. this is the way of loosing business data that my gas supply issues most remind me of. data corruption. it can be harder to detect situations where the information wasn’t hacked or stolen, but simply got mangled en route so that it’s unusable or simply disappears. either way your data stinks, like the whiff of methane, or dissappears altogether without a trace like a gas. little factoid for you: domestic gas is naturally odorless. that familiar whiff of gas comes from smells added artificially by gas suppliers, based on chemicals like Methanethiol. given the volumes of gas consumed by homes across the world, could it be claimed that the most popular perfume fragrance in the world is the aroma of rotten cabbages?

so, back to connectivity software… can we learn lessons from the gas industry? can we add something that makes it clear when information is leaking? perhaps checksums performed before and after sending information fits the analogy. if the checksums don’t match, then the data smells funny as is discarded or re-transmitted. certainly for this reason products like WebSphere MQ File Transfer Edition provide checksums to help ensure file data wasn’t corrupted. meanwhile, we focus on making the transport layer for connectivity as robust as possible to prevent leaks in the first place using techniques like queuing and two-phase commit to make mis-transfers invisible, automatically resend information and make sure it’s always written to persistent storage in a way that can be recovered if the systems fail.

however, the critical part of the gas industry solution isn’t the smell in the supply, it’s the nose on the consumer. so how do we provide IT professionals with “noses” for their connectivity? it’s got to start with governance and visibility. governance over what happens and visibility into what’s happening, and specifically what data went where and when, and – because IT can change more frequently than copper or lead pipework – what the connectivity looked like when it happened.

this is the motivation behind the audit trail built into WebSphere MQ File Transfer Edition and behind applying governance and visibility to file infrastructure. (i”ll blog about what we’re doing here in detail soon).

so, can you detect a whiff of data leaks in your IT? if you can’t, perhaps you’ve accomplished something truly incredible in your IT. but in that case, it’s more likely your sense of smell needs checking. my advice? get a bigger nose. apply governance to your file transfers, your connectivity, your SOA.

meanwhile, it’s time for me to give my plumber a call from my desk in hursley.

vee seven oh two

it’s announced! our second significant update this year to our Managed File Transfer product, WebSphere MQ File Transfer Edition called V7.0.2.

cool image created using www.wordle.net

actually today (friday) i’m taking a day off to rejuvenate and i will be giving the computer a rest too. so i’ve taken advantage of this clever feature in blogger where you can schedule a new post for a future date. so if the above link to the announcement hasn’t quite gone live please try again later.

anyhoo – we’ve cram-packed the V7.0.2 update with lots of good stuff!

for example, we’ve introduced a new type of agent (called a Bridging Agent, although i confess i was also keen on Special Agent) that can “talk” protocols other than WebSphere MQ. in other words can send files over alternative transports to MQ. transports we’re supporting in this update are FTP and S-FTP. why on earth would anyone want to move files over anything but MQ? well – the objective here is to enable co-existance with existing environments such as home-grown solutions based on those protocols as well as support situations where the sender or receiver simply can’t run MQ. because the protocol is handled by a Bridging Agent it’s fully integrated into the graphical, command line and XML scripting interfaces. most importantly the Bridging Agents feeds all FTP and SFTP status into the single, centralized audit trail making it easy to track all the file movements regardless of transport. although FTP and SFTP aren’t as robust as MQ, we provide check-point re-start to improve the reliability across FTP & SFTP too.

if you read Gartner’s comments in their latest Magic Quadrant for Managed File Transfer (G00170848, 18 Sept 2009) you’ll have noticed that Frank makes mention that IBM needs to expand its product beyond the MQ protocol alone and alludes to IBM having something up its sleeve in this regard. well, this was it. FTP and SFTP support via these new Bridging Agents.

the protocol support provided by the Bridging Agents are client-side only and are designed to complement the extensive Server-side protocol support provided by IBM B2B gateway offerings like WebSphere Partner Gateway and DataPower XB60 B2B Appliance, in addition to partner onboarding and management.

speaking of IBM DataPower Appliances, in V7.0.2 we’re also supplying documented and tested configurations for integrating WebSphere MQ File Transfer Edition with DataPower Appliances. This enables file transfers to be sent across WebSphere MQ File Transfer Edition networks and on to trading partners via the DataPower XB60 B2B gateway across a range of protocols like AS2. this great article on developerWorks from my colleagues in Italy describes how to take advantage of DataPower as a file gateway in the DMZ and link it to WebSphere MQ File Transfer Edition to handle the internal traffic.

V7.0.2 also bolsters the security support with finer grain access control to agent resources at the user and group levels. this extends the “sandboxing” feature we have to limit agent’s access to the local file directories. we’ve also found the time to extend the platform coverage to include iSeries, HP-UX 11.11 on PA-RISC and more. also, to help our clients move to production faster we’re providing a scriptable interface for creating the file transfer artefacts and enable the configurations to be stored. this can help automate the transition from pilot to production.

we’re excited about this V7.0.2 update and i’m keen to know what you think. please let me know. and i’ll bring you more news, as ever, from my desk in hursley.

tinker, tailor

i tinker. i really do. whether it’s a powerpoint slide or an excel spreadsheet. i can’t help it. nudge the graphics this way a bit. align everything centrally. fiddle with the font style. deliberate over the colour scheme. the end result just feels right. in a world where much of what IT professionals do (and certainly Product managers) produces only intangible results, the need to tinker is driven by that sense of satisfaction one experiences from knowing that you’ve produced something you can be proud of. but in a fast-paced, throw-away world, where most things are out-of-date before they’re even finished, endless tinkering isn’t a virtue. that said, when you’re trying to communicate a message to an audience, polish that shows evidence of thoughtfulness (usually that little bit of polish produced by a measure of tinkering), that reflects how important the message is to the author, can make all the difference in how you audience responds. i see this when I create presentations for our sales teams and our clients. sometimes that little bit of polish makes all the difference. but, life, as ever, is about balance. walking that middle path between slap-dash, and tinkered into meaningless sheen. so it’s about knowing when to stop. i’ve been indulging in some tinkering today over lunch. the result is the new logo/title for this blog and mild indigestion. was it worth it? did i know when to stop? can I resist the urge to tinker with this page layout in the future? time will tell. meanwhile, if you’re a tinkerer too: welcome, and thanks for stopping by my desk in hursley.

perspective

yesterday my wife and i went hot air ballooning. it is great fun. if you have the opportunity to i would seriously recommend it. we had a lot of difficulty finding good weather because we’d been booking our adventure for over 2 years without success. so what my wife originally planned as a surprise for our 1st wedding anniversary finally got the lift off well into our 3rd year. the weather always turned out to be the wrong kind. too windy. not windy enough. wrong kind of wind. yesterday’s flight was very nearly cancelled to because most of the south became covered in a blanket of fog. fortunately the experienced team at go ballooning had good local knowledge and drove us to a launch site away from the fog. once you’re up there, hanging silently above the earth, looking down on the patchwork quilt of fields, the tiny model houses and moss of trees, it certainly puts things into perspective.

peering down from the clouds, the familiar world takes on a whole new shape. tying this back to my day job, makes me realise how much our clients would benefit from a bird’s eye view of their IT systems so that they can step back and take stock of what’s going on. in our busy lives and jobs that might seem an expensive step to take, but it may help put IT priorities into perspective. and that could be priceless. in particular i want to take a look at how we can do this for WebSphere MQ and our other SOA Connectivity products. to see how we can provide IT Architects with an abstracted high-level view of their connectivity solutions, see how everything’s interrelated, where the cross-dependencies are between applications, services and middleware artefacts like queues, channels, message flows etc. if you’re one of our clients and you’d be interested in exploring this with us, please drop me a line. together we can help get some more perspective on connectivity. and while it’s breathtaking to be up at four and a half thousand feet, it’s nice to be back on terra firma, safe and sound, at my desk in hursley.

already a leader

it’s very satisfying. we first entered the market for managed file transfer with WebSphere MQ File Transfer Edition only last december. since we didn’t announce our product until after gartner published the first ever magic quadrant for this space last year, we’ve been explaining to our prospects why we were absent from it ever since. now gartner’s updated the quadrant and we’re very nicely positioned. we’ve got a great vision for where we want to take our managed file transfer story and i’ll share what i can (and expand on it more when we make official announcements soon), as ever, from my desk in hursley.

fail over

new blog. a new start. my previous attempt at blogging – started just over a year ago – didn’t last long. i’ve never really been disciplined enough to keep on creating entries despite the link in my web brower to the blog staring at me every day. my prior efforts were disrupted by a bout of illness (an acute dizziness caused by labyrinthitus) but really that excuse can only account for a couple of months – not an entire year. so why does this blog begin with such an apologetic tone? because i know that i’ve missed that chance to share a lot of the exciting and interesting things that have happened since. i’ve spent more time than ever with customers – my favourite part of my job – learning much about their challenges, concerns and fears and deepening my respect for how they do what they do, and my appreciation for the ways that we can help them succeed. we’ve also shipped brand new products. nothing in work is more satisfying than taking the idea from a new product from its inception right the way through to delivery and the first clients moving into production. yesterday brought yet another noteworthy example: announcing a significant update to WebSphere MQ, numbered as V7.0.1. the feedback so far has been so positive – i’m really looking forward to getting more from our clients as they get hands-on when we release the code. one of the many highlights is more choice on how MQ fails over when problems occur. no only can that help when bad things happen, but makes it easier to handle those planned outages. take a look and let me know what you think. i’m waiting at my desk in hursley.

flush the flash

is that a security exposure in your pocket…? organizations are starting to turn their attention to the widespread use of usb flash memory sticks. during a recent tour meeting customers across the US in november, i discovered that usb memory sticks were starting to be banned by several companies, mostly in financial organizations. the main concern is the ease with which sensitive data could be loaded onto these sticks and from there end up in all kinds of places, with little control over who might see it and no idea what the exposure could be. it’s bad enough if you’re able to detect a security exposure, but worse still if the first you hear about it is on the evening newscast. a story today from the bbc.com site shows that government organizations are banning the memory sticks now. whilst viruses that lurk on memory sticks are clearly one part of the problem, the issue of where the data could end up is also part of the headache. completely banning memory sticks may work for organizations where going through metal detectors is a daily activity, but that’s not (yet) the case in the majority of companies, and doesn’t solve the issue for home-workers. will notebook machines appear on the market without USB ports for cautious organizations? perhaps. will spot checks be conducted for memory sticks? unlikely. if organizations made it easier to share and use files than having to wrestle with memory keys and hunt for the usb port? probably. can Managed File Transfer offer an easier way than usb sticks to securely share and use large files in the future? definitely.