APS8: Don't Fear the Cloud -- Minimizing Concerns and Maximizing Benefits

Nathan Gerber : Like Glen said, my name is Nathan Gerber. I'm from Utah Valley University. And I'm talking a little bit about cloud computing, our journey through the CMS world, that kind of thing. This presentation really ought to be probably called that. And once we get done, hopefully you'll understand. Really, I just want to share our story, tell you what we've been through hopefully that will help you in whatever you're trying to accomplish and hopefully answer up some questions that we can discuss at the end. So, let me just give you a little bit of background.

I've worked for Utah Valley University since the dawn of time. I think I started there like in '92. So, I've been there a while. I've seen quite a few changes. I worked on their Web. I've been the director of their Web development services department for about 11 years. So, I've been involved in the Web world that way. And recently, I've also been added to the Noel-Levitz as an associate consultant in the Web strategy services team. So, I've been enjoying that, having a lot of fun there, getting to know a lot of different institutions and seeing different challenges that everybody's up against.

So, let's get into it, let's have some fun. So, this is APS 8. You can find the presentation at that location. It is not there right at this moment but it will be shortly after this presentation. I tried to get it up there but I ran out of time. It will be there, though, here in just a little bit. And I love feedback. I love to hear your comments about how the presentation went or other questions you may have or whatever. So, feel free to hit me on Twitter or on email, either way. I'll be glad to communicate with you and we can chat.

This last summer, I had an opportunity to take my son, travel to California and climb a mountain. Everybody has got to do that once in a while, right? So, we tackled a mountain there called Mount Whitney. Anybody familiar with Mount Whitney? It's the tallest mountain in the lower 48 states. So, outside of Alaska and Hawaii, it's the tallest mountain in the United States. It summits 14,500 feet.

So, it was a little bit of a challenge. I'm not the most in-shape guy, especially working in technology. I have more desk muscle than regular muscle. So, it was a little bit of a challenge for me to get prepared. But one thing I wanted to talk about this here is two things; first of all, perspective. I hope that I can give you a good perspective of where we've come from and what we've gone through because that will help answer questions if this is a match for you or if these things are relevant to you, those kinds of things. So, it's all about perspective, right?

So, the first thing is, can you find my son in that picture? Photography is a little misleading, right? Because if you don't have something in the photo as something to be relative, you can't really tell how big or small something is or how far away you are or anything like that. To give you a feel for perspective, he's right there. As we came around this bend in the trail, this thing was looming ahead of us. It was quite an interesting feeling. But it's all about perspective, right?

The other thing is, the more I can prepare you for whatever journey you have to go on, the easier it will be for you. We started on this trip with a bunch of the youth from our local area and a few leaders. And we started with seven boys and six leaders. And we finished with four boys and three leaders. So, obviously, some were more prepared than others. And so, hopefully, the more that we can prepare you or give you what you need to pack your pack the proper way will help. Anyway, there's my little mountain analogy, how's that?

Let's just talk a little bit about where we were and what we're up against. I know we are very unique in this perspective. But your dollars are shrinking. You don't have enough to do things, do more with less, that kind of thing. You guys don't have that problem, do you? Nobody. See, I knew we were very unique that way.

But we were being crunched pretty hard on quite a few different projects and initiatives that were going on. We also were told, "Well, even with all these new stuff going on, you can't lose track of the current student services that you perform and are available on the Web. You got to make sure those keep running. And, oh, by the way, we have this new push for perspective students and to recruit where we can."

New studies are coming out. And I don't know if any of you had the opportunity to see the expectations presentation yesterday. Some of that data is pretty interesting about how important the Web is to perspective students. It's very important. I put two stats up there. Ninety-two percent will drop the school, drop it or be very disappointed if they don't see what they need on the Web or if it's out of date. On the flip side, 65% of visiting students will actually become more interested if their experience on your website is good. So, this is critical information to understand if you have a big push towards recruiting of perspective students.

