Mike Schubert

I have spent a lot of time over the past year (really over the last 20 years) looking at the keys to success and failure that have been experienced by certain technologies and platforms. Many product organizations take a kitchen sink approach to delivering features in their product. This can lead to a "jack of all trades, master of none" perception in the marketplace. It can also confuse users as to exactly a product should do. On the flip side, you have groups that release products that seem to be incomplete.

Right now I am a fan of Apple and its approach over the past decade to personal electronics. They seem to have taken the approach of delivering a chunk of value, letting people adjust to it, and then have the customers say "it would be really nice if this thing did x."  iPhone OS 3 gave us the ability to cut / copy / paste. This function point has been ubiquitous in computing for the past 2 decades, and yet Apple decided not to include it in the original release. The same is true with multitasking - even the Palm platform in the mid 90's allowed a form of multi-tasking (such as it was) and yet Apple it's waiting to the 4th generation of it's OS to make it available.

When you first look at this, you may think "Gee, they just wanted to lock in a monetary stream of upgrades." But if you think further, they have really been delivering fully baked features at the time they really become needed. When the iPhone app store first opened, there weren't enough apps with functionality that would make you want to multitask. Who knew how quickly apps would catch on that people would want to copy / paste? Apple has done a great job of delivering features at a pace that allows the ecosystem to adjust, and the customers to understand how to use it.

Hopefully, on the next generation of our intranet platform, we can duplicate this success. For now, I'm calling it reductive feature design and I think that it can be viewed through the lens of technical and organizational readiness. If either of those two factors truly aren't ready to introduce the feature, it should be removed from the version stream and placed into the backlog. Now to pitch it to the rest of the folks and see if it flies...

I am joining a project at work that will revamp our intranet architecture and allow us to continue to bring innovative and cutting edge capabilities to our workforce. One of the issues that we've seen over the past few years had been that rich applications that have integrated with our portal have been too tightly integrated. In several cases, they have the capability to hog resources or even take a server offline due to a catastrophic fault. This is one of the areas that we want to prevent in the future and are working with our partners to articulate this desire.

This week, one of those partners was in town to talk through our needs and the analogy I came up with was that "Farmville should not take down Facebook". That is to say the Facebook is an application platform that provides base services (demographics, content, wall updates, etc) to applications that can then use them to do interesting* things. This is similar to a corporate intranet that knows who a user is, what permissions they have, and what their demographic information is and then exposes those to applications and portlets based on their permission. In my current environment, there are some of these constituent applications that use the same resource sets as the portal platform and thus, they could negatively impact the performance of the intranet. In V.Next this should not be the case.

*Pre-emptive snarky comment: I do not consider Farmville or any of those games to be "interesting things". In fact, I've never played a Facebook game. It's merely illustrative of the type of Platform as a Service (PaaS) model that we are striving for.

One of my missions in developing web applications for a Fortune 15 company is to emulate the dominant design of well known internet applications when designing new functionality for inside the company. I occasionally am beat up for not doing this. One recent example was an RSS reader portlet. The goal was to provide people with a customizable portlet on the McKNet homepage that would allow them to subscribe to various feeds within the company and see the 3-5 most recent updates for those feeds. When my management team saw the proposed product, they questioned why it didn't look and work like Google Reader. I tried not to laugh - you might imagine that it comes down to money. This was one function point out of 8 proposed in a quarterly maintenance release that was being worked on full time by a single programmer. I don't know for sure, but I'd say that Google Reader took someone more than a week to develop.

One of the things I've been involved with lately is establishing "maintenance" pages for each of our applications. These maintenance pages are just meant to say "sorry - we've got some planned maintenance going on, here are some links to other content that you may be looking for that is not currently impacted by our maintenance." Finding examples of dominant design for this are a little more difficult, since you have to find either a reputable site that is under maintenance or read a blog post about it. Today, I tried to go to My Cigna based on some mail I received yesterday and found they were under maintenance. Perfect! Here's a screenshot of what I saw:

This gives me a good idea, but also points out the pitfall. The idea? Let them know when the maintenance window is planned to end. In this case, it says "The site will return at approximately 12:00pm on Sunday, March 28th.". The down side is that you have to keep up with the page and make sure that it reflects an accurate date and time. You'll see I included the status bar from Windows to show that today is April 18th - 3 weeks after the above referenced date.  So now that I think about it, this isn't the greatest of examples. Guess I'll have to keep fishing for a dominant design of under maintenance pages. 

transparent screen
Originally uploaded by fromform

Part of my job involves evaluating and recommending IT solutions to business problems we face. I have a wide background in technology and do not fit the mold of a "Java guy" or "Microsoft guy". This can be exasperating for some as they try to figure out which direction I lean and offer me sales spiels to convince me toward their product.

Even more troubling to sales reps is determining how I view solutions from IBM, Microsoft, Sun and Cisco. My previous employer was a business partner / gold reseller for those vendors and you would think that I automatically drank the kool-aid. There are people that I work with that have obvious biases towards some vendors due to past affiliations and/or friendships. If it works out for them, great. But that's not how I roll and I do not appreciate people toeing a company line for a company they don't work for.

I will always prefer the solution that supports the most features my business partners require, with the lowest initial and recurring costs, that has the best chance at adoption and longevity within our environment. I don't fit any mold - I make the mold.

Last night, the Georgia Tech Yellow Jackets defeated the Vanderbilt Commodores 56-31. The game was not available on any broadcast networks, but it was touted as being available on ESPN360.com. I assumed this was some sort of pay per view thing and at 7:30 pm, I was ready to pay to watch the game. So I went to ESPN360.com and checked out all the available videos and in-progress games that were available. Sure enough, the Georgia Tech game was prominently featured.

I clicked on the game and was very surprised to see a message indicating that my Internet service provider did not carry ESPN360.com. What the heck is that all about? Apparently, The Disney Company, owner of the ESPN properties, has forayed into pay model for ESPN360.com similar to what is in place for cable networks. Your ISP has to pay a certain price per subscriber in order to view content on that site. I was immediately reminded of the feud going on between DirecTV and Comcast over the Versus channel. DirecTV's argument is that not many of their subscribers actually watch Versus (although I routinely did) and that they were essentially subsidizing the network by paying a fee on behalf of the majority of their subscribers who did not watch the channel.

I thought the whole point of the Internet was to provide unfettered access to all of the Internet's content. If a company on the endpoint wanted to charge a subscription to those who signed up, more power to them. But forcing an ISP to pay based on # of subscribers is simply unreasonable and in the long term unsustainable. Recently, this image began floating around the net - and it could be a sign of things to come:

I thought I was against the type of thing ESPN360.com is doing until I saw this article -> ACA To FCC: Restrict Models Like ESPN360. Now I don't know where I stand. On the one hand, I don't trust the cable companies because they've have been screwing me with the above model for years. Ultimately, I'd like a la carte programming so that I could pick what channels I want, get a price, and move on. However, I end up with all these lousy channels that I never watch, simply because I wanted to get Discovery Channel, etc. On the other hand, perhaps the government is to blame for this mess with their regulation of the cable television industry and the cable companies are standing up to say "No - please, not again."

At the moment, I agree with the ACA article for the reasons they cite. This is something we all need to pay attention to over the coming months and years as the Federal government continues to discuss their proposals for net-neutrality.