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.
Monday 21 November 2011
Sunday 6 November 2011
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/
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.
Sailesh wrote an interesting post on requirements here: https://plus.google.com/u/0/115629371379295233882/
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.
Subscribe to:
Posts (Atom)