Sections:

Breadcrumb

Kent state cio talks about his cloud ambitions accomplishments and his new cloud book

Kent State CIO talks about his cloud ambitions, accomplishments, and his new cloud book

Mar 31st 2016

Ed Mahon, CIO at Kent State University, was bitten by the cloud bug in 2012 and is methodically marching the school to the cloud model, with early benefits being better use of resources and the ability to focus IT staff on bigger picture efforts, among other things. In fact Mahon is so smitten with the cloud he wrote a book about it, “Transitioning the Enterprise to the Cloud: A Business Approach,” which is is an Amazon #1 New Release and is also available on Barns & Noble.com. Networ World Editor in Chief John Dix recently talked with Mahon about what he has learned.

Ed Mahon, CIO at Kent State University

What issues were you facing that encouraged you to think about moving to the cloud?

There were several. One was better utilization of our staff. There was an opportunity to shift people away from plumbing and administration work to customer serving roles, building mobile web apps, investigating born-in-the-cloud SaaS offerings, building a web development platform in the cloud. So number one, it was better utilization of staff skills and resources.

Number two was a chance to normalize our budget process by moving away from a capital environment to one focused on operating expenses. So instead of the stair step method of having to acquire hardware and that sort of thing, moving to a more flexible environment that would give us choices depending upon usage.

And a third motivation was moving to a capacity on demand model that would let use minimize unused systems capacity. So better leveraging staff and reducing unused capacity are the two really, really important ones, although I should point out there’s not likely any savings in the cloud from a head count point of view. You’ll end up transitioning people from data center operator positions to cloud architects, or you’ll need to develop vendor relationship managers or more cost accountants to make certain you’re making informed decisions as you contrast your current costs to cloud prices.

How did you get started?

I went to an AWS training day in DC back in 2012. I wasn’t even halfway through the day-long event when I leaned over to a colleague and said, “You now know where we’re going. This is a no-brainer.”

So we created a small cloud group and trained a couple of people so they were completely knowledgeable in all aspects. Then we made the strategic decision to be cloud-first for anything net new. There would have to be a heck of a reason for us to put anything new in the data center. That also helped us get familiar with SaaS and PaaS offerings which are

really niche oriented, because when user departments would ask for something either by name or by describing the desired functionality, it was a no-brainer to turn to SaaS and PaaS because we could meet their needs without having to build and customize an application or build infrastructure to support it.

Can you give us a thumbnail of your current infrastructure.

We have about 500 UNIX and Windows virtualized servers. Our network supports about 18,000 phones and 12,000 data ports, and we average about 26,000 concurrent users on the wireless net.

We have the usual mix of applications, including a legacy ERP platform that doesn’t have the attributes of a cloud structure to bring forward, and our development platform was built over years with different sets of tools and isn’t object oriented like you can find in a PaaS environment in the cloud today. We also have an extensive data warehouse and we’re contemplating Hadoop.

But all told we have a very reliable environment. I’ve been the CIO for a dozen years and we just hardly ever fail (knock on wood). The key areas of growth, though, are web apps and automating processes and revisiting existing workflows. We have an insatiable appetite, as we should, for automating processes and that remains one of my most important goals.

What did you have to do to prep for cloud adoption?

Obviously virtualization is a cornerstone for Infrastructure-as-a-Service, so virtualizing was a major preparatory item. But we did a lot of other things, like created a security check list that current vendors and cloud vendors need to sign before we’ll do business with them. But you’ll fall off your chair if you read Google’s security paper or look at how AWS approaches security. The giants, I submit to you, can handle security better than we can. But we needed a checklist for cloud suppliers other than the giants.

Then we did a marketplace review, and for that I repurposed a cost accountant to do pricing assessments. On the surface the online calculators in the Infrastructure-as-a-Service space seem simple, but the services have different pricing models and it’s a more difficult than it looks. Related to that I kicked off an activity cost management process that assessed exactly how our staff spent their time, and that was extraordinarily enlightening as it is important to leverage their time in the most effective way.

And I also did a capacity assessment on our infrastructure to see if we were getting near the need to add more capacity. That showed us where we might be able to use the cloud to avoid upgrades, but it also gave us an idea how much capacity we needed to buy in the cloud so we weren’t just winging it.

And finally I also did an application rationalization. We combed through every application from small to medium and large and established some criteria for each, like is it at end-of-life, is it a Tier 1, a Tier 2, what is its cost of ownership, those kinds of things.

What did you learn with the application rationalization?

We had too many darn applications and many were underutilized. That’s independent of the cloud. Those that were underutilized and those that were long in the tooth we set to the side, meaning there was no reason to spend time and money and energy to move them to the cloud if they were likely to die a natural death or were currently living beyond their useful life.

