Consumerisation trundles on

A friend just posted a link to "Client4Cloud: Desktop Transformation to Universal Clients" that got me thinking again about the whole consumerisation thing. Quick context: I haven't read the book, although I've just skimmed the sample, so I'm not saying anything about the content or message of the book - simply that it's appearance on my facebook stream of news has prompted this post.

Here's one scenario that has always seemed to me to be a barrier to consumerisation; at least for now. Let's assume we deliver a virtual desktop to our workforce and allow them to bring in their own device (laptop, ipad, whatever). One of the employees comes in today and says his laptop is broken. He's taken it in for repair and it will be a week, so he's a bit stuck and can't do his job. Whose responsibility is it now that he is unproductive?

Of course, there are loads of ways around this. We could have a stock of loaner laptops to dish out in times such as this. However, it just all starts to look rather untidy. We're still managing kit, which consumerisation was supposed to get away from. I'm sure it works better on a small scale with a workforce in the 10's; but scale this up to thousands and I just don't see it.

The flip side is give everyone a laptop that is not locked down, controlled and inflexible. Use virtualisation to deliver the standard set of tools and isolate it from the user-play-area in which enables the employee to make a productive tool for her to do her work.

The world has moved a long way since the early days of machine and then application virtualisation. I haven't really kept a close watch on this area for a few years, but I'm about to do another round. It will be interesting to see what's changed while my eyes have been diverted on other things.

Managing Requirements

I just posted these thoughts on managing requirements on G+: https://plus.google.com/u/0/103322217256114006757/posts/5ZBmgU1umq7

Sailesh wrote an interesting post on requirements here: https://plus.google.com/u/0/115629371379295233882/posts/7sTEwaUA6Cj.

I agree with him that management of requirements is so important, but a challenging thing to do and not helped by the tools we have at our disposal. Nevertheless, manage them we must and I organise the requirements I come across into Business strategy, Functional requirements and Deficiencies.

Strategy/Vision is perhaps not strictly speaking a set of requirements. However, as change can arise directly from strategic initiatives I capture them as requirements, although I might equally create functional requirements derived from strategy elements.

Functional requirements are things that we would like to, but are currently unable to do. This might be launching a new product or reducing travel through the use of video conferencing. Deficiencies capture requirements that address things that aren't quite right in the way the business operates or in the applications, data or systems we use.

I intend (but don't always succeed because the model isn't complete) to trace all functional requirements and deficiencies back to a source: either business drivers (captured as strategy requirements) or business process or technology.

I am using Sparx EA to model requirements along with the conceptual model I have been building of the business process and application landscape. As Sailesh points out, the tools available aren't great, but manage requirements we must... so a man's gotta do... I'd love to know how others have tackled this challenge.

Managing the Mix

I presented a 5 year plan to the board last week. One aspect of the presentation that seemed to resonate really well was an adaptation from the Pragmatic EA Framework's Enterprise Debt. However, I re-badged the terms Remedial, Tactical and Strategic as Deficient, Temporary and Permanent.

I found the term Remedial a bit ambiguous - is it a remedy or in need of a remedy? The intent is 'in need of', but to avoid confusion I chose deficient. We live with deficiency in all aspects of our lives - I have a headache, but I soldier on; the handle on the toilet is wonky, but it still flushes OK so I leave it be; we are a headcount down in our department; our systems don't integrate. Some deficiencies obviously more severe than others.

To address deficiencies we find a remedy, which can either be temporary or permanent. I prefer this to tactical and strategic, largely because tactical has become associated with quick, dirty and cheap, and strategic with expensive and (potentially) over engineered - at least they have in my mind.

So the distinction I draw is whether the remedy will no longer be used, replace by a different solution, at a planned point in time, or one with no foreseeable event that will trigger replacement, even if a desirable replacement exists. Many solutions are built with every intention to replace them, but that replacement never comes - hence the emphasis on a known point in time or triggering event.

Putting this into the presentation gave the roadmap a sense of pragmatic commercial awareness, which can often be lacking when the focus is on technology. It acknowledges that in all areas, technology included, we manage the mix of deficiencies and remedial measures (temporary and permanent). Each section of the roadmap referred to the changes in terms of deficiencies and temporary or permanent remedies.

I didn't get into the ratio measurement proposed in PEAF, partly because the application inventory doesn't use this language yet and partly to take small steps in introducing this new language/model; let it gain traction and then develop it.

I encourage you to read PEAF. How have you used this concept?

UPDATE: So I abused the PEAF terms, doing something a bit different. Made sense in the context of painting current state. I'll have to read over the PEAF material again.

Some good reminders

Andrew McAfee has posted some interesting articles on the adoption of E2.0 applications. His most recent post, Is Management the Problem?, seems, inadvertently, to be a pretty good summary of these posts.

Is this just because he's been right all along ;-)?

I'm convinced that our success with news feeds (RSS et al) is due, in no small part, to getting senior management to experience it and use it. I can see the same pattern emerging (oops, no pun intended) with some E2.0 apps, although I'm not prepared to say which here.

Nokia that Symbian

Wow, this is interesting.

Nokia Corp. Resources | ZDNet

Nokia is to buy out Symbian and set up a new open-source platform with Motorola, Sony Ericsson and NTT DoCoMo, forming a major rival to Google's Android The mobile open-source world suddenly has a very major new player, after it emerged on Tuesday that the Symbian, Series...

587 days

Got this in my inbox today.

Hello from Weebly!

It looks like it's been 587 days, 21 hours, 57 minutes and 37 seconds since you last logged in...

Of course I'd completely forgotten what Weebly was all about and what my password was. The Weebly folk did something clever that I've not seen before, they included in the email a link to log in if I have forgotten my password. With the barrier to entry so lowered I clicked the link.

I remember this site, which 587.92 days ago was unusable. It's a simple web site editor and was usable enough for me to have a quick play and publish. You can create two types of content - pages and blogs (although you'll probably only have one of the latter). It reminds me a bit of jotspot, which is based on a wiki model.

Unless you fear the evil of Google I'd use Google Sites.

Social Network Fatigue

Not for the first time I received yet another invite to Naymz. I just don't want to get into yet-another-social-networking-tool (just crying out for an acronym - YASNT).

Anyway, all the people who have invited me so far are people I'm connected to with Linked-In. Where's the added value?

So far I've just declined. Nothing personal, you understand.