The idea of SOA is very appealing to many people, is a hot buzz word. We at UPRM, believe that SOA has a lot of potential as a mean to allow for short development cycles, provide development flexibility and room to grow with ease. For the past past couple of years or so we have done a lot of work to make sure that our underlying framework is SOA ready.

While thinking about Higher Education and what commercial products like STC and Campus Solutions offer I noticed that they are mere web service providers in a SOA o Service Bus environment but to must part they are rigid black boxes with little opportunity to exploit the potential of their internals.

Then I convinced myself that our goal should be to build a framework that allows for a composite/match-up development. Imagine the idea, instead of a program I give you a box of LEGOs. They are many challenges to accomplish this.  We will tackle these challenges later on the discussion, but for now the idea is very  promising. Allow me to describe such framework.

A composite design pattern IS NOT a make a web-service of every API. The composite design is the notion of developing every API as a service. In a our object-oriented world of REA, a class is a service and while a service may have dependencies it is still for the most parts an atomic element able to exists on its own. Instead of designing a class based on the abstraction or object it represents, we design classes or modules based on the services it must/may provide. I talk about classes here but the notion of a service may no necessary make sense at the class level, may be the case of a module/library or an application as a whole. What is considered a service is something that will be greatly influenced by the dependencies of what ever it is that we are trying to represent.

These entities as services should be our replacements for a traditional API, thus allowing for the composite/mash-up development of solutions. Now these entities exists in domains or groups in a provider. When we turn entities/classes as services we have physical limitations that will determine how these services are exposed. For example entities that relay on direct access to a database will be bound by the need to physically access the database. A service will also be bounded by its dependency and relationship to other services. For example a class schedule service needs the course service. This grouping of services by its physical boundaries or a logical needs becomes a “cloud of services” or a “provider group”. I like to think of it as a “domain”. There is NO programatic representation of a “domain”, is just a notion to help us understand the associations. Where these domains exist is irrelevant it could be in our university it could be somewhere else, it is the distributed nature of our composite design pattern. We could even have many “domains” providing the same services in a sore of load balancing way… Entities between “domains” should have no physical attachments. The physical attachments is an abstraction that the Service Bus creates for these entities.

The service bus borrows a whole lot from the commercial notion of a service bus, yet its main part is the messaging layer.

Before you said, this does this already…

We at UPRM have NO money, it is very unlikely that we can obtain more hardware. Commercial solutions are simply out of the question. Open Source/Community Source are our only option. JAVA is not a jump we will make (I promise to open a wiki on why we would not use Java).

Challenges

QOS. Assurance of availability. Dead channels, Drop transactions, dependancy of transactions across multiple entities,

Entities going out of service (black-outs) in a loosely couple environment is deadly. You need a sort of checks for availability of dependancies. Before you start an operation you NEED to know that the entities you relay on are available. I can not start a course-registration operation if my scheduling entity is not available. Some transactions need to be ATOMIC and guaranteed.

Of messaging queues and service bus