I found a lot of them like that. But importantly, it then allowed us to concentrate on the list that couldn’t go away, that served a useful purpose. On some of those applications, it was exciting to see that functionality could be rolled into easy plug-and-play SaaS apps, like into the AppExchange in the Salesforce.com platform, and so we are teasing apart those that are slam dunks.

How far along are you on this journey?

I wouldn’t be surprised if it’s a ten-year journey. We started in 2012. Maybe we’re a third of the way there. We look at it on a use case basis. What problems are we trying to solve? Which apps are long in the tooth? Where is there some cost avoidance on hardware platforms that will either need to be refreshed or avoided by putting in the cloud or where are we spread too thin? That gets me back to what our staff does -- How can we use them better? -- because that is, to me, the most important thing of all. One of the last things to go will be ERP. We’ll probably make the decision to move to a born-in-the-cloud ERP in a year or two. People can’t believe that the guy that put in the ERP system would want to tear it out. I’m not looking forward to it because it’s so disruptive.

I don’t see the network equipment going away as we need that ato remain local and remain immediately servicable for both local and cloud traffic. Although we’re looking at a VoIP call manager in the cloud. We looked at it when we installed VoIP a few years ago but it didn’t look ready for prime time so we built our own. Maybe that could live in the cloud now. But other than racks of edge devices and core gear, and maybe some security components, most of it will be out of here in, I would say, another eight years.

Are you able to turn stuff off as you shift, or do you have to run both environments in parallel for some period?

That’s my number one issue. I’m always asking people here, “What have you turned off lately?” The more we turn off the more it reduces complexity and reduces costs. So the short answer is yes. Our data center is half empty, and when we started we didn’t have any extra rack space at all.

For example, I was one of the first in higher education to move to Microsoft Office 365 for mail and I think we had 18 racks for that. We turned all of that off, and of course with Microsoft the price is right for higher education: It’s zero. A lot of my colleagues still don’t feel comfortable with that, but to me it’s a low risk area to start.

I have a graph in my book that shows that costs actually go up during the transition until you turn off the old costs. And when I make presentations I often start off by saying, “Hey, sign me up for a project that increases cost, increases complexity and increases risk.” That’s really what’s going on until you turn the old stuff off.

Was the idea of going to the cloud a hard sell internally?

When we started no one really knew what I was talking about except for the staff and they immediately associated it with losing their jobs. But I was easily able to show them they’re needed in the cloud.

How long before the staff recognized that this would be great for their careers vs. a threat?

I’d say six months. It went quickly once they started looking at it, because anybody that looks at a born-in-the-cloud solution compared to something that’s legacy -- the usability factor of the new compared to something designed 15 years ago -- the conversation gets over very quickly. Never mind that the service delivery model enables us to accomplish the other objectives like staff opportunity cost and better utilization of the platform underneath it.

Let’s switch to the book. What inspired you to take on this project?

I have been an IT practitioner for a long time and, as a service delivery model, this new thing looked far superior to our current model. So, first and foremost, I didn’t want to miss the opportunity to explore and learn the latest and greatest, which, I would submit to you, is more of a fundamental change than anything we’ve seen before. That was the primary reason. But I also wanted to write a book to keep my career moving forward.

How is the book structured?

The book is “Transitioning the Enterprise to the Cloud: A Business Approach.” It’s not a book that will quench the thirst of a programmer, but most business folks and CIOs would, I think, find it useful.

I use the phrase in the first part of the book, “Inch by inch, life’s a cinch; by the yard, life’s hard.” The goal is to be iterative, so I spend the first portion mapping cloud benefits to our current problems. Then I talk about the cloud value proposition and give a balanced view of the pros and cons.

But the heart of the book is about 30 tables, indexed into three or four categories, that are based on an activity based costing model that, if readers record different expense elements, they’ll be well positioned to answer a host of questions I provide and that will help them get a sense of where the opportunities are.

Then I switch to building a half-dozen use cases, which, I hope, will turn on some light bulbs for readers by getting them to think about specific uses.

Then in the last chapter where I wrap it up, I build a sourcing strategy that starts with defining service level issues that are unique to the cloud. One, for example, is an exit strategy. If the person’s head is spinning while they build an entrance strategy, I’ve got bad news for them; you need to build an exit strategy too.

That, of course, starts with your data, making sure you can get it back in the format you want and when you want. If a cloud provider goes south you have to have a game plan.

So the book starts with a grounded approach and highlights the use of a cost management system to get to the root of what you’re good at and what you’re not, and then finishes with a sourcing strategy.

Is the book particular to the field of education, given your backgound?

No. I didn’t want to limit it to one industry.

If you want to purchase the book "Transitioning the Enterprise to the Cloud: A Business Approach": $32.95 on Amazon