Solving the symptom instead of the problem


Last Winter two mice came into our house each night through a vent and ate dry goods in our pantry and cupboards. As a general rule we don’t kill – insects, spiders or mammals – so the ‘obvious solution’ was not an option. What did we do, and what does this have to do with ICT?

Disclaimers: My views are my own. In general I live a vegetarian/vegan lifestyle. I consider pesky a term of endearment. And, I apologise in advance when I generalise the complex.

Of Mice
The general concern with mice is that they spread disease and breed like, well, mice. But really, our mice were endearing. They would come in at night and peek around the back of a desk. If we moved they shot back to the vent. If the coast was clear they darted from furniture leg to furniture leg until they reached the kitchen. We first noticed when holes appeared at the bottom of the bag of dog biscuits on the floor of the pantry. So, we lifted the bag onto up a shelf.

They still got to the dog biscuits, via a tin of oil. So we put the dog biscuits in hard plastic tubs with lids. The following night we heard russling in a cupboard which contained some dry goods like noodles, pasta and muesli. The shelf was 1.5m (5′) above the ground! It took me two weeks to find all of the ways they climbed and leapt their way up, but eventually I secured the shelf and cupboard.

The mice went back to the dog biscuits and for four nights we heard them scratch and bite at the plastic, to no avail. Our food was secure. And the mice stopped coming. We still saw them outside occasionally but we probably prevented the start of a population boom, without traps or poison.

It turned out the mice in our house were a symptom. If we killed them, more would have come. The problem was that we stored our food in ways that attracted outside animals to come in. When we solved that problem, no more symptoms.

And (Wo)Men
I have witnessed ICT professionals complain about another species of mammal, the computer-literate academic. The ‘problem’ was that these pesky academics would spread viruses through unsecured PCs, and breed new Mac-users like, well mice. And the ‘obvious solution’ was to crack down, lock down and institute rules and bureaucracy. Except, that wasn’t the problem.

The real problem was that we provided computers that didn’t suit their needs. We eventually learned to solve that problem by progressively addressing indicative symptoms. First, standardised PC hardware configurations options covering the spectrum of needs. Then a managed operating environment (MOE) for Windows 7, providing security and improved performance. Then a suite of self-installable applications. Then a streamlined desktop migration process. Then an MOE for MacOSX. Then a Managed Print Service with swipe-to-release follow-me printing (which is fantastic).

And next thing you know, no pesky academics. Okay, sometimes the occasional one is found divulging their passwords through phishing – but we don’t have to resort to traps and poison!

So, my observations are:

  • A recurring ‘problem’ is probably a symptom;
  • Defining the real problem enables the right solution to be found;
  • The right solution is often revealed iteratively by addressing new symptoms as they emerge;
  • Working with the natures of those involved is easier than working against them – i.e. user-centric approaches;
  • You don’t need to kill mice (or ants). Find what they are coming for, make it unavailable, and repeat until they stop coming.

Note: I am currently reading “This is Service Design Thinking” and guess what step 1* is… find the real problem. Ric Phillips might be onto something with his Thinking Differently…. By Design post.
*a suggested step 1, since Service Design has no fixed process

Just ‘e’ cause

I once received some feedback that some of my peers felt I was a “zealot” about eResearch. Evidence of this was that I was single-mindedly focused on eResearch and continued to promote my own definition of eResearch, dismissing the definition of a highly regarded independent IT research organisation (which was ‘IT used for research’). “Yes!”, I replied, “but not about eResearch”. I was flying the flag of the ’e’ cause and the cause was just.

Disclaimer: As usually, the views expressed are my own.

So let’s start with my definition. eResearch is the significant enhancement of research outcomes through the use of information and collaboration technology. That is, eResearch is the conduct of research first and foremost. ICT is used to increase speed, scale, scope and open new lines of inquiry.  There is a good discussion of the changing research methodology at the eResearch NZ Blog.

Now onto the zealot bit. I was passionate about eResearch. I am passionate about eResearch. Passion is a strategy of mine. So being called a zealot about core University business by other ICT people was not an insult, it showed I had a marketing problem. But eResearch wasn’t the source of my passion. It was the target of my passion. I was actually passionate about the new role of ICT departments – the ‘e’ that gets tacked in front of every business function.

