In the very early days of humanity, primitive cave dwellers were forced to use software installed directly on their office computers. They would have to run from cave to cave (often in bad weather, possibly dodging wild animals like the giant sloth) in order to install “updates” whenever the software was improved, to make sure each cave was doing consistent, compatible work. Sometime after the invention of the wheel and the Enlightenment, a few cave men came up with the Internet. I’m glossing over lots of important things. Eventually, people realized that the Internet would be a great way to deliver software-like services without having to maintain individual caves.

Today, many of us use a number of web-based applications. Here’s a list of what I’ve used so far today:

• Backpack - a lightweight personal information manager (PIM)
• Google Reader - alerting, monitoring
• Gmail - email
• Heroku - an integrated development environment (IDE) [ed: technically, working with this after midnight counts as “today”]
• Flickr - photo sharing
• Oracle - finance-y stuff
• A Number of “News Services” - blogs, most of which were application-calibre
• My GXS Blog - publishing and feedback
• Trading Grid Online - of course

However, we still use desktop software. Some of our software handles large local files and work wells on the desktop–think Photoshop. Serious 3D games are very performance and latency-sensitive and also handle local texture files and model files. One of the newest questions being tackled by development groups like Microsoft, Adobe and Mozilla goes something like this:

“Is there a middle ground between a pure web application and a pure desktop application? A web application delivered on the desktop, with desktop integration. How would this be accomplished? What would the benefits be?”

This is a really interesting line of thought.  Imagine signing on to your work computer one morning and finding a desktop icon called Trading Grid Online.  When launched, you would be using the Trading Grid web portal, but as if it were a locally-installed program.  It would show up in the taskbar.  You could alt-tab around with your other programs.  You could drop files in to the web-based transaction manager directly from your file browser.  In fact, the program would minimize to your system tray and show a desktop pop-over window each time a transaction alert triggered on the Trading Grid.   Now, imagine that a new version of the portal was released.  Because your desktop version simply packages the on-demand web service, no local upgrade would be required.  The benefit of both worlds?  Sounds good to me.

There are a number of competing approaches and technologies starting to explore this space:

• Adobe AIR - I have not researched AIR extensively on the developer end, but have used an AIR-based application call.  The AIR approach is to use technologies like HTML w/ Javascript or Flash/Flex (Adobe technologies) to build desktop applications with access to local files and remote data.
• Microsoft Silverlight - This project, while often lumped in this list, appears to be about creating rich internet applications (RIAs) based on the Microsoft .NET platform.  That makes it a competitor to some of the Adobe technologies used by AIR.  I have yet to understand how Silverlight intends to push the melding of the desktop and the full on-demand web application.
• Mozilla Prism - This system is based on the idea of providing a dedicated “Firefox” desktop window for a web application, removing things like the location bar, bookmarks, etc. to create the single desktop app feeling.  I believe web developers could use custom tags in their pages to invoke things like desktop alerts through the Prism framework.  I’ve played with this a bit and its clearly very early stage.  Mozilla’s approach seems to be based on enhancing integration via packaging and extending an existing web app, but not custom-writing one.
• Google Gears - I want to try Gears in my evening time to see how it works, but the idea is not so much to provide a brand new type of application as it is to provide a code library for web applications that are on the web (in the normal sense) to support an “offline” mode by storing data on the user’s desktop and referencing from the web.  This is one kind of integration with the desktop, but doesn’t cast as wide a net as AIR or Prism.

Exciting times for the Internet.  There is some convergence brewing even if none of these particular technologies become the next wave.  Google Docs as an “office suite” is growing in popularity, but mostly for niche web-sharing uses.  Microsoft Office, OpenOffice and Apple iWork all still excel in usability when dealing with local documents; any given user will have tons of these lying around the cave.  One of the major, unsettled questions that you can see lurking in the list is still the question of how the web and desktop will come together.

