Heikniemi Hardcoded

Twitter and OAuth in desktop applications

2010-09-02T12:33:56Z

If you’re into Twitter API programming, you probably know that the end of basic authentication is here. This post delves into the question of using the OAuth authentication mechanism in desktop applications. If you know the subject, this post will give you some practical advice for C# application development. If you don’t, it’ll act as a primer on OAuth for modern web sites.

The context: A typical application making use of Twitter or another web service almost always needs to act on behalf of a user. The need might be read-only (such as reading a user’s friends list or status history), or it might be read/write, such as with a Twitter client.

Why OAuth?

First, it is necessary to define OAuth and its place in the world as a step forward from basic authentication. When I say “basic authentication”, I mean the technology of sending the users’ credentials in an HTTP header, essentially in plain text.

This approach has three main caveats. First, intercepting the HTTP traffic allows the attacker full control of the user’s account. Second, the application needs to know and store the credentials for the user. Third, since the credentials by definition mean full control, there is no way to grant a limited permission set to an application. And a fourth minor thing, more an inconvenience, is the fact that when a user changes his password, he must change it in all the applications he is using.

The Twitter API has traditionally supported both basic and OAuth approaches, but basic authentication has now been deprecated. The preceding reasons are the main causes for this.

OAuth how?

OAuth, an open protocol designed for secure API usage, builds on a fundamentally different model. The following describes a basic exchange for OAuth-based authentication. In the exchange, three parties take a role: the user (a human being), the service (e.g. Twitter) and the consuming application (i.e. the code running on the user's behalf).

The user indicates his/her desire to use a given service provider, like Twitter.
The consuming application issues a request to the service, asking for an URI where to push the user for authorization.
The consuming application redirects the user to the authorization URI hosted within the service.
The service asks the user for permission. See the image to the right for an example of Twitter’s permission grant dialog. Note that a more granular permission dialog might contain checkboxes allowing the user to control the level of access to the application.
Once user clicks Allow, he is redirected back to the application; the URI contains a token that enables the application to authenticate.
All further API calls will be made with said authentication tokens, establishing user identity.

Details have been skipped and some mechanics may vary between services, but that’s the rough idea.

Note that one element this Twitter example presupposes is that the consuming application must be registered in beforehand. When any API calls are made, the consuming application always identifies itself, which identification Twitter then shows in the permission dialog. This makes it much harder for malicious apps to impersonate other applications. We’ll look at this in more detail shortly.

OAuth and desktop applications

The previous example had details that clearly show it was engineered for the web. For example, note the use of the word “redirect”. Works great if you’re in a browser context – and in fact, opening the permission grant dialog isn’t really a problem in any scenario, because the browser is readily available.

However, the step 5 is more of a problem. Unless the consuming application happens to be a web site, redirecting to it isn’t really possible. Well, most consuming applications work on the web, and that’s exactly the scenario OAuth has been designed for.

Yet still, there are quite a few applications that run on the desktop without a browser GUI. For these, the “redirection” must be done manually, by transferring the token through methods such as look-and-type or copy-and-paste.

xAuth then?

xAuth is a protocol that enables browserless token exchange, essentially simplifying the process to this: The application asks for user name and password and then calls an API that turns the username/password into authentication tokens.

xAuth thus provides a compromise between the values described earlier: The consuming application will get its hands on the username/password combination, but it doesn’t have to store them. If the application is benign, it will not misuse the credentials and will discard them right after getting the tokens (and storing them instead), thus bringing all of the OAuth benefits into play for the rest of the time. Malicious applications will, of course, be able to misuse the username/password combination.

Unfortunately, xAuth isn’t widely available for Twitter yet, and needs special activation by the Twitter API team. So, in the next example, we’re going to tackle this with OAuth. And while xAuth will probably become mainstream one day, the next steps will still be a valuable learning experience – xAuth is, after all, mostly a layer upon OAuth.

Twitter, OAuth and a console application

In the next example, I’m going to build a .NET console application that supports OAuth authentication, storing the authentication tokens in a local file store and then use them to allow the user to send tweets. Actually, the syntax help for the application is pretty informative of the application’s capabilities:

Syntax: TwitterOAuthDemo <command> <arguments>

Valid commands and arguments are:
  authenticate <accountIdentifier>
  tweet <accountIdentifier> <text>

A typical usage sequence is to call authenticate, which opens up a browser
that you can use to get the OAuth PIN, then enter the PIN into the console
window. Once done, you can use the tweet command to actually send
tweets. Since the OAuth access tokens are stored, you only need to call
authenticate once.

Note that the account identifiers are only strings used in this system.
The OAuth system does not need to know the actual user account name.
You can use whatever identifiers you want. The identifiers will get mapped
to twitter usernames at the time of authentication.

For example:

TwitterOAuthDemo authenticate OurNewsInEnglish
TwitterOAuthDemo tweet OurNewsInEnglish "This is a hot news headline"

Ok, let’s look at how this works.

First of all, we must register the application. You do this by going into Twitter’s application registration page and entering some basic information. Perhaps the most important choice there is to denote the application as a Desktop app, so that Twitter will know to show the PIN instead of redirecting the user to another page.

When registered, you receive a pair of tokens for your application – essentially, a user name and a password. Whenever you want to access the service, you always need to authenticate yourself (the application). These tokens must be stored inside the application.

The application secrets

static TwitterClientInfo clientInfo = new TwitterClientInfo {
 ConsumerKey = "DQtmU4Gs3wiAlU3Qw…",
 ConsumerSecret = "tu6oidbDb5XK5MMqmAsMQyZdkIOX0gkW…"
};

The created clientInfo object will then be passed on into each of the method calls made to the Twitter API. In this example, I will be using the TweetSharp library, which while having reached version 1.0, is also out of support by the original authors. However, until drastic changes occur with the Twitter API, it’ll work quite OK.

The authorization part

Like stated earlier on in the syntax help example, the application does not know the Twitter username of the account it uses. So, say the user gives a command of “TwitterOAuthDemo authenticate MyAccount”. The “MyAccount” part is just an identifier within the application, necessary mostly because typing the authentication tokens would be very cumbersome indeed. What happens next?

Unauthorized token

// Get an unauthorized token first
var twitter = FluentTwitter.CreateRequest(clientInfo)
 .Authentication.GetRequestToken();
OAuthToken unauthorizedToken = twitter.Request().AsToken();

This step is required to get a token, a text string that identifies the forthcoming authentication request. Even though the result is wrapped in an OAuthToken, it’s really a pair of strings pretty much like the ConsumerKey and ConsumerSecret in the example above. Looking at the generated request in Fiddler, we see this (unnecessary pieces elided for readability):

GET http://api.twitter.com/oauth/request_token HTTP/1.1
Authorization: OAuth oauth_consumer_key="DQtmU4Gs3wiAlU3Qw...",
  oauth_nonce="l8hn3ftmxrnw4umd",
  oauth_signature="C2EHUSpCJOjtgeE5ObQybJ9Q8qg%3D"

Note that while the request does contain the consumer key, it does _not_ contain the consumer secret. Rather, the message is signed with the secret (again, skipping some less relevant details). Thus OAuth protects both the user and the application from having their identity stolen: this message could not be crafted without knowing the ConsumerSecret.

The HTTP response to this message contains a token (yet another string) and its secret. With the token received, we should get the user out to Twitter to grant us the permission. This operation is really nothing more than formatting an appropriate URI, although the TweetSharp API makes it look like a complex API call. With the URI prepared, we can redirect the user to the authorization page.

The user interaction part

// Now get the URI of the page we're going to redirect the user into
string authorizationUri = FluentTwitter.CreateRequest(clientInfo).Authentication.GetAuthorizationUrl(unauthorizedToken.Token);
System.Diagnostics.Process.Start(authorizationUri);
Console.WriteLine("The Twitter authentication page has been opened in your default browser.");
Console.WriteLine("Please authenticate and return with the PIN code.");
Console.WriteLine();
Console.Write("PIN code: ");
string pin = Console.ReadLine().Trim();

In this example, the URI opened by the default browser was http://api.twitter.com/oauth/authorize?oauth_token=pzvqEf1HybC4z… – i.e. it contained the token returned by the previous API call to request_token. Now, the user gets to see the authorization page shown earlier in this blog post. When he clicks Allow, he gets the PIN code he then can type into to the application.

Validating the PIN

OAuthToken accessToken =
 FluentTwitter.CreateRequest(clientInfo)
 .Authentication.GetAccessToken(unauthorizedToken.Token, pin)
 .Request().AsToken();

With the PIN, we now use the original unauthorized token and the given PIN code to verify the login. The response to this request is an authorized token – again, essentially a pair of strings. Looking at this request in Fiddler (with nonrelevant parts sliced off):

GET http://api.twitter.com/oauth/access_token HTTP/1.1
Authorization: OAuth oauth_consumer_key="DQtmU4Gs3wiAlU3Qw...",
  oauth_token="pzvqEf1HybC4zD7MbIqiJzuuAMnsyqmQrsb1WdzOVbE",
  oauth_signature="jJ%2BEYt72JT548tZsTNw725Er5Ko%3D",
  oauth_verifier="8771529"

For a response, we get (headers removed):

oauth_token=185590444-Z4PWQNxM4PnoWMZfAXhJMOgjA0alTy8d2s3QVJv6&
oauth_token_secret=SxMO9duioXhRcpf1llXWdppEdAEIqgYfE9APrpQcjc

It is now this pair of strings we need to store for future use and pass them in each of our requests.

Next, we store them locally. There is a hand-written TokenStore class for this purpose, but its implementation is irrelevant and needs no revising here. Check out the source package if you’re interested.

Tweeting with the credentials

With the OAuth credentials stored, we can now use them to create requests. The Tweet method thus becomes extremely simple, the core being this:

Tweeting with OAuth login

var twitter =
 FluentTwitter.CreateRequest(clientInfo)
 .AuthenticateWith(authToken.Token, authToken.Secret)
 .Statuses().Update(message);
TwitterResult response = twitter.Request();

While the clientInfo structure contains the identity of the application, it is the AuthenticateWith call that specifies the user credentials. But again, note that the application only stores the oauth_token and oauth_token_secret – it does not store or even know the username. The account identifiers are only used as easy-to-type names for tokens inside the application – Twitter knows nothing about them.

Look at the request at the HTTP level:

POST http://api.twitter.com/1/statuses/update.json HTTP/1.1
Authorization: OAuth oauth_consumer_key="DQtmU4Gs3wiAlU3Qw...",
  oauth_token="185590444-Z4PWQNxM...",
  oauth_signature="opZPjnyd1PQg2tz%2FEd1hhPi95po%3D"

status=ThisIsMyNewStatus

As you can see, the oauth_token_secret is not conveyed in the request, but again, rather used as a part in signing the message. Thus, anyone capturing this request could not use it to hijack the application’s access to the user’s account.

Where’s the source?

Here, go get it. The source compiles to a fully functional executable with two additions: First, you need to download TweetSharp and fix the references in the project, and second, you must register your application in Twitter, then fill in the OAuth consumer key and secret from the Twitter site to the initialization of the ClientInfo structure (the source has my test app’s keys removed).

Have fun!

Dreamers, shapers, singers, makers

2010-08-18T08:46:45Z

As Lauri announced, our company is called Offbeat Solutions. But in the announcement, he also quoted Technomage Elric from Babylon 5 in a way that deserves a closer look.

“We are dreamers, shapers, singers, and makers. We study the mysteries of laser and circuit, crystal and scanner, holographic demons and invocation of equations. These are the tools we employ, and we know many things.”

– Technomage Elric, in Babylon 5 episode “The Geometry of Shadows”

Never mind the lasers, scanners and holographic demons for a while. Let’s instead look at being a dreamer, shaper, singer and maker.

Any single part just won’t cut it

I believe these four bear an excellent link to successful technology consultancy – especially a forward-looking one. We practice them all, and they all link together to support one another.

We dream of a more productive, more straightforward way to solve problems with software. We feel the future, and we have an idea on how to wield it.

But future doesn’t come for free, so we shape it. We stay in contact with Microsoft, with open source circles, with software methodology evangelists, with business decision makers. We give them feedback from the field and test drive the next step.

True leaps happen within the community, and community needs leadership. Thus, we sing. Sharing our experience with our customers, competitors, fellow developers – not only it challenges us to become better, but also powers the innovation cycle and raises the IT business standards further.

And yet, it would all be for naught if we didn’t actually make it happen. Almost everything valuable in the software world is realized through actually working software. If we kept to a role of a philosopher, we’d bear less risk, but we’d also be irrelevant. Besides giving the real hands-on experience, it powers our dreams, thus restarting the cycle.

On competition

Some of the previous might seem like new age altruism to you. Where’s the business in sharing your findings? Won’t you give up the competitive advantage?

Yeah, sure. However, we have a broader view of the issue. It consists of these points:

There is more than enough to do on the IT scene. No single deal really makes the difference.
The main threat to IT business comes from software having excessive cost.
The key way to drive down cost is to manage quality and productivity.
For the last statement, having good people is pretty much the only real cure.
Therefore, sharing information is not really all that critical (compared to the people).

But with that said, isn’t sharing information then fake charity, and building the community just an illusion?

No. First of all, people are not inherently good or bad developers. Good people grow within organizations driven for – and by – improvement. The stronger community we have, the more it pushes companies towards improvement in substance (instead of growth in numbers). Sharing information works here: It accelerates the growth and skill level of the community.

More good companies results in more good developers, and more good developers push down software cost, creating more and more opportunities. And finally, the more demanding customers we have, the more opportunities there are for the best of the market.

Of course, there’s no quick win here. But Offbeat Solutions feels that business success and money is a result of doing things right, and we are here to improve ourselves and have fun. If it produces results, so be it.

"The ability to learn faster than your competitors may be the only sustainable competitive advantage."

– Arie de Geus

All good things…

2010-08-12T07:22:42Z

It is time to head out and risk everything to find a yet another great world. 29th August will be recorded in the annals of history as my last day in Sininen Meteoriitti.

I have been working for the company for six years now. And what six years have they been! I was employee #13 when I joined, and now we number close to 80. I’ve been experiencing – and to an extent, hands-on creating – the change from a small web outlet to a fast-growing, ambitious SharePoint consultancy. So yeah, it’s been a great experience with a lot to be thankful about!

Freedom?

First, the answer to the critical question: The time is ripe to start one’s own company.

When all this finally clicked into place, a quote from Star Trek: The Next Generation came to mind. In the scene, Captain Jean-Luc Picard is pushing his first officer to take up a promotion that will give him his own ship – not entirely unlike leaving a visible position in a recognized company.

Your present position as first officer of the Enterprise

brings you prestige, distinction, even glamour of a kind.

You are the second in command of Starfleet's flagship —

but still, second in command. Your promotion will

transfer you to a relatively insignificant ship

in an obscure corner of the galaxy, but it will be your ship.

Being who you are, that ship will vibrate with your authority,

your style, your vision. There is no substitute for

being in the center of the stage — any stage.

– Jean-Luc Picard, in “The Icarus Factor”

I need nor want no more control or authority over others. But freedom, in the form of having the maximum available choice of options for your destiny, that is certainly something worthy. Freedom, in the form of maximum liberty to arrange the work/life balance, that certainly has value.

And thus, at this time in life, this just feels right.

Details?

Unfortunately, there are few yet. I’ll share what I have, though:

We are four people (Sami Poimala, Lauri Kotilainen, my wife Riikka and me).
We all have versatile software development backgrounds particularly in the Microsoft space, so it’ll be the business we’re in.
- Honest, we don’t have a very exact business plan yet! Of course, we have a few dozen leads and zillions of ideas, but we’ll get the right people together first, then look at what we’ll actually be doing.
We won’t be having an office quite yet, but will rather work from our homes.
We will be available starting from 30th August, although we’re likely to keep a rather low profile in the beginning.

The company name and more details will be published as things mature. Meanwhile, I have a bit over two weeks to get my desk clean and make sure nobody at Meteoriitti notices my absence when September comes. Better get crackin’.

(Oh, and of course, if you are in Finland and happen to need some quite professional developers/consultants on the .NET platform, please feel free to contact me)

“Quadrant” scrapped, “M” refocused – Oslo soon under water?

2010-08-06T09:22:33Z

Mary-Jo reports that her sources tell Quadrant is going to get scrapped and the M language refocused. What’s up with the previously massive Oslo codename?

Both parts were key to Oslo – in fact, the most visible parts left of the original vision that once seemed to span the data modeling needs of the entire universe. Quadrant was the visual designer (see the image), M was the language that allowed the description of data structures and much more. Supposedly, M was going to get some ground also outside the pure developer space – for example, it was planned to be used in the next version of Active Directory.

I think Quadrant sucked all the way in its complexity. Even for pre-alpha software, it failed to generate any excitement in me whatsoever. Admittedly cool concepts, but really, rather little in terms of immediate benefit for practical, everyday software development. In this sense, its dismissal is no surprise. There’s so much available in terms of cheap or free Visual Studio and its designers already – and the platform certainly can be extended further.

M, on the other hand, looked like an abstraction that would have unifying impact across various forms of data storage (AD, relational data, SharePoint lists, …). In that sense, it’ll be very interesting to see the scope of this “refocusing”. If M loses its universal nature, it loses its appeal – or at least, I tend to think so.

Whether or not SQL Server Modeling will ship in Denali or not remains to be seen. The third part of said module is the model repository, but with Quadrant’s and M’s shuffle, will there be anything to store there? At any rate, SQL Server Modeling November CTP is still out there for download. While supplies last, at least.

Oh, and yet another PDC with a chance to announce something regarding Oslo? Looking forward to October…

Windows Azure Appliance – Your private corner of the Microsoft cloud

2010-07-13T12:46:58Z

The “private cloud” concept (i.e. the idea of running the cloud-designed applications on your premises) can be implemented in a variety of ways. Not surprisingly, each cloud vendor also provides its own notion of “private cloud”. Now Microsoft adds yet another approach to the mix by launching Windows Azure Appliance.

Before looking into the appliance launch made yesterday in WPC10, I’ll provide a short backgrounder on the cloud, private cloud and the different XaaS approaches. If you just want to read about the launch, skip ahead!

What is private cloud?

Private cloud could be defined as the cloud-level infrastructure implemented in an enterprise setting. Perhaps the simplest example is the one often used with VMware products: Instead of buying a bunch of servers for a specific purpose, you buy a stack of general-purpose servers, assign them into a massive pool and start dividing out the resources (computing power, storage, …) to the various purposes within your organization.

The key levers to this are automated management and the virtualization. These advances allow reasonably sized pools of computers to act with a cloud-like elasticity, providing fault tolerance and scalability on-demand. Thus, the role of IT operations change: They become more like a service provider, perhaps with less exact control over the applications running in the datacenter.

The different levels of service

The virtualization-based level of abstraction from the cloud is typically called IaaS, Infrastructure as a Service. In an IaaS setting, the application is a normal Windows, Linux or whatever application – it just runs on servers virtualized in a specific way. The virtualization environment could be your local Hyper-V or VMware installation, but it could also be a cloud provider such as Amazon EC2.

It is a reasonably simple notion when compared to PaaS, Platform as a Service, which Windows Azure mostly represents. With a PaaS application such as a Windows Azure Web Role, the software is specifically built for the service platform. In exchange for requiring a slightly different development skill set, the PaaS platform hides the complexity of scale and fault tolerance. For example, a failure of a Windows Azure server is transparent to the application. Likewise, an Azure application can be scaled to thousands of computers without code changes – if the Azure programming paradigm has been duly followed.

Above both these is the notion of SaaS, Software as a Service. The users of SaaS applications are the end users – they don’t want a platform, they just want an application that works for their purpose. Typical offerings include Google Apps (email, document sharing etc.), Microsoft Business Productivity Online Suite (likewise), Salesforce.com (CRM) and so on.

Note that all these XaaS offerings are layers upon one another. There is no grading here: one is not better than the other, nor does one represent an advance over the others. What works for you depends on your needs.

What is the Windows Azure Platform Appliance?

Essentially, it is a container of about a thousand servers, deployed on your own premises. You can’t touch the inside though – just plug in lots of electricity, cooling and network capacity, and you’re good to go. What runs inside is the same application platform as in the public Azure cloud.

The key point is that the software platform is managed by Microsoft. When Windows Azure gains new capabilities, the software inside your container will be upgraded. And although you’re in charge of the schedule, you don’t need to – and you can’t – touch the actual upgrade process.

This is what separates the Appliance from various other private cloud offerings. For example, VMware’s notion of a private cloud mostly revolves around the idea of getting cloud technology to run on-site. Microsoft now extends this notion by bringing the service into the on-premise datacenters. The Azure Appliance is not just the platform on-premises, it is the platform service on-premises.

So far, it has been promised that the appliance will be running both Windows Azure and SQL Azure. This means that it will be a sufficient platform for most cloud-based application that can be currently run on the public Azure cloud.

The figure of thousand servers was thrown in the air by Bob Muglia; he also stated that somewhat smaller appliances were in the plans. Given that the container model requires a rather considerable amount of nodes in order to provide sufficient fault tolerance (remember: the container is probably replaced once a certain percentage of hardware requires replacement), I doubt we’ll see anything below 300 servers.

Why the Appliance?

The Appliance strikes an interesting balance. It provides the usually quoted benefits of private cloud (better control of data, less dependent on the Internet connectivity, faster data transfer inside the organization etc.). It also provides much of the public cloud benefits – most importantly computing without the need to setup or maintain the servers – the “serviceness”.

Scalability and elasticity don’t really apply to the appliance on a hardware level, but it does provide reasonable scalability inside the box. It remains to be seen if Microsoft will start supporting various more complex scenarios such as resource pooling between appliances and even perhaps the public cloud.

The appliances will be available both for hosters and end customers. Initial partners are HP, Fujitsu, Dell and eBay – the last of which is an actual customer. Since the big partners have their own datacenters around the globe, this also broadens Microsoft’s reach considerably: For example, organizations who have a legislative (or policy-based) need to keep their data in Finland could not have done so with Azure so far. However, a sufficiently big customer might buy a container of his own, or a smaller one might depend on Azure services provided by his local hosting company.

The pricing was not announced yet. This is an interesting point, because there is no precedent. Such appliances could be sold with a sizeable upfront cost, but they could also reasonably be rented. And yes, usage-based billing is an option too. If Microsoft decides to go with usage-based billing, it essentially takes a great step towards month-based licensing for on-premise software, a vision from long ago. At any rate, some monthly cost is definitely to be expected, given Microsoft’s commitment to providing the updates.

Sadly, no idea of the schedule so far.

PDC 2010 – 2 days in Redmond

2010-07-14T05:54:34Z

And we all thought PDC 2010 wasn’t coming, but it does. Not sure if Microsoft intended to slip it already, but www.microsoftpdc.com is live!

It’s only two days, so getting shorter every year. No idea on the agenda, but I’d be surprised if the slippage wasn’t related to the WPC keynote starting in 50 minutes. So stay tuned…

Update: MJF covers some of the content in her blog post.

Coming next week: WPC 2010 in Washington D.C.

2010-07-07T09:10:34Z

Next week is the holiday-breaker for Microsoft partners as Microsoft’s Worldwide Partner Conference, colloquially known as WPC, kicks off. WPC is not much of a technical launch conference, but it does provide an interesting perspective into various things. I’ll be staying here in Finland, watching the news wave from afar.

A short recap of the last year is available in my blog post from July 2009. The main themes were Azure pricing and Office 2010. But what are we really looking forward to for WPC 2010?

First and foremost, there is the cloud

2010 has been the year when Microsoft announced the “We’re all in” mantra for cloud computing. No doubt, this will be the key theme for the whole WPC, as Microsoft tries to convince its partners, critics and the press of its plans for the cloud era. There’s a lot of ground to cover, too.

The main question is: How do partners take part in the cloud ecosystem, where customers start paying directly to Microsoft? On a theoretical level, this really isn’t a problem. Microsoft’s cloud offering without professional assistance will satisfy only the most tech-savvy customers and perhaps those with very simple and flexible requirements. But a lot of the actual business mechanics are still… well, clouded. Hopefully we’ll be a lot wiser a week from now.

Plus partner program and everything else

Another key theme should be the heavily refreshed partner program, now known as Microsoft Partner Network (MPN). Although the key new things were already announced last year and a lot has already been implemented, I think there’s still more to come.

And of course, a plenty of hype around the commercial success of Windows 7, SharePoint, Azure and whatnot. And surprisingly, I look forward to all that :-) Despite being a bit excessive even on the border of religious fervor, it does provide a good mindset for envisioning the future and thinking about your competence goals for the next few years.