As I described during my 2010 QuestNet presentation the role of the ICT services department is changing to Information and Collaboration Enablement (ICE). With this:

  • Focus changes from Processes to Outcomes;
  • Relationship with ‘business’ changes from Service to Partnership;
  • Value changes from Efficiency to Optimisation; and,
  • Scope changes from Strategic Alignment to Vision Fulfilment.

So that is what I believed. And when responsible for eResearch Support – I fervently sought ways to work in partnership with researchers to significantly enhance their (our) research outcomes in pursuit of the University’s (our) vision. In doing so, I worked with my colleagues within ICT and other service providers to optimise the services available to researchers.

But, my zeal alienated and confused some colleagues while attracting others. That reduced my overall effectiveness because I lost influence with those who dismissed what I said as complicated (or the rants of a fanatic). Even as I tried to communicate why and how and what I and we and they could do I was adding bricks to the wall. And when someone doesn’t get a message, the sender is responsible.

So, what can I offer from my experience?

  • Having a purpose and being passionate about it attracts people, but can also overwhelm and, if misunderstood, concern others;
  • Thinking about the jobs-to-be-done by your clients/customers helps identify how your skills and expertise can uniquely help get them done;
  • It is important that peers really understand your approach and will go along with it, and if they don’t slow down and get them on board (and I don’t mean just talk slowly ;-);
  • The ‘e’ cause is the way of the future – optimising a business function near you soon!

Final note: Seriously, ‘IT used for research’. That sounds awfully like a commodity function to me. Important, but a job for someone else. And that was a problem for me. My colleagues were still the ‘some one else’ and they had their own challenges. I was writing cheques our collective capability couldn’t cash. Live and learn.

The iceberg model of interpersonal perception

Iceberg in Antarctica

By Ben Stephenson from Beltsville, Maryland (Picture 809 Uploaded by Hike395) (CC-BY-2.0) via Wikimedia

When I was in Year 6 I was busted for picking my nose. I was standing in line at the front of class to get my spelling checked. The teacher from the next classroom came in and called me out for having my finger up my nose. It caused a stir with some laughs, especially from my friends.

The teacher saw me picking my nose. I was in fact simulating picking my nose, with my nostril pressed closed so that it looked realistic. It was an in joke with my friends and was intended to get attention of other people in the class. I don’t think the teacher believed me. The teacher probably left thinking I was an 11 year old who picked my nose and did other distasteful activities.

The tip of the iceberg

Well, it reflects my experience of how I and many people (if not all) make judgements based on seeing the tips of others’ icebergs. I am not judging it – plenty has been written about how this is normal evolved behaviour. However, we need to be aware of this so that we may compensate for shortcut thinking.

The following Interpersonal Perception Iceberg model reflects how outcomes arise from behaviour and thought (intention, motivation, etc). Only a fraction of relevant information is ‘visible’ to us directly. We get some third-hand information from others – although it may be tainted by their hidden assumptions. And then we have our assumptions about the other person’s behaviour, intent and motivation.

Interpersonal Perception Iceberg

Interpersonal Perception Iceberg by Peter Hicks (CC-BY-SA-2.0)

So if we apply the iceberg model to my classroom experience:

  • Outcome: I appeared to be picking my nose
  • Behaviour: I pushed my nostril closed and pretended to pick my nose
  • Intention: to amuse my friends and members of the class
  • Conscious thought: it would be good for a laugh
  • Subconscious thought (maybe, knowing what I do now): I wanted to stand out to make friends

There is a long way from wanting to make friends to the teacher next door assuming I regularly pick my nose, yet that is where he and I ended up.

Skirting disaster

I see this happen all the time, and I do it myself. Whenever I say “I think” about someone else there is a good chance that the assumptions I am standing on are about to be ripped open by a hidden part of an interpersonal iceberg.

I credit my awareness of this to the team at Manager Tools, who recommend performance management through a focus on specific behaviour and outcomes – which are indisputable – rather than conclusions – which are perceived. To check if you really know the difference I suggest you listen to this podcast on giving feedback.