So, we were getting crunched in many different ways, being pressured in a lot of different things. And since 1999, we've actually gone through four complete full CMS implementations. If at first you don't succeed, try four times then it works, right? That should be my motto. And to be honest with you, we started questioning our own sanity and what we were trying to accomplish. But we were pretty sure by the fourth time we got it right, we got it really right. And it has been a great solution for us and a mix of different things but we'll get into that.

Just to give again perspective, we started on the Web in '95, right after Web browsers started coming out to the public. It basically was an online catalog. And then, we started to say, "Well, you know, we wanted to be more than an online catalog." So, we created a department of Web presence for each department. It was basically one page for each of the departments.

In '99 we, "we" meaning our little Web center, it was one full-time person, one part-time person, couldn't keep up with the demands. Anybody in that boat, where too many requests are coming in, you just can't keep up with stuff let alone think about new, cool stuff that's happening? Just trying to keep your head above water is a little tough. That's where we were.

So, we decided, "Hey, we are going to put into place a content management solution. We're going to allow users to have access to the system. And they're going to maintain things. And happiness will be all around and everybody will be glad." That was a miserable failure. In 2001, just two years later, we had to totally restrict all access to the site because apparently, giving access to people and telling them what they can and can't do wasn't working because then they would just do whatever they wanted. And it was really becoming a problem. We actually had a couple of businesses being run off of our site and all sorts of fun stuff. So, it was kind of crazy. We had a good time, lots of smiles during that time.

In 2001 we brought it back. Well, have you ever given out access and then tried to bring it back? It's not an easy thing to do. So, we ended up having a real lash back, saying, "Well, we had access. Why don't we have access now?" So, obviously, we needed to look for a new solution. And so, the demand for access really spiked. And we had to look for a second solution. So, we put a second solution in place.

By the time, this is what my Web team looked like. This was us, just absolutely out of control, pulling our hair out. We really weren't sure where we were going and it was getting very frustrating for us. But in reality, this was our users, too, because it wasn't working for them. And that's what we kind of missed the point at that point. We thought, "Well, this is all about us, being able to push work out a little bit better and distribute that workload out to other people." And so, that was frustrating to us.

So, we went back to the drawing board and we said, "OK, we need to do something different." In 2004 we did a bunch of research. We reimplemented and we said, "This time we're going to get it right. We're going to get the biggest, most robust, most powerful system we could possibly find." So, we launched this big, huge commercial system. And it was very powerful. But our users started to say, "Well, it's so complicated. We don't even know how to get into it." And it wasn't better, it was worse. Things just deteriorated and got even worse.

So, in 2006 we decided, "Well, we really got to go back to the basics and get more input." We decided, "You know what? We're IT." How many of you are on the IT side of the things? OK. How many of you are on marketing side of things? And that's always the big question, right? Where does Web belong? Well, we kind of decided it belonged in both places, made a few adjustments. And we're still on the IT side of the house. But we also have a sister department on the marketing side of the house. And together, we do everything Web. So, it has worked really, really well for us.

But we decided to do some more research. And we found out what our users wanted. And based on what the users wanted and based on our frustration levels and everything, it pretty much reduced us to this. So, now we've gone from bad to worse, right? Now, we're just the wet puddle on the floor. We're just terrible. It's just really not a good situation for us. But we did find one thing. We did answer one big question for us. And that was, instead of thinking about what's best for IT, we thought what's best for the users across campus. How can we help them?

So, we put into place a couple of different things, distributed content management model with ownership of each site out to the departments. And we launched with a CMS in the cloud a software service solution by OmniUpdate. They're here at the conference in the vendor area, if you're interested in talking with them.

But there's a couple of things that kind of came together all at this same point. Up until that point, we were Utah Valley State College. We weren't a university. So, there was the announcement made. We were moving to be a university. There was a little bit of budget, very little budget, allocated with the transition. And so, we decided now is a good time. We've been running this Web thing for about 15 years. And anybody running their Web server for 15 years, you get a little bit of non-essential information on the Web server. It gets a little bit bloated.