No, that’s not a typo. I recently received an invitation to Heroku, a Ruby on Rails platform that seems to me to really highlight what’s possible in the new age of the web. Heroku is both an on-demand, web-based development environment for building web-based apps in Ruby on Rails and a scalable deployment and hosting service using Amazon’s platform services. This means that apps built on Heroku have on-demand access to virtual servers and bandwidth to simply scale with performance. Amazon’s Elastic Compute Cloud (EC2) and Simple Storage Service (S3) provide both “machines” and database.

In short: I can open an account on Heroku and immediately start building an app through my browser. I don’t need to deploy servers, setup a web server such as Mongrel, setup a database like Postgres or be concerned with scalability beyond writing quality code. All of that magically happens with about as much trouble as it takes to open a Gmail account. Really. I did it. That’s about how hard it was.

I think this is a great example of what on-demand services are all about, especially at the smaller scale of the user spectrum. With Heroku, the only thing I need to worry about is building the app itself. I get flexible cost-efficiency and I’ve basically out-sourced the mucky platform concerns to an expert, freeing myself up to focus entirely on my service quality. Like Trading Grid Online’s web-based mailbox tools or Intelligent Web Forms, I can register by invitation for a hosted service that connects me to partners without any need to worry about software installation, distribution and other issues such as protocol mediation which require time and money to manage and which provide on-going cost and challenges to my service quality, but don’t stand to differentiate me significantly if managed well. Although it’s too early for me to tell, I would bet that the value of this approach will really be felt as new versions of Ruby, Rails or changes to the Amazon platform services are rolled out–like working with GXS, infrastructure improvements, modernization and adapting to my partners’ change should be handled by experts with economies of scale and extensive specialized experience.

Heroku also happens to be a YCombinator company. If Heroku is any indication, YCombinator’s unique approach to venture capital seed funding appears geared to producing some new and valuable services.

Blame Bryan Larkin for this one.

***

GXS Managed Services as a Sonnet

Translate and map your business processes.

Ramping up your partners around the earth.

Connecting to your back-end ERP.

How much is your IT sanity worth?

Your supply chain should be outsourced to us

To root errors and data problems out,

Connect you to TPs, no muss, no fuss,

Earn bragging rights and ROI, no doubt.

Now focus on what makes you best out there.

Let us get your initiatives unfurled,

Partner integration out of your hair

And grow your business all around the world.

You and your customers deserve no less.

Let our experience bring you success.

***

I couldn’t quite twist “Center of Excellence” into iambic pentameter–in fact, I’m not entirely convinced I twisted some of the other terms well enough.  Do me a favor and pretend the verbal emphasis is on the first syllable in “supply?”  This exercise, fun though it was, reminded me of why I stick to free form.

Recently, a few colleagues, friends and pseudo-random internet acquaintances have asked for usability/web-related blog recommendations.  Today’s post is a link list of blogs that I’ve found to be either useful, informative or interesting enough to foment some of my own ideas.  My goal is not to deflect anyone for continuing to ask me for recommendations (honestly).  I’d be interested to know if any feed readers already check out these blogs or have their own recommendations to share.

So here are the three I’ve been most interested in of late, with notes and the addition of one rogue blog that is no longer but still worth back-tracking through for some wisdom about creative disruption:

•  Occam’s Razor - Avinash Kaushik is well versed in web analytics and his blog is a good resource for content providers looking to broadly assess their UI’s success from a statistical viewpoint.  His “Web Analytics Demystified” thread is a great intro, but his general tips on getting the most out of loggable, aggregate user information to improve service quality is worth a read.
• UIE Brain Sparks - With a name like “User Interface Engineering,” how could you go wrong?  Brain Sparks blogs about UI design theory and practice, does practical reviews of good web UI and also serves as a good way to stay alerted about UIE events.
• Simple Bits - Although not updated frequently, this small design shop covers browser developments and type-face (sort of a UI designer’s secret vice) content and commentary.  I’ve found that small design shops with a strong aesthetic are great sources of very pragmatic information–in particular, the cost at a small shop of maintaining cross-browser compatibility can lead to some tips/tricks that bigger shops can learn from.  Plus, these guys developed Foamee, which allows you to owe someone a beer through Twitter.  Sweet.
• Creating Passionate Users - Great blog.  Sadly, it’s not maintained now because the author was harassed by other bloggers.  Focusing on non-traditional advice for software and service designers, this blog also provides a great example of how images can be used in a blog to convey information very effectively and break up the doldrums of seas of blocked text.  I promise to work on that…