PS ( I Should add that me being a compulsive programmer decided that I need to explore for the equivalent of loosely-coupled spinal cord for this idea. I researched service bus, and messages queue alternatives that are open source, very interesting stuff out there. ActiveMQ is very promising. Yet I asked myself what do such a spinal cord would need to work on a very dynamic, with a volatile existence of components and synapses and loosely coupled elements. (And do not forget limiting overhead and performance penalties, but you were already thinking of that one anyway…)

We need to send Events messages and Reply-Request messages. For every single message over the service bus I do NOT want to pay the TOLL of a HTTP request(s) nor do I want the overhead of XML encoding and decoding the payload. So messaging should be close to the host language (PHP in our case) yet be able to translate to foreign queues for example using STOMP to talk to brokers. We should be able to encode the payload in different forms with a degree of transparency for the clients using the service bus. For example in the safe heaven of PHP, natively serialized data should be able to be passed over the service bus with ease, alternatively JSON or XML are good choices for sharing outside this protected heaven. When possible a message like for instance a Reply-Request should allow a physical coupling of components (sender-listener) to avoid the HTTP talking, clearly this is only possible if both components live in the same cloud.

I figure that I could write a layer on top of ActiveMQ and its alike to cater for this particular objectives to an extent, yet the overhead of setting a Java infrastructure and such simply was NOT appealing. I decided to take a CRACK at it. I saw Blackbird an attempt to create a service bus in PHP, very interesting yet not what I had in mind. I went looking for inspiration on the messaging functionality of OSs like in COCOA/Objective-C and Dot Net, added a flavor of Enterprise Integration Patterns and POOF!! the idea of a Service Bus for REA was consuming every second of what little sanity I had left.

I stole from my family a couple of hours at night and in two days I had a good proof-of-concept of what this service bus could be. Pure PHP, flexible messaging options, coupling and decoupling was dynamic, and a few EIP where in place, PIPEs, Multicast, Events, Reply-Requests. While the work was mainly a Publish-Subscriber kind of deal, It was enough to show that it can be faster than a purely Web-Service solution.

Another term gone

July 29, 2011 | General  |  Leave a Comment

So, this last term was quite productive.

I think the basics of documentation and procedures are some what cover and the habit of documenting is now officially institutionalized!

We streamlined a lot of procedures, documented a whole lot more. We questioned everything and are now building more efficient procedures.

Software and Development is now on course to embrace new development technologies, yet we have to tackle an architecture migration for RUMAD. That is a big set-back, yet we can no longer bargain our luck with RUMAD. This last term we had some serious incidents. We are now waiting for the hardware replacement of RUMAD to arrive to start our migration. In another note it seems that we would be able to hire a new developer after all and thats good news.

We are know putting our attention into Operations. “Operations” is what keep us running 24/7 yet it has operated on status-quo for a very, very long time. We are bringing our “operations” more inline with our actual “operations”. There is a lot of room for improvement here but we have no doubt we would fix this. The basic challenge here is getting things done with less people and yet some how offer some sort of warranty of being able to sustain operations 24/7.

Development wise we got some work done on the creation of new curriculums. A very enthusiastic group of academic counselors from the engineering faculty learned the ins and outs of the new curriculum system to start the creating the definitions of their programs and help with the testing of the system. We are now working on the “equivalency” system and once that is done we should be able to move along with curriculums.

Email

May 4, 2011 | General  |  Leave a Comment

Quite often we are asked why is cartero (our bulk email service) getting so saturated. A regular day will have more than 10 emails from cartero, in others we see over twenty. The problem here is that we are desensitizing our users and destroying the value of the service. I would like to briefly discuss this topic and what are we doing about it.

I believed there are a couple of problems to be addressed. For once people new to technology are automatically convinced that “email” is the one and only mean to communicate. We need to create a new culture and create mass around our new communications outlets.

Then we have the tools to send bulk mail in Mi Portal. They are very easy and accessible to plenty of people, making it very hard to control what is send.

A long time ago we completed a project for “Agenda Colegial” a calendar like web site where events and activities were to be published. The service is available at http://www.uprm.edu/eventos/. Today that service needs ownership and an institutional policy.

We started crafting an “email” policy and hopefully it will get the discussion started in the proper administrative levels.

CTI will put a tighter control on who can request access to the bulk mailing tools in Mi Portal. Hopefully this will help also.

We also hope that the new webpage for the campus will set the start for making other means of communication a mainstream culture, specially social networks.

RUMAD, where are we

March 31, 2011 | General  |  18 Comments

RUMAD is a hot topic for us. The hardware is no longer under contract. Today we still do not have a ownership title. The latest attempt to solve this problem is a migration project from the Central Administration. Now while it seems it has the administration support it is clear that just the purchase of the equipment is a couple of months away. By the time we get the equipment and start the actual migration it could be easily 6 months from now.

On 2011/Apr/25 we were informed of a final proposal from HP. The vice president of research and technology presents the proposal to the IT committee (Sindicos) and its approved.

On 2011/Mar/23 we had a meeting with the vice president of research and technology and it seems that the Central Administration is convinced of the need to solve the problem with the legacy servers. That day we got commitment from the vice-president and a syndic to fund the migration for all 10 campuses. We got in contact with HP to follow up on the proposal started by OSI-AC. HP is collecting new information and they should have a new proposal hopefully in a couple of weeks.

On 2011/Mar/29 we decided at a staff meeting that even if we received the new hardware now it is not an option to attempt to have it ready for this next enrollment process (april-may). This is true even if we could get the necessary licenses for our own Itaniums servers.

The issue with the license keys is a show stopper for our migration attempt using our Itanium servers. At first the information we got was that a new CSLG was part of the migration project cooking at the Central Administration. Later we found that a new CSLG is very unlikely and without it our migration efforts are worthless unless we find the money to buy those licenses. For now the game plan is to push for the migration project at Central Administration and ensure it actually materializes.

I have put a list of some events to put in context our efforts to solve this issue.

2011/MAR/23: Third meeting with vice-president. We received the information regarding the migration proposal that OSI-AC was working. Contacted HP to discuss specs and proposal details. Send correct information to HP. HP will collect up-todate info from other campuses to work on a new proposal. Next meeting schedule for Apr 6 @Arecibo.

2011/MAR/2: Second meeting with vice-president of research and technology and OSI directors @RUM. Issue with the legacy hardware is discussed in more depth. Vice agreed to find the information regarding the proposal at work in OSI-AC and send the details of proposal to the directors.

2011/Feb/20: HP sends us the missing license keys for the C compiler for Itanium. Keys are installed on Feb/25. Work starts on compiling and testing Apache code and other libraries written in C.

2011/Feb/7: HP sends us new temporary keys (extension) for the compilers in the Itanium. Keys expire in december. HP representative told us that this extension is a one time deal. Seems like there are no plans for a new CSLG contract. If we want to use our Itaniums we have to buy our own licenses.

2011/Feb/1: Requested OSI-AC details about the proposed equipment for RUM in their migration project and the status.

2011/Jan/19: OSI-AC makes available Multinet 5.3 with Integrity support.

2010/Dec/8: ( We finally have formal details for the “couta de estabilizacion”). Managed to move work ahead.

2010/Nov/20: Follow-up with CIO on status of virtualization project. We inform of our intent to migrate RUMAD to the Itaniums.

2010/Nov/12: Work on mayor changes to the enrollment software (eg: cuota de estabilizacion, new payment system, etc) delays work on migration. Yet all changes to the enrollment and collections systems are compiled and tested in the Itanium. Work on enrollment continues until mid february of next year.

2010/Oct/26: Apache and PHP environment in the Itanium is ready.

2010/Oct/21: Check for $4,146.52 is sent to HP for the buy-out of the two Itaniums.

2010/Oct/20: Paperwork and approval is completed for the Buy-Out option on the two Itaniums for $3,850.00. A $333.86 fee was pay due to the fact that the original payment (2009) we received the wrong quote and the amount was different. Payment is sent.

2010/Oct/19: OSI-AC makes available source for HRS and FRS for compilation in the Itanium.

2010/Oct/16: Cobol compilation tests are successful. We request OSI-AC the sources for HRS and FRS.

2010/Oct/13: A quote on new Integrity hardware from HP is requested. This number will be used to evaluate the option to buy new Itanium hardware. Quote is received on the Oct/15 with a cost of $89,693.33.

2010/Oct/9: We picked up form OSI-AC, OpenVMS media and keys to start work on the Itanium.

2010/Oct/6: We coordinated with Ahmed in OSI to obtain required software for the Itanium.

2010/Oct/6: HP’s Nelson Alicea, coordinated with Angel Rosario to provide us with evaluation keys to use C and Cobol compilers.

2010/Oct/5: We requested HP some Itanium licenses for the C and Cobol compilers.

2010/Oct/1: Itanium machine is up and running with OpenVMS. We were evaluating
the licensing options for the software (CSLG).

2010/Sep/31: Brainstorming session to evaluate the migration strategy to RUMAD, and evaluate alternate plans to the migration.

2010/Sep/24: We opted to accept the new buy-out terms for the Itaniums. We sent a reminder to HP’s Nelson Alicea asking for the ownership title for RUMAD as discussed on the Aug/5 meeting.

2010/Aug: ( Work on enrollment. Implementation of payment receipt for enrollment. Removed old Enrollment Invoice. )

2010/Aug/5: Meeting with Nelson Alicea (HP), Wanda Colo (Rectoria). Discussed the status of RUMAD leasing and the Itaniums leasing. Requested the donation of the spare ES40 in RUM. For a couple of months HP was charging us for an order that we had no idea what it was. HP financial said that we had an outstanding balance. In this meeting we asked HP to tell us what it was. In 2009 we processed a buy-out option for what we thought were the Itaniums. So happens that the quote and account that we received was the wrong one, thus we never completed the buy-out for legal matters. In this meeting this problem is sorted out. HP was going to send a new quote with a new buy-out options, without penalties.

2010/Jul/20: Meeting with CIO in AC, Virtualization project was discussed. CIO gave details into the status. Still working on proposal. We requested participation on the evaluation of the proposal.

2010/Jul: Staff meeting. RUMAD options are evaluated. Migration to our Itaniums is the favored option.

2010/Jan: Various inquiries into the virtualization project at AC. OSI doesn’t have much details.

2009/Dec, 2010/May: Found out that HP Financial is telling us that we owe over $9,000 yet there are no details of exactly is what we owe. HP is not answering our request of quote for a new maintenance contract for RUMAD. HP representative tell us that those contracts are not attractive to HP since parts are hard to find and labor is scarce. Started contacting third-party consultants for maintenance options. Quoted contracts
are above $9,000. We also find out that we do not have an ownership title for RUMAD to be able to contract support with. We can not find any documentation of a buy-out or termination of RUMAD’s lease.

2007: An extension to the lease is requested for $7,664.00.

2006/Jul: Acquired two Itaniums in a lease.

2006: An extension to the lease is requested for $10,437.55.

2001: RUMAD is acquired with a lease for $136.525.40.

On the table, big goals?

February 15, 2011 | General  |  Leave a Comment

What are we playing with this semester, hmm! lets see… Lets try a Bullet point pitch for this semester’s agenda…

1. Financial Aid:
1.1. Very manual processing and time consuming.
1.2. Programs are quite fragile and vulnerable to changes in procedures and regulations.
1.3. Hosted on a mainframe era technology, OpenVMS/Alpha (RUMAD). Hardware no longer supported, costly maintenance cost (compared to today’s commodity servers). Hard to find labor (service/maintenance/operators) with expertise on the platform. Parts hard to find on market, no replacement parts are manufactured only refurbished or used. ($12k plus on maintenance every year.)
1.5. Employees at RUM (all UPR) with expertise on OpenVMS and Alpha are due for retirement.
1.6. UPR’s PATSI project failed to materialized after more than 70 millions of dollars and over 8 years invested, without evan a 20% of the project completed.
1.7. Campus Solution is rushed as an Oracle’s OSS replacement. Implementation is bias and narrowed by the particular needs of FA, it lacks scope and proper analysis of design constrains and ways to tackle them. We are failing to asset our readiness to implement, deploy, run and support Campus Solution. Trying to implement a monster on a broken foundation is bound to fall apart. (Marked this down!, this has all the tell-tales of Oracle OSS Part 2)
1.7.1. An implementation of Campus Solutions could take at least two years to materialize, and FA only implementation at least a year.
1.7.2. RUM is NOT involved in any of the Campus Solutions talks. Where are we in this master plan?
1.8. We are ready to deploy big. REA as a framework is mature. We have new infrastructure.
1.9. Federal regulations on FA are NOT as scary as some swear they are. Changes are not a missile that would require new systems with every change. Could the Department of Education would require universities and companies to re-do and invests on FA systems every year? The true is that they have not and they do not, changes are more subtle than what many think. Ask yourself when they talk about Federal regulation changes for FA every year, DO you actually know what these changes are? Well WE DO!
1.10. This semester we would run our first mayor procedure out of RUMAD!

2. Time and Attendance
2.1. Did we mention is time consuming? Time!, people!, lots of work.
2.2. Information is never up to date.
2.3. Software solutions are expensive! please Google it!
2.4. Its actually a fairly simple problem.
2.5. Runs on the same Alpha/OpenVMS that we need to get rid off.

3. Property Management.
3.1. How is it that we can not achieve a purchase muscle/ecosystem? How many departments need to buy the same printer toner? Good inventory/property tracking is key, to maximize purchases and enabled volume savings.
3.1.1. We need suppliers to come and compete for our business. We have a plan and property management is an obstacle that must be solved. (more on this in another post)
3.2. The current systems is dated and runs on RUMAD (OpenVMS/Alpha).
3.3. Reduce time/resources it takes to manage assets.
3.4. Maximize assets.

We have exam corrections and professors evaluations as a one of those odd services that we provide. We have an OpScan 8, a hardware scanner use to process OMR marks used in the forms or (hoja de bolitas). So happens that we have provided that service for quite a while. I have a couple of issues with this service. Lets see.

The actual scanner costs $6,000 every year. The forms are over $75.00 per 1k pages. We have an employee with a salary of $3,000 a month doing a job that has nothing to do with our core business.

We need employees, and we can not afford to loose an employee on this. Adoption of online platforms should ease the burden for exams.

Alternatives:
Educate professors on the use of online tools for exams. (Aggressive education)

Get OMCA to take over professors evaluations, and push a dormant project for online evaluations. (actually the programming is already done, all it needs is logistics and procedures.)

We are preparing a pilot for OMR software. OMR software allows any department that wants to provide the OMR forms service to their faculty to purchase an off-the-shelve scanner (wallmart, officemax) and a regular PC to scan “omr forms” without the need of expensive hardware.

Short term we would provide the Opscan as a Do-It Yourself type of service.

2010 was a busy year for us. While we have kept ourselves under the radar it was quite a productive year.

For must part we have put a lot of efforts on documenting processes and establishing procedures. We found that many things were left to the habit and knowledge of people but nothing really written down on paper. This year we gained a lot of ground on documentation. We put a lot of thought on what we are doing and how we should be doing it. As a programmer, you would say we were refactoring our selves.

May sound trivial but this task along took quiet a lot of time and effort and we are far from done still.

I think we have a good idea as what kind of challenges the university (and us) is facing and thats really important.

Yet we managed to get some time to play. We replaced the traditional tuition payment invoice in favor of the online invoice and added traditional receipt printers for payment transactions. We got new servers, better monitoring of systems. We finally have a sort-of formula to keep RUMAD alive during enrollment (thanks to some overdue metrics). We worked on a new payment system. We finally have electronic signatures in grades reporting, and we started a couple of significant projects (secret).

We did a lot diplomatic work with other campuses and the central administration. We are trying to keep our selves visible and relevant in some of those important discussions of technology at the central administration. That was a bit complicated. The administration still not settle or defined, yet we have time critical problems that needs to be solved. Things are not easy but we would try to keep these topics on the table regardless of all the changes in administration.

RUMAD a bit of thinking…

September 18, 2010 | General  |  Leave a Comment

Since 1966 when we started our first information system, our campus has shown the spirit and determination that had helps us face some difficult times.

Around 1966 or 1967 we had our first enrollment system. By 1986 we had the base of the enrollment system used today running in a DEC-10. In 1988 we had the arrival of our first VAX server. About that same year the registrar’s office was using the “estudiante” screen.

In 1993 we acquired our last Digital VAX 6320 with a 8GB storage with a price tag of over $170,000.

Some time around 1986 the Central Administration acquires a set of administrative applications for Finance (FRS), Human Resources (HRS) and a Student Information System (SIS) from Information Associates. By 1991 our campus had completed the deployment of the Finance and Human Resources applications. While I’m still trying to get more details about SIS, seems like it actually came after the HRS and FRS applications.

SIS was planned to be the standard student system to be deployed in all 11 campuses. The story at this point is that our campus decided not to deploy SIS. The arguments used were mainly ones of functionality. Despite the resistance in 1997 the campus completes a deployment of SIS and it is used for the first time for the fall and spring semesters of that academic year (Aug/97 to May/98). The process was described as troublesome with many complications. In summer 1998 the campus returns to our local system and drops SIS.

Just a tease but in 1998 the Central Administration starts its plan for updating and replacing the existing technology. An RFP is submitted. Sungard, PeopleSoft and Oracle presented proposals, but more on this later.

In september 2001 the campus replaces the last VAX server with an Alpha ES40. This Alpha ES40 is what we know today as RUMAD. I need to verify this but oddly enough our RUMAD seems to be the largest server in the 11 campuses in terms of hardware. Rio Piedras does have two smaller servers running in a cluster, but I’m not quite sure how that stands next to RUMAD. So in terms of physical machine RUMAD is still the biggest and bolder.

Today RUMAD is our host for over 37 years of development. It runs our Human Resources, still runs parts of Financial System, Medical Services, Budget Systems, Debts and Collections, Financial Aid, Academic Records, and Enrollments. Our campus has a great deal of development in our administrative and academic system known as “RUMAD”. Development that we can assure surpass any other at the UPR. RUMAD is as critical as it was back in 2001 when it arrived.

In 2002 we started an aggressive plan to replace an aging foundation of technology with more current web platforms. Yet in 2003 our efforts came to a halt with the beginning of PATSI.

PATSI stands for “Proyecto de Actualización de Tecnologías y Sistemas de Información” (http://patsi.upr.edu/pub/index.php). PATSI is the result of that project started back in 1998. While the actual bid was won by Oracle in 2001 the implementation was delayed by numerous problems. (PATSI is a long subject and a bit complicated, I do have other readings for those interested in the subject, so i’ll limit myself to what is relevant to our RUMAD discussion.) From 2004 to 2008 our campus put must of its recourses into the deployment of PATSI. We were very critical of the many problems with the project and its functional limitations specially in the Student Module of Oracle (Oracle Student System, OSS). Not officially but by 2006 our campus was not considered to go-live with OSS as planned with the other campuses. Our roll was limited to what information or interaction was needed from us in the scope of the other campuses. Later that year we were no longer listed on the Go-Live schedules. Today we are the only campus that never implemented any of the parts of OSS.

By 2006 we were able to commit to a limited degree to our original efforts. In 2006 this effort was already measured in over 265,215 lines of code. Today we have a great deal of self-services and applications available online 24-7 and thru our self-service kiosks. This new development is what many of us know as “Mi Portal”.

In our development strategy we port functionality to Mi Portal gradually. To do so we use what we call “la pega” to bridge data and functionality from RUMAD and Mi Portal. This new functionality puts a great deal of stress in an already busy RUMAD.

This new development has overwhelmed what RUMAD can do. Its all great “candy” but sadly it had taken to long to replace our core student systems, and as such we have abused of “la pega” for much longer and for uses beyond what it was meant for.

We lost almost 6 years of development with Oracle. We have a lot to catch up to alleviate RUMAD if we want to keep all of the new functionality provided by Mi Portal. Not that we are too far but 6 years of development is a lot and we need to do it fast.

RUMAD (our ES40) is what is called in the market on its “End-of-Life”. No manufacturing is done at all, not for parts or related equipment. Everything is used or refurbished. Prices for spares is based on demand. The more it is needed the more you pay. This on top of a higher price-tag from a limited supply. It’s very unlikely to find spare’s in PR, most come from abroad. The workforce with expertise on RUMAD is retiring and hard to find in PR.

With an “End-of-Life” equipment we get forever increasing maintenance costs. Our maintenance contract is more than $13,000.00 a year. The maintenance service is far from what you would expect for the price tag. For a server that can be found online for about $2,000.00 or less if you go to eBay. In contrast a fairly top of the line server can be acquired with about $3,000.00 with 3yr warranty and service.

The official support for the version of our operating system in RUMAD, ends in 2012. http://h71000.www7.hp.com/openvms_v8%204_strategy.pdf

In 2008 our backup unit was discontinued and we no longer can contract support for it. Given this and the many problems with have with the unit, last month when the budget was assigned we purchased a smaller external unit to do backup.

While RUMAD is an exceptional machine by all accounts and it has done a lot for us, it is an expensive machine. The operating cost is high at it will continue to increase. The operational risk is also increasing and the options limited.

The student part of PATSI was officially dropped in 2009 and we are back in square-one with the technology of six years ago.

The two main issues with RUMAD is performance and operational risk.

While we can mitigate the performance issue, performance is not a problem to be solve within RUMAD or using similar technologies. I’m convinced that we must migrate the remaining services out of RUMAD as soon as possible. The cost to scale the performance of RUMAD to what is needed would simply require an investment for which we will never see ROI.

We either discard everything we have done in

In the other side the risk of something going very wrong with RUMAD is a scary one. For once there is no machine similar to ours in the UPR. Contingency plans tested were limited to payroll. Can we take our data and setup our student system, hrs and satellite systems or parts of them? Picture that the least significant of our problems would mean a downtime of two or three days, imagine a mayor hardware failure.

We have an audit finding from the “Oficina del Contralor” where we are required to have “Business Continuity Plan” and a “Contingency Plan” and we have answer that finding.

The Central Administration deployed a software virtualization project to emulate the ES20 server in Bayamon. This project came about to address a hardware failure in their equivalent server. This project had a price tag of over $100,000.00 in Bayamon alone. A plan to virtualize all the systems was proposed but it never came about. Currently there is a proposed project to virtualize Rio Piedras, Ciencias Medicas and RUM. In my opinion the financial situation of the university will become a mayor obstacle for the visualization project to come a reality. In the meantime we have no idea what to expect.

Should we invest or wait to see if the virtualization does come. It has been almost a year since the idea of virtualizing the three main campuses started.

Currently as of september 20, we do not have a maintenance contract for RUMAD. HP is no longer interested on renewing the contract. We have found other companies willing to provide contracted support, but we still evaluating our options.

Also on the table are still the options to purchase a spare machine or a company willing to host a spare machine. A certified spare machine is quoted around $12,000.00.

As for performance we have gained some ground on that front too. This past enrollment was our first were we finally have enough metrics (network, io, memory, cpu) on RUMAD to base any decisions or work. We should be able to look at this past enrollment with numbers and that for me is very significant. We hope that we can finally say the threshold for this or that in RUMAD is this, no more guess work.

Another option is to avoid the overhead of calling RUMAD. This will require to change how we treat “volatile data”. Currently we check all the time to get the latest info regardless if it changed or not. With the new addition to “la pega” see (http://blogs.uprm.edu/ctkjose/2009/08/27/la-pega-and-the-internet-multiplier/) we are now capable of pushing data. This means that a program in RUMAD can tell Mi Portal when something changes. Doing this requires time to change programs in RUMAD. The same time and resources that you need to develop new apps in Mi Portal. How we balance our priorities and limited resources is a challenge for this and anything else we do.

This last enrollment we added a check to Mi Portal. We know check how well RUMAD is doing before we send it a request. If RUMAD was beyond a threshold we presented the user with an error, instead of sending further requests. This check was one of the reasons we survived the adjustment period, that and closing or limiting access from outside the campus.

As for options there are some (not that many when you look at them from the price tag). This is not only our problem all 11 campuses have a similar problem. Yet I think that we have an upper hand on the issue and far more ground covered. For once we are quite comfortable with the Do-It Yourself attitude.

I the other hand there are a couple of things I think we should not do.

In my opinion it would be wasteful to scale a new system to handle the enrollment process we do today. We need to erase any preconceptions of this process to redesign a new one. We need to accept the fact that the offer will never be able to match demand and thus demand must be orchestrated to meet curriculum requirements and balance resources.

Technology is an intrinsic part of our capacity to perform and grow. To ignore it in our strategic planning will be simply a death sentence.

We just deployed our second self-service kiosk at the student center lobby. Not to many services available but is all about having the platform to deploy. Expect more to come.

Curiosamente estaba pensando sobre el servicio de email institucional cuando encontré un buen articulo en Inside Higher Ed (http://www.insidehighered.com/news/2009/09/30/email). Este articulo al igual que otros parece meramente plasmar lo obvio pero para mi, lo interesante no son los acontecimientos, ni la modalidad sino nuestras opciones y alternativas ante estas realidades. Es una oportunidad para repensar como vivir en el Cloud. Para mi lo más interesante es que cuando vemos la situación económica de la universidad el Cloud es una oportunidad para hacer un regroup de nuestros core services y movernos a objetivos con mas significado y peso para la institución.

Para mis es hora to shed the extra weight, become a lean learning machine! Dont fear! Ya me imagino que estan pensando para donde se dirige el argumento, pero permitan que explique la idea.

Por muchos años la actividad académica y administrativa revuelve alrededor de la comunicación. (Yeap, I’m so smart! I manage to come up with that one all on my own! do apologize, but bear with me) El email se convierte en nuestro defacto vehículo para esta comunicación. Pero el issue entonces es que todo proceso electrónico se ha convertido en esclavo de este email y operan en función del email. Por ejemplo la cuenta de Mi Portal Colegial es tu cuenta de email. Hemos creado una dependencia operacional en el email.

Cuando miramos al Cloud vemos que? Tenemos un sin numero de proveedores de email y mucho más servicios de social networking, entre otros servicios. Todos estos son vehículos de comunicación. El email institucional existe por varias razones, veamos:

1. El email institucional provee una garantía de delivery y disponibilidad de servicio, la institución asume responsabilidad. Lamentablemente ya esto no es cierto. El servicio de email es controlado por Google. El estudiante puede optar por reenviar su email a otro correo si lo desea.

2. Proteger la privacidad de datos sensitivos. Hmm tricky one! Dificil. Una vez traemos un third-party en el juego, sencillamente es otro juego. Pero no es necesariamente para mal ya que los problemas fundamentales de proteger los datos son los mismos. Antes tu podías auditar tus operaciones de email ahora no puedes. Vemos que hay controles que sencillamente perdimos, pero la esencia del problema sigue igual no creo que se añadió un agravante mayor.

Si vemos ya no tenemos justificación para estar pasando por tanto dolor de cabeza. El email ya fue movido a un third-party (Google) pero aun tenemos que tener todo un andamiaje de cuentas , logística e infraestructura computacional para sencillamente darle una nueva cuenta de email en “upr.edu” a una persona que de seguro ya tiene una o varias cuentas de email o fácilmente puede obtener una. Mi pregunta es porque.

Es hora de convivir con el cloud, no de nosotros montar un kiosco en el cloud. Email es email y ya hay mil formas de que un usuario tenga email. Debemos de olvidarnos de como se provee email y repensar como usamos el email. Eliminemos toda la logística de proveer email de nuestro core business, claro el email institucional tiene su lugar, pero cuando repensamos el uso del email, entonces veremos que mantener un email institucional no será un dolor de cabeza.

Pensando en voz alta sobre como usar el email:

1. Dejemos de enviar correos en masa para cada minuto detalle. Cada email q enviamos en masa solo degrada la utilidad del medio y su relevancia. Explotemos las redes-sociales, rss, blogs y el web. Hay que creer nuevas culturas donde el email no es el único canal de comunicación.

2. Cada miembro bonafide es requerido tener una cuenta de email institucional. No realmente; cada miembro bonafide debe tener una cuenta de email, pero no tiene que ser institucional. Aquí tenemos varias opciones. El email como herramienta de trabajo para empleados de la institución puede requerir q yo como institución te provea un email. Pero yo como empleado puedo optar por usar mi email o mi email personal puede ser atado a una identidad de email oficial provista por la institución. Para un estudiante no debe haber razón para que el utilice su cuenta personal o se le requiera crear una cuenta de email como parte de su admisión.

3. Información sensitiva comunicada a través del email. Esto es una obsesión. El email es una herramienta tan sencilla que simplemente se nos hace tan fácil abusar de ella. Tengo un sistema de información donde no quieres generar un papel o un proceso, bum! en cinco segundos lo cambiaste para que enviara un email en su lugar. Wow, quedo de show, mira que eficiente es ahora, mira lo que me ahorre en papel y tiempo. Sencillamente no exploramos otros canales. Nuevamente es cuestión de culturas, de explorar las tecnologías que tenemos disponibles. Para cada cosa debemos tener un canal, un lugar para su uso y acceso. Si tienes un sistema administrativo/académico que es web enabled disponible 24/7, use it!!!. Keep control of your sensitive data; no crees copias de tu data sensitiva.

4. Vinculo sostenido con la comunidad universitaria. Wow! este argumento fue usado como parte de lo que nos llevo a Google. Yo como institución te doy una cuenta de email, que tu seguirás usando hasta mucho después q te gradúes o te marches de la universidad, una cuenta vitalicia. Por que esta cuenta de email es el vinculo con tus exalumnos y demas (perdonen el sarcasmo). Aun cuando el mayor burden de infraestructura esta del lado de Google, pensemos en el recurso computacional y logística que se requiere para lograr esto. Realmente esta es la única forma? Que tal un portal de exalumnos que sea diamativo, vivo y eficiente.

keep looking »