And yeah, I’ll post the keynote highlights this year here in this blog, too. If you want a live part of the action, the keynotes will be streamed on digitalwpc.com on Monday, Tuesday and Wednesday next week.

Changing the capri pants – a reminder on customer service

2010-06-29T03:52:35Z

I recently visited the Vero Moda boutique in Kamppi, Helsinki on an errand to change a pair of pants unfit for my wife. The affair was done accordingly to their change/return policy, except for one thing: the missing original price tag.

The lovely salesperson decided to give me hard time on this one. Despite the fact that the conditions indicated a nigh-zero chance of an attempt to cheat, she immediately started by stating “I really can’t help you here”. Which is, basically, quite fine. She was correct: their policy said no returns without the receipt and the price tag, and it’s not an unreasonable policy. I could’ve understood that.

However, the next step was that she begrudgingly admitted to taking them back, after closely examining them for possible wear and tear. Finding nothing, she felt almost disappointed as she told me she’d make an exception this time. “Just remember to keep the tag attached the next time”. I seemed to need this reminder for a couple of times, even.

Yeah yeah, we will remember.

If your customer is wrong, swallow it

The worst thing is that we do this all the time in IT as well. A customer rolls in a ridiculous-sounding request. We tell him it’s a no, but then turn our heads due to one reason or another. And while we are working on the request, we whine about how things should be differently, how the customer has no clue and so on.