The best learning is hands-on, of course, so I highly advise trying new web apps that pop up with a fan base and doing your own pro and con assessment.  Of course, UI-opinionated blogs are a great way to discover these apps.  I continue to be a fan of Flickr, a photo-sharing site purchased by Yahoo! some time ago.  Recently, I used their integrated online photo editor to touch up a camera phone pic and the experience was quite smooth.  Overall, it was more efficient than using iPhoto.

I continue to mourn the loss of Newshutch, my favorite feed reader.  I’m getting more used to Google Reader, though, and there’s still no sane alternative to feed reading for keeping up with all these blogs

I hope you all had a great holiday season.  It is really, really cold at headquarters today.  Time for another cup of tea.

Time to drag out the old usability soap box. It’s starting to bend in the middle, and so I might need to buy another year’s supply of bulk soap to get a replacement.

I spent some time messing around, as a nerd/technologist and child of the Internet revolution, exploring the virtual world of Second Life last year. I will spare you a re-creation of my assessment. Suffice to say, it’s a great concept and has some interesting value for proof of concept or collaboration work but is hampered by poor usability in the client GUI as well as poor performance usability on machines with less power than something like a Cray or perhaps the Amazon or Google computing clouds. Well, not that bad, but I could definitely hear my Mac Mini struggling to vent heat while my avatar was “walking around” the Adidas virtual island.

An interesting article came across the Reuters Second Life bureau RSS feed this morning reporting on claimed versus perceived performance improvements in Second Life. Linden Labs, the company behind Second Life, made the claim that performance had improved using the metrics of server-side frames-per-second (FPS), a measurement of how fluid the 3D images are being presented to users, and the occurrence of crashes. A user poll, however, indicated that users were perceiving a simultaneous steady decrease in performance. The issue, client-side FPS was creeping downwards despite gains in the server-side measurements.

The lesson here is one that I’ve often repeated within GXS. The only way to measure usability *really* is to measure it from the user’s perspective. We have a re-design to one of our Trading Grid Messaging Service dashboards, for example, which moves one data element to an asynchronous lookup so that the dashboard can draw very quickly and the user can review 9 out of 10 metrics while the 10th is populating. Performance usability improvements often focus on optimizing data display so that (for the sake of the argument) a 10 second page render moves to 8 or 9 seconds, on average, when you can make significant usability improvements by moving to a 3 or 4 second average page render and defer a single data element to asynchronous. The user needs time to review the other data elements anyway, so the overall impact is positive. In Linden Lab’s case, the server can push out content faster and faster and faster, but if client performance doesn’t change then nothing has improved in a meaningful way for the end user.

On the upshot, it’s clear that Linden Labs is doing the right thing by being sensitive to this issue and responding to it, rather than continuing to tout their purely provider-side enhancements.  I was going to dovetail into applying this principle into airline customer satisfaction during the holiday season, but you probably don’t want to read this entry for another few hours. Suffice to say, the carrier with the least over-booked and canceled flights shouldn’t have reason to brag. Whether you travel or stay home this season, make sure you have a good time

My family had a lovely Thanksgiving dinner with a husband and wife–choir director and friend of my wife, respectively–this past week.  The wife is a professional chef and produced a feast three times the size of what would still be overkill for the eight adults and three small children in attendance.  This included two enormous fried turkeys, about 9,000 metric tons of stuffing and some interesting experimental dishes like battered, fried cranberry glaze.  Honestly.

However,  one of the husbands in attendance left several hours earlier than everyone else.  Far from minding his caloric intake, he was heading out to line up for a huge discount sale on an HDTV at a retail store the following morning.  Plates were prepared for him and he also took a van to park on site with bottled water for all the other campers.  Sure, he might be slightly crazy, but at least he was well prepared and not as crazy as the other people who arrived even earlier.

