ландшафт. the exhaustion that was the combined CampusEAI Portlets2008 and Annual conference is now behind us, and it seems like time for some reflections and observations. Hopefully some of these items will be items which I expand upon at a future date, but in no particular order, dumped straight from my brain:

• JSR-168 is here! Everyone really wants to write good standards compliant portlets. Architecture and engineering is a harder sell (or at least the time/cost trade-off) but there’s wide consensus that standard portlets are the way forward — at least excepting a couple of us widget fans
• SOA is something people are interested in, but that there’s been relatively little forward progress on. Some is governance. Some is tools (SOAP, WSDL, and what’s this REST thing?). Some is just that it’s big and strategic, and there’s many tactical must haves. I suspect some of it is also that much of our interesting data/services are locked in vendor platforms that have shown little interest in opening up. Though, a small trend does exist of creating SOA-style services to reach into vendor platforms and extract data from them
• Mobile wasn’t as big as I thought it would be. Not sure why. Most people seem to be interested in the abstract, but with few concrete plans. Maybe my iPhone has clouded my vision, but I do wonder if we’re going to get blindsided come fall — our target demographic is basically 18-22 year olds, afterall…
• AJAX in portlets is still hard. There are some tricks like wrapper divs, namespacing, and builtin support and integration patterns, but it’s still not a common practice.
• Identity Management is big. Governance is a big thorny issue, though many IT departments are rolling out vendor products from big players (Oracle, Sun, a little IBM) in the interim, tho ugh the exact scope of those items is somewhat unclear.
• Oracle is really putting portlets in lots of interesting places. Webcenter. Product mashups. Inside BI tools, and other GUI devices. I think they’ve probably embraced the architecture more than any other major vendor which is an interesting trend.
• Lots of awareness, and wanting to look at uPortal 3. Ooohs and ahhs over both the AJAX D&D, and maybe more importantly the new content adding UI — good going Jen!
• Really beautiful portals — some, though not all new portals really seem to be breaking out of the lots of boxes approach, or at least wrapping it in neat functionality like Boston College’s Agora design. Nifty trend. Sign of maturity?
• Community Development is hard. Aligning roadmaps, agreeing on implementation strategies, and putting all the pieces together is challenging. Even more so, justifying “doing it right” (and fit to share) versus quick and dirty, or getting a student up and running was a big trend. Makes my inner-engineer quail, but my inner-economist says that throw-away code lowers the barrier for solving problems, which is a good thing. Evolution isn’t always pretty and all that.
• Lots of desire for training, best practices, and advice on policy and governance. Real role for communities of practice, not just code and software.
• Increasing interest in “Enterprise Learning Management”. Lots of worries about migration, but the beginning of seeds wondering whether our current platforms are sufficient for a foundation for the next 10-15 years, and University strategic goals. Of course, some of this is the “enterprise IT guys” getting pulled into the LMS discussion for perhaps the first time in many places.
• Good beer is key to facilitating interesting non-session discussion. Content is king on the program, but largely only because it gets people in one place and produces interesting spontaneous interactions. Hands-on is something everyone wants, but it’s not clear a conference composed of many 1 hour sessions is the right format to deliver it.
• University IT teams wear many, many hats.
• British Universities seem to have a much richer and more abundent IT project management structure than (most) American schools. Really interesting thread about Imperial College in London blending ITIL and Agile methodologies.

In general I think the focus of “enterprise portals” has always been one of integration and convenience, and as a result these products are moving towards being the place that knits together all the attention streams a user might have across the digital (and non-digital) campus. I think there’s a couple key use cases, some of which have more successfully been deployed than other.

1. One stop shopping (typical) + SSO
2. Summary Views & Aggregation

Less commonly actually implemented, though often talked about/pitched: 3. Dashboards 4. Actionable Intelligence (you have overdue books, return them!) 5. Deep aggregation (e.g. pulling in all the announcements from different systems and putting them into one stream)