For your deity’s sake, if you decide to comply with your customers’ wishes, don’t make him feel bad about it. Once you make the call of going one way, focus on making the situation a customer service victory. Perhaps you did expose your company to a risk of a few extra man-hours of unbillable work, or perhaps there is a slight chance that those pants were used and somebody gained unjust advantage. But once you decided your course of action, you couldn’t retreat anyway.

Perhaps there is a time for politics, but the it is almost never when you’re actually working with an immediate customer problem.

Well, I got my (or my wife’s, actually) pants changed. However, I’m left puzzled: It’s almost like I felt worse than I did at the first phase when my request for a change was reasonably and politely denied.

Avanade collaboration study, and what can we learn from it?

2010-06-24T04:30:07Z

In the beginning of June, Avanade published a study on collaboration practices (press release [PDF], executive summary [PDF]) in enterprises. Here are some of the key findings from the study, spiced with some of my own views.

Target group: 538 executives, IT decision-makers and business unit leaders in 17 countries.
80% of executives see enterprise-wide collaboration as a key element necessary for business success.
35% feel that the communication and collaboration tools have made it easier to work with others.
75% of companies plan on increasing the use of collaboration technologies in the next year.
The collaboration tools’ importance was assessed as follows (percentages indicate the proportion of respondents considering a given medium as “essential”):
- 90+% email
- 89% phone calls
- 74% shared disk volumes
- 62% corporate portals, intranets and team sites
- 57% conference calls
- (too bad there’s no data on instant messaging!)
44% of companies think that collaboration technology must pay for itself in 24 months. 42% do not measure cost benefits, but this certainly doesn’t mean they wouldn’t name cost savings as a key driver.