So, we took the opportunity to say, "Hey, let's start over." So, we brought up a whole new server. We didn't migrate anything. We looked at every page. We brought everything across and put it in this new system. And the system that we used, like I said, was OmniUpdate. It was an XML/XSL-based system. And so, it sits on the standard technology. And that was really good for us.

And we went from about 60,000 pages down to just under 30,000 pages. Now, we've grown since then. But just under 30,000, we've got 300 users in the system, just a few more than that actively using the system, engaged in updating their content and things like that. And we really started to push this distributed ownership model, trying to make sure that the users across campus in their different departments not only have the access to maintain data but also have the responsibility and authority to make those content changes.

So, this ownership model that we've pushed out really did help us out. This last year, what we've been looking at now, as my team has been freed up instead of taking care of content maintenance changes, now they're free to actually implement new technologies, research what's up and coming, where we're headed from there. We've launched into a huge mobile initiative. There's lots of different things that we're doing now. And we're a little bit happier. So, this is pretty much the image that reflects what we're about now. So, the Snoopy Happy Feet, right? That's what it's all about.

So, why did we choose a cloud-based solution? Well, the very first reason why is because it met our users' needs. It met what we needed. We spent quite a bit of time going through a needs assessment on this last round, going out to campus, finding out what the needs were, talking to all the users, talking to everybody in IT, talking to everybody in marketing, trying to find out what exactly this need was, how were we going to scope the requirements document. And then, we scoped it and we were looking for standards-based technology. We were looking at something that was designed specifically for higher ed, not retrofitted for higher ed. That was important to us because of some of the experiences that we had had in the past. And a strong ongoing vendor relationship was important to us.

The way we looked at it was this way; anybody have a tax accountant? Anybody? OK. Anybody go to Wal-Mart? OK. Do you have an ongoing vendor relationship with Wal-Mart? Or do you have an ongoing vendor relationship with your tax accountant? It's a little bit different. And so, what we thought was we need an ongoing relationship where we can have communications on an ongoing basis, not just purchasing a product and walking out the door with it, but something where it can grow with our needs and we can grow with its capabilities. And so, it's a good win-win for both of us.

We also needed to make sure that we came in within our budget or under our budget. Our CIO made it very clear to us the dollars were stretched. It's a tight thing and it gets tighter every year, it seems like. And so, we needed to make sure that we were staying within those budget needs.

And most importantly, kind of tied to the budget was that we had to stay within our people needs. When I say "people needs", I mean the staff that we currently had. We didn't have a lot of money to go out and do a whole lot of training and retooling into a new system. We didn't have any money to go hire new people or a new skill set pool. We had to use and leverage the people we had, with the skill sets they had, and try to transition as quickly and as cheaply as possible.

So, that was important to us. But those were the three main reasons why we chose. Now, when we got into our needs assessment, the number 1 thing on the top of our needs assessment during this process was that it had to be simple for the users to use. Like I said, we've been through several systems. One of the main reasons why our systems failed is because the users just couldn't use them. They were too complicated, too difficult, too heavy on their systems, too slow, those types of things.

We also wanted to make sure that we had a Web UI to the system. We had no desire to go around to different clients to make sure the latest patches were installed on clients as they use the system. We also wanted to make sure that we had the ability to publish the way we need it to publish. It doesn't sit real well with your president if he says, "I need to get something out on the Web today," and the reason he can't is because the publishing process of your current CMS doesn't allow it to happen in a timely manner or not the way he needs it done or those kinds of things.

It needed to be scaleable. It needed to be template-driven. We definitely wanted to make sure that our system was a separation of content and design. We wanted to make sure we knew that some things were coming down the road. We could see mobile was on its way in. And we wanted to present that same data not only to a public website but also to a mobile device or maybe to a PDF or to some other document. We wanted to make sure that the publishing processes were the way we needed them to be as we continued.

