Resuming the Blog

Hi,
Apologies for the delay in updating the blog. I’ve got a lot to talk about, but unfortunately on August 16 the hard drive on my laptop crashed. By sheer coincidence an hour earlier I’d copied all the files I was working on for my new book onto the family computer downstairs so I could print them out. So I had that. Otherwise I would have gone nutty for sure.
It looks like a controller failure, and there’s a chance if I order a new drive and swap controllers, I might get my data back. Otherwise, no chance. So I’m waiting to see if my local computer shop can locate one of those old (!) IBM 30 Gig drives…
Greg and I finally submitted the book on August 23, after incorporating the somewhat substantial review comments we received. For me, it’s really great when someone takes the time to carefully review and comment on a manuscript, even when the comments are negative. In fact, I’d rather have negative comments than the sort of fluffy stuff you get sometimes when a reviewer doesn’t really read a chapter.
Addison-Wesley has put the title on Amazon.com with a December ship date, so it finally looks like the end is in sight.
The worst parts are that my shoulders ache from all the typing, and that I have to somehow manage to keep the whole book in my head so that I can be sure it hangs together. The day before I was finished I could tell I was almost done, and it was like a fog lifting.
Eric

It’s the mobile device, not the server

Richard Vedyard posted an interesting collection of blogs on the subject of fat vs thin clients.
A key quote struck my eye from Phil Wainewright’s post:
“…what matters most is being able to tap into network resources…”
This is exactly the wrong way to look at things. We’ve been thinking about mobile devices as clients tied to servers, and this is backwards from reality. Mobile devices are computers in their own right, with their own resources. What matters most is the resources on the mobile device and being able to use them to best advantage. I’m sorry, but the thin client paradigm falls down on this every time.

ZapThink Forum – SOA factory analogy

It’s been a week now since I was on the panel at the ZapThink Forum in New York. (I am still working on the book, although we did get the manuscript into the reviewer process.)
I stayed overnight at the New Yorker Hotel, where the conference was held. It’s a weird old place between rennovations. But with character. It was across the street diagonally from Madison Square Garden and Penn Station, so this was doubly wierd for someone flying in from Boston during the DNC, ending up where the RNC would be in a month’s time.
The panel discussion was on ROI for SOA. We had a good mix of software vendors and end users on the panel. The first question was how to think about the ROI.
I like to compare the investment in SOA to a factory. A manufacturing company needs to set up an infrastructure for mass production, including an assembly line, physical plant, architecture, design, and so on.
The software business is pretty much a craft business today, relying on the skills of individuals to create programs and map business requirements to technology. Assembling applications is not really a scientific exercise with predictable results, as all of us know who’ve been through the seemingly endless build and test cycles to ship a product, or upgrade a production application.
While an SOA may not be the ultimate answer, it does provide an infrastructure and approach to developing applications that pays off over time. The first service may be relatively expensive to build, but the hundredth will be relatively much cheaper, and so on. And once a library of resuable services is available for common functions such as customer lookup, credit card authorization, and shipping an order, new applications can be assembled much more quickly and easily.