In addition to portals focused on horizontal integration, I think we’re starting to see vertical integration around “portals” in Learning, Collaboration, HR/Admin, SIS, Libraries? and other clumps of functionality. Some of the goals around bundling related tools together are similar, but focused around a particular toolset, or context. At some point these could probably decompose into the “lots of tools/portlets in the uber-portal” that I think represented the portal thinking years ago, but I think the reality is market forces, as well as organizational and reporting structures make that unlikely to happen any time soon.

I suspect the interrelationship w a product like Sakai to a portal is mostly as a provider of information/data — pushing out items like announcements, scheduling, files in resources, and exposing them in a different context. Ideally if we shift our thinking more along the line of wire protocols (RSS, Real SOA, RESTful APIs) this I think positions us to also start doing “network integration” where Sakai can also start talking with and working with say Banner, or Kuali FS, or Facebook, or whatever platform. I’m very impressed with CARET’s mySakai work, and think John Norman’s vision on this is similar to the kind of plan I’d outline as benevolent dictator of the Sakai universe.

Along this line, I’ve scheduled another LMS-Portal integration BOF for JA-SIG and would like to use this project as the testbed for both a WG, and an incubated integration project within JA-SIG. I think a lot of the architectural level aspects should really span LMS’s — e.g. if we do it right, ANGEL, D2L, BB, and everyone should be able to use the same protocols, though Sakai seems an ideal reference implementation. I admit to being weak on knowledge of the IMS-spec side, and am not sure whether there’s work on that front we can leverage as well. So far what I’ve seen at least on the TI front has been less API/Data centric than I think we need to go though, though Enterprise seems promising.

One particular short-term item I’d like to see Sakai expose more broadly is the group contexts expressed in the form of class enrollments & particularly ad-hoc groups represented by project site membership. In many respects I think this is the most useful data in Sakai — it’s a social-network like context that integration with and hooking other systems into seems quite valuable. Enterprise grouping systems like Grouper while promising architecturally seems to have had slow adoption, and I suspect fitting systems like Sakai with something like OpenSocial or Google Contacts-like APIs to mesh groups together may get us farther faster in the short run.

The major new features of version 2.0 include: * Events – enabling a portlet to send and receive events and perform state changes or send further events as a result of processing an event * Public render parameters – allowing portlets to share parameters with other portlets * Resource serving – provides the ability for a portlet to serve a resource. * Portlet filter allowing on the fly transformations of information in both the request to and the response from a portlet

I have to admit I have mixed feelings on the spec. It certainly adds a number of features to facilitate inter-portlet communication, and messaging which were commonly requested. Part of me does wonder though if Gadgets, Widgets, and platforms like OpenSocial are going to leap past the Java Portal space. The aggregation and plumbing aspects which we’ve really focused on in many ways seem much less interesting than standardizing the data model behind obtaining presence, personal, relationship, and other data — something that the social networks seem to be moving full speed ahead on.

What Happened?

While it still feels a little strange to say it, as of 2 Fridays ago (2/8) I am no longer employed at Rutgers University. Over the last 9 years as first a student, then staff member, I’ve had the chance to: first study under, and then work with some incredible people. I’ve gotten to watch projects and services grow and evolve into solutions that are used every day by tens of thousands of students, faculty, and staff.

Before addressing my personal situation, I feel the need to speak a bit about the Rutgers Sakai deployment which up until now has occupied so much of my thoughts and energy. I was fortunate enough to see myRutgers grew into a service providing tools and services to every student at Rutgers. Sakai usage is currently somewhere on that curve, with usage growing by leaps and bounds. This Spring’s semester in many ways feels like a qualitative shift in the nature of the service — marked by a huge increase in the number of students asking “where’s my class’s Sakai site.” This semester these questions are particularly significant, as many of them are coming from students in classes where either:

1. Class was not yet in session. This is a big change from the dynamic in previous semesters where students typically visited the first meeting of their class, and were then directed to visit the Sakai site. Now students are looking to visit the Sakai site to see the syllabus, readings, and get a leg up on going to that first class.
2. Their instructor had not created a site. Sakai seems poised to make the jump into ubiquity, as in some students minds it’s already there.