On the negative side:

38% of respondents think that people equipped with collaboration tools solve less problems on their own. In the US, this number is as high as 54%.
- The fear centered on the idea of people offloading responsibilities and work onto their social network.
25% of executives and IT decision-makers were “dreading” collaboration because of the amount of time and energy it wastes.
In companies with less than 1000 employees, 12% of employees consider collaboration to slow down their work. On the other hand, in larger companies only 6% find collaboration a slowing factor.
Also, C-level executives consider collaboration a slowdown three times more likely than IT decision-makers or business unit leads.

So what?

I think we’re looking at a significant cultural change here. I definitely agree with the 80% of executives holding collaboration as a key factor in business success. Simultaneously, I can clearly see a significant part of the workforce using social networks to avoid responsibility. But these are the people who were avoiding it all along anyway.

Collaboration tools (team sites, instant messaging, unified communications) aren’t really a revolutionary change, perhaps with the exception of IM and cheap video conferencing for geographically dispersed teams. Rather, they are an accelerator. A SharePoint Team Site, for example, can potentially combine data from dozens of applications and provide it in an easily browseable, offline-usable and shareable format.

But that doesn’t make anyone more lax or slow than before. What slows people down is either the improper control of work flow (see the classic Slack: Getting Past Burnout, Busywork and the Myth of Total Efficiency for the typical stories) or the lack of competence. Collaboration tools make social, energetic and determined individuals shine, leaving less accomplished persons more alone. Social tools can be used to alleviate this loneliness, perhaps causing the phenomenon the upper management fears.