I’m not a big shopper.  I never have been.  I tend to stay home around Black Friday to avoid the usual (probably hyped) tales of people fighting over spots in line, tension in parking lots and the other types of things that happen when excited people assemble in large masses.  I’m definitely an online shopper, with a few notable exceptions such as clothing and groceries.  The past few year’s end media sweeps have frequently discussed the competition between online shopping and physical store shopping for holiday market share.  If you look at my ilk, you might see that clearly the Internet has a big impact on physical store shopping.  But, if you look at my friend and his van full of bottled water, there are clearly reasons to hit the stores.  The shopping experience.

In this case, there are few key factors in the shopping experience:

• A deep discount on a popular piece of electronics.  This kind of promotion relies on a good supply chain, among other things, to get the word out about the discount and to have appropriate inventory levels to stores based on a specific publicized date.
• The collective “geek” or “Otaku” factor (to slightly mis-use a Japanese term) of camping out, as if one were after hot-selling concert tickets.  This is driven by digital communications: message boards, bargain hunter websites, word-of-keyboard through social networking.

So, rather than being a competitor in this case, the Internet became the engine that drove him (metaphorically) to stand in line for the sale.  Although there’s not much research in this area, I also wonder how often someone goes in to a store to check out a product in person and then goes home to buy it from the company’s website.  That’s probably far less common, due to adding shipping costs and the fact that web-only promotions are not widespread and deep enough to get over the “have it in my hands today” factor.  Perhaps there’s more we can do to use physical shops to drive online sales and online activity to drive store visits.  The relationship between brick and mortar and bits and bytes shops is still in its infancy.

Happy holidays, and let’s hope for big retail numbers and no supply chain headaches, online or offline, this season!

I’ve been using RSS for a very long time. When I found out that there was a convenient way to read the multitudes of websites I wanted to track in one place–and only be bothered when something was new–I was excited. Having used RSS for a long time on Windows, Mac and Linux, I’ve gone through a significant number of RSS readers trying to find one that suited my opinionated stance on usability and simplicity.

So, for a very long time, I’ve used nothing but Newshutch. I started with desktop readers but quickly gave up on those because I switch computers frequently. It had to be web-based. I tried a few web-based readers and found them to be clunky, obnoxious and unwieldy. But Newshutch won my heart quickly. It was usable, simple and made smart use of Ajax. When I used it, I wasn’t thinking “I’m using Newshutch,” I was thinking “I’m reading news.” Catching up on my feeds a few days ago, I came across a Newshutch blog entry titled “Newshutch Service will end on November 10th, 2007.” Shock. Horror. My favorite reader is going away and I’ll be condemned to use one I already know that I don’t like.

I read the farewell blog entry and I have to say that it won me over. The title starts out with “We’re pulling the plug on Newshutch.” The first two section headings are “We lost the hunger” and “No regrets.” The Newshutch team goes on to explain that some trouble with moving to a new hosting service (which didn’t affect me at all) forced the team to admit that they had lost the passion for Newshutch. It started as a creative disruption service to prove that RSS readers could be better. They did have some success in that area. At least one VC group came after them with an offer despite having no understanding of the business model. But to compete with all the other feed readers like Bloglines that I tried and abandoned, they would have to work on Newshutch constantly. Working constantly on something they were no longer passionate about would produce sub-standard results for Newshutch users and there would be no winner at all.

I think that’s an admirable stance. Why would I want to continue using Newshutch, knowing that quality and innovation would decline over time? I don’t pay for the service, so Newshutch doesn’t need to keep collecting revenue from me while basically only making critical corrections. They’ve re-designed the app to make the feed list export feature prominent and clearly stated that it will go away and that they will start to work on other projects now where they can make more of an impact and feel more passionate along the way.

