Location:

Synchronized Swimming

Created by Theresa Rowe (Oakland University) on November 26, 2007

I'm swimming in synchronizing challenges - maybe better said as "the challenges of synchronization."  One of our emerging IT skill sets is the "expert of synchronization."  This has come at us several ways.  The first was the Blackberry infiltration and the desire to synchronize a calendar on a hand-held to the master appointment calendar on a desktop.  Email came into this too, but it seemed easier, often one-way.  Two-way synchronization of something like a calendar is more troublesome.  Of course, this synchronization requirement emerged after we had implemented a new email and calendar system, and the product we are using just hasn't made this easy.  This is also complicated by the consumerization of the environment brought on by IRS tax rules, making all those cell phones personal devices and purchased to personal choice. 

Which brings me to one perspective on the issue:  Our clients are increasingly the student and faculty - the individuals - making personal technology choices.  Michael Hites of New Mexico State University describes the "self-enabled, free-to-download, creative-minded user" and Shelton Waggener describes the "rise in technology controlled by the individual" in the Nov-Dec 2007 Educause Review.  These individual choices come to campus, and we are expected to provide the synchronization solution - for a hand-held device we haven't seen before and for which we have no control.  We can't train on everything, so our support model changes from trained staff provided proven and tested solutions, to resourceful staff who can figure it out.  We prefer things that are web-accessed on from handhelds, which has been more successful to support, rather than synchronized.

Synchronization is pushing at us in other ways.  Several of our vendors have pushed to "own" our identity management infrastructure:  the email vendor, the ERP vendor, Microsoft's push of Active Directory, Oracle's push of the OID structure.  Sometimes we have one solution coming at us different ways, like Oracle through our ERP and Oracle again through our portal (which is a separate product from our ERP. The end result is that we have multiple identity management structures, and we've implemented one authority (LDAP) that is not tied into any one product. We now have to integrate or synchronize or at least establish communications among the structures.

We've found that request-based integration is the most reliable to support, especially over time and through product upgrades.  This is where we've designated a home-base as an authoritative core that is not connected with any product, and other systems send an authoritative request that simply requires a yes/no response from the authority.  After that, a one-way synchronization can work, such as sending our authoritative LDAP entries to populate or depopulate OID.  Finally, and only if we can't avoid it, we'll consider two-way synchronization (we've been able to avoid that so far).

The synchronization monster has turned out to be our ERP database.  Our ideal is a primary server in the main location, and a stand-by system in a remote location, with the remote location updated real-time with data updates synchronized across both systems.  We've found this to be a difficult item to manage and very costly to implement.  Data increasingly seem to live in multiple environments, too, requiring more integration strategies.
Synchronization is now something we are routinely looking at when we evaluate and analyze a new service.  How are login identities managed?  Are data updates exchanged?  Which data elements are integrated?  How are data updates across systems managed?  How can we manage Noah's Ark (two-by-two) for disaster recovery?

 

A few principles are emerging:

1) Handhelds need to be receiving devices with updates done via web-based applications, rather than later synchronization.  That "synchronize later" seems dated and unreliable.
2) We always need to determine and document the home authority, for logins or data, and feed from there. This requires ongoing documentation and testing.
3) Request-based from a client to home seems to be the easiest to manage.

 

From an IT staff perspective, we haven't perfected our educational strategies on staff development to support this environment. We do believe that:

1) Resourceful people comfortable with playing with technology, rather than working from established road-maps, are best at supporting the environment. That means some work that used to be handled by students at the Helpdesk now needs to go to professional staff.
2) Integration needs to be fully documented, with home authority named, data elements identified, and technology defined.
3) Understanding how to test when one side of a synchronized product is updated, or a new product is introduced, is a necessary skill.
Submitted by Theresa Rowe (Oakland University) on November 26, 2007 - 11:58am.

Michael Hites of New Mexico State University describes the "self-enabled, free-to-download, creative-minded user" and Shelton Waggener describes the "rise in technology controlled by the individual" in the Nov-Dec 2007 Educause Review.

Increasingly we are seeing products purchased by individuals coming to campus (probably starting with the home computers and video games in the Res Halls).  But even some of my own staff have come to work with their own laptops.

And services are increasingly defined by individuals, with expectations of niche-marketing and customization.

How are you giving this direction consideration in your strategic planning?

 

Theresa Rowe Chief Information Officer Oakland University


 
© Copyright 1999-2009 EDUCAUSE