Now, that is a workplace problem worthy of C-level executive attention, but it’s hardly a tool question. It can be mitigated, but it requires a cultural change. C-level officers, often further away from the daily hum of the workplace, often see this as a structural problem. It rarely is; effective use of collaboration is probably best facilitated by first-level managers and middle management, driving their team culture towards effective working model.

To facilitate this, compliance and governance rules laid by the top brass should be simple and generic enough to allow relative organizational independence. The corporation never dictated the agenda of team meetings, so why should all team sites be forced to the same template?

Gold rush ahead?

There’s a whole bunch of work to be done. But that doesn’t mean it’s going to be a gold mine for everybody. First of all, while the late recession left companies yearning for innovation in technology (in fact, the Avanade study says 80% of companies have become more open to new technology due to the economic turmoil), building a credible business case for collaboration tools isn’t exactly trivial. Apart from the obvious reduction in travel expenses, the financial gains are hard to measure and prove.

I think there are two types of vendors benefitting from this next wave.

The first ones are the big ones who actually can provide a credible enough story to convince the top management. This approach breeds the traditional enterprise adoption problems.

The second ones are the small ones who empower smaller units within a corporation by providing a solution that actually turns out to be effective, becoming a phenomenon within the company (see an example of enterprise micro-blogging spread, from my previous OfficeTalk post).