Kudos. They even included a footnote to the blog entry recommending the least offensive (based on Newshutch philosophy) of the other feed readers that are available. I’ve ended up dropping back to Google Reader. It’s not bad, but it makes me miss Newshutch. I accomplish both things with the same tool, but using Google Reader always takes a bit longer, is harder to read and requires more hunting around for buttons and generally feeling a little dis-orientation. I’ve blogged about Backpack before, so I loved the comment that “If I was Google I’d drive a cargo container of cash to 37signals’ or Dan Cederholm’s offices and say ‘Congrats, you’re the new EVP of UI at Google.’” Compared to Gmail, which I love, Google Reader just feels less pleasant.

So, to bring this all back home… it’s a good thing to stop and reflect. As a Product Manager, I may have some frustrating days, but I still look back at the week and feel passion about the Trading Grid. Especially the portal and other related projects that I’m hooked into. Innovation and thought leadership are exciting, but if I didn’t feel some hunger about my little product, I wouldn’t be here blogging. I hope you feel equally hungry about the success of your B2B program and I hope you think of GXS as a big, satisfying bowl of soup to feed that hunger as the weather here in the US starts to cool down.

And if you’re reading this in Newshutch, I’m sorry for your loss. I’m working on a project which produces some RSS feeds. When I draft some help content and I can’t unofficially recommend Newshutch to anyone who doesn’t have a reader yet, I will continue to feel your pain.

You haven’t heard from me in a while.  Lots of top secret projects.  Secret at least, but hopefully you think they’re top notch.  I’ve been checking out the recently set up GXS Insights portal.  Lots of good stuff there, and I like the fact that we’re making more of our content available outside the site via video services like YouTube and Google (’s Other) Video.  I also particularly liked our SVP and CTO Rowland Archer’s write-up called “A World Without Version Numbers.”  One of my top secret projects, [—redacted—] involves re-visiting how we internally and externally notate releases on our Trading Grid platform, the value of which Rowland explains well.

I’m a big fan of hosted services even in my personal life, where I make extensive use of tools like Backpack for lightweight PIM and Newshutch for RSS.  I have no clue what version number I’m using.  Aside from any internal development environments at the service-provider’s level, the only version relevant to me is the production version.  If you call GXS for support on your Trading Grid service and they ask what version number you’re using, tell them “I’m using version Tuesday, October 23, 2007, GMT-5.”  Except, make sure you update for your actual date of call.  They wouldn’t ask you, of course, so I’m just being difficult.

If you’ve taken the dive into RSS because you woke up one morning and couldn’t face the prospect of reading 40 different web sites before work, make sure you subscribe to the Insights RSS feed.  You’ve already subscribed to all of our blogs, of course, so you wouldn’t want to miss any GXS thoughts.  If you aren’t using RSS yet, you should give it a try.  It might come in handy with one of these top secret [————–redacted————-].

While I’m generally not fond of websites that function like a PowerPoint presentation, I am fond of the Knight News Challenge. I heard about it on the radio and thought I’d check it out. It’s a cash prize for ideas on using technology to further community interaction in specific geographic locations. The foundation behind this thinks that the Internet has created wonderful virtual communities, but it is under-utilized in strengthening existing physical communities.

So, I started thinking about what I would do. The first thought that popped in my head was: farmer’s markets. My wife gets a good chunk of our produce, meat and some other things at a local farmer’s market. We supplement that with cereal, pasta, diapers for the kids and other such consumables from the grocery store. Therefore, I have a decent view of the upsides and downsides to both services.

On the one hand, the grocery store (very much like fast food, in some ways) offers consistent availability of products, layout, easy navigation and also facilitates bulk shopping while being highly available. The farmer’s market excels at providing freshness, local connection, products whose organic or wholesome nature are easier to verify and understand, high quality seasonals and adding a little spontaneity to stocking up. I think the two complement each other well, as far as our routine goes.

A good farmer’s market, though, is more of a community event than a chain grocery store. That’s not a knock on the grocery store. McDonald’s doesn’t try to be a community social forum in the way that a local sandwich shop might book bands and other events. It’s a different model. But what I’m wondering is whether the farmer’s market can use technology to attract more people who have become somewhat reliant on the conveniences and predictability of the grocery store.

