Nathan McBride joined AMAG Pharmaceuticals in 2008 with an ambitious goal: to rebuild IT using as little internal infrastructure as possible. He succeeded. In the ensuing years McBride, vice president of IT and chief cloud architect, successfully shut down AMAG's data center, moved everything to the cloud, went wireless everywhere, made BYOD standard practice, and did away with desktop phones. The migration slashed in half the $2.8 million 2008 budget he inherited, but, more importantly, made IT faster and more responsive to the needs of the business. The experience has also taught McBride a lot about managing cloud providers, which is a new IT art form. Network World Editor in Chief John Dix caught up with McBride in his Waltham, Mass., office.
Where did you come by your aversion to data centers?
The company where I used to work was heavily invested in building data centers, making them bigger. And I was having a hard time coming to grips with the need to buy these big boxes only to use 10% of them. When I joined AMAG they had an external IT consulting firm doing all of their day-to-day IT work, but I convinced the CFO to get rid of the data center. At the time SaaS was not really formally used as a term but SOAP was, so the idea was to chain together these co-lo structured environments. He didn't think it was possible, but said, "If you think you can do it, then let's go ahead and try."
With the promise being?
To run IT very lean. I would only need a small team to do this, and by cutting out the data center I would net out cost. My budget would become much lower. I didn't know how much lower, but I just knew it would become lower. So I hired a staff of three specialists, coaxing them to join by saying we were going to get rid of this entire data center, take everything that's in here and change it into something else, and we're going to make this company efficient as we grow.
We had assembled our A-Team by the middle of 2008 -- a project manager, somebody who had experience with agile and Scrum and PMP development, and a data center master, someone who understood not just how to put in a big server, but the security, the network, the whole thing -- and the goal was to see half of the data center gone by the end of the year.
We then built a bullpen with whiteboards all the way around and started to map out our plan.
We identified the five main areas you typically find in IT -- backups, email, file servers, security and service and then set about figuring out how to strip them down to their leanest part and, more importantly, how to get them all out.
This is kind of starting to get towards the Fall/Winter of 08, and a vendor came out of the woodwork that offered offline backup. They would basically install an appliance and take care of all of the backup. So that was kind of our first step, our first foray. So then we said, "We have backups, now what else can we do?" And more and more vendors started to merge as you we probed deeper and deeper.
But it was about that time that we realized that this whole thing was going to be inhibited by two things: A One was what were we going to do with email, and two, what were we going to do with authentication?
Google Apps had been available for business for almost a year and a half by this point, but we were apprehensive about going that direction. But we did our due diligence and we all used Gmail in our personal life, so we did a company survey. Turns out almost half the company was using Gmail in their personal world, so we had a big migration campaign and did all this communication stuff and migrated over the Gmail.
How many clients?
By this time there were about 250. So with Gmail in place we were left with Active Directory. We knew this was going to be a problem because the more we looked at it the more we realized that to make this venture successful we would have to get rid of it.
For example, in order to mature we had to be able to give employees back the rights to their equipment so they would stop calling the help desk with problems. In order to get rid of that we had to get rid of group policy, we had to get rid of domain administration. We had to get rid of these things and they all kept pointing back to this deprecation of Active Directory. So that was ultimately the plan.
But what became clear to us in a very short amount of time was Active Directory had become almost a virus because it infiltrated everything we did. We had let it, as most companies do, spread everywhere, whether we wanted it to or not.
Isn't that part of its appeal?
Yeah, if you have an internal data center you want it everywhere. The redundancy and the authentication is great, but when all of a sudden you realize you don't want it anymore, it's practically impossible to clean off every counter.
So we thought out a process for how we would get rid of it step by step, and for the most part the process was relatively painless. We started by giving everyone in the company their local administrator password and told them they could do whatever they wanted. You can install whatever you want. And so we started this process of enablement, where people were walking around or emailing each other saying, "Hey. Did you know you can install a new version of Firefox that just came out, or a new version of iTunes, blah, blah, blah."
It was a very nice period of enlightenment for the company. In the background, of course, we're stripping Active Directory. And the beauty of it was that now when somebody emailed the help desk saying, "Please install my printer software," the response would be, "Here's the link. Feel free to do it yourself at your own time. If you need help, let us know." So the mind shift started right then and there for support.
For the cloud services you have today, do you specialize by application, or do you look for a company that can offer you a host of services?
We're big believers in not putting our eggs in one basket. And the only exception to that would be Google. Google not only does our mail now, but with some third-party auditing services we use, they also do our file sharing in collaboration. So we have some additional layers on top of Google because again, though we have our eggs in that one basket, we try to offset it with as much risk mitigation as possible.A
+ ALSO ON NETWORK WORLD 5 reasons Google can catch Amazon in the cloud +
Otherwise, from a cloud vendor approach, we're constantly looking at the market and saying, "Here's our business need, and who is the best in the industry in this particular niche?" Our loyalty only extends to those who innovate the fastest. My vendors know this. They know every October when it's reckoning time they're going to be put up against everybody else in the market to see how well they stand and how well they're doing. And if something's been going wrong we'll generally switch to somebody else. That's usually transparent to the end users when that happens. It's a buyers' market these days. Whereas in 2011 you might only have one or two vendors per vertical, now I have 50 to choose from.
How many do you have today?
Have you had to go swap some out, and if so, how painful is it?
We have, and the effort depends on the users it effects. So when we dropped WebEx for Join.Me, that barely registered a note. We had 20 trainings in-house and via conference calls to the field on how to use this new tool and why we were moving over, and when it finally came around to it, it was kind of anticlimactic.
We switched over from Egnyte to Google Drive after giving Egnyte multiple warnings. They're a big file sharing company. But they insisted on continuing to use WebDav for file transfer. We did not want to employ webdav in any way and preferred other methods. So we moved on. Same thing with YouSendIt. We are huge fans of YouSendIt, but we are eliminating environments that allow themselves to authenticate to social media platforms, which has all sorts of implications, so we switched.
Have you had to switch a supplier that was housing a lot of data?
Yes. We moved off of NaviSite over to AWS. We wanted the greatest amount of flexibility for our cloud stack and no one was even coming close to what AWS could offer. Additionally, the cost differences is just too substantial to overlook. That was a very, very big drop. But it was really a backside IT thing. None of the people out here noticed a thing when it occurred.
How do you go about that?
It was a very structured plan. It wasn't just one night we thought about it and decided to do it. Going into 2013 there was a clear process developed to migrate off of NaviSite to AWS successfully and we executed it in a short amount of time.
Sometimes you change because new options emerge. We may find a vendor who's the cream of the crop and then a month later find out there was another vendor sitting there that was just waiting for a Series C round of funding and suddenly emerges.
A great example is this new security model we're building. We have five vendors working together to build a model that eliminates passwords and creates a document classification process. One of the vendors allows us to eliminate passwords by using our smart phones as a token. When that smart phone is within proximity of another trusted device, it passes through a hash token that allows that device to immediately log in to any service we've approved.
Now we've been looking at this company for seven or eight months already, talked to them extensively, they've been our little darling. We helped them through beta, helped them through pilot and now we're piloting them internally. Then I get an email that the No.1 telecom in Canada, TELUS, had partnered with a company who came out of nowhere that offered the exact same service. We'd never heard of them, and all of our diligence had never come across them because the whole time they were secretly working with TELUS on this pilot and came out of the blue with a press release.
It just goes to show you how all the diligence and research you've done can be upended by somebody who just pops out of the blue.
Is it hard to get cloud companies to work together to solve your problems?
For this security effort we've had to adjudicate some kerfuffles, where one didn't want to talk to another, and so on. But ultimately it's been a matter of us saying, "We don't really care whether you like this vendor or not. This is what we want you to build for us." Some vendors are a little bit more entrepreneurial and see this as an opportunity for something that they could capitalize on. Others have decided to wait and see how it turns out. But from my standpoint, what matters most to me is that by December 1 no one in this company outside of IT will need to know a password for anything. That's the goal.
How does it work?
So say a new hire is coming onboard. Their manager submits a request via this workflow portal, which collects their name and their start date and their title and their department and all the other stuff. The second they hit submit, many things occur, one of which is the user's first name and last name are put into Google Apps and an account is automatically created. And that account is created in a particular sub-org, which you might call in Active Directory a group. A sub-org based on the role.
Simultaneously, in Zendesk a ticket is created which is routed to our help desk contractor, who can then create the laptop, create the smartphone and create the iPad, because we give all three out. Once that account is created in Google Apps and a profile is established for that person, our IAM vendor sees there's a new hire and automatically provisions every app that that user should have. So let's say for that particular profile the user is allowed to use 21 apps. So the IAM vendor creates all those accounts and obfuscates all the passwords.
Once that's done the user is given the equipment when they start and they have to log into each one to establish a certificate. From then on, as long as two of their three devices are within three feet of each other, the two devices become trusted.
How will you roll it out?
We hope to have the first pilot group here at company in place by June, essentially sooner, but we're giving ourselves until June. But the whole thing will roll out to the company by Dec. 1. The flip side to this, of course, is that once you have access and there's trust going on, the next piece will be, "OK. So you've got trust, but what can you actually see?" And that's where the second piece comes in, the part that addresses document ontology and classification.
So we're going through a big effort now to ascertain just exactly what in our company we care about securing. And when we stepped back and thought about it, we realized that less than 1% of our approximately 2 million documents could actually harm us if they were released.
Now that's still a lot of documents, but once you've identified a class of document, it's not so much about going backwards and securing them, it's more about going forward. If a document fits this type of profile then this is what happens to it and people that need to see it are invited to it; the document never actually leaves our cloud. If I have a document I want you to see and work on, I can't actually email it to you. I can't put it on your USB drive or I can't email it to you as an attachment. But, I can invite you to it, and once you come to it everything you do is audited.