We had a pretty deep list. I believe there was 32 things on a total for what our requirements document or our needs assessment was. Anybody ever done a needs assessment? They can get pretty deep, can't they? Yeah, it's like a pie in the sky. What exactly do want the system to do? And by the way, that underlying "It can't cost too much. You got to stay within budget. You got $1.50 to spend so stay within it," right?

So, what we found was we found that there are some systems out there that are specific to higher ed and there were some good solutions. Everybody understand the difference between what higher ed needs are and corporate? I'm kind of preaching to the choir here, right? I mean, we all understand that. I've talked to a lot of different CMS companies. And I've talked to a lot of my friends that work in the corporate world. And when I tell them, "Yeah, we don't necessarily get to say that everybody looks the same," they don't quite get that. They're like, "Wait a second."

In the corporate world you don't get to choose while in the academic world you do. In some institutions you get to choose quite drastically. So, you got to really be careful with that and make sure that the system can handle that. It has to be built for distributed content. A lot of systems will make sure that you can distribute to a certain point but you can't push beyond there. You have to keep it within a certain scope. And it needed to be secure and scaleable for some of the unique needs that we have, the workflow, the content, those types of things. So, basically it just needed to be flexible, really flexible, for higher ed needs.

So, like I said, we jumped on board with OmniUpdate in the cloud. It was really a leap of faith. Anybody ever seen the movie "Indiana Jones and the Last Crusade"? Great movie, right? Well, you know the scene where he's standing on the edge of the cliff and he's trying to figure out how to get across and some phrase or something is basically telling him to step out on faith? And so, he steps out and there's a bridge there but it didn't look like there was a bridge there to catch him. So, it was a real step of faith.

That's literally what we did. We jumped on board and we jumped into the cloud. We had no experience with cloud computing. Everybody in my IT group was saying the same exact things. You can't do it for this reason and this reason and that reason. And in reality, it was more fear than anything else. But those of us in IT, if it doesn't in your data center, it really doesn't exist, right? Isn't that the way IT works? We like that control. We like the touchy-feely thing. If I can go and turn on the server, tweak the server, then we're all good.

So, it was a huge leap of faith on our part. We stepped out there. And it was a good test for us. And we succeeded really, really nicely. So, it was a good thing for us. To give you an example of where we were just before we stepped out into the cloud is we were running a very large commercial system that required three on-site servers to run. And we were having quite a few difficulties with the system every time we do an upgrade. Every time we do an upgrade, something would break. And then, our entire system was down until we could get it fixed, causing all sorts of problems. Obviously, people don't like to see the public website go away very often, right? That's not a good thing.

So, we were having some real technical difficulties every time we do an upgrade. So, we talked with the vendor. And the vendor said, "Well, to solve the problem, we just need to put in a redundant system of three additional servers so that you can do all your testing there and then move it live," which is the legitimate internal IT solution. Have a test system, have a production system. Understood. The problem was, this wasn't a cheap system. These three servers were very expensive. We already had three installed. And now, they were telling us we got to add three more. That was going to be a lot of expense that we didn't have.

The other thing was that our data centers, they're not cheap. Square footage in the data centers is pretty pricey. And our data center at the time was kind of bursting at the seams. And so, when I called our infrastructure IT guys and said, "Yeah, I've been told I got to add three more servers," they said, "Good luck. Go find yourself a place to put them."

So, a few things came together. But what happened was, when we decided to move to the cloud, my CIO was a little bit concerned that moving to cloud would be more expensive, it wouldn't be as cheap as running something locally or in-house because of what we had heard and what we thought we knew. So, I was in charge with putting together, coming up with a document that showed the costs and things like these. This was after we moved to the cloud and our CIO was still concerned that we were spending too much money. So, we put together some numbers. I'll just share some of them with you here.