The infantile form of my plan involves developing a web service for facilitating pre-event interaction between farmer’s market organizers, vendors and shoppers. For example, if a vendor can indicate a day or two in advance what they intend to bring for sale at the market, consumers may be able to better plan their menus, shopping and other things. Provide a little bit, but not too much, predictability. They can also provide descriptions or information about their products which are too logistically complicated to display at the market. It might also be possible for vendors to lock in some revenue and for shoppers to lock in some reliability in advance by reserving up to a certain quantity of goods for pickup at the event.

For large events, a “floor plan” type display would also allow people to see what’s available, where it can be found in the market and also view things like hours, special parking (if applicable) and other things which are generally only learned by showing up the market a few times and figuring it out. The key would be to increase the convenience of the farmer’s market in a way that boosts attendance and creates more of an ongoing atmosphere beyond a single event. To get more of the community involved, but not to fundamentally change the market. Lower the barriers to entry and encourage the farmer’s market to be less of a vicarious thing–which works for some people, but probably keeps some people away. Securing advance sales and advertising products a little more would hopefully be enough incentive to get vendor participation and buy-in.

That’s not as fancy as the Google moon landing prize. But, there are clearly fewer barriers to entry. Now I start wrestling with myself over taking the time to enter. If you’re reading this and thinking it’s a secret GXS product initiative, it’s actually just a personal technology interest post. Since I should probably say something related to GXS, though, I’ll say that the Managed Services customer forum is going well. I always like a chance to suit-’n-tie up for a customer meeting and play “professional” briefly every quarter or so.

Every Tuesday night (almost), I get together with my friends Ajit and Dustin. We’re old college budies. I lived with Ajit for a while and Dustin, having introduced me to my wife, was the best man at my wedding. Ajit is an IT guru for a casino. Dustin is a developer for an IT software/services company. I used to work for that company as a Product Manager prior to GXS and pulled Dustin in. I’m gone, but he’s still there. So, most Tuesday nights, we get to talking about the old days and the new days.

One project I was involved with before I left was piloting agile software development practices with the developers. Since my formal education as a software engineer left me jaded and opinionated about the traditional waterfall module (or, spend a lot of money and time on something, hope it works, and spend a ton more if it doesn’t), I had some research and stake into proving out a new way of tackling projects. Also, the fact that I did development with Ruby on Rails lent me some completely undeserved street cred.

So, for the last few months, Dustin has been updating me on Scrum. He’s positive. Walls are going down within engineering. Literally and metaphorically. No one is dancing in the streets with trumpets blaring, but these are IT developers we’re talking about. Many of whom, after that statement, will likely leave nasty comments and never read this again. I’m hoping Dustin tells me at the every least that the following things have happened (these are not all of the potential benefits by a long shot):

• Management visibility and on-going engagement has increased on projects, such that micro-management and requirements transmission issues are reduced and the actual number of concrete decisions per day (the CDPD rate) increase. Yes, I made that term up.
• Projects are more likely to meet deadlines, or where they are not, management and developers have signed off on any particular delay as a desirous event based on requirements changes or design feedback.
• Developer awareness of projects that aren’t assigned to them increases along with the ability to adjust requirements for smarter integration, such that seams between services are smoothed.
• QA became better able to validate the accuracy and usefulness of a service, rather than being restricted mostly to cross-checking the detailed design specs against the tables in the database and doing other somewhat self-validating exercises. In other words, the same syntax validation with more semantic validation.

I can’t take credit for the company going to an agile methodology. After all, I piloted a hybrid Agile (with a capital A) program and the company settled on Scrum. I like Scrum. At a tech forum, one of the Amazon executives talked about the ups and downs and it pretty much matched up with what I was seeing in my own hybrid approach. However, I’d like to think I can take credit for breaking the ice. Going cold-turkey on a more traditional methodology makes developers suspicious, worried about their job security and afraid of not being allowed to sit down in meetings (yes, Dustin, living up to my promise to mention that). Those are generally groundless concerns, but they do have to be taken into consideration.

