Prior to Summit, on the eve of the release of Luminis IV, there were rumors spreading that Luminis' future as a portal built on a uPortal architecture was seriously in doubt. The rumors indicated that Luminis was going to undergo a radical transformation and be rebuilt on Oracle portal.
At the UDC kickoff session at Summit, this seemed to be confirmed; Brian Maddox, Sungard CEO, announced that Sungard had come to a wide ranging agreement with Oracle to standardize on Oracle middleware. Although this includes a number of components, the one that caught my eye was (naturally) the inclusion of Oracle portal.
This did bother me. Part of my concerns were simply based on my lack of knowledge of Oracle portal. How does Oracle portal integrate into other systems; do they have something similar to CPIP or GCF? Does it support JSR 168? While the answer to these questions are surely interesting; they are also practical. How much time should client Universities spend on customizing an architecture present in Luminis IV that Sungard has already slated for death?
I was also bothered by concerns that were far more personal. I'd be lying if I told you I didn't experience a sinking sensation when it was rumored we would have to throw out all the work we had done with Luminis over the last few years to support a brand new architecture.
My concerns though, were based on more than simply the threat of years of lost productivity on the behalf of myself and my team. I'm sure you all have your own stories on how you arrived at the decision to go with Luminis. At Hofstra, we had evaluated a number of portals that interoperated well with our existing technology. Luminis was one of several finalists. One of the deciding factors for our choice of Luminis was that it was based on uPortal-an open source portal being developed expressly with Universities in mind. To purchase a portal based on uPortal and after purchase being told we're getting Oracle portal instead made me feel like Sungard had beaten us at a game of three card monty.
At one of the sessions at Summit (I think it was 'Peek-A-Portal') one of the panelists stated that you might not like Luminis directly out of the box; but one of its great strengths was that you could customize (and hack) it to serve the needs of your institution. I'm sure this isn't news to any developer on LumDev. But imagine if Luminis was based on a closed source solution; that customizations were difficult or impossible. That out of the box was what you got.
You can see why I was worried.
But later at Summit, I was reassured when Sungard representatives at the well attended Luminis Birds-Of-a-Feather session stated unequivocally that Luminis V (tentatively scheduled for release sometime in 2009) would support *BOTH* architectures. I was surprised at this for a few reasons. Primarily, with my admittedly limited knowledge about such things, it doesn't seem that Luminis really has 'an abstraction layer' that would allow it to easily run on both platforms. This will undoubtedly take some serious development work. Secondly, I was a bit surprised simply from a resource allocation perspective; two platforms means twice as much work-for development and for support.
With all that being said, Sungard reiterated their commitment to uPortal and said it is their intention to run on both platforms for Luminis V. Hopefully, in the meantime, those here on LumDev can continue to demonstrate why having an open source platform is truly worthwhile.
Comments
Shared Fears
I share your fears, but am not as easily appeased by the concept of support for both platforms... Firstly, Mark Boyd has stated that the fine grain access control (FGAC) functionality that is maybe the most significant innovation in LIV is built on uPortal and is not present in Oracle Portal (oPortal?). This leads me to wonder if they will be spending a majority of their development resources for LV retrofitting all the "stuff" we love to leverage (CPIP/GCF, CARs replaced with JSR-168) and the new infrastructure (ex. FGAC) in uPortal in to oPortal. Does this mean 5 more years with no significant innovation? Minimal concentration on usability and the Web 2.0 features we all desire? I'm also left wondering further out, sure they'll have dual engines in LV, but what about LVI? My guess is they would ditch uPortal at that point.
Clearly desire to make this change is based on a feeling of too much time spent developing the uPortal engine. It seems as though they would like to reclaim that development time to concentrate on the value add aspects instead of infrastructure. I understand this, but it if that is the case uPortal will have to die eventually...
10,000 ft. view
From a 10,000ft. view it seems to me like uPortal is already far behind some of the other options out there.
Sure, things like DotNetNuke and Drupal are really more CMS-type solutions than portals, but they're already loaded with the Web 2.0 goodness we want and can easily be extended to allow customizable home pages and the like (and they're completely open-source).
My personal opinion is that uPortal (and hence Luminis) seems like a "good enough" solution. I'm not certain we'd have selected it were it not for the promise of Banner-integration.
Worried as well.
This whole thing is certainly worry some. As an institution that has locked in to all Sungard technology, I'm worried about their direction.
First, this decision seems to have been made by high level managers, and it seems that they did not research any best of breed solutions, but just took what Oracle said they should use. This is just a feeling though, and I'd like to hear something different.
Second, I question why they have decided to go toward a Portal at all? Honestly is the portal not a 1999 sort of topic? I know that edu is usually 6-7 years behind industry... but if they are planning for the future should they not look at integrated dynamic content in web pages? Channel style info on demand on web pages? Shouldn't user interaction between the website and personalized information be seamless? and personalization of the website in general? Or maybe go toward a webtop...? That certainly seems to be their and every other portal's direction, but I think Oracle Portal is a bit of a step backwards.
Now this all may be moot because from what I have seen, PeopleSofts Portal is very nice, and with their buyout, maybe Oracle will replace their Portal with PeopleSoft's which is certainly a lot nicer from my experience.
Anyway, I'm done ranting. I would be much more comfortable if we were given the reasoning behind the direction, and it corresponded to the goals of web developers... Usability, accessibility, User Interaction, relationship building...
I would like to see their vision statement for Luminis...
On the other hand, maybe they will shift their focus from building portals, to building integration. I would love to see better portlets for banner integration, and other application integration (sharepoint? exchange?).
more to worry about
I'm currently recovering from surgery which is why I wasn't able to attend Summit this year. Today is my first day back on the interwebs and imagine my reaction to reading this posting. Followed by a posting on the JA-SIG dev list that I'll expand on in a moment.
I've read that SGHE may be moving to Oracle's Portal but had no idea that they admitted to that change during Summit. I wasn't too worried about it because I think that we would probably all be better off if we implemented pure uPortal rather than Luminis anyway. I don't know too much about "oPortal" but it probably isn't going to be a bad portal implementation except for the loss of development and customizations we have done based on Luminis and uPortal. I think that as all these web apps evolve they are all moving in the general direction of portlets, web services, etc. such that it may not be as important what portal we implement at our respective universities as long as they are all supporting the same standards.
Personally, I believe that SGHE would be better off developing and supporting these type of connectors to abstract the portal and not have that heavy weight to support. If they provided APIs and/or pre-built portlets and/or web services that we could take advantage from whatever platform we chose then they could potentially lighten their load and even continue building new customers because the university wouldn't have to choose to implement a new portal (abandoning one they currently have paid for or built from open source). Universities may not have to make the decision based on whether they have Java resources to support Luminis/uPortal or Oracle Portal and could instead use something like Drupal (supposing they have PHP developers) and modules that implement the API calls to display SIS info or whatever the case may be. Or perhaps the university does have java developers but already have uPortal in place or Unicon's implementation of uPortal or Liferay or whatever and now they can just use the portlets for that kind of integration.
This afternoon I got another jolt of "worry" when I checked email and saw a thread from the JA-SIG dev list that another one of the SunGard developers is leaving and going to a completely different industry so he won't actively be supporting Luminis/uPortal development in the future. I am new to the JA-SIG infrastructure team helping to manage CVS accounts but not sure how public this particular information is yet so I won't say who this is right now. But it bothers me more knowing how involved he has been in the recent contributions from SGHE to uPortal and how his work has been much anticipated in Luminis IV.
I'm sure that SGHE has made this partnership with Oracle more for business reasons than customer relations and that is understandable. However, I am also a big believer in open source and supporting those types of applications so it concerns me that our vendor of choice and the major vendor of IT solutions to the higher education industry is now planning on not supporting probably any open source (much less higher ed developed open source) software.
If you can't tell I've been cooped up in bed for a few days on pain meds and very much enjoyed bending your ear (eyes?) for a little bit. Hopefully, I haven't offended anyone with my opinions or bored you too much. :)
Cross Thread
About 10 weeks ago I leaked the news to LumDev http://www.lumdev.net/?q=node/1009 asking for confirmation and some interesting conversations spawned from it.
Some things I still feel strong about... SGHE were so many revs behind the rest of the uPortal community we did not gain the full benefit from the open community. My plead to SGHE was to have them stay more current with mainstream versions of either uPortal or now... Oracle. Their "additions" caused them to fall behind the current state. We need them to leverage APIs and frameworks vs come up with their own.
I think it will be hard for people to make a change if given the option to stay or move to a new engine... but as others have said... how long do you have till they drop uPortal?
Josh told me that they have over 600+ schools on Luminis so they WILL have to port the existing services over.
Interesting times are coming... I look forward to it! Oracle will soon have their own linux distro (based on RedHat) as part of their install base so this should be a nice tight fit.
David - UNC Charlotte
CampusEAI releases portlet for Banner
There was an interesting email I received this morning about CampusEAI developing a portlet that works with Banner and Oracle Portal. I thought these people seem to be on the ball and know which way its rolling... I can't find the article online yet but when I do I'll post a link.
While looking for that article on their website I found one that said they have also developed a portlet for MS Exchange. Hmmm....
CampusEAI
Contact Jason Shao at jason_shao at campuseai dot org
Glad you feel fine : )
Cause I don't... I'm sure you were just finishing the song lyric though...
Nice to meet you at Summit!
Same here
It was nice to meet you too. :-)
Be open to change
Being that I am a complete novice to Luminis, and that I don't even use it yet, I cannot talk about it's supremacy or inferiority to the Oracle portal solution.
What I have been through are some proof-of-concept exercises, portal evaluations, and shared experiences with fellow administrators. I can also tell you that there is some debate on the necessity of a portal solution, all with the redesigning of internet applications these days, but no matter what, you will need an infrastructure to support those applications.
Through the many iterations of evaluation of product after product, the one (and I mean one) thing that always brought us back to Luminis was it's tight integration into Banner. The products we looked at were industry leaders, and we also looked at open source solutions that we could grow a custom solution with, but any other route would have meant years of development to get up to speed.
I receive the Sungard Luminis Platform listserv emails and cannot help but shake my head in disbelief that people are still struggling with version 3 as much as they are. I've seen the demos, and Luminis looks like SSB on steroids, I don't see the difference in the base install.
Here's what I can speak to (this is not a paid advertisement)
I've been working in a mostly Oracle shop almost 8 years now, and I've been privileged with resources to support it, but I've only tapped into those resources when I've really had to, because unlike most open source products I've had experience with, the knowledge I need is there, when I need it, not on someone's blog, listserv, or 3-year-old static website.
And talk about a user base, Oracle has to have one of THE largest user bases and forum activity I have ever seen. You can almost get an answer to ANY question Oracle related in about 24 hours max, try getting THAT from the SungardHE Clent Support site.
I've also dealt with the portal piece in many different facets. It has been easier and easier to implement over he years, and there have been many improvements to administration. Deploying new functionality does not require a command line tool, restarting a web service is transparent to the users, and about JSR 168: Oracle helped write the specification.
I think that given the chance to implement Luminis on Oracle's infrastructure, I would love that opportunity. It would be the best of both worlds.
Is oPortal still taking over
I didn't hear anything about this at this year's summit. Is this old news or should we rethink implementing luminis at our institution?
No. And Yes. But mostly
No. And Yes. But mostly No.
As they move forward with Luminis 5 they are looking at supporting a number of Portals by using standard Portlets. There is probably a lot more information out there. But thats the basics in general. Luminis is being transitioned from a portlet with a bunch of apps inside it to a bunch of apps that connect to a portal. Their amin is to allow you to change the baseline portal if you want.
Portal options
A few options were presented at Summit:
- uPortal
- Oracle Portal
- LifeRay - http://www.liferay.com/
Luminis would work with all three.
There may be other options out there, but those are the three I remember hearing about in the SunGard presentations. Also, in my notes I have "end of 2009" as the projected delivery date for Luminis 5. As one speaker put it, though, things with Luminis 5 are not set in stone, in terms timetable and deliverables.
Portal options continued
That is basically what I heard too, with the following nuance .... "we really like Liferay, and we will make things work on Oracle because we think it is important to leverage our customer's current application stack."
Liferay over oPortal (?)
From one of the talks in the developers lounge, it sounds like the Luminis 5 team is leaning towards the full stack version of Luminis shipping with Liferay. Among other things they seem to have run into some technical problems with the things they want to do with Oracle Portal. However, they also want to support running Luminis on any portal platform which supports some set of standards, including WSRP and probably JSR-168. The one thing they were fairly clear about changing is that they would no longer be in the email and calendar business.
luminis email
We're pretty new at this - haven't had any training and haven't started anything yet - but our plans had been to move to the luminis email for our students when we brought it up. Does this mean we should stick with Exchange for their email or start looking at gmail instead? We wouldn't want to move them all over to another email and then change it again in just a couple of years.
Nothing confirmed
I don't think the SunGard people confirmed it one way or the other, but I got the sense that SunGard is getting out of this sort of thing. That is - they'd prefer to tie into existing mail servers or services. This doesn't mean that they will no longer bundle one with the portal product, they still may. So, it's as clear as mud. :)
Luminis V cynic
Being the cynic I am I have a question that stems from a deep scar from my past. I admit I'm naive about this "luminis stack" and what that really means so feel free to enlighten the cynic.
I worked for a .com in the past and we went full out with a product called Vignette - which rocked. At its basic level, its similar to PHP / ASP in that it was used to build page templates that would be combined together to build web applications and content management systems. Using TCL as its language, it was quite powerful, it was also quite expensive ~$500k - perfect for the .com era. After about 3 years they 'evolved' the product to support J2EE and the product barely served up the original tcl template pages and all the developers had a fit because not only did they have to rewrite all the code they've done, as far as a feature rich J2EE app server - it sucked and was super expensive compared to other better solutions. See where I'm going?
Luminis 5 is a stack of portlets that can be used in 'any' portal application. Ok - so now I have to learn JAVA (for real this time) and rewrite all my channels into 168 compliant portlets and then learn a new portal platform so I can use those portlets. I guess I see too many similarities between Vignette and Luminis. What exactly does the stack get me ... if its just a pile of portlets - why do I need it. If whatever portal software I decide on leverages my LDAP authentication, and sso into applications at some level, then why waste the time to cope with the stack? Why not just build content whatever way my portal software needs it? Just seems like another point of failure - and if the portal stack goes down ... I have a portal full of holes.
just curious.
Drop the roman numerals!
Tsk, tsk - don't you remember anything from the opening presentation? It's not Luminis V, it's Luminis 5! One of the benefits of Luminis 5 that Josh touted was that they were stopping the insanity and dropping the roman numerals!! haha
They're only about 5 years behind me. I've been calling their products Luminis 3 and Luminis 4 since 2003.
Todd
I know... I know
I did that on purpose, figured I'd stir the hornets nest a little more than the rest of my post.
I'm kind of partial to the Roman Numerals myself, they should have kept them and changed the dot release digits to numerals too. It'll be like the Superbowl!
Developer A : "Hey what version are you on?"
Developer B : "Um let me see ..."
cpver
Luminis Platform III.III.III. ... oh crap what's 142 in numerals ...
Hahahaha
Luminis email is not Luminis email
Regardless of what actions Sungard takes your email will still be supported as the "Luminis" email they install is really Sun's Java Enterprise Services. You'll still be able to get support through that community.
from front-end to middleware
I was very happy with the Luminis teams direction.
They seemed to have their hands full with banner integration, messaging, etc.. all the backend stuff, and the user experience at the front-end suffered.
Standardizing the way in which information is presented to any front-end portal of your choice, including uPortal, is a great way to go imo.
Luminis is in no way disappearing, rather, it sounds like the future of Luminis is as middleware, not a portal. But middleware that will tie multiple data sources together, and produce standard compliant portlets to feed any portal of your choice.