my recent reads..

Heroku - Ruby in the Sky with Diamonds

I've been using Heroku since I heard about it on the Ruby on Rails podcast. It offers a hosted Rails development environment (all web-based), with instant deployment ... essentially you are running your dev, test and production environments 'in the cloud'. Heroku themselves use Amazon S3 I think.

It's worth checking out, even if you are not specifically interested in rails. A great example of how to operate 'up in the clouds'.

A couple of key things I've learned/noted in working with heroku..

Disabling the heroku toolbar


You probably don't want the heroku toolbar appearing for public users of your application (and I found it had some issues with IE). Disabling the toolbar is done by creating a file config/heroku.yml:
toolbar_collaborators: true
toolbar_public: false
request_timeout: 10

(picked this tip up from the mailing list)

Running with Rails 2.1


Rails 2.0.2 is the default, and 2.1 support took a while to arrive. It's here now. Simply update your config/environment.rb file to specify..
RAILS_GEM_VERSION = '2.1'

Distributed Version Control


Version control using git is rolled into heroku. And if you want to develop locally, there's a heroku gem that simplifies setting up your local clone. Once git and the heroku gem are installed, a typical session goes like this:
heroku create myapp
heroku clone myapp
cd myapp
ruby script/server
[..work locally for a while..]
git add .
git commit -m "some changes made locally"
git push
[..work on the server for a while and commit..]
git pull


Postscript Aug-09: heroku have since split their services in two: herokugarden.com, which includes the online, web-based editor, and heroku.com which is intended for high-performance production deployment (with no online editing)
read more and comment..

What Customers Really Want


I was involved in a conference last week that left me painfully aware of the missing "voice of the customer".

However it did bring to mind a great book I recently read - What Customers Really Want by Scott McKain.

Not to be confused with the product management text What Customers Want: Using Outcome-Driven Innovation to Create Breakthrough Products and Services by Anthony Ulwick. Completely forgettable in my view, and arguably dangerous in the wrong hands ... particularly when it gets into the dangers of having customers actually involved in the process!

.. well perhaps one good thing about "What the Customer Wants" is that when picking it out at the library I discovered "What the Customer Really Wants" only a shelf away.

I still can't find "What the Customer Really ReallyWants".

Back to "What the Customer Really Wants": in the first few pages I was skeptical, expecting the book to be yet another meaningless management ra-ra piece. Luckily Scott managed to catch my attention before too long and it soon became clear that the book is a gem. Scott McKain talks from the perspective of real experience, and his no-bullshit, folksy plain talk is a welcome relief from the "gurus". Importantly though, it is not just about experience, but also the fact that McKain has distilled and can share valuable insights as a result of that experience. Most are in the "bleeding obvious - but why haven't I thought of that before?" category.

Even the book's organisation is refreshingly to the point. Six main chapters covering six key disconnects..
What Customers REALLY WantWhat Business Supplies
Compelling experienceCustomer service
Personal focusProduct focus
Reciprocal loyaltyEndless prospecting
DifferentiationSameness
CoordinationConfusion
InnovationStatus quo

"Continuous improvement is the enemy of innovation". That got my attention. It's an interesting point of view: Kaizen - constant change - has its role. But innovation is anything but about being constant - its about seeking the dramatic step change. The problem is that most of us cannot cope with being completely focused on incremental change AND at the same time the search for shattering innovation.

The customer is not always right .. but they are always the customer!






read more and comment..

Designing the Obvious, the Moment, Not Thinking and how bad design can make you physically ill


I had a violent adverse reaction to the design vomit that is soshiok.sg
  • massive visual overload

  • poorly aliased graphics used instead of heading text

  • shockingly low-res advertising images (at least DBS have had the initial ads used on launch replaced)

  • "social networking features" that pervert the term, like submit a recipe that is an email link!!

  • Deserves a Daily Sucker award and should probably be renamed to soseow.sg

I could go on, but it just makes me choke. Best medicine: jump to hungrygowhere, who got there first and have done a vastly better job on the web site.

The other essential part of my recovery was to go back and luxuriate in the clarity of thought epitomised by Robert Hoekman's two books on design:

These are two books I think every web designer and, yes, every developer should read. Or have on a bookshelf in easy reach.

Designing the Moment is the one I find myself returning to. It takes a case study/cookbook approach and nuts out many of the issues in contemporary UI design. It's not an encyclopedia or complete reference - you will need to go elsewhere for that. But it does get you in the groove (in a "teach a man to fish.." kind of way). Even if my immediate design challenge is not directly addressed, it is great for getting in the right frame of mind for cutting through all the confusion and honing in on my core issues and purpose. It also contains the single best argument for using "sign in" rather than "login", and some great discussion of form alignment considerations.