But this is a GXS blog. So let’s talk about GXS. Prior to my joining the company, GXS had been investigating and piloting agile practices. Part of my interview involved a discussion about my experiences with and thoughts on agile, so I could tell before taking the job that I would get to work on something that interested me even if I found EDI to be very dull. Now, those of you who work in B2B EC and SCM know that EDI is far from dull, but I came from another industry, came of age in the era of hypertext and had only heard the term slurred in a hushed voice on subway trains.

Agile methodologies have a consistent theme about doing things in context. Work in context. Develop requirements in context. Engage the customer in context. Abstraction, vagueness and high-level thinking are less likely to produce solutions that you don’t dislike using than solutions produced context. An example of an out-of-context process: heavy-handed change management processes. The goal is usually to reduce the disruption of requirements added during a development cycle. But in context–that is, the real world–change is not a bad thing and so it’s better to take change as a core principle of development and figure out how to make change less disruptive not by reducing it but by capitalizing on it.

So, I have to re-evaluate agile because agile itself must be placed in context. Consider this principle of agile development from the Agile Manifesto (http://agilemanifesto.org/):

Business people and developers must work
together daily throughout the project.

Well, that worked great at my old company where development for my product line was focused into one wing of one building. But GXS, thinking in context, is pretty global (http://www.gxs.com/gxs/worldwide.htm). You can’t have all the team members in the same room, in the same time zone, throughout the project. At any given point, some are wake, some are asleep, some wish they were asleep and some probably wish they were more awake. So, right there, is a big challenge. If we agree with that principle, how do we attain it without physical proximity from the stakeholders? That’s a context issue. If you’ve been reading my blog, you know that I have a habit of flying overseas for a while to spend a few weeks sitting on the development floor working hard on achieving a good CDPD rate and providing customer perspective during development.

For 2008, one of my goals is to propose a new release management strategy. Some GXS deployment practices still have the feel/smell/taste of distributed application roll-out. Being an outsider, maybe it’s more pronounced for me. A few colleagues of mine with more tenure might disagree. But, never the less, it’s something I’d like to investigate and tackle. GXS uses customer meetings to review and validate requirements during development as well as beta programs and other agile strategies today. Where else can we optimize?

Given that the Trading Grid is a hosted, on-demand SaaS platform, we owe it to ourselves and to our customers (hopefully including you) to capitalize wherever we can on increasing the speed and accuracy of our delivery. So I’m doing some research and some thinking on this release management question. I’m starting from core principles. What would be valuable to us and our customers, regardless of any other considerations:

• Faster turn-around on defect fixes.
• Faster time-to-market changes from customer feedback.
• More predictable time-to-availability of your defect fixes and changes from your feedback.
• Predictable recurrences of larger releases, such that you can plan business impact and manage more by exception.

When I say faster, above, I don’t necessarily mean that it takes less time to develop. I mean that rather than waiting for a big release in which to include a bunch of fixes, fixes would be pushed out closer to “as ready” than “in bundle X.” Obviously, we do this today, but we might not be doing the best that we can in context.

One interesting habit that we still have today in the Trading Grid is the idea of a release number. We assign outward-facing version numbers to Trading Grid solutions. As if you’d call in one day and say “I’m using Intelligent Web Forms version 5.23.” We don’t put version 6 in your shop and version 7 in Bob’s shop. It’s hosted, on-demand Saas. You’re all using the same version, all the time! Now, there’s value for the sales guys to know that a new release has come out and to differentiate the functionality from any previous release. But I’m not convinced that saying 5.23 is any more valuable than saying March, 2008. Certainly, it’s no easier to confuse March, 2008 with June, 2008 or with March, 2009.

Now you know why I gave up on being a presidential speech writer. This exercise does help me order my thoughts, raises new ones and gets my engines turning. I might do a blue paper on this, internally. That’s kind of like a white paper, but I’d print it on blue paper so people pay more attention to it. Sneaky, huh? If I do, I’ll try not to abuse bold as much. As always, feedback is welcomed and will be incorporated early in the process with minimized disruption.