As far as hard work costs were concerned, before we moved to the cloud, we had invested about 67 grand into the servers. We were spending upgrades of 6,000 per year. Once we moved to the cloud, we only had a cost of $9000 in hardware that we had to maintain. So, we actually saved quite a bit in hardware. The CIO was fairly excited about that because now we no longer had the hardware to support. It was all in our contract with the cloud solution.

The next thing that I had to show him was that the software-as-a-service in the cloud would also benefit as far as time. We were at a situation where we were spending almost a full-time equivalent employee at a sysadmin level, maintaining our current CMS at the time. We also had to enlist one of our DBAs and it was taking him about a quarter of his time, overall time, to maintain the databases that would run the CMS. And then, every time we had an upgrade, we had quite significant challenges and upgrade times and testing times from my development team and my programming team to make sure that everything was working because we found so many problems in the system every time they upgraded.

So, we moved to the software-as-a-service in the cloud and we found that no longer did we need our database admin because the database sits in the cloud and we no longer needed much of our time of our sysadmin. The only time we needed his help was if we ever had any concerns or updates to our production Web server. And it's a fairly robust server but it runs a simple Web stacking. So, there weren't a lot of updates that were needed at that time. And since there weren't too many problems every time there was an update, the developer and programmer time was minimal because the updates were taken care of in the cloud for us. We no longer had to do any of that.

So, that was a huge benefit for us. And when we have crunched the numbers on that, we actually found that we were saving almost one in a quarter FTE in our full-time staff. This really screamed at my CIO. He was very excited about this because he was able to reallocate those resources to other projects that were in serious need of further manpower resources. So, this was a good thing for us.

Everybody always asked me, "Yes, but how much were you paying for your service because it's a yearly service?" When you're hosting a cloud, that is something you need to take in consideration. So, our initial costs before we went to the cloud was about 70K. And we were doing ongoing costs about 17K per year with an increase of about 4% a year. That's pretty standard.

Then, we moved to the cloud, we only had a $2500 setup and then the ongoing cost for 40K a year. So, yeah, they were a little higher per year. But when we crunched the numbers and we went out to a five-year span, we were actually able to show because of the resources we were saving on manpower and the hardware and the updates that were needed, we were saving well over half a million in five years. So, those are just are our numbers. That doesn't mean that that's something that you can take to the bank. But that was just our experience with it.

But what was more important in my team than saving money, that was for the CIO. The CIO obviously wants to know that. The administration wants to know that. And once they saw that, they really did realize how much of a benefit this was to move to the cloud. One thing that I was tired of dealing with was I was tired of dealing with screaming customers, users across campus trying to get their work done but couldn't use the system.

So, before we moved to software-as-a-service, creation of a new page was taking around 15 minutes per new page. Now, 15 minutes doesn't seem like very long. But if you ever worked in a CMS, 15 minutes is forever. That really is a long time to create a new page. Publishing of a new page would take 4 to 12 hours. Again, not a really good thing to go to the president when he wanted to get something published and say, "Well, it's in the system. Now, we just got to wait 4 to 12 hours until it goes live because the publishing process takes that long to render it."

In fact, the last opportunity that I had to visit with my president on this exact issue, we were sitting in a president's council. There was a situation on campus where we needed to update some stuff. And they wanted it on the Web right away. And I reported to him, "It's on there, just going to take 4 to 12 hours to render." And he made the statement at that moment. He says, "That's because of our CMS?" And I said, "Yes." And he says, "All right. Here's your job. Fix it or dump it." That was his answer. So, he gave us good incentive to fix it. It would take about 30 minutes to edit a simple content item. The system was very slow, it was sluggish and the user frustration on a scale from 1 to 10 was about a 37. I had to change my address, lose the phone number, that kind of thing.