Designing the Obvious is the first book, and contains the full discussion of Hoekman's philosophy of the obvious. You could probably get a web design job on the basis of studying this book alone! My only slight qualm is that while it presented a methodology and process for requirements analysis for example, it doesn't really give you a glimpse of other established practices and advice on how to harmonize in a larger and more diverse team situation.

This may sound like sacrilege, but I find these books even better than Steve Krug's Don't Make Me Think. Krug's book is great in its own right, but I feel that Hoekman has taken the art one step further. I'm sure he would agree with Isaac Newton:
If I have seen further it is by standing on the shoulders of giants..

But there's no doubt Don't Make Me Think has some great advice. Some of my favourites:
  • Don't use a mission statement as a Welcome blurb (aargh!!)

  • Usability testing on a budget. Spend one morning a month with a few testers. Debrief immediately over lunch. Act.

  • Mad magazine parody of the NYT tagline:
    All the News That Fits, We Print..






read more and comment..

OpenID - the missing spice in Enterprise 2.0?

I have been playing around with OpenID recently and considering its significance. OpenID offers a "single digital identity .. you can login to all your favourite websites", and its adoption is rapidly accelerating especially since services like Yahoo and Blogger have added OpenID support to the many millions of existing user accounts.

Maybe I'm missing something here, but I am surprised by the lack of attention OpenID is getting in the enterprise context.

And when it is considered, it is often as an either/or proposition. As Nishant Kaushik writes in his excellent identity blog:

.. simple web applications with minimal needs could get away with simply supporting OpenID. But that should not be confused with not requiring a full-fledged identity services infrastructure where appropriate.
I think this is somewhat misdirected; certainly not the whole story. OpenID-enabling existing applications for an external audience is already a trivial exercise. It's a simple API, and plugins or toolkits are available for most programming environments. I think the much bigger deal is looking at OpenID from the opposite perspective - using enterprise security infrastructure to support OpenID authentication.

In my view, OpenID is key to unlocking the true potential of "Enterprise 2.0", which is what I wanted to discuss here to try and explain my thoughts and get some feedback.

It may also lead us to think more clearly about what Enterprise 2.0 really is. This is the current definition up on wikipedia:
Enterprise social software, also known as Enterprise 2.0, is a term describing social software used in "enterprise" (business) contexts..
The "social" nature of Web 2.0 tends to get the headlines, and hence by simple transference must be to basis of Enterprise 2.0. Right?

However, I'm not convinced.

Expecting Enterprise 2.0 success by simply adopting social networking features of Web 2.0 just seems a little naive. For a start, it implies and requires phenomenal change in the social and organisational fabric of a company to get off the ground, and there is no guarantee the benefits will be worth the pain of change. In many organisations it may just be too much, too soon, and fail completely.

Much as I love them, I don't even think "mashups" will be the killer app for Enterprise 2.0.

I think the key is a much more mundane aspect of Web 2.0 that gets lost in the facebook frenzy: the simple fact that users are being exposed to just so darn many useful tools in the ever increasing range of web applications (or Rich Internet Applications aka RIA).

We see unprecedented utility in the applications on offer, approaching what we expect from desktop or dedicated applications. And there is an incredibly low barrier to participation - you can sign-up within a minute and with usually no immediate associated cost.

So my main proposition is that the quick win for Enterprise 2.0 is for companies exploit the RIA boom. Spend your time figuring out how to exploit the burgeoning Web Application offerings. Do NOT waste your time scheming how to clamp down on usage, or on replicating the tools yourself.

The real and immediate benefits include reduced IT spend, better utility and happier users .. and set the stage for moving to the world of "Advanced Enterprise 2.0" with mashups and social networking for example.

The caveat of course is that the enterprise must ensure that matters of availability, data protection, confidentiality and privacy are not compromised in making such a move.

But this presents a dilemma for the enterprise. A tough choice between undesirable outcomes:
  1. ban and fore-go the benefits of adopting external Web Applications for enterprise use;

  2. allow their use, but lose control of the data, identities and secondary use derived from using such applications;

  3. or be faced with re-implementing all those cool features within the firewall (and risk becoming disconnected from the external audience).


This leads us to the present state-of-the-art in Enterprise 2.0, which must necessarily work around the constraints of the corporate boundary.

  • Some companies are adopting External Web Applications where they address a largely external audience (a good example is the official Oracle Wiki which runs on wetpaint). But here they remain disconnected from internal systems.

  • For internal adoption of Web 2.0 technology, IT departments are often re-implementing all the cool stuff inside the firewall.

    The CEO wants a blog? Customer support want to setup a wiki? Sure, we can install it. Where install means friggin' around for a few months to select and acquire the software, integrate it with the standard enterprise security/monitoring/hosting/blah environment, customise it to the corporate branding etc etc.
Toto, I've a feeling we're not in Kansas any more.. suddenly Enterprise 2.0 doesn't seem so exciting.