Also, there’s going to be intense competition from the cloud, particularly within the second group. Services like Basecamp provide an excellent bang-for-the-buck ratio, and the setup is easy enough to enable adoption even without centralized support.

Winners in this game are those who not only setup the tools, but also facilitate the cultural change required to use them successfully.

Live Mesh dying soon – some saved by Live Sync, some not

2010-06-14T07:59:26Z

The fact that Microsoft had Live Mesh, Live Sync and SkyDrive offerings was always confusing. Things are getting a turn for the clearer, as the Live Mesh brand gets nixed and Live Sync gains much of what Mesh used to be. But it’s not a change without losses.

When installing the Live Wave 4 package, Mesh will be removed and replaced with Live Sync. You can’t have both on the same computer. But a branding change isn’t really that touching. What is actually changing?

Not very much, in fact. Live Sync gains the Remote Desktop capabilities from Mesh. It is also designed to sync far more data and more intelligently. For example, if you want to sync movies between two computers on the same network, Live Sync uses the local network to do the synchronization instead of passing the data up to the cloud and back again.

On the other hand, Live Mesh used to provide users with 5 GB of cloud storage for their files. This change shrinks the storage to 2 GB; a change perhaps not that significant for many, but a somewhat surprising direction. If you’re more interested in this, check out Paul Thurrott’s criticism on the issue; it also speculates on the possibility of providing the ability to buy more storage space in the future.