Now to handle the really common question — if the Rutgers Sakai deployment is so clearly poised for greatness, where am I going and why? Well…

Starting this past monday (2/11) I have taken a position with the CampusEAI Consortium, where I will be serving as the Director of Open Source Solutions. Recent years have seen a huge upswing in the popularity, and visibility of open and community source solutions in Higher Education. Sakai, uPortal, CAS, Kuali, and othes have garnered attention, awards, and deployments. Due to significant interest expressed by member institutions, CampusEAI is looking to complement its existing strengths on the Oracle platform with broader offerings in the open-source space.

Answers to some personal-ish questions:

Are you moving to Cleveland?

No, I’m going to be based out of NJ, though Continental is certainly getting a good chunk of my time for the next few months as I schlep back and forth.

What does Lisa think?

She’s excited. Well, more excited when I’ve been gone < 2 days as opposed to > 3 days…

What do the kids think?

The kids are still getting used to not picking me up at Rutgers. They think it’s really funny that daddy works somewhere they can’t see. Sunday nights are hard. Phone calls are bittersweet. Coming back is good.

Aren’t you on the JA-SIG Board?

Yes. When my career change became definite I notified the board at the January video call. JA-SIG has always been a community of volunteers (stellar volunteers more often than not) and particular given my new employer’s willingness to continue backing my involvement in JA-SIG it was felt that there were no significant barriers to my continuing to serve in this capacity. As always, JA-SIG

So… is your Rutgers job open?

Yes. Though (see below) I’m hiring too…

What’ll I be doing?

So what does this mean in concrete terms? My personal definition is pretty simple. We’re looking to help members deploy solutions built on open source software. Given my background, Sakai, uPortal, CAS, and maybe even Kuali are obvious possibilities. I think however, that it’s a broader story than just support for deploying a few specific products. Many institutions have experienced challenges in building around open-source due to shortages in staffing or specific skill-sets. Others have successfully deployed open-source solutions, but been burned trying to deepen integration, or due to staff turnover (a problem which I should note also happens around commercial solutions). So the goal of this new unit is to make deploying solutions built on open-source:

1. Easy
2. Cost Effective
3. Low Risk
4. Sustainable
5. Did I say easy?

Basically the goal is to allow schools to leverage the strengths inherent in the open-source development model:

• Try before buy
• Rational licensing and cost-containment (instead of getting wracked with heavy licensing burdens as you get “too successful”)
• Open implementations, generally of open standards
• Economy of scale versus custom developed institution-specific software
• Freedom from vendor roadmaps and strategy shifts — even to go as far as obtain competitive bids from multiple vendors on the same solutions
• Peer interaction with really bright people working hard to solve the same problems you see

So that’s the goal. Make open-source easier, removing barriers for schools large & small — the kind of topics that have continually been commented on lists, in journals, and at conferences. Reducing installation pain. Helping with patch management. Providing support and training. Taking the pain and risk out of going open-source, all while working to make strategic contributions to enable the production of more good software.

It should be exciting.

P.S. Did I mention we’re hiring? Drop an email talking about your love for open-source, and how you really want to join in making it easier: jason_shao@campuseai.org. Oh, and mention you saw the posting in my blog

The Ed Techie: What Mailbox limits reveal:

Grainne posted recently about the frustration of continually getting the ‘Your mailbox is over its size limit’ in our OU email accounts. I can’t tell you how annoying this - sometimes I am just trying to send a quick response to someone before I have to dash out of the door, but it won’t let me because I have to find and delete any attachment over 2K to free up space. Grrrr.

(Discovered this site through the Edublogs Awards.)

It’s interesting to see the comments on the gist of this article — in terms of how reasonable the restriction or attitude behind it are. IT usage restrictions always seem to generate two separate camps of apologists and critics. Apologists focus on the rational behind it, the need to balance services with resources, and limitations of the technology or workflow. Critics tend to express frustration over inconvenience, limitations, or restrictions that make their work harder, or prevent them from performing a specific action, or in a particular way.

