MARIA DAMON: Thank you for
clearing that up so nicely
about the front stage.
So continuing with
our theater metaphor,
we have actors on the
front and now we're
going to talk a little bit
about how people do interact
with that data.
So after talking with a lot
of partners across campus,
we realized that
there were essentially
three types of actors.
There are the end users who
are our individual learners,
our faculty, and staff who
are not really technical.
There are the technical users.
The developers, the
system administrators.
And then there's this hybrid.
The administrative users
is how we're calling them.
They are somewhat technical
but on the whole not.
They do advising and they're
business process owners,
et cetera.
So throwing out
there for feedback.
These aren't solutions that
we're promising to deliver,
but we're considering
some different ways
that these separate
types of actors
might interact with the
interoperability tools
that we've been
discussing earlier.
So first, for the
technical users
we're considering some developer
tools, a developer portal.
For the administrative
users, who are that blend,
we're talking about an
integration concierge.
And for the end users, an
improved login and profile
experience.
We'll begin with the end
users, with login and profile.
And these are individual
learners, faculty, and staff.
So we'll consider a
scenario with Mary.
She is a first-year student
and has an interest in geology.
She attended a camp before
college at UW Madison
and forgot her NetID
that she was issued
at this pre-college camp.
So when she applied,
she got a new NetID.
Additionally, she used to
go by her middle name, which
was how another NetID
was issued to her.
But now she's corrected
it so, if you'll advance,
she now has three NetIDs.
And her father contacts
her to get her NetID
so that he can log in
to her student center
to pay her tuition bill.
So the landscape for
NetIDs is very complex.
We have identity record creation
occurring in multiple systems,
and they're opaque.
The errors can result in
multiple NetIDs and people
like Mary can't
self-assert identity.
It's the HR Department
or the registrar
that is entering her identity.
Some departments know
some things about her.
So for example, at source
she mentioned that she
had an interest in geology.
The geology department
does not know that.
SPEAKER: [INAUDIBLE]
introduce you?
MARIA DAMON: Sorry.
My name is Maria Damon.
I'm a user experience
researcher in the UX team.
SPEAKER: [INAUDIBLE]
MARIA DAMON: Thank you.
All right, so the first
idea that we have.
This first interface that
we're throwing out there.
Allowing users to easily
create an account.
Enable affiliates,
so people either
like Mary who as an under--
or not even undergrad,
as a high-schooler, decided
to come to a pre-college camp,
could create an account.
And people, affiliates at UW
Health who aren't necessarily
in the university proper,
allow them to enter and use
their own information.
Secondly, establish a
profile for each person.
So part of creating an
account is creating a profile.
Mary knows to go to MyUW and
enter her profile information.
It's a single place for her to
view and modify and configure
her preferences and
privacy settings.
In this she might,
in her preferences,
indicate that her father
is an authorized payer.
This would reduce complexity
and create faster integrations
with person data, which
saves time and money.
And as a piece of that profile,
one was an interest piece.
So she can indicate that she
has an interest in geology
so that the geology department
actually understands
that she has an interest.
Finally, since her
father was indicated
as an authorized
payer in her profile,
her father receives
a link that sends him
to a page that allows him to log
in with familiar credentials.
So summarizing the
login and profile.
A simplified account recovery.
Easier to reach new populations,
such as affiliates or parents.
Cleaner data through self-entry.
Mary knows her first name and
she knows her middle name,
so she's able to create
a clean record first.
And it's easier for
departments and advisors
to reach interested parties.
So moving on to our second group
of actors, the technical users.
We have developers and
system administrators.
Let's imagine a scenario,
keeping our geology theme.
[LAUGHS] So a researcher
in the geology department
made a very interesting
and exciting realization
this past summer.
While he was in Colorado, there
were some unexpected features
of rocks there that were
similar to rocks in Wisconsin.
And he has some eager
graduate students that
are going to help them
with this research,
and has contacted a developer
in the geology department,
and they are going
to create an app
to facilitate this research.
So this researcher needs data
from the [INAUDIBLE] rocks
in Wisconsin, he needs
the data that he collected
over the summer in
Colorado, and he
needs to give access to
specific groups of students.
This might not be as
straightforward as it seems
and we'll have a developer
come and talk a bit about that.
JARED KOSANOVIC: All right.
Hi, everyone.
My name is Jared Kosanovic.
I'm a developer with
enterprise integrations.
So I was going to talk about,
leading up to that example
that Maria started off, from
a developer point of view.
What does it look like to
integrate with another system
or get data from the university?
So right now some of the pain
points associated with that.
You have to start
from somewhere.
You've had a list
of requirements.
And you need to get the
data from somewhere.
So that might start with
an email or a meeting.
Go down a long rabbit
hole of who do I contact?
Where do I start?
And maybe you do go
down that rabbit hole
and it ends up being
a dead end and you
have to reverse back
and go another way.
Maybe when you do
eventually get to the data,
it's not abstracted, meaning
maybe you're integrating it
directly with the systems.
You have to learn specific
system terminology.
One side effect of that is
high maintenance overhead.
When you eventually do have
that integration interacting
directly with a
system, going back
to those point-to-point
integrations,
can have a lot of maintenance
due to small changes
in the system that could break
a point-to-point integration
downstream.
And oftentimes
there's a low amount
of documentation with the
data that you're getting out.
So it's hard to
know, once you do
have some sort of
integration going,
whether it's the
correct data or if you
need to vet the definition
of the data with someone else
before you start using it.
So if you want to go
to the next slide.
One thing Tom was
talking about a lot
was the idea of a
developer portal.
So these are a few
developer portals
from a few fellow universities
across our country.
And what this is, in a nutshell,
is a self-service web interface
to allow developers
and technical users
to integrate with data
across the university.
So one of the things
here that stands out
is it's really focused
around the idea of APIs.
So for maybe the
non-technical people
in the room, the
definition of an API,
one analogy I like to bring up
is the idea of a restaurant.
So think about you're
in a restaurant.
You're going to order some food.
And then there's the menu
and there's the kitchen.
Well, you don't go
directly to the kitchen
to tell them how to cook a
burger, to toast the buns,
to flip the patty,
cut the tomato.
You interact with a menu to
just choose, I want a burger,
and then the kitchen
does the rest of the work
and it comes up.
Hopefully eventually
secures you a burger.
So that's kind of the
same thing with an API.
You're not having to go
back through the intricacies
of a back end system to try and
manipulate and gather the data.
There's a menu of
operations that you
can perform on the
data, and you're just
interacting with that.
So if you want to
go the next slide.
This video should autoplay.
I was just going through
some of the developer portals
from the previous slide there.
So this is just going through
some of the workflows that
might be pretty common.
For example, this is going
to get some documentation
about a person API.
So I'll just let that
play in the background
and talk about some of the
benefits that this provides.
So one thing, when you
see these examples,
is that you won't
see in a developer
portal terms like PeopleSoft
or specific system
names on the developer portal.
It's all abstracted,
so you're either
focused on
integrating with data,
instead of integrating
with the system.
This has huge benefits because
now that it's self-service,
you don't need to
worry about going down
a rabbit hole of
contacting people
that might be managing the
system that the data provides.
You're just focused on providing
or integrating with the data
and that data has already
been abstracted and embedded
into an interface, a
menu of operations,
going back to the
analogy, that you
can interact with as a
developer to integrate that data
into your application.
It also has the
benefit for people
that want to provide APIs.
So if you manage a system or
if you're a steward of data
and you want to provide APIs
for other people to consume,
the developer portal allows you
to publish your APIs as well
as the documentation and maybe
some of the policies and access
processes around it so
that other developers can
come to the developer portal
and interact with that data
without a direct email or
communication every time
someone wants to get
data from your system
Let's see.
If we're going to go
the next slide here.
So one of the benefits, using
a specific example here,
was from our CIO, Lois Brooks.
A few of her initiatives
are for this idea
of business enablement.
One of the things that's
going to come out of that
is replacement of
the HRS system.
So when we talk about APIs,
one of the benefits we have
is since we have an abstracted
manual of operations
we can perform on data,
we're able to change
the system that's
providing that data
in the back end
with little or no
notice on the developers that
are integrating with that data.
So an example here.
We've got the current state
of apps, applications,
interacting directly with HRS.
During a transition state,
we can move to those apps
instead interacting
with an HR data API.
So this gives the benefit of
apps can interact with an API
to do the same business
processes they need to do,
but now the data is abstracted.
So that while the new HR system
is being brought up and set up
in the background, apps can
move to integrate with an API
at the same time.
And this is nice because once
apps do integrate with an HR
data API and we have
those common enterprise
business object
definitions of HR data,
the new HR system can be
brought on in the future state
to be able to
switch out from HRS
and those applications are still
interacting with the same API
to get the same data.
Going back to the
main benefit here
is that the system is
changing in the background
but there's little or no
notice to the applications that
are consuming the data.
I think with that,
go to the next slide.
I think handing back to Maria.
MARIA DAMON: So imagining
something like our peer
institutions have done.
Creating some sort
of developer tools,
developer portal such that
our geology researcher
can access easily
the students that he
needs to give access to that
This helps gathering the data
and also helps them fail
faster and succeed sooner.
So the developer tools
will provide consistency
for the APIs and standards,
as Jared was mentioning.
Making the APIs useful.
So not just having them,
but also making them useful.
It's a trust signal.
There's confidence that this
is the right API to use.
And the ability to try
integrations and fail fast
and succeed sooner.
So our last group
is our admin users.
The schools, colleges,
departments, advising,
business process owners, who are
somewhat technical but possibly
not.
So continuing with
our geology app.
It was a big success.
It's producing a lot of
unexpected and wonderful things
and the initial researcher
wants to contact
the College of Agriculture
and Life Sciences
for some of their soil data
and integrate that soil data
as well as expand access
to the application
for undergraduate students.
So if he's lucky, he knows
someone in middleware.
Otherwise, he'll
stumble around a bit.
There are no definitions.
You don't know how to know
who is a geology student.
Nothing is automated.
The identity data
integration is currently
how someone goes about this,
but those aren't intuitive terms
to search.
So after he does fumble
around and find this,
he submits an
identity data request
and fills out a Qualtrics form.
You can advance, please.
And then in one to
two business days
someone will contact
you in one to two weeks
for a consultation.
So this is the current way
that we have to go about this.
And it's confusing and
challenging and painful.
So our researcher needs
to know where to go
and how to ask for help.
So we can imagine something--
oh sorry.
So he eventually does
find the Qualtrics form
and he works directly with
CALS, the College of Agriculture
in life sciences, with a contact
to get a feed of the soil data.
So he does a direct integration
and they work out something
where they occasionally
make updates.
So we have this nice
fragile custom integration.
So a solution that we
would like to throw out
for feedback, again.
Some sort of
integration concierge
where you can access systems,
access people, provide data,
collect data, share
data, add a new system.
That our researcher is
able to expand the services
so that the undergrads
can access it and collect
the data from CALS that they
have so kindly offered them,
to the system.
Obviously we aren't the only
school to struggle with this.
So looking at some colleagues.
BYU has an InfoHub
where you search
a keyword for types of data that
you're looking for, or persons.
And then if you'll
go to the next slide.
So a concierge summary.
We are supporting
campus partners.
Using predefined populations to
enable campus to build quickly.
There is also clearer
communication.
There's less confusion
about what is a student.
This is a tool that is automated
and self-service and more
easily discoverable than a
Qualtrics form that, again,
if you're lucky you know
someone in middleware
or know the lingo.
Otherwise you are
fumbling around
for quite a while and
unable to fail fast, so.
Finally, we are giving
guidance toward these best
practices that we mentioned
early on in the behind
the scenes.
So the high-level
principles are sort of
built in with
accessibility and security.