Platform support slashed

A somewhat challenging issue is the cut on the platforms supported. Live Sync will only be available on Vista and Windows 7, leaving Windows XP, Mac and Mobile users out in the cold. The Live Mesh infrastructure will be supported for a while – at least six months from the RTM release of Live Sync. But after that, users without Vista/7 will be looking for alternatives (Dropbox, anyone?).

The key problem here is shared folders. While Sync supports sharing folders between your friends just like Mesh did, it does not support sharing between Mesh and Sync users. So if you want to upgrade to Live Sync, you’ll be leaving out your old Mesh friends. Simultaneous upgrade for all your friends works great… until it turns out one of your sharing mates has XP or still needs Mesh to collaborate with users on XP.

This upgrade policy will certainly lead into broken social networks, as people lose a lot of the flexibility originally provided by Mesh. It doesn’t make the new Live Sync a bad product, but a cutback from the current state provided by Live Mesh beta. Certainly, the upside will be a far more integrated and better supported solution.

The Mesh train losing steam?

When the Live Mesh was at its hyped peak in 2008, the Mesh concept encompassed everything in the world. The Mesh was intended not just as a data synchronization platform for files, but also a conduit through which applications and their attached data could be shared.

For example, you could install HTML or Silverlight-based applications on Live Mesh, which would then propagate these apps to all your devices. The Live Operating Environment would make sure that the structured data needed by these applications would be available at all locations, synced in real time. There were grandiose demos with things such as Ori Amiga’s car equipped with a Mesh-connected computer system.

Today, there’s none of that. In August 2009, the Live Framework developer tools were cut. In PDC 2009, the promises were already watered down to file sharing. In this announcement, remote desktop stays, but much of the platform independency is stripped off. Also, the idea of implementing even that trivial Wine Cellar (see the previous link) on top of the currently announced Live Sync seems far-fetched.

We can safely say that Live Mesh has been reduced to a platform-integrated, cloud-capable synchronization tool. That’s not a bad offering per se, but looking at Ray Ozzie’s visionary statements on the future of Mesh and the feature cuts involved, it does feel a bit cheap right now. In this regard, MIX10 delivered far less than expected.

I’m sure the team is working on the next increment even as I type this, but given the relative maturity of Live Framework in 2008 and the natural synergy with out-of-browser Silverlight, I’m surprised to see the delays. While HTML5 is gaining support for local storage and whatnot, the original Mesh offering provided device-independence and sharing as features that the standard web technologies will struggle to match for a long time. I would have expected Microsoft to better take the advantage of all that.