When we moved, it took us a little while to get everybody into the system trained. But training was very simple for us. And creation of new pages now takes less than two minutes. Publishing of a new page is really instantaneous. But we had to put a benchmark on us. So, we set about 15 seconds.

Editing a content item, again, depending on what the content item is like, it only takes a few minutes. If it's tremendous amounts of content that you want to edit, that's obviously however long it takes you to put the content into the page. But it's very simple. And our user frustration level, we have been tracking it, and it literally is on a scale from 1 to 10 about a 2. We have a few users that would like to do different things. We're figuring out ways to help them do what they need to do. But it's about a 2.

And so, we have a very happy user base. We have a very happy IT staff. And we have a very happy marketing staff. And they really do like the system that we have in place. And the reason they do is because we found that as the frustration goes down, the productivity to update pages goes up, which makes the president happy because one of his mandates for us was make sure that all pages can be updated and maintained very easily and quickly because we're going to put a policy in place that all pages have to be updated every year.

So, that was good for us. It was good for them. But what was even better for us was the fact that with us trying to push out this ownership model to try to get departments to take ownership of their content, if they can do it and they can do it productively and efficiently, they're more likely to take ownership of that content. If they don't, then they won't. If they can't get it done, they're not going to take ownership.

Anybody trying to push ownership of content out to different departments and give them access? A couple of you? How are you finding it? Is it an easy thing? [Laughter] I like that answer of nodding the head yes, answering no. Yeah, it's a tough thing. It's a change management issue more than anything. And if the tools behind the scenes facilitate that change management, that's great. If they don't, it's really difficult to facilitate that.

And so, we were very, very fortunate to have a system that would allow us to help promote this ownership, allow them to make the changes and really give them the benefits of the that. Question?

Audience: [28:39 Unintelligible]?

Nathan Gerber: Yes.

Audience: [28:44 Unintelligible]?

Nathan Gerber: It's one and the same for us. It was part of the same process. So, a lot of times, when I talked to people about cloud computing, people have different questions about what our experience has been. And one of the things that has been brought up a lot is that we don't want to do cloud computing because the vendor will take too much control, that we lose control. This really comes from an IT perspective more than anything. If we don't have it in our server, again, it's not really ours and we don't have control.

What we have found is that's really more perceived than reality. And again, it depends on, I guess, the way the vendors put it together or their services that they provide. But from our experience and with cloud computing with the CMS, the staging server for us, where all of our users actually update pages and save those changes and get ready to do workflow on those changes and approval on those pages, that whole process happens in the cloud. But when it publishes, it publishes back to a production server that's in-house, it's local to us. It's in our data center.

So, it really gave us the best of both worlds. It allowed our IT people to see a cloud-based solution without feeling like they lost complete control. They literally have complete control. The nice thing about our system, the way we've implemented it, is if we ever did decide, "Hey, we want to just do our own thing, we don't want to use the cloud solution anymore," we still have all of our files. We still have everything we need. And it's sitting on a local production server. And our website never goes bye-bye, that kind of thing.

The other question that we come in contact with is that the cloud is insecure. It's a security question. This is probably much more of a question that most people have when it comes to cloud computing. I don't know if I feel comfortable putting our data out there because we don't know about the security.

Well, again, our answer is that when you go into a cloud computing system, you want to make sure your connections are secure. You want to make sure that the database is secure. And you also want to make sure that it's not publicly accessible by search engines or those kinds of things, depending on what kind of system you're running. Once you've done that, you probably need to decide what type of data you're going to store there. We don't store student social security numbers or anything in our content management system because we don't present that information on the public Web pages.

So, for us, a content management solution in the cloud was a perfect way to get into cloud computing without running any security risks because pretty much all the data we have in our Web system, in our CMS, is stuff you want to publish to the public anyway. So, it's not like it's secured data that needs to be really watched carefully.

