CSG Winter 2013 – The Changing Nature of Support #3 – the Cloud and BYOD

Erik Lundberg (Washington), Bill Wrobleski (Michigan), Carol Craig (USC)

Cloud impact on support – our role is changing from provider to broker; support services need to react more quickly as the cloud enables speed to elivery; cloud introduces confusion around boundaries of authority.

Bill notes that they can tell users with issues “google just doesn’t do that”, but executives aren’t willing to hear that. 

Erik says that using cloud providers should save energy somewhere, perhaps in third tier engineering. 

We need people with the skills to program various APIs to integrate cloud and on-campus solutions together. 

User migration to cloud services can take a long time, and if you turn it into a user-run pattern it becomes a support burden. 

BYOD – Steven Sather (Princeton), Russ Kaurloto (USC), Marin Stanek (Colorado)

Embrace the drench!

ERP systems don’t support a lot of heterogeneous devices – how do we address that?

Within higher ed we’ve always embraced students bringing their own devices – unlike industry.

USC – ~2.5 wireless devices per person; number of wifi APs – 4,518; Number of simultaneous connections: 26,751; peak video streaming: 2.9 Gbps (on wireless only).

Devices (one typical day, just registered devices): 13 Roku; 79 Plastation 3; Apple TV 867; iPod 3,068; iPad 5,187

Network architecture considerations: wireless priority over wired – the new norm? should we still do end station wiring? multi-tiered segmented wireless networks? cellular DAS network overlays? SDN (software defined networks).

The time to delivery of support materials is shrinking and the number of devices people are using is huge. 

How do you structure the support organization to very high touch support for a set of VIPs and support BYOD for the masses, and how do you structure funding for that?

It’s now everyone in IT that has to do customer support. We’re consultants more than we are solution providers. 

Even if we can’t resolve the problem with cloud providers, if we communicate around it people understand and may be satisfied – at least for students. Not true for faculty and staff. 

Will the Knowledge Base of the future be forums where the crowd can contribute answers?




CSG Fall 2012 – Balancing Central and Distributed Services

Bernie Gulacheck from Minnesota is leading a discussion on Central and Distributed Services. This is not a new topic, but the context has changed. We’ve seen the delivery of technology services change over the years. In the late ’80s and early ’90s distributed service units in Libraries, Administration, Academic Computing, were amalgamated into central IT units. Then the conversation shifted to the current landscape of distributed technology units and a central unit. The model along service continuum was often new technology emerging in the distributed units and then later being centralized for economies of scale. The cloud shifts this dynamic, where both central and distributed units can shift or bring new services into being in the cloud.

We’d like to believe that each unit that manages its own technology services is focused on its mission so as to create complementary and not duplicative services – sometimes that’s the case, sometimes it isn’t. What are the elements that facilitate this model? One comment is that what works is transparency – letting the deans and administrators know what is being offered centrally and going through the services each school is offering to see where there is duplication. The service catalog was very important in making this happen. Making that visible allows the conversation about efficiency and making sure that the quality of central services is acceptable to the schools.

Cornell has a structure where the distributed technology leaders also report in to an associate CIO in the central office – they are learning how to build the trust and efficiency in the group. They are building a brand of IT@Cornell that encompasses the entire concept, and that’s starting to work. The services organization is trying to lower cost and maximize efficiencies in order to provide the best service possible to demonstrate the utility value of central services so they don’t have to be duplicated locally.

Kitty notes that we have to be conscious that some services can only be delivered by the person who sits right next to the user – need to know the people, who’s got grant deadlines, etc. Also it’s a challenge for us to make core services easy enough to use.

Bernie notes that often the cloud services are superior to what we can offer, but the factors preventing us from moving in that direction are some of the same factors that prevent the distributed units from moving services to the center.

Elazar notes that trust is a key factor – they’re rolling out a new desktop support environment that will cover the whole institution, and it’s the same with consolidating data centers. Ron Kraemer notes that little things count – like referring to services as the “OIT” data center instead of the “Notre Dame” data center.

Tom says that the ability to present central services as something that distributed units can just use, much as they do the cloud, is important.

Sometimes the actual consolidation of services, even when everyone agrees it makes sense, can be perceived as threatening people’s jobs, which makes it hard to make progress.

Tracy notes that the more you can include people from the units within the central organization as much as possible can help build the relationships. Also you have to build a story and stick to it that gives people hope and a sense of purpose – where is the evolution of their position?

The concept of the say/do ratio is important – ideally would be 1:1.

Developing soft skills in the organization is important.

Bill notes that they started something called the Stanford Technical Leaders Program, where they brought in MOR to help build skills with 13 technical people from the central unit and 13 distributed people from around the campus. Last year they put on an un-conference, and registration fills within minutes after they open the web site. Once it gets to management it’s a failure – want to build the soft skills and the relationships.

It’s important to be honest that jobs are shifting and new skills will be needed – it won’t always be possible to retrain people, and in some cases groups will shrink.

At Brown they looked and found that they’re 49% central and 51% distributed, and in many cases the distributed people are being paid better than in central IT.

Tom notes that governance has helped, but that inputs from distributed units hasn’t always come through those administrative processes. Being able to prioritize and schedule work realistically is important.

Bill talks about “getting beyond polite.” He was told that that his (Bill’s) presence in the room was too loud, and without him in the room the discussion gets more down to earth.

I noted that often people ask for the help of the central unit in solving problems but we don’t have the capacity to deliver help in a timely manner. Bernie then asks what happens when we build services that have been requested by the distributed technology services but the units then opt out and complain about cost increases? Chuck has found that an effective technique is to let the unit lead the project and be responsible for end-to-end including announcement can be effective. Ilee says that making sure that the distributed units are involved in the definition of the services and that having a way to communicate with the deans is important.

Where we’re still in hot water is where we’ve over-promised and underestimated the complexity of replacing local services with central services, which burns our goodwill chips. We don’t want to stifle innovation in the units.

There are often pressures on the CIO to optimize cost in IT, but deans and other leaders can be hesitant to have conversations about the steps necessary to achieve those savings.

It might be possible to give schools score cards about where they are in comparison to each other and central units – has to be done independently (e.g. by the finance unit). Can help deans make decisions on how to allocate resources.

Having visibility into all the IT requests can help people understand what is happening and alert people to potential duplications of effort.

At one institution they don’t use the word “distributed” but use “federated”.

One person notes that if you have distributed people also report in to the central unit that you let the units off the hook a bit – can be a double-edged sword.