While I can’t claim to have a solution to IT limits (regrettably, my superpowers don’t seem up to the task) I do notice that we seem to have an opportunity for dialog. IT Governance is an increasingly hot topic, particularly with institutions struggling to prioritize during lean budget years. We clearly have a pool of customers who are more than willing to tell us what they think is important.

I think the need to create dialog highlights one of the reasons a number of us found Collier’s MyUMBC feedback feature so compelling. By integrating feedback submission forms into every page, portal visitors are encouraged to communicate their reactions and thoughts (even about email quotas ) making the barrier to contribution very low. At the same time, while many of us have feedback forms that email teams, the MyUMBC example of integrating the admin panel & tools to ease followup/contact make it easy to go back, and mine through the data, or engage customers in dialog regarding their experiences with the product or service.

I’m happy to say that Jenn’s work on the feedback portlet stemming from the JA-SIG Unconference seems likely to move uPortal (and maybe someday Sakai or other portlet containers ) further in the direction of built in mechanisms to collect these user sentiments and provide information so we can work to better address our users concerns, experiences, and frustrations.

Overall, the attendance, interest, and excitement demonstrated by all of the participants was pretty overwhelming. We had both more individuals, institutions, and organizations represented than we ever would have anticipated for an inaugural event. Even JA-SIG product deployers like Collier from UMBC and FLUID were well represented. While everyone undoubtedly came away from the event with different thoughts, two items struck me as particularly exciting.

MyUMBC

Collier demonstrated the MyUMBC work he’s been doing. While not uPortal based, the reactions related to the functionality of his portal ranged from “wow, I want it” to “you built that yourself?” to “don’t show that to my users or they’ll want it.” A couple of thoughts on why everyone in attendance found Collier’s work so compelling:

• Presentation: Collier threw away the assumption a portal must allow users to add/remove/re-arrange content. This dramatically simplified his problem domain, and allows him to capitalize on web-design techniques to tune his layout and presentation.
• Focus: MyUMBC is focused on end-user tools, not building frameworks. While in many portal project 75% of the time seems to be spent bringing up the platform, and making changes there, Collier spent 75% of his time building tools for news, events, favorites, etc.
• Integration: MyUMBC has a number of tools and concepts that serve to knit the experience together — the favorite stars, the dashboard on the start page, navigation cues all make the experience feel integrated
• Feedback & Monitoring: MyUMBC built a feedback system integrated into every page, and a lightweight dashboard to extract key statistics from that system. As a result, feedback is easy (~6000 in less than 6 months) and mining the data for trends is also correspondingly easy. This combined with standard tools like Google Analytics support a nice feedback-response loop while requiring minimal custom tooling.

Portlets

JA-SIG and uPortal have always been very focused on building out uPortal as a portal Framework. A consistent thread throughout the un-conference however (partly sparked by MyUMBC) is a bubbling thread of focusing on portlets and tools. I think there’s a growing recognition in the community that the tools are what users are visiting a portal for in the first place — and an area we have not focused as much attention on in the past.

In particular, collaborative efforts in the portlet space received a lot of discussion at several different sessions. LMS, SIS, Library, and other areas all seem to be places where schools have repeatedly re-invented the wheel. Collier’s demonstration of the return from focusing on tools, and the timing related to the talk on JA-SIG project incubation I think have all contributed to an atmosphere where people are highly interested in collaborating higher up the stack.

Update: I was reminded (and should have been more explicit in the original post) that you really need permission to distribute recordings of speakers. To clarify — I have recordings of most of the lightning talks, but certainly intend to email all of the speakers to ask for permission before posting. I had hoped to have real release forms available for the event, but didn’t quite make it — in the future events we certainly aim to have all our ducks in order in advance.

In fact, further than just being considered on par with packaged or commercial products, many, many people have indicated the message of “by Higher Education, for Higher Education” really resonates both within IT as well as with our end users. Ranging from solid support for integration with existing systems in uPortal, to teaching and learning as evidenced by the comment “It seems like EDUCAUSE is all Sakai” show a tremendous amount of attention and consideration being given for education build open-source solutions.