So, for us, this was a good step into the cloud world without having to deal with a lot of the security issues. But it gave us a good flavor of what type of security questions you need to ask when looking at vendors and cloud solutions. We also actually came across several people that thought, "Well, you know, higher ed is just too complex for the cloud. The cloud is more of a basic system. It can't handle really the complexities of higher ed." And what we found was that the higher ed's flexibility that we need and things like that, I guess, it depends on the product you choose.

For us, software-as-a-service in the cloud gave us all the flexibility we need, especially with our budgets. As I've shown you, it gave us a lot of flexibility with our budgets. Our resources were freed up, it gave us that flexibility. And it gave us the flexibility to implement how we wanted to implement. Again, we can put the Web staging servers in the cloud. We can keep the production server on campus. It was a good solution for us to be flexible, to move into the cloud wherever we were more comfortable.

Other questions that came up was what about upgrades, how are they handled? Well, for us, they're handled seamlessly behind the scenes. We don't have to allocate any resources to that, which is very nice. And it's actually one of the big selling points of any kind of cloud solution, that they will take care of those and maintain those upgrades.

The stability? IT always has questions about, "Well, what if it goes away? What if it's there today and gone tomorrow or up or down or those kinds of things?" Again, because we had our production server on campus, that was not really an issue for us. And since we've been dealing with software-as-a-service in the cloud, we have had complete uptime. We haven't had any problem.

In fact, I better be careful how I say this, but we had more problems with our own internal IT staff taking servers down than we ever have with our cloud solution. I say that with love. But, yeah, it was a challenge for us. And so, we've had a really good stable system since we moved this into the cloud. The speed was always a question. It's going to be remote. So, how's the speed going to be? We've been very, very pleased with the speed. It has been fast. It has been responsive. We've never had any problems that way.

And then, support, this is where the ongoing relationship really needs to start to occur. It's that not only are you going to be calling for support, but did any of us think that mobile computing three years ago was going to be as big as it is? Or do we really even understand how big it's going to be? Everything is changing so rapidly, especially in the Web world. We need a vendor and a strong relationship where the vendor that can grow with our needs and we can grow with what they're doing. We need that vendor along with us. The vendor needs to be looking at it and anticipating future needs. And that was important for us.

I can be wrong but I think in our experience, vendors that deal with cloud computing are a little bit more future-focused. They see where things are going because they know they have to stay ahead of it a little faster than you would if you were running it locally. So, when we talk about the vendor relationship, these are the things we found very important. And because of our past experience with other vendors, this last phrase would make more sense to you if you understood our whole story. But we had to have a relationship where when we ask for something, we don't just get the answer.

That might be a good idea. We may put that in a future release. We need a lot more of a response than that. We need to know, is this going to be in a release? Can you give us a Band-Aid fix? What do we do? This is our need right now. What do we do and when would it be available if it's going to be available in the future? So, it really needs to shift to the "How can we improve it for you?" instead of "We'll get around to it."

So, this has been kind of fast and furious. But some of the questions that you might ask yourself about software-as-a-service or cloud CMS solutions is in our opinion, first of all, you have to meet your users' needs absolutely. You have to find out if that solution will meet your users' needs.

The second thing is does it meet our internal CMS needs, whether it's IT needs or whatever it is marketing needs? I know our marketing department, one of their big needs was that they needed to make sure that because we're a centralized shop, that we are able to brand the entire website with the right brand, the right image, without hindering people's ability to update the content. But they wanted to make sure that brand was consistent and so did our president. So, that was a huge issue from our marketing's perspective. So, that was a CMS need for us.

It also needs to meet our budget needs. In our situation, our CIO was very concerned. He was very excited when he saw how much money we were going to save. And we needed to make sure that we weren't going to end up having to go to the presidential council and say, "Yeah, we have implemented this great system. But now, we need more money to support it and maintain it." And our people were excited about it because it was sitting on standard technology. They didn't have to be retooled in a whole lot of different ways. They had to learn how to use the system. But that was fairly straightforward. It wasn't too difficult and it wasn't too time-consuming.

