Complexity kills
by Volker Weber
So interesting to compare the route Apple is taking with OS X apps (instant download/install/update) with IBM's Eclipse-based app focus. Everything about IBM software shouts 'weight' (Eclipse, WebSphere, DB2, MQ), everything about iOS/OSX10.7 yells 'agile'. #whosright?
Stuart is mixing server and client software. Let's look at the client:
Example: in theory, IBM could use an Eclipse update site to slipstream updates into Notes, Sametime, etc. In practice you have a mess of different Expeditor runtimes. Which means customers have to do full scale rollouts for maintenance releases.
On the client, simplicity wins. Big time.
Comments
Things like smart upgrade (and now update sites) do not make a difference here. All software is packaged. (Advantage: no differences in installation.)
The user is not allowed to install anything. Using update sites would cause "program code" in the user data because he does not have write access to the program folder. And those updates would be downloaded and installed on every machine he uses.
And that was the promise of the Workplace Rich Client technology architecture as I recall - that the server would auto-provision new features and updates automatically via policy:Auto-provisioning capabilities. Provisioning features allow for the creation of accounts based on policies defined for users.It's a shame that got lost in the shift to the Hannover client.
I'm not really interested in slipstreaming software updates.
It's nice in the consumer area (Apple), but in the business world, the I want more finite control over the client. A new release is tested, an ear is kept to the blogs to look for issues, piloted, then distributed in waves to the user community on a timetable that we can support as IT and respond to any issues that arise.
The 'lightweight' piece, I'm in agreement with. I don't mind a heavier, robust client, I just want it to start a bit quicker. Once it's up and running, the debate over fat vs thin is kinda a non-issue.
The dual core I use at work for development and my day to day stuff uses 36gb of an available 120gb. My hardware isn't being stressed (except when I load apps), and I can't buy a drive that's 1/3 this size anymore. Thin vs fat is an interesting argument, but it's pretty much just a theoretical discussion at this point that geeks enjoy debating.
@Mike Sorry I would utterly disagree.
The different between the ethos of focussed/lightweight/elegant vs. broad/heavyweight/complex is a significant one. Wherever you look right now, consumer IT is headed toward the former, and for good reason. User's find it more intuitive, its easier to support, makes individuals more productive and so on.
Only in enterprise/corporate IT are large, heavy, difficult to learn software apps accepted any more, and that has to change. If users can make sense of Facebook/Twitter/Dropbox/GMail/iPhoto/Facetime at home with no training, update them regularly with no significant outages, and use them 24x7 with no dedicated support department, why on earth would corporates want their heavyweight/static/unintuitive alternatives.
As Volker says, simplicity wins (or at least, it should).
@Stuart We'll agree to disagree:)
Using Facebook as an example, it's lightweight, but also light on functionality. Twitter and dropbox, even more so. That's OK, because it must be light for it to succeed. There's no reliable way to train Facebook users, and before random netziens invest time learning the advanced features, they'll simply move elsewhere and spend their 30 minutes a day there.
In corporations, we have the luxury of control over our userbase...to some extent!:) At the least, we can train them on tools we deem most suitable to perform the jobs we'd like them to perform. We may put a 'heavy' tool in front of them, but that's usually because we need the full functionality. Need may be a strong word, but we've taken the time to do a cost analysis and decide that a Notes client + 3 days training offers us more ROI than giving them a Gmail account and walking away.
There's a place for both, but to say that simple, low-functionality tools trump heavier, more feature rich tools is an unfair generalization. If the functionality is the same, then I agree I'll take the lightweight, quick, simple model most of the time, but that's rarely the case.
Oh, I should note that I just made up the 3 days of training as an example. I don't think anyone does 3 sessions of user training on Notes:)
We offer 2 hours at hire during orientation, and then we did a 1 hour refresher for 8.5 that was optional. I know someone will jump on me for that, so I wanted to clarify!