To minimise the risk of this I try* to:

  • Be mindful that I have a perspective based on very limited information;
  • Assume my assumptions about intent and thinking of others are guesswork and PROBABLY WRONG;
  • Act on facts – outcomes and specific behaviors;
  • Remember that most other people will perceive me through the tip of my iceberg.

* Hey, I can only try. After all, mental shortcuts are normal evolved behaviour.

So, does this make sense? Do you have a deep, misunderstood block of ice below your surface? I’d appreciate your comments.

As a final note, did you spot the ironic twist when I fell into the iceberg trap during this post?

Just because we must doesn’t mean we should

A duck walks into a bar and says, give me a drink. I couldn’t think of a relevant punch line but while we are on the subject of ducks, I recently wrote about different levels of abstraction. I also wrote about commodities in the context of ICT services. Today I am writing about how these apply to (de)duplication.

Disclaimer: The views expressed are my own. I could write a treatise on this topic and some concepts are oversimplified. From an ecosystem perspective overlapping interests and interdependence mean that outcomes must be optimised collectively rather than maximised in single domains.

What is the purpose of deduplication? Very simply, control of quality and efficiency. The espoused benefit of standardising is consistency. The espoused benefit of consolidating is economies of scale.

Value add or commodity?

For the past year I have been referring to just about everything Curtin IT Services does as a commodity service relative to the work that the CITS eResearch Support team does (illustrated in my eResearch Australasia presentationslides). The reason is deduplication, a priority of the CIO. So, I have been using ‘commodity’ to make a clear distinction between the unique capabilities we add to the traditional ICT services currently provided.

Recently I was challenged on whether some elements of the work my team does is duplicating. As I described with ducks, it depends on your level of abstraction. What it highlighted to me was the can factor. I considered everything my team did until now to be non-commodity because a year ago other teams were unable or unwilling to do it. Today we still do much of it, even though it is a distraction, because I assumed other teams were still unable or unwilling. I was constrained by the present, what is. Rather, I must focus on the future, what can be. What is truly part of our purpose and what is just lacking the insight and will to push change? Our (eResearch) most unique function is understanding how we (as CITS) push more of the apparent ‘unique’ activities into ‘commodities’ to release more effort for collaborating with researchers. It is my responsibility to help the rest of CITS to take ownership of these ICT functions so that my team can focus on helping researchers achieve research outcomes using the right mix of expertise and technology.

Duplication

So, is the commodity overlap I described a functional duplication (skills) or outcome duplication (effort)? Duplication of effort, repeating work to achieve the same objective again, is clearly a waste. If the duplication is functional then outcome duplication probably exists at a management level. I.e. Performing the same operational tasks to achieve different ends, but managing multiple people/teams with the same skills and associated processes and technology. This may mean that processes and standards are not the same (quality) or more work is created maintaining parallel systems and later trying to integrate them (efficiency).

Where functional duplication makes sense (ie doing the same thing for different outcomes) is where the overhead of managing the differences is greater than the savings of managing the equivalents. That calculation may change over time. Initially the differences may be quite significant or there is high uncertainty about elements of expectation and cost. With effort the overheads can be significantly reduced, or the outcomes and activities abstracted in a different way, to justify eventual consolidation.

Implications

Really, what is the difference between deduplication within Curtin and deduplication beyond Curtin? I think none in the long run. As Peter Nikelotatos says, 90% of what ICT service groups across universities do is functionally the same. Chances are that 80% of what we do is functionally the same as the activities of ICT groups in large organisations in Australia and globally. This doesn’t mean it is a total duplication of effort (effort and function are different) but it begs the question (and explains the unstoppable march to utility computing).

So, for my situation at least:

  • Justification of duplication requires a clear understanding of the desired purpose and outcomes;
  • Quality and efficiency factors of duplication change over time and should be reassessed periodically;
  • There may be multiple ways to achieve desired quality and efficiency outcomes;
  • Don’t be constrained by today, start changing tomorrow.

The value of commodities

Recently colleagues and I discussed the use of words like commodity and utility with respect to ICT services or activities. The point was made that these words diminish the value of our work by implying our effort is readily interchangeable with equivalent alternatives and can be easily switched on/off. An examination of the concept of commodity service highlights potential for increased value and innovation, especially for those providing the service.

