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.
Sunday 9 October 2011
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.
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.
Subscribe to:
Posts (Atom)