Minutes of the SIPB Meeting of 2014-12-01 The meeting was called to order at 19:30 by vasilvv. In attendance were Voting members: vasilvv, dove, dzaefn Associate members: k_sunter, tlyu, tthoma24, zoz Prospectives: slz Guests: jcharles IT@MIT Presentation: vasilvv: Today, we have John Charles, VP of IS&T, who is going to give us an update on the Strategic Planning Process over at IS&T. [Presentation; PPT file to be made available] [Questions] vasilvv: Do I understand that we're going to get more APIs getting access to register data? Previously, people had to go through painful processes to schedule appointments and fill out academic forms. jcharles: We explicitly put in the part about being able to leverage data using delegated authentication. The idea being we want to build confidence and trust so that data owners can feel comfortable exposing data elements in their systems using the APIs. For example, with MITSIS, the data is in MITSIS, but you can't get to it. Now, instead of students having to scrape data off of multiple websites, we can enable students to use the right data at the right time by passing along authorization. To make sure we can drive this via governance, we have formed an IT Policy committee. Chaired by Professor Redwine. There is a faculty committee which is charged with Data Governance guidelines, which will tell stewards of the data that they provide data access via APIs using delegated authentication and authorization so that data access will be opened up to the community. vasilvv: I hope it will be extensively documented. For example, with Touchstone, even though it’s a nice platform, it’s a very painful process to deploy. We've never been able to deploy it on scripts as I can understand. jcharles: Yeah, in some ways we do have to live with what we've got. OAUTH and OpenID are being accepted more widely. Additionally, we need to pull data from outside MIT and inside. So at the same time we make Touchstone more robust, we can deploy OAuth and OpenID as well. vasilvv: So, can we expect IS&T and others at MIT to provide more access to third party platforms we have? I ask because we have Dropbox and Github which are deployed, but there are some subscriptions, like the Akamai DNS service, which we hope to see deployed more widely. jcharles: We are moving in that direction. The IT Governace committee understands as we move to these distributed service models, it doesn't make sense to buy limited licenses; you have to take an ecosystem approach. Part of getting to that is changing the monetary landscape. We are building momentum in that direction; we have Dropbox and Github with APIs, and we're going to do a lot more. It is just going to take some time to get there. vasilvv: It's great to hear that. dvorak42: With services like Github and 2FA, IS&T did early release programs to IS&T staff and IT Partners before a full deployment of these services. Is that going to be the general method going forward? jcharles: Probably, that's pretty much what you should expect. Dvorak42: I noticed you had things on the previous slide about AWS. Is IS&T thinking about getting resources for the community to use? jcharles: Yes, absolutely. I mentioned that we Have 200 faculty members still using Cyrus with Eudora. We also have Exchange servers which we are hosting, and we're not shutting any of these services off. We want to be able to shut things off. Additionally, on the public cloud side (AWS and Azure) you have to look at our on-campus infrastructure: imagine that as the "base of the pyramid. Then we have Green HPC, etc as the next level up. Then we have AWS and Azure as the next level up. As we try to scale the on-premises up, there isn't enough power and space on campus to scale up for future needs. So we need to flip that pyramid and scale out public infrastructure in better ways. Moving more and more into things like AWS and Azure Is clearly the way to go. Even with our private cloud, bursting into these services is going to be very cool. dove: Going back to documentation, what is the role of that in the future? What kind of focus shift can we expect? In SIPB, we have issues bringing people into our community to work on things due to lack of documentation about our systems and even basic Athena tools. I'm curious to see what you think the role is. jcharles: I'm expecting we will have some kind of API management platform. Mulesoft is an API management platform we're looking at, which has a lot of connectors that hook into existing systems. These platforms can serve as repositories about the system, APIs, templates, etc. We're also looking on the data side, the metadata, and "data dictionaries" so that people can know which data to use and when. There are some things we're going to do to make things reusable in terms of documentation and existing code. Some of the toolkits we use (like Mendix) are self-documenting; it's model driven. There's also the versioning piece we need to get right, so Mulesoft and Github will help us with that and allow people to get familiarity with dealing with these systems. zoz: What about policy documentation? When we move services to an outsource model, documentation takes a back seat to policy. I haven't found anything about VPN and Wifi access login tracking policy, Crashplan access to files and meta data. It doesn't seem like Policy data is being kept up to date. jcharles: This is certainly something to keep in mind. We'll need to keep in mind these things as we enter into agreements with vendors. dove: What has the initial employee reaction been? In SIPB, we draw a lot of parallels between teams who innovate and which keeping lights on. Though there is a lot of joy to get rid of the load of keeping lights on, there is some joy in taking pride in your product. vasilvv: To rephrase, there were services which were built to be maintained by the innovation team due to high skill level, etc which does not work well with being handed off to a separate maintenance team. dove: This is a big part of [our] culture, and I imagine this is tough to fight against. Jcharles: [PPT] When something moves from innovation team to maintenance team, it is traumatic for people; it's hard. That's another part of the governance process that a move over can't be an IT decision; it has to be made by Governance committee, and I have no voting power on it. The Governance committee has to say we will no longer invest things in it, and want you to seek efficiencies. That's what didn't happen with email. Instead, it's IS&T asking to shut it down dove: and now you've waited too long. jcharles: Right, so there's that piece to deal with. But, when that handoff happens, the innovation team has ideally already moved on. But if you never did that handoff, and you're talking about retirement, it can be really painful. But the IT Staff in terms of reaction is that it is a platform mindset. A lot of IT folks are used to dealing with monolithic systems and not thinking about platform. We need IS&T staff to put things in place as a platform so others can build on it. It really is a mind shift that some people are having difficulty with trying to rethink and re-envision what their role will be in the new world. Take DevOps for example. Instead of throwing something over the fence to stand up servers and bootstrap, now it's one click to setup a new server instance. It's been tough on SysAdmins that this process is being modify. In the IT world, we'll have fewer differentiated roles but more fully staffed roles. btidor: I also wanted to say Github, Duo ,and Dropbox are great and we love them. I am interested in APIs and am wondering if there is a community where people can go for help. Does anything exist now? jcharles: Part of the plan is the Technology Strategy, the Governance plan, financial plan, and the communications plan. In the communications plan, there are a number of things that will happen during Feb-Jun timeline around social coding community infrastructure in place; providing extra information sharing dialog stuff. That will be on the Future of IT@MIT website, going up probably before Holiday break. Governance will look at it Dec 18 and it should go up shortly after. If there are changes, it will instead go up some time in January. btidor: What should SIPB do in all this? What other things can we do? jcharles: Stay true to your core values of trying to make it easier for students to engage in innovation. I would start thinking of adopting a similar Lifecycle model for your services. Can you push things to IS&T to free up capacity for innovation? vasilvv: I can think of plenty of people who want to hand things off to IS&T. We talked about this in the Spring that there were some services to handoff. jcharles: I'd say let's keep that dialog. Garry Zacheiss will be very interested in pursuing these conversations, as will John Doherty. We don't have final Governance committee approval , so we haven't pulled the trigger on everything, but there will be plenty of opportunity. If there are roles of SIPB want to play in service delivery, there's no reason we couldn't collaborate on that with a mixed team vasilvv: We do that with Debathena. I do a lot of innovation on the code base and IS&T does a lot of the management. tthoma24: I'd like to see more of that. jcharles: We should, if we do this right, and the enabling services stack gets more robust, it should lower the overhead to do innovation. Though we don’t have everything in place for enabling services, try to actually build on the APIs to lower overhead and make things easier to do the handoff. vasilvv: Thank you very much. Now, we'll proceed with the regular part of the meeting. Administrivia: NONE SIPB Projects Report: NONE New Prospective Introductions: NONE Other: NONE Other Other: NONE The meeting was adjourned at 20:40. Minutes taken and submitted by tthoma24.