Disclaimer: This is about semantics and I have not really captured value from an SDL perspective; i.e. value in use and value cocreation. Comments on commodities in SDL are welcome.

A problem for those who use the word commodity is that the most common use is in the evening finance report talking about minerals and agriculture products. Therefore the primary word association is with a superficial understanding of bulk goods. Even with bulk goods there are some quite complex factors such as grade and transport logistics that determine buyer decisions.

Desktop computers are an example of a complex commodity good. They are complex inside, there are slight differences in the functionality detail, yet they all provide the same platform for running applications the user needs. In this respect they are interchangeable. Of course not all desktop computers are totally alike and factors such as reliability, performance, delivery, support and price all go into the mix in deciding what meets a purchaser’s need.

It gets interesting when we consider commodity goods and commodity services. Commodity services are those where the inputs and outcomes are well understood. Delivery has matured to the point that quality and cost are stable and can be clearly specified, contractually if necessary. An example is payroll. I remember during my teenage years getting my MicroPay slip each week with my hours, rate and deposited amount listed. Payroll is clearly an example commodity service and is outsourced in many organisations. Much of what we provide as ICT services are also commodities, e.g. email.

So the common element of both is that a number of parameters such as price and quality can be specified. This enables them to be traded commercially. Commodities are those goods and services that are tradeable with input and output characteristics clearly specified. Service Dominant Logic (SDL) suggests there is actually no difference between goods and services. At a minimum goods sit within a ‘supply service’.

I’ll write about my fascination with on Service Dominant Logic another time (you can look it up at sdlogic.net). It contrasts with traditional Goods Dominant Logic (GDL) which considers services to be an awkward type of good. There are significant implications of an SDL perspective with respect to value and engagement.

