Enabling Research and Learning: Themes and Variations Driving the
Evolution of our Enabling IT Infrastructure MUSC: 1998 - 2006, Duke-NUS
(Singapore) 2006 - present
My fundamental assumption:
Our university family is a mix of senior and junior learners where senior
learners assist junior learners as they prepare for a productive career.
A well prepared junior learner know what he/she does not know and also
is a skilled problem solver.
Within university communities, I see
no reason to distinguish between students, patients, faculty and staff.
Problem solving is facilitated when resources are within reach of wherever you
Said another way, data/knowledge transport enables the end uers to do
their job, be it learning, processing a requisition, treating a patient,
solving a research problem or repairing
a motor. If I am successful in facilitating the transport of data to a
member of our university family thereby enabling the
end user with all the resources required to solve a problem, then I'm pleased.
The IT Lab was my response to our IT outsource contractor at MUSC.
My experience is that outsource contractors are often
driven by what was convenient which can lead to a rather disabling
IT infrastructure. For example, when I arrived at MUSC,
here was no supported off campus access to the MUSC network,
databases were inaccessible and there was a rather rampant ignorance of
what the Internet in general and specifically internet-accessible
web resources brought to the learner's table (whether researcher,
junior or senior learner). The rational for not supporting off campus
access was that there were insufficient support staff. While a dial-up
service was available, the outsource contractor perceived that without an
adequate staff to support off campus computers, it was better not to provide
the service. There was no measure of "adequate" staff and apparently,
our outsource experts felt that off campus access to MUSC was so different
than off campus access to any commercial service that it could not be supported.
The IT Lab and its activities were my tools for building enabling IT resources
that were accessible by all members of the MUSC family. The IT Lab provided
and alternative to our outsourced contractor and provided proofs of concept
that displayed to the university community that many "perceived" obstacles to
enabling the MUSC IT infrastructure were just that - perceptions that were
not supported by data acquired through proof-of-concept experiments.
We were driven by issues raised by the Provost and other leaders within
the Provost's office. The success of the IT Lab was a result of not
only a group of very talented individuals, but the chemistry of our
work environment and our avoidance of hierarchical management. Many of
the items below were obvious after they were articulated - but articulating
them was a challenge.
- All our effort must be directed toward building a univerity (MUSC)
that was greater than 6 colleges + hospital
- Our infrastructure must be enabling, not disabling
- Our infrastructure must amplify the innovative potential of students,
faculty and staff.
Shifting Innovation with Toolkits)
- We must facilitate learning, not teaching
- We must facilitate patient care, not diagnosis and treatment
- We are problem solvers, not workers. This means that there is
no boundary between learning and doing. Learning is an integral part
of problem solving. Thus, continuous learning happens because of the way
we view our job; that of solving problems (and enabling others).
- We must partition each problem into two components: a data
transport/data management component and a process (business, learning etc)
process. We strive to resolve the transport/management component within
a few days, realizing that enabling the process requires longer because of
collaboration between the IT transport specialist and the
staff, student, faculty specialists.
Solving the process part of the task is facilitated by the immediate
availability of a rapid prototype that displays the required information.
- We must reach out to the community and enable them as affiliate
members of our family. I am involved with
Frierson Elementary School and exploring how to
ignite the curiosity of young learners.
- We must craft our web pages to facilitate learning. We have
struggled to achieve this goal with
the IT Lab web site . Rather than
a web site of links to our resources, we want our site to be a place where
one can learn about our ideas and how we
develop them with prototypes. I have explored different strategies
for sharing insights and igniting curiosity
via my web site with varying
degrees of success.
- We must publish both documents and abstractions via
RSS. Why? RSS provides
automatic notification of web site changes, saves clicks
and avoids your having to remember URLs of linked stories.
- Automatic harvesting web resources followed by display of consolidated
saves clicks and avoids remembering URLs. In other words - you can retarget
brain energy from clicking and remembering to thinking and problem solving.
Our Atlantic and Pacific Weather
pages provide one stop shopping for approaching hurricanes and cyclones.
- We are problem-driven, not tool-driven. We focus on clear
articulation of our colearner's problem. Specifically we want to
understand whether resolving this problem will lead
to an action. Problem solutions that do not lead to an action are
less useful than solutions that lead to action.
If the problem does lead to an action, then we push to understand
the input to the problem, the output and the action. Sometimes the
solution will result in reengineering an existing process
(and possibly not an IT issue, but we must accept
the role of messenger) - other times the solution will identify the need
for a new process. At all times, we do not expect the learner to
articulate an IT solution. Rather we want to understand enough of what
the learner is trying to do so that we can craft an acceptable solution
that meets the need.
- We harvest resources from internet-accessible locations. Whether
software tools or domain-specfic information, the idea is to either
manually or automatically harvest what is available and build on
a foundation of harvested products.
- With our knowledge transport tools, we strive to demonstrate to
the end user the data/knowledge transport component of a problem
within a few hours or at max, a few days. With a web accessible prototype
that displays the requisite data, we put our student, staff or faculty
colleague in the driver's seat and enable them to identify the process
issues. Together we activate the process. This strategy achieves
two important goals: The end user becomes the rate limiting step in solving
a problem, so IT schedules are, for the most part, unnecessary. Because
the end user is in the driver's seat, identifying the process issues and
assisting in evolving the prototype to a finished product, there is no
need for training. Training occurs as part of the development process.
- We must build our activities around data repositories created
by our institutional systems systems (finance, hr, patient care). We must
construct our solutions with compositions of tools,
and minimize building new systems wrapped around core systems.
- We must base actions on data, not speculation
- Experiments are ok - they produce data. Committee discussions are often
of marginal utility - and can produce speculation and fantasies
- We must accept 80% solutions - simply because there are no 100%
solutions. Why? Because we cannot predict tomorrow with 100% certainty.
- We must grow our infrastructure - not roll it out . MUSC
will not remain stationary while we prepare what we roll out.
- We strive to craft a prototype solution within a few hours or days
after understanding the problem. Typically we start our project with
one IT labber and a single member of the MUSC family. This prevents scope
creep and facilitates rapidly engaging the user. Because we are tool based
and problem driven, our solutions are suitable for changes in the problem
description as the user gains experience with our prototype. Typically,
we seek to avoid problem specification with a large (> 4) people
simply because it makes the prototype impossible to develop. Similarly,
its much more difficult to engage 4 users in the prototype than to engage
a single user.
- Our IT infrastructure is standards based and provides
core web-accessible services including email, shared storage, web services
and calendar services
- Our infrastructure must facilitate exchange of knowledge among local
and distant learners by email, voice, video and data.
- Our infrastructure must facilitate transport of knowledge from
resources to your desktop
- We must enable students, faculty and staff (here I'm referring to
the traditional characterization of any university) to manipulate
knowledge we transport so that they can produce the documents they prefer
- We must take ownership of our problems -
not implicitly or explicitly assign them to a nebulous third party "they".
- Our infrastructure must serve the role of coordinating distributed
- We must have a group of energized, creative and out-of-the-box
thinkers and prototypers that can outline the direction for tomorrow's
production work. Within the
- I am the senior learner and I have 7 serious
junior learners. The junior learners are free to provide me with their
best insights and can make no mistakes. If non-IT labbers
we made a mistake - then its because I directed the effort and therefore
its my error . This results in a group of hyper-productive and
self-directed individuals - as the results below indicate. Our deadlines
are continuous because we are growing solutions to meet someone's need.
The best growth occurs when both the IT labber and the needer are actively
Themes Driven by Compliance and Security
- We must realize that we are increasingly compliance driven
(FERPA, HIPAA, FDA good laboratory practices,
medical reimbursement, IRB, Risk Management) and our
infrastructure must support rapid development and deployment of
compliance-related sensors and centralized monitoring of these sensors.
regulations from on high
- Unfortunately, people misbehave and violate our implied trust. Thus
we must evolve a risk management strategy with respect to the security
and integrity of our network infrastructure and associated information
repositories that does not seriouly impede getting the day's work done.
- Then there is malware (viruses, worms etc) that are released into
the Internet wild. We must aggressively scan for vulnerabilities
and educate students, faculty and staff about the risk of infection and
the resulting loss of network integrity. We must view our policies
as similar to public health policies. A child will not be admitted to
the public school without proof of vaccination. Similarly, vulnerable
computers will be disallowed on our network if vaccination is not
- We must engage all members of our family to accept more responibility:
- Curiosity is rewarded - if you don't understand something, the
chances are very good no one else understands it either
- Committees generally produce consensus results - that often
lack originality and creativity. Individuals often produce original and
creative solutions to critical problems. Committees operate on a time
scale dictated by the slowest member of the group. Individuals work at
a much faster rate by avoiding the consensus process.
Committees diffuse responsibility
and ownership of problems and solutions to the point where often, no
one can fail and no one can receive credit for a success.
Clearly, I accept that group processes have their place - but we
seem to opt for group processes over individual processes
- We must accept the culture shift required to realize a transition
away from dependence on our IT infrastructure
to prepare reports and documents to our preparing our own
reports and documents. In a business sense, depending on IT for report
generation (except for routine stuff) is a cost shift from ourselves to
the IT group. It really does not make sense to place report generation in the
hands of a $100k programmer instead of a $30k junior learner. We take our
enabling role very seriously.
- Information available from our infrastructure is confidential
- Information entrusted to me, on my desktop, laptop or PDA
is my responsibility
- Learning is continuous. Asking google.com before you ask a
colleague facilitates continuous learning
- Share your knowledge with others
- Internet memory is more reliable than our biological memory.
We must focus on developing tools that facilitate access to specialty
knowledge. Google is a good
example of enabling a junior learner to access facts and concepts from
the world. Differentiating quality information from trash
requires an internal absurdity detector -
a new skill essential for internet-centric living. As an infrastructure
component, we must facilitate learners in our institution with separating
good stuff from junk.
Our action plan for migrating to our Internet-centric paradigm
- Our major obstacle to change is cultural, not technical.
Every trick we identify that helps us overcome cultural obstacles must
to be shared with others. Someone probably should keep a list of
specific cultural obstacles we encounter. The
IT Lab Wiki is the latest
step in sharing ideas and insights. Our wiki supports collaborative
writing by many members of the MUSC family.
- We shall use repetition to help others understand what
we are doing. For example, we are rebuilding the MUSC web site. The
central theme of uniformity will be achieved by using either the
internal or external hat that will facilitate navigation
across MUSC resources.
- Lead by example: A major challenge is to figure out
how to change a report-expectant group of users to shift to a
do-more-for-yourself perspective. Since we don't know how to do this,we
must take ownership of each user's individual needs and
out how to shift the needs from report-driven needs to knowledge
transport needs. My notion is that after we work with 10 or 20 early
adopters, we'll begin to see general trends that will lead to how tos,
tutorials and perhaps instant messaging-like help resources. I believe
that the majority of our solutions will involve report generation
using Excel or something like Crystal Reports, driven by data transported
by our tools from a database to your desktop. Thus we need to accumulate
examples of "how I generated this document or how I generated this report"
- We'll start with early adopters. This means that our initial
efforts will be focused on helping the Finance division realize their goals.
Lessons learned within Finance will be made available to the hospital and
- Our transition will be incremental, with a minimum of
formal training and a maximum of co-learning. IT-enabled folks will
be the senior learners, and our non-IT colleagues will be the junior
- Succeeding with a few early adopters will encourage
others to follow (by example). We need to find a way to reward
early adopters and early followers.
- We need to help our co-learners to understand thinking,
learning, analysis, and doing in an internet-centric setting. We are all
learning as we go along. Learning to effectively use google.com
appears to be a new essential skill for an internet-centric workplace.
- Implementation schedule: At this point, we are using our
early interactions with the Finance division to guage the time required
to overcome cultural obstacles and shift our activities to internet-centric
workflows. I think 2-3 weeks/application is a good initial guess.
Our progress depends on the number of senior learners we can dedicate to
the conversion. The
more senior learners we can invest in the transition, the more parallelism
we can generate in our conversion and the faster we will become
- more later - because this is new territory for me
Our results to date
- I established the IT Laboratory
as a forward thinking group of innovators that are charged with developing
internet-centric, browser-accessible tools that enable our students
faculty and staff to transparently transport knowledge units from a
variety of resources to their desktop. This transportation function is
the key to our transition to an internet-centric university.
IT Infrastructure Policy Richard has a number of works in progress
Computer Use Policy An agreement signed when a network
account is established
Richard's survey of wireless infrastructure issues
Our MUSC web site for external folks Collaboration led by Brian
and Brian. The navigational hat will
appear on all primary MUSC web pages - its what tells someone from
the outside that they are dealing with a university not 6 colleges
and a hospital. The left side-bar is for department,
division, center, lab, or personal site navigation
Our MUSC Portal - customizable for individual
needs Brian has at least one good idea each week. This was his best.
An internal navigational hat that will appear on MUSC sites
that are predominantly for internal use. Our portal provides a platform
independent way of accessing institutional resources from anywhere.
Moreover, it provides a way for individuals to adapt the content box
offerings to their specific need
- Tools to check spelling, check status of Purchase Orders and Requisions,
access the paging system, track contents of open source repositories,
security alerts, etc: see
myMUSC content blocks
- We are building libraries of tutorials to facilitate learning
Our information location and transport tool Each website reflects
a web interface to either a legacy or current database. The search
engine permits asking simple questions - our 80% solution. More complex
questions can be asked via a GET pointed at the search engine. Data
transport is available as either HTML, text, Excel format or with XML tags.
Brian translated my ideas into reality with the trick of changing the mime
type (another good idea) to facilitate tranport of data to an
A web accessible IMAP mail tool from Matthew, who is always a step
ahead of all of us and a minimal function (no folder management)
IMAP email resource. When our primary mail server died - Matthew, OCIS
and the IT lab had a backup operating within 12 hours
Josh, (an IT lab graduate) built our suite of tools for building web
accessible interfaces to institutional data repositories.
mySiteMaker: An overview of our data transportation project Josh
crafted this as our workhorse
web interface for database retrieval
Our approach to workflow management Brian started this, Christopher
picked up the ball and jabberized it - a major major tool for MUSC
Automatic notification: enabled by combining RSS with workflow
with Jabber Christopher made this a reality and demonstrated how
to facilitate communication among IT labbers and MUSC. Authentication
is based on our authentication daemon
- A survey tool
Matthew found this, pressed the development group and became a developer
- What do I do? I'm the cheerleader!!!
This work is licensed under a Creative Commons License.
C. Frank Starmer