So, what did we learn through our process? Well, our process that we went through showed, number 1 and foremost, we've talked about cloud computing. We talked about our solutions. We talked about all sorts of different things. But the number 1 thing that I could tell you, if you're going to implement a new CMS system or you're thinking about implementing a new CMS system is that you got to make sure that you do your research about the systems. And then, you also need to define your user experience because it really is all about the user. If you don't meet those user needs, it doesn't matter how cool the system is. It's not going to go very far.

And the last one was my favorite, therapy is cheaper if you learn from other people. So, hopefully, we have eliminated any need for therapy. We'll open it up for a couple of questions. I think we've got about four minutes left. So, yeah?

Audience: I'm worried about the actual setup of the SaaS. We all know that cloud, if you had a user updating there. How did you push to your production server? Did you have to have a custom CMS software for both platforms for the firewalls and whatever?

Nathan Gerber: No. Again, in this situation for us, it's a standard FTP or secure FTP connection. So, it just pushes the files down to that box when you publish. Yeah?

Audience: Just a standard Windows or Linux box?

Nathan Gerber: Yeah. You can run it on standard Windows, Linux. I mean, that's what's cool about it. It's all standard. There's nothing proprietary. You don't have to run some client or agent on the server. Yeah? Does that answer your question?

Audience: Yeah. I mean, users know that the work they are doing on site are...

Nathan Gerber: If they see it in the URL, they would know it. But they don't focus on it. We don't focus on it. And nobody really cares as long as they get their work done. So, it works really well.

Audience: [39:00 Unintelligible]?

Nathan Gerber: We had attempted and we thought we were answering the user question until a couple of people on campus said, a couple of users who were very kind, but they were very blunt and said, "You're not doing this for us. You're doing it for IT. Or you're doing it to disseminate the content management. You're not really doing it for us," which made us kind of stop and wake up and go, "You know, we probably aren't doing it for them." So, we shifted our mentality and our attitude towards it. And that made a big difference in our needs assessment.

Audience: [39:48 Unintelligible]?

Nathan Gerber: No. We had actually implemented just before those units on that second were created. We had done the research and had chosen and started implementing just before that was created. So, it's about the same time but it wasn't to do with that. Does that answer that? OK. Other questions? OK. Oh, yeah?

Audience: [40:18 Unintelligible].

Nathan Gerber: Yes, I will. I'll tell you with kind of tongue-in-cheek. The big commercial system that we implemented was Lumina CMS. It was a SunGard product. So, that's the one we chose and it just didn't work for us, not to say the product isn't a decent product. It just didn't work for our needs. Does that answer the question? Anybody else? OK. Well, thank you for coming. Oh, did you have a question?

Audience: One of the products you use now like there's more delivery. You can switch platforms but doesn't have the content or either part of the platform?

Nathan Gerber: Yes, because it's all in XML and when it gets published, it's published to pages. So, it's easy to be able to collect that data and do what we need. We can pull it from XML in the database or we can pull it directly from the pages. So, we have both options to do it however we would like to do it. It's a very standard technology. And that was a big issue of ours because we've been through so many implementations. We wanted to make sure whatever we do buy into, we're not going to lock it so tight in a box that we can never get it out.

OK. Well, thank you for coming.

Audience: Is there one thing that is a disadvantage about it or something you can't quite grip? What would that be?

Nathan Gerber: One of the things that we've been talking with the vendor for quite some time about is the ability to have more granular control on permissions. The permission system that's in place works fine for us. But if we wanted something better, we've been talking with the vendor to try to come up with ways to implement that a little bit more granular, a little bit more in our control. Right now, it's in just user levels. And what we'd like to be able to do is create groups or where you define the group name and then choose what functions that group does. It could be anywhere on the board of features and then assign people to those groups and go from there.

OK. Well, thank you all. I hope this has been good. If you have other questions, just let me know.

[Applause]