Commodity DOES NOT mean ordinary, boring or of low value. In fact commodity services can be of immense value due to the ability to focus innovation on what we know and do best. The supplier of the commodity can use scale and intellectual property to innovate in the way services are performed and delivered. The customer can innovate in the way services are used, even combined, to meet their unique needs. The result is a continually optimising exchange of value (in an ideal world). [just because they can doesn't mean they will]

So to summarise:

  • We need to set the context in which we use words which have a common simplistic association;
  • The properties that make commodities tradable allow them to be the focus of innovative provision and innovative use;
  • Value exchange is at the heart of service (SD Logic rocks!).

I was recently challenged about my working definition of commodity service, which I’ll write about shortly. Until then, any thoughts about commodity services? Are there better words to express the intent?

vBlock is part of our cocoon

We need to transform from lumbering technology-focussed caterpillars to agile business-outcomes-focussed butterflies in order to help Curtin harness the forces of cloud, social and mobile computing for positive change. Until we build our cocoon will never be able to stop eating leaves long enough to grow wings. The implementation of VCE vBlock is a critical part of our cocoon.

Disclaimer: This is buzzword saturated and some of you need to turn down the sensitivity of your detector (you know who you are).

I didn’t get it. I listened intently to everything the CIO was talked about, reflected upon and internalized it, and repeated it in appropriate contexts. But I just couldn’t tie all of the threads together. A couple of pieces of silk were dangling and one of biggest was them was vBlock. With the lack of a connection as to ‘why vBlock’ in the cloud strategy I assumed it was ONLY about innovation and partnerships.

That was until a conversation over coffee at a conference with our Enterprise Architect. vBlock, he said, will enable us to move applications seamlessly in and out of our data centre. We don’t even need the physical equipment in our data centre. But we need to rearchitect the way the run our applications. There is a lot of work to get it to the point that Peter wants. We can’t just move the existing VMs across. This will transform the way we think about and operate services, including the possibility of true ‘utility’ services.

And then the last threads were tied in place and a shimmering silk tapestry of transformation appeared. vBlock, and the preceding vCloud pilot, are critical foundations of everything else I was banging on about at Questnet – the move from ICT services to information and collaboration enablement (ICE).

When I told this to a colleague, they agreed they didn’t get it either and we talked through the implications together. That was the time I went public (to a dozen people) with my ignorance and kicked off a useful (for me at least) discussion. I do not doubt the imperative priority of and effort invested in the vBlock implementation.

To summarise what I got from the experience:

  • vBlock is part of the utility/cloud transformation strategy, as well as innovation and partnerships;
  • a small but critical insight can completely change the (strategic) level of comprehension of a situation;
  • when you are unsure about something, don’t assume – ask and share.

Now I need to get my head around the next thing ‘I know’ but not fully understand the implications of. To stretch my metaphor to its absolute limit, I think it has something to do with Curtin being a sunflower and other universities being daisies, daffodils, etc, with some nectar thrown in. Anyone want to guess?

Please let me know if this has been useful or not and examples you may have seemingly disjointed initiatives being part of a bigger picture.

The utility of words

Recently colleagues and I discussed the use of words like ‘utility’ and ‘commodity’ with respect to ICT services or activities. The point was made that these words diminish the value of our work by implying they are simply switch on/off or readily interchangeable with equivalent alternatives. So, should we continue or cease using them?

Commodity

For the past year I have been referring to just about everything Curtin IT Services does as a commodity service relative to the work that the CITS eResearch Support team does (illustrated in my eResearch Australasia presentation). The reason is deduplication, an operational priority of our CIO. So, I have been using ‘commodity’ to make a clear distinction between the unique capabilities we add to the traditional enterprise-focussed services currently provided.

Really, what is the difference between deduplication within Curtin and deduplication beyond Curtin? I think none in the long run. That said, the daily commodity price report on the evening news creates a strong association with low value-add (which is the point of the use of the word commodity, but it might be counterproductive in this context).

Conclusion: the subtle differences of meaning between commodity services and commodity goods is easily lost and the word is probably overused (to which I contributed!) so I will cut back on it.

Utility

I have increasingly talked about utility computing, along with mobile and social, to discuss the trends Peter Nikelotatos has identified as driving our strategy in Curtin IT Services. Utility computing signifies essential, simple to use and available on demand; like water, power and telephony. The word is aspirational, representing all the things that information and collaboration technology should be. 

Utility also represents efficient, which many of the 20th century utilities achieved by consolidating activities. This is unfortunately the primary meaning taken from it. Interestingly, the utilities have/are undergoing structural transformation to address imbalances in distribution systems.

It is true that flicking the switch for a light is easy for the user. That does not diminish the need for the user to install the lightbulb for the required wattage, hire licensed electricians to wire the house, a distribution network to be built and maintained, and generators of a variety of types (gas, coal, solar, etc) to provide electricity, all billed according to use. The variable individual demand throughout the day is aggregated and smoothed, allowing matching of supply to predictable demand trends based on time of day and year. Almost all people use the same electricity. There are some with exceptions such as 3-phase, generator backup or local solar feeds. Standards ensure safety and reliability. That is the same for many of the emerging ‘utility’ elements of ICT. 

If the benefits of information and collaboration technology depend on everyone understanding and appreciating the backend complexity we (as professional technology experts) aren’t doing it right. It may take several years, but we have to start planning and implementing now.

Conclusion: the word is packed with meaning and should be used in a positive context – the transformation of user experience. Utility is a concept and a word that is rightly here to stay.

A parting thought: commoditisation doesn’t just apply to ICT. Many industries are facing the same challenge. Look at the content debate for Higher Ed and globalised online learning.

What other words can we use to describe the trend toward commodity services and utility computing?

When it walks like a duck and talks like a duck

Abstraction is a funny thing. When it walks like a duck and talks like a duck it may be a duck, but not necessarily the same duck as yours. The Greater Scaup is a diving duck that feeds underwater while the Mallard is a dabbling duck, eating from the surface. Both walk and talk the same but specialise in living in different worlds. The flip side is that in the end they are still both ducks. There is a good chance they both swim in a pond and will eat snails.

The same goes for IT. The trick is working out what level of abstraction is appropriate for your purpose. The owner often thinks at the level of species. The enterprise system administrator is usually thinking at the family.

My approach:

  • Be clear about the purpose;
  • Meet in the middle-ish: is it enough for the duck to swim in your pond and eat their mealworms?

I-C-Dead People

The movie 6th Sense has a classic one liner. The young boy whispers to Bruce Willis “I see dead people” and our spines shiver. Then, unexpected until the last moment, comes the the head imploding twist: our protagonist was in fact one of the dead people and didn’t know it.

So what does that have to do with information and collaboration technology?

Disclaimer: The views expressed are my own with respect to industry changes over the next decade.

In my Questnet 2010 presentation Where, Why? I concluded with a look at how the current ICT functions in an organisation might change over the next decade. Helping people informate and collaborate will become the focus. The technology role will be, well, dead. OK, not dead but at least shifted to another plane of existence – among the clouds.

What to do? Mark Tigwell from Microsoft shared many ideas during his (15 minute!) lightning talk at CloudCamp Perth last year. You can watch it here.

I am not a career advisor so don’t bet your house on what I say, but this is my approach:
Be alert, not alarmed: This is not happening tomorrow so there is no need to panic. Significant change is approaching, for some roles sooner than others, and ignoring the trend is not a path to success;
Conduct your own review and create a career plan: Take responsibility for directing your own career where you want it to go. Get advice from your managers (immediate and above). Look at trends in your line of work, particularly with respect to cloud services. Do you want to stay with the organisation or the technology?
Get the appropriate skills and experience: Within an organisation like a university you need to be able to communicate with members of the ‘business’ (research, learning/teaching or administration) with the aim of problem/opportunity identification, definition and solution (through others), or have technical skills applied to niche business problems. To stay connected to the technology identify which platforms are growing and companies are active vendors/implementors/providers. Being independent is definitely an option in the age of apps.
Bail out: Trying something else is always an option. Don’t underestimate the value in changing career direction. Problem analysis and solving skills are valuable, especially with the ability to communicate and collaborate. I almost became a carpenter 5 years ago but that is another story.

With all that said, many thought COBOL was for zombies. Who would have thought being the living dead could be so lucrative.

Curtin’s QuestNet 2010 Road Trip

In July 2010 three colleagues and I went to QuestNet 2010 at the Gold Coast to present. A theme running through all of them was the cloud story of Curtin Uni.

Most sessions were recorded by the event organisers. I also took a recording of each of our sessions using the Cisco FLIP camera provided by Dimension Data. The recordings are now available through Curtin Uni’s iLecture system via the links below. I have combined the slides and video for mine whereas the others have talking heads with the slides downloadable.

Disclaimer: This is not a blog about the semantics or viability of cloud. There are a lot of definitions and I take a broad view to capture the diverse thinking and implications of a number of trends. Opinions expressed are my own. 

Desktop 2010 – What, Why, How (slides.pdf)
Ben Doubleday talked about the experience of developing the Windows 7 Managed Operating Environment. This is the starting point for preparing users and Curtin IT Services for the anytime, anywhere, any device vision for applications and information. To use the cloud analogy this is the rainbow of options which connect users to their information and applications (and making sure everyone has an umbrella?). 

Curtin’s Cloud Infrastructure Strategy (slides.pdf)
Steve Lim explained how and why Curtin IT Services implemented EMC Avamar as a hosted backup solution for enterprises systems, dramatically reducing our storage footprint and greatly increasing system performance. This is the cumulus cloud which provides a sturdy foundation for service delivery.

Microsoft Cloud Platforms (slides.pdf)
Heath Wilkinson discussed the benefits of Azure as a platform which Curtin continues to expand into. This was in the context of a roadmap for porting components of the award winning iPortfolio, having already migrated to the Live@EDU email system for students. This is the cirrus cloud, fast moving, adaptable and streaking across the sky.


Where, Why? Toward QuestNet 2020 (slides.pdf)
I wrapped it up with a look at how the purpose of computing has changed in organisation over the past 30 years and what the current trends (especially cloud) might mean for the next 10, generally and from the perspective of those of working in ICT services in universities. This was a forecast of meteorological conditions based on past data and satellite imagery taking in the whole picture. This recording has the video embedded with the slides 

Each is about 25 minutes.

We also did a live video conference (recorded) cross to the monthly CITS Insights Seminar with Mark Tigwell as an invited guest. Mark also presented at QuestNet 2010 about Microsoft’s Roadmap for Cloud Services and Unified Communications.   
  
I will expand on the ideas presented in Where, Why? in blog posts over the coming weeks.