And I think it denies the dirty little secret that I bet exists in most organisation: your employees are already using these services for business purposes!

Using a personal credential for business purposes on an external service (whether OpenID or not) presents a whole range of challenges:

  • It is a provisioning nightmare. What happens when the employee leaves? The company doesn't control the account, so it can't be disabled. Whether you can remove access from any corporate data held in the external service depends totally on the application itself and how it was setup.

  • For the individual, there is a concern about keeping their professional and private lives appropriately separated. Too easy for your tweets to end up in the wrong hands in the wrong context.

So what's a girl to do? I'd suggest the answer is pretty obvious - we need corporate identities that can extend beyond the boundaries of the the organisation in a safe and controlled manner. This was the intention with SAML, but adoption has been slow - I suspect hindered by the complexity of its WS-Deathstar burden - and now OpenID is streets ahead in terms of acceptance (an interesting parallel to the adoption of SOAP v. REST for SOA Web Services).

In other words, the key to all of this IDENTITY.

Imagine for a moment the ideal world. I would have a corporate identity that works transparently within the enterprise and also for useful external services. And I could keep this quite separate from my personal identity (even though I may use some of the same external services on my own time).


The question now is whether we are far from being able to achieve this? I think not...

The call to Enterprise Identity Management Stack providers..

That means Microsoft, Oracle, IBM, Sun and so on.. the companies that produce the security software that is managing your enterprise identity every time you sign in to an enterprise application.

Many of these guys are members of the OpenID Foundation, but on the whole it is hard to find clear statements of direction at the moment, and the initial focus has been around demonstrations of how they can use credentials from other OpenID providers.

We need to see two things in particular:
  • OpenID provider support in their core identity management stacks, so that enterprise credentials can be used as OpenID credentials under the control of the company (e.g. they can be disabled when the employee leaves). Call that part of a "Service Oriented Security" strategy if you like, just make the option available;-)

  • Include that ability to blacklist/whitelist sites that the credentials can be used for.

    There will always be good reasons why certain Web Applications may be off limits for corporate use. For example, a law firm may not be able to use Google Documents because of jurisdictional concerns.


Dion Hinchcliffe presented the case well in the recent article "openid: The once and future enterprise Single Sign-On?", along with a great visualisation:


The call to Web Application providers..

Firstly, the big guys like Yahoo! need to support third party OpenID credentials. This seemed to be the main thrust of Hinchcliffe's article. I hope this is just a matter of maturity and not business model pig-headedness, but to offer OpenID sign-in only if your OpenID provider is the same company is not really in the right spirit of things!

More generally applicable however is a major consideration for any Web Application provider that wants to target the enterprise market: addressing the security issue with OpenID support only opens the door. To step through, you must be ready to meet the specific demands of an enterprise customer.

First of these must be data ownership. I didn't want to focus on it in this post because I think it is an orthogonal concern to security. But if you want enterprise customers, be prepared to to consider requirements such as:
  • Access to all data owned by the company's users on the service. For backup, export, and analytics.

  • Audit and compliance

  • Service levels

The call to Enterprise Software vendors..

The idea of a "Web 2.0 appliance" is I think very attractive to many organisations: an easy on-ramp to the space without the need to build up a whole range of specialist skills within the company. In the appliance category I would include Oracle WebCenter and the new IBM Mashup Center. Needing OpenID authentication support in these products is of course a no-brainer in order for them to have appeal in cases where you wish to mix internal and external user audiences.

Enterprise Software vendors need to go further however. The enterprise of the future, which expects to operate seamlessly on the web, will need the ability to "export" corporate identity to the world. Right now, that means capabilities like having OpenID provider support in your Enterprise Identity Management services.

Given the state of consolidation in the industry however, OpenID may present a dilemma for vendors who are faced with the prospect of OpenID support in their Identity Management stack cannibalizing sales of their application suites, as users start to exploit external Web Applications.

But to be recalcitrant and stand against the move to OpenID will only accelerate the onset of a winner-takes-all showdown in the enterprise applications market.

Personally, I believe the showdown is inevitable: with the combined pressures of RIAs, cloud computing, oligopolistic pricing and increasingly sophisticated open source alternatives, I think it is quite likely we will see the enterprise software market go supernova within the next 5 years i.e. blow itself to pieces after a few more years of consolidation ... but that's a topic for another post perhaps;-)


The enteprise software vendors that survive will be the ones who truly embrace being open, and that includes OpenID.

Conclusions?

Well, I wonder if I've convinced anyone?

To me it seems that the ability for enterprises to add OpenID provider support to their security infrastructure will be the key to unlocking the full potential of Enterprise 2.0.

Until such a facility is available from the mainstream Identity Management vendors, we will just be messing around on the fringe.

NB: edited for clarity 9-Sep-2008
read more and comment..