Goals: The goals of this proof-of-concept were to deploy Cognos in a multi-tenant fashion to allow departments, labs, and centers to be the masters of their own slice of the Cognos infrastructure. From an organization's perspective they will see a shard of the Cognos installation in which they can manage their user collection, utilize alternative branding, and build a trust model in which only they will have access to their business critical information. This should reduce issues and concerns about allowing access to their data sources while allowing them to leverage our Cognos investment to provide solutions to their own business needs.

Deliverables: 

• Multi-tenant service/policy statement. (July 2014) Complete
• Initial proof-of-concept multi-tenant environment available and tested by IS&T. (July 2014) Complete
• Preparation of tenant solutions for current service customers including the following: Computer Science and Artificial Intelligence Laboratory (CSAIL), Admissions Office, and Alumni Association. (August 2014) Not Completed

Timeline: The proof-of-concept was completed September 2014.

Outcome: The initial plan involved leveraging Cognos' built-in multi-tenant capabilities, but this proved inadequate to our needs. We are in discussion with IBM to implement the necessary functionality via an alternative, automated, cloud-based solution. The existing clients of the POC will be migrated as the new solution becomes available.

Lessons Learned:

Technology – The Cognos multi-tenant architecture as advertised by IBM proved insufficient to the task. Issues focused around segmenting the administration space. Licensing and deployment costs will be a factor in moving forward.

Skills – There is a significant skill gap in the community in regards to management and administration of Cognos. This will require extensive training of the community to be useful. The existing documentation provided by IBM requires a baseline understanding of the product that our user base is not likely to have. It will also require an extensive support network. Significant resources must be allocated to training and support.

Process – An automated process is required to make this tool effective. The current manual processes must be replaced by a turn-key/lights-out automated process.

Community Partners: CSAIL, Admissions Office, and Alumni Association.

Goals: 

The goals of this proof-of-concept were to:

• Create a new departmental degree application programming interface (API) that can be leveraged to prove new functionality can be added on top of current legacy system without the need for customization.
• Prove a department, lab, or center can consume the API for their local system in a faster and more secure way.

Deliverables: 

• Create prototype API and sample code for calling API.
• Test prototype.
• Complete development for the API.
• Complete testing.

Timeline: This proof-of-concept was completed in August 2014.

Outcome: 

• APIs were created to read degree information from MITSIS.
• No legacy MITSIS code needed to be changed.
• The Math Department was able to integrate the API into their departmental system ensuring they will now receive real time data and no longer need to rely on manual intervention from a central unit to provide the information needed.

Lessons Learned

Technology

• This API took longer to create than originally anticipated.
• Some of the existing framework tools we used are not conducive to rapid API creation.
• Need to think about tools or techniques for creation of simple APIs in hours, not days.

People/Skills

• We need to ensure the barrier to API creation is lowered so more people can contribute without needing a lot of ramp up time.

Community Partners: The Registrar business application owner and the Mathematics Department participated in testing.

Goals: 

The goals of this proof-of-concept were to:

• Create new application programming interfaces (APIs) that can be leveraged to prove new functionality can be added on top of current legacy system without the need for customization.
• Prove a department, lab, or center can quickly add new functionality by leveraging a third party-developed application.

Deliverables: 

• Complete development for the APIs. (June 2014) Completed
• Complete integration testing. (June 2014) Completed
• Production go-live. (July 2014) Completed

Timeline: This proof-of-concept was completed in July 2014.

Outcome: 

APIs were created to read real time student account information from MITSIS and post real time payment activity to MITSIS. Legacy MITSIS code did not need to be changed and Student Financial Services (SFS) were able to use a third party cloud application (Nelnet) to deliver new functionality by leveraging the new APIs. All student account information is now available in real time to students and their authorized payers (usually parents) in Nelnet. Previously, students and authorized payers had to go to different locations that did not have real time data, causing confusion and a significant number of support calls.

Lessons Learned

Technology

• IS&T spent time last year thinking through the design for the API framework in MITSIS and the foundation was already in place. That effort took approximately three months. This was very important as it allowed us to focus exclusively on creating the APIs.
• Since the framework was in place, creating the new APIs was a relatively fast process.
• The APIs were created without the need for any special tools.
• Tools for quickly creating documentation is important. IS&T is experimenting with some new tools that will hopefully reduce the manual creation of documentation.
• Versioning for the APIs will become important as more people use them and changes are required.
• As this API was not meant to be publicly consumed, we did not need delegated authentication in place. Once that is complete in August, public APIs will be created at a similar pace.

Skills

• Strong architectural and design skills are important for creating the framework. Once the framework is in place, most developers will be able to create APIs quickly.
• Ramping up teams to create APIs should not require any specialized skills beyond developer skills.
• Not having to worry about creating front ends takes away a lot of the development complexity.
• Having an engaged business partner was invaluable.
• Having a real problem to solve was important as people were able to clearly see the benefits of what was being created. 

Process

• Creating stubbed out versions of APIs initially is a good way to get started; It allows quick feedback on the interface data and for different parts to be worked on in parallel (i.e., front end integration to be tested while the back end API functionality is being implemented).
• Having a simple front end for testing is important. Showing a JSON string is not really useful.

Community Partner Feedback

When announcing the release of the new functionality, Mark Walter, Director of Student Receivables stated:

"In conjunction with IS&T and Nelnet Business Solutions (MITPAY Vendor), SFS has successfully deployed real-time student account activity and real-time payment notification in MITPAY this morning. The success of this project is due to the efforts of everyone involved and I would be remiss if I did not acknowledge the commitment of the team to get to today – Thanks everyone for your hard work, dedication, and contributions! These enhancements will hopefully go a long way in reducing customer service inquiries and assisting SFS in meeting the expectations of our students and their families."

Community Partners: The Student Financial Services business application owner will participate in user acceptance testing and production deployment scheduling.

Goals: 

The goals of this project were to:

• Provide Open Source and Open Standards.
• Expose data safely, through application programming interfaces (APIs).
• Empower a community of developers at MIT.
• Support teaching and research.

Deliverables: 

• Complete OpenID Connect POC. (September 2014) Complete
• Complete WSO2 POC.  (September 2014) Complete
• Hold Hackathon.  (October 2014) Complete
• Release iPad App built on APIs. (November 2014) Complete

Timeline: This proof-of-concept was completed in November 2014.

Outcome: 

MITREID Connect (MIT’s implementation of the OpenID Connect standard “OIDC”), was moved from proof-of-concept to pilot in September 2014 (odic.mit.edu).  The WS02 API manager proof-of-concept was completed in September 2014, with the test use of that platform to manage the Mobile APIs. The MIT Mobile APIs were stabilized and moved to production in October 2014 (m.mit.edu/docs).

IS&T participated in a two-day hackathon (“HackMIT”) involving 700 students. Two of the winners of the competition (including the grand prize winner) used one or more IS&T-provided APIs as part of their team project submission. The grand prize winning team, BeaverDash, and the Big Data Living Lab prize winning team, ClassiFi, both used MIT APIs in their projects. BeaverDash combined campus wifi data supplied by IS&T, two MIT email lists (reuse and free food), and APIs from Google, Uber, and FitBit to create a web application to calculate the user’s likelihood of reaching free food or discarded equipment before other students.

ClassiFi combined the campus wifi data with IS&T legacy APIs for course and classroom information and a Facilities API for classroom coordinates to create a web application that charted wifi usage in each room during meeting times for each class. IS&T provided mentorship to the ClassiFi team by helping them find some additional information they were looking for in our wiki. We learned that some of what they wanted to access - specifically, the total number of students registered in each course for the current term - was not discoverable via a published API. The ClassiFi team was hoping to explore correlations between wifi data, classroom capacity, and course registrations. Lacking that data, their project instead mapped the wifi data to the rooms and times where classes take place to show an indicator of activity in each class, but did not lead to insights into relationships between the number of connections and the number of students. The experience of working with this team served as an example of the positive effect APIs can have on student education and research.

Although we do not know of any completed projects that used our Mobile APIs directly, nor did we observe any new resource or application registrations on OIDC.mit.edu, IS&T was able to use these resources as examples for students while mentoring teams and responding to requests for help. IS&T’s presence at HackMIT was positively received by participants - hackers and organizers alike - as a welcome gesture of support and an indication that IS&T understands the needs of student developers. Several participants remarked that they were very pleased that IS&T members were aware of and supportive of the event, and looked forward to being able to work with more IS&T APIs in the future. This was a great start in promoting student innovation through APIs.

Lessons Learned

Technology

We observed APIs enabling rapid discovery and development, performed by developers ranging from beginners to experts.

Skills

Mentoring students is an excellent professional development opportunity for IS&T staff. Students appreciated having access to experts. Some observations from the team include:

“I think that combining our technical abilities with our knowledge of MIT-things is hugely valuable.”

“The part that I liked the most was discovering all the cool things that were done and attempted. I really engaged in every conversation that I had with the teams I was judging. Conversations included talking about their original concept, the problem they were attempting to solve, their many different ideas, and the next iterations of their projects.”

“Seeing what others did live, on-site, and discovering the technologies people used was really valuable to me, and inspiring.”

“We need to build more APIs and keep developing apps that use APIs. This hackathon proves that APIs are the smartest way to make systems/apps modular and loosely coupled. This way we do not need to predict the use cases, but let the community discover them. During the event I met with people that had no previous programming experience, and yet they were able to put together one or two APIs and came up with something useful.”

Process

Most of the projects students created at the hackathon were born of ideas that arose from exposure to data and technologies at the event itself. Students did not start with a request for certain data, but rather they examined what was available, found interesting patterns in the data, and built upon that. One of our team members, Denis Babani, suggests that making sample data available to the community, appropriately anonymized or scrambled, could help solve the problem of data governance. Rather than waiting for someone to make a specific request, then determine what rules need to be in place to meet that request, instead let people see what is available so they can figure out what they want to do with it, then formulate the request and rules.

The HackMIT event illustrates the recent paradigm shift from the old model of WebSSO via browsers to the new model where users delegate authorization to Applications (including able Apps) that access RESTful APIs. Unlike WebSSO, this new delegation model based on OAuth2.0 allows Applications to perform data access and computation, and does not require the user to sit in front of a browser.

From HackMIT we learned that in order for an Application (such as BeaverDash) to successfully read data from various sources, each of these data-sources must: (i) deploy standard APIs for data access, and (ii) they must use an authorization model that supports delegation to Applications. The student Applications were able to easily combine data from various RESTful APIs (including from Google) precisely because these APIs support the same authorization model.

From HackMIT we also learned that systems of records such as SAP, MITSIS, and the Data Warehouse at MIT have been designed for use by the user at a browser (using the WebSSO model). In order for these systems of records to be accessible to Applications, a new layer of RESTful APIs will need to placed in front of their existing interfaces. More analysis will need to be done on this front.

In order for API publishers and applications to find each other, a discovery service is needed. There are a number of commercial products that support discovery services, however they do not use standards for discovery, in order to achieve vendor lock-in. MIT requires a standards-based approach.

Community Partners: Computer Science and Artificial Intelligence Laboratory (CSAIL) and Media Lab faculty members and students.

Goals: 

The goal of this project was to provide a modernized storage service for unstructured data to the MIT community. This service would build upon the successes and lessons learned from IS&T’s current service offering in this area (AFS, in use at MIT for over 20 years) but provide an experience more consistent with current user expectations. In particular, the service would:

• Be accessible on all common desktop, laptop, and mobile platforms:  Windows, Mac OS, Linux, iOS, and Android.
• Provide users with service from an existing cloud-based vendor (Dropbox) whose product is already in widespread use on MIT’s campus.
• Leverage MIT’s existing central authentication systems (Kerberos, Active Directory, Touchstone) for authentication.
• Facilitate sharing data not only within MIT, but also with external collaborators as well.
• Establish contractual protections for regulated and confidential MIT-owned data stored outside of MIT’s premises on non-MIT owned equipment.

Deliverables: 

Phase 1 deliverables: Complete

• Successful implementation of a proof-of-concept internal to IS&T Operations and Infrastructure. This implementation lacked authentication integration but otherwise demonstrates all user-visible features of a production deployment. 
• Contract negotiation and review by MIT’s Office of General Counsel. The contract has not yet been signed pending final agreement on purchase sizing and pricing, but both parties have agreed to mutually acceptable contractual language.

Phase 2 deliverables: (July-September 2014) Complete

• Execution of Dropbox service purchase for all MIT faculty, students, and campus knowledge workers.
• Integration of Dropbox service with MIT Touchstone / Shibboleth infrastructure.
• Expansion of pilot deployment to include entirety of IS&T and other selected EVPT areas (EVPT HQ, Facilities).

Phase 3 deliverables: (August 22, 2014) Complete

• Campus-wide rollout of Dropbox service, including end user documentation and support via existing IS&T customer support channels.

Timeline: This proof-of-concept was completed August 2014.

Outcome: 

Dropbox for Business service has been licensed and made available to all MIT faculty, students, and staff.  The service has been integrated with MIT Touchstone for single sign-on and account lifecycle management, and a self-service enrollment portal has been created using the Dropbox API allowing community members to sign up for MIT Dropbox accounts. Previously, dozens of MIT DLCs and individuals were purchasing Dropbox for Business or Dropbox Professional service for themselves or their workgroups, and these individual departmental expenditures are no longer required. Additionally, MIT now has in place a contract with Dropbox covering institutional use of their service for all members of the community, rather than individual users agreeing to the Dropbox end user click-through terms of use.

Lessons Learned

Technology

• MIT’s investment in Touchstone / SAML for web single sign-on was extremely worthwhile; it enabled integrating Dropbox with our campus identity management possible in under an hour of total effort.
• Dropbox’s comprehensive API for interacting with their service was crucial for creating an MIT-specific account registration process.  When investigating future cloud service / SaaS providers, a mature API should be considered a requirement.

Skills

• Vendor management and integration (with campus identity services) skills are critical to working with any cloud platform.

Process

• Focusing on and adopting products / platforms that have already been widely adopted by the community greatly increases customer acceptance and satisfaction.
• Working with existing users and other heavily engaged business partners was invaluable to building internal confidence and expertise prior to the community rollout.

Community Partners: Phase 2: EVPT areas – Facilities, Human Resources, and Office of the Vice President for Finance. Phase 3: Involvement from the MIT community.

Goals: 

The goals of this proof-of-concept were to prove that a popular third-party learning management platform with a closed application architecture could enhance functionality in a way that significantly improves workflow, reduces administrative overhead, and improves the end-user experience by leveraging Modular Service Framework (MSF) APIs.

The plan was to enable MITx to enhance functionality and user experience by integrating the standalone Membership Service Module to enable programmatic population and management of class rosters, student membership information, and faculty/staff lists (along with associated role-specific access and control privileges) from within MITx.

Deliverables: 

• Work with MITx to integrate membership into their test environment. (July 2014) Complete
• Complete testing and document lessons learned. (August 2014) Complete
• Integrate the Membership Service Module with the MITx service platform in the production environment. (Spring 2015)

Timeline: This proof-of-concept has been transitioned to a regular project and is scheduled to be complete by Spring 2015.

Outcome: 

The Membership Service Module has been integrated with the MITx service platform in the test environment and is undergoing further development and testing to enable its implementation in production.

The Membership Service Module will be integrated with the MITx service platform in the production environment, and will be leveraged to provision the groups and associated roles as discussed above. Once the integration is live in production (target timeframe: Spring 2015), all group membership data will be maintained consistently across MITx courses via the integration with the Membership Service. Previously, membership needed to be maintained and managed within MITx as a separate and manual process, resulting in greater management overhead and increasing the likelihood for data inconsistency.

Notes

1. No legacy code needed to be changed as part of this project.
2. The Office of Digital Learning (ODL) supports continued development and integration toward the goal of fully integrating the Membership Service Module with the MITx service platform, and intends to rely on the Membership Service Module as its “system of record” for MITx membership data.

Lessons Learned

General

• The documentation associated with the APIs was central to enabling self-sufficiency on the part of the customer team.

People/Skills

• Having an engaged partner was invaluable. Identifying customers who have defined problems to solve and are willing to work with us will be key to the success of future endeavors.
• The presence of a baseline level of development talent on the customer team is a necessity for quick turnaround and long-term self-sufficiency.

Process

• The existing service architecture was integrated within the MITx platform without the need for extensive modification.

Community Partners: MITx will participate in user acceptance testing and production deployment scheduling.

Goals: 

The goals of this proof-of-concept were to:

• Implement Membership Service API integration to provide new or improved functionality and user experience within a subset of Sloan systems without the need for customization.
• Prove that an academic department with an established industry-standard application architecture (Active Directory in this case) can enhance functionality in a way that significantly improves workflow, reduces administrative overhead, and improves the end user experience by leveraging Modular Service Framework (MSF) APIs.

Sloan systems identified for integration with the Membership Service were:

• MySLoan: Localized portal aggregating Sloan-specific content for MBA and Executive Ed students enrolled in a Sloan degree program.
• Software Downloads: Aggregation site providing links to software licensed by Sloan and used by Undergrad, MBA, and Executive Ed students enrolled in a Sloan degree program.
• Qualtrix Insight Platform: Online survey and data aggregation platform supporting Course surveys as well as bid-centric courses within the MBA and Executive Ed curriculum.
• Remote Labs: Remote components of Sloan's Action Learning Model, focusing on providing learning interaction with simulations, as well as remote access to discipline-specific scientific instruments and observations.
• MediaSite: Powered by the Sonic Foundry engine, Sloan MediaSite provides access to rich multimedia, and incorporates webcast and simulcast functionality within Sloan curriculum.

Sloan systems chosen for the proof-of-concept were:

• MySLoan
• Software Downloads
• Qualtrix Insight Platform

Deliverables: 

• Work with Sloan School of Management to integrate Membership in their test environment. (June 2014) Complete
• Complete testing. (July 2014) Complete
• Production go-live. (August 2014) Complete

Timeline: This proof-of-concept was completed in August 2014.

Outcome: 

1. The Membership Service was integrated within Sloan’s AD-based environment using our standard API interface.
2. Security Groups in MIT Sloan’s Active Directory (MSM.MIT.EDU) are being provisioned using data provided by the Membership Service.
3. User membership within these groups is classified and assigned based on Membership Service data.
4. These Security Groups are then utilized within a number of Sloan Systems to control access to systems, services, and content.

All group membership data is now maintained consistently across the Membership-integrated Sloan applications via the API integration with the Membership Service. Previously, membership needed to be maintained and managed within the framework of each system in question. This resulted in greater management overhead and increased the chances for inconsistency between systems. Legacy code did not need to be changed as part of this proof-of-concept. Based on the success of the proof-of-concept, we are now proceeding with the investigative phase of integrating the Membership Service with the following Sloan services:

• Remote Labs
• MediaSite

Lessons Learned

General

•  The documentation associated with the APIs was central to enabling self-sufficiency on the part of the customer team.

Skills

• Having an engaged partner was invaluable. Identifying customers who have defined problems to solve and are willing to work with us will be key to the success of future endeavors.
• The presence of a baseline level of development talent on the customer team is a necessity for quick turnaround and long-term self-sufficiency.

Process

• The existing APIs were implemented within AD-based Sloan services without the need for extensive modification.

Community Partners: The Sloan School of Management participated in user acceptance testing and production deployment scheduling.

Goals: 

The goals of this proof-of-concept were to:

• Create and deploy an API to enable extraction of single articles or lists of articles from the Knowledge Base [see https://kb.mit.edu/confluence/display/hd/The+Knowledge+Base+API for specifications].
• Create a simple proof-of-concept Drupal module that demonstrates how to use the API to dynamically access content from the Knowledge Base and display it on a Drupal site.
• Use the proof-of-concept to demonstrate that certificate how-to information can be displayed in-line in DLC Drupal sites rather than redirecting their users to the Knowledge Base.
• Use the proof-of-concept and demo to engage early community developers and partners eager to use our Knowledge Base as a common repository of searchable knowledge.

Deliverables: 

• API v1 developed, documented, tested, and available as a closed beta release. Complete
• Proof-of-concept Drupal module demonstrating in-line certificate how-tos. Complete
• Engage with community developers (Human Resources, Office of the Vice President for Finance, MIT Medical) to partner on developing production modules to meet their needs. Complete

Timeline: This proof-of-concept was completed in November 2014.

Outcome: 

The initial writing of the API enabled staff, who otherwise do not have much opportunity to engage in development work, an opportunity to do so around a system that they use and understand. This clearly helped develop a stronger understanding of platform concepts among historically end-user support staff. The API key management interface for self-provisioning took a little longer than we anticipated but is now in production.  Anyone with certificates can visit https://knowledgebase-api.mit.edu/keys to request a key.  One of our key community partners wanted to see a demonstrated use of the API in a sample Drupal site. The Drupal module that we created is available at http://kb.scripts.mit.edu/drupal/. We delivered the API and the Drupal module to our partners in the community who were asking for this functionality to deliver KB content on their websites. Their website redesign projects are proceeding according to their own timelines, and we expect that when their sites go live they will make use of the KB API.  And finally, as we begin work on our next Customer Support platform proof-of-concept, a service to enable consistent error message handling, we are using the KB API internally to integrate the errors service with knowledge about errors in the KB.

Community Partners: The Human Resources Department, Office of the Vice President for Finance, and MIT Medical expressed an interest in leveraging this API.

Goals: 

The goal of this proof-of-concept was to develop an application in collaboration with the Computer Science and Artificial Intelligence Laboratory (CSAIL) that addresses the widespread pain point of “chasing receipts” for P-card transactions and matching them to SAP financial transactions. CSAIL identified this as their top administrative pain point. Other areas have built applications that do not integrate with SAP. User experience research identified this as a common manual task for administrators across the institute.

This proof-of-concept will reconfirm results of the initial Mendix Vacation Tracker proof-of-concept and provide additional proof of the platform's delivery of:

• Rapid application development using Mendix "business and IT collaboration and extreme agility" approach and tools.
• Business workflow.
• Complex business rules.

MIT will also gain a better understanding of:

• The difficulty and/or complexity of learning the Mendix Platform.
• The skill set necessary to use the Mendix Platform.
• The capabilities of the Mendix Platform.
• The user interface flexibility of the Mendix Platform.

Deliverables: 

• Three-day proof-of-concept. Complete
• Cloud test environment. Complete
• Shibboleth Delegated Authentication for SAP. (September 2014) Complete
• SAP integration. (September 2014) Complete
• Test and roll out to CSAIL. (September 2014) Complete
• Potential roll out to other departments, labs, and centers. (September 2014) Complete

Timeline: The project was rolled out to a pilot group in late October / early November 2014.

Outcome: 

An application that allows a purchaser to submit a receipt for a purchase by taking a picture of their receipt via a mobile device or by uploading an image or document via their laptop or desktop computer. The receipt will then enter a review and the approval process and once fully reviewed and approved will update SAP (the system of record) with approval, workflow history and the receipt.

Lessons Learned

Technology

Through the delivery of the application from a proof-of-concept to a production application the Mendix Platform proved capable of handling complex requirements, business workflow, roles and authorizations and a flexible user interface. 

Skills

A technical skill set is needed to learn and understand the modeling capabilities of the Mendix Platform. However, getting up to speed on the Mendix platform is relatively quick. After attending a three-day Mendix training course a business systems analyst with a good technical background can be efficient in building applications using Mendix within a few weeks. A developer can be efficient in building Mendix applications within a couple of weeks. 

Process

The platform supports rapid application development and integrates well with Agile development methodologies. The ability to rapidly develop and receive feedback on a working application proved extremely valuable in working with the Business Owners and clarifying and refining key application features. As the process of rapidly developing applications continues to evolve, understanding and deciding on the appropriate time in the lifecycle to include user interface design.

Community Partners: CSAIL

Goals: 

The goal of this proof-of-concept was to help determine if the Mendix platform is a good fit for developing and delivering Administrative Systems applications in the MIT environment. Specifically, if the Mendix platform can perform the following functions:

• Single Sign On
• Integration with SAP (retrieve and update data)
• Rapid application development
• Business workflow
• Roles and authorizations

The proof-of-concept will also identify the following:

• Difficulty and/or complexity of learning the Mendix Platform.
• Skill set necessary to use the Mendix Platform.
• Capabilities of the Mendix Platform.
• User interface flexibility of the Mendix Platform.

Deliverables: 

• Vacation tracking application integrated with SAP. (May 2014) Complete
• Production ready. (August 2014) Complete
• Roll out to Administrative Systems (pilot). (September 2014) Complete
• Roll out to IS&T. (October 2014) Complete

Timeline: This proof of concept was completed in October 2014.

Outcome: 

A vacation request application was created that allows employees to schedule vacation time, withdraw vacation requests, see vacation time requested by peers, and track vacation balances (Standard and Fifth Week). Managers are able to approve employee requests, view employee balances, and track team vacation.

Lessons Learned

Technology

Through the delivery of the application from a proof-of-concept to a production application, the Mendix Platform proved capable of handling complex requirements, business workflow, roles and authorizations, and a flexible user interface. The platform supports rapid application development and integrates well with agile development methodologies. The ability to rapidly develop and receive feedback on a working application proved valuable in reducing the delivery time from inception to production.

Skills

A technical skill set is needed to learn and understand the modeling capabilities of the Mendix Platform. However, getting up to speed on the Mendix platform is relatively quick. After attending a three-day Mendix training course a business systems analyst with a good technical background can be efficient in building applications using Mendix within a few weeks. A developer can be efficient in building Mendix applications within a couple of weeks. 

Community Partners: Sloan School of Management, Facilities, Human Resources, and the Office of the Vice President for Finance expressed an interest in learning more about this proof-of-concept. Demonstrations were delivered in May and June 2014.

Goals: 

The goals of this proof-of-concept were to:

• Prove Mendix can consume non-SAP application programming interfaces (APIs), both secure and non-secure.
• Prove that Mendix allows new applications to be created faster and without deep technical knowledge of MIT Student Information Systems (MITSIS).

Deliverables: 

• Room Inventory proof-of-concept application running in a test environment, consuming a non-secure MITSIS API. (August 2014) Complete
• Reduced Load Petition proof-of-concept application running in a test environment, consuming a secure MITSIS API. (August 2014) Complete

Timeline: This proof-of concept was completed in August 2014.

Outcome: 

Mendix is now consuming APIs from MITSIS.

Both applications have been created but are not production ready yet as all necessary APIs are not yet created.

Lessons Learned

Technology

• Mendix empowers people to build and deploy their solutions without ongoing operation help. Some initial help is needed to set up the application but after that they can do it themselves.
• Mendix will not be fully utilized until enough APIs are available for the systems of record.

People/Skills

• Having a development background reduces the Mendix learning curve.
• We need to ensure the barrier to API creation is lowered so that Mendix apps can integrate with systems of record faster, thus ensuring a better user experience.

Goals:

The goal of this proof-of-concept was to deliver a platform for the management of Institute metadata primarily focusing on administrative units. The scope of this system includes the following:

• Provide front-end tool/service collection for the rapid acquisition and entry of metadata.
• Provide public web services to allow access to the metadata repository information.
• Reference a front-end application that will allow rapid search, review, and exploration of metadata.
• Allow departments, labs, and centers to maintain their own metadata.
• Provide application programming interfaces (APIs) for other systems to add and modify metadata.

Deliverables:

• Draft of web services completed during time frame with enterprise wrapper to allow alternative authorization tools, rate limiting, and auditing. Complete
• Reference implementation of front-end application to allow search, review, and exploration. Complete
• Service access implementation code samples available in multiple languages. (August 2014)
• Initial data population of Data Warehouse and Cognos metadata. Complete
• 1-2 rounds of initial revisions with the identified community contacts. (September 2014) Complete

Timeline: The proof-of-concept was completed in September 2014.

Outcome:

The metadata system allows users to view detailed information about reports, business roles, business processes, business questions, high-level topics, and Cognos packages and reports.

An initial collection based off of Human Resources focus group work has been populated and is scheduled to be reviewed by the associated focus groups. A test instance of this system is currently available. The process of socializing the product with the community began in October 2014.

Lessons Learned

We will need to work closely with the community to tailor the associated data entry interfaces. We need to optimize for time-to-process and ease-of-use.

Skills

The reporting teams have shown that the associated documentation work can be easily integrated into our current workflows. The development teams have shown that we can effectively build these sorts of solutions in a rapid fashion.

Process

Vital in integrating this work into our processes is that we will have to work closely with the community to embed this tool in their stewardship processes. Our existing agile development and documentation methodologies remain effective.

Community Partners: The Physics Department and the Chemistry Department.

Goals: 

• The goal of this proof of concept was to determine whether or not it was possible for SAP authorizations to be created/maintained in the Roles database and proactively prevent Segregation of Duties (SOD) conflicts by making real time calls to the Governance, Risk, and Compliance (GRC) API from Roles. Currently, SOD violations are not prevented or even identified until a nightly report identifies them after they have already been created. The hope was that users could leverage the existing enterprise authorization system (Roles) to prevent SOD conflicts from ever being created. Specifically:
  • Roles should make a call to GRC to check for SOD conflicts for only those users and functions that are flagged as having potential SOD issues.
  • If a new authorization would result in an SOD conflict, Roles should provide an error message and not allow the creation of the authorization.
  • Although initial requirements come from the Vice President for Finance area, the solution should be expandable to any group who may in the future use GRC for SOD conflict identification.

Deliverables: 

The primary deliverable was simply answering the question of whether or not it was technically possible to have Roles communicate with the GRC API to determine whether or not newly created authorizations would result in SOD conflicts in SAP if they were allowed to be created via Roles.

Specific deliverables included:

• Nightly feed from SAP via the Warehouse into Roles with current list of GRC users. Complete
• Initial data population into Roles of functions that can result in SOD conflict, and how they map to SAP composite roles. Complete
• Roles code modifications to make SOAP web service call to GRC to check for SOD conflicts prior to authorization creation. Complete
• Documentation
• Business process (https://rolesweb.mit.edu/conflicts_explained.html) Complete
• Technical (https://wikis.mit.edu/confluence/display/ROLES/Roles+SAP+GRC+Integration) Complete
• VPF New Hire Use Case Process Flow Documentation Complete
• Turn on Roles GRC integration functionality. Complete
• Verify org unit / user group alignment. Complete

Timeline: The proof of concept was completed in October 2014.

Outcome: 

We were able to create the system integration between Roles and GRC in a test environment. We were able to determine proactively whether or not a newly created authorization would result in a SOD conflict in Roles and, in those cases, disallow the creation of the authorization in Roles.

Lessons Learned

Technology

• GRC provides a SOAP API. Roles is able to make the web service call. No additional technology investment is required.

Skills

• IS&T already has the resources necessary to turn this PoC into a real project.

Process

• Once VPF provides the green light to proceed with this project, a cutover date will have to be identified where users will have to agree to creating/maintaining all VPF SAP authorizations in Roles instead of in SAP.

Community Partners: Office of the Vice President for Finance (VPF)

Goals: 

The goals of this proof-of-concept were to:

• Create and expose SAP application programming interfaces (APIs) related to administrative functions.
• Implement SAP Netweaver Gateway. Platform to expose SAP APIs – REST and SOAP. Previously a licensed product, now free and bundled with Netweaver. This required some configuration and activation.
• Participate with other proof-of-concept initiatives related to authentication, management, and support.

Deliverables: 

• Create and expose SAP APIs related to administrative functions:
  • HR Pernr Lookup (for Mendix proof-of-concept). Complete
  • HR Summer Session Appointment updates (for Faculty Effort Summer Session project). Complete
  • HR Summer Session Distribution updates (for Faculty Effort Summer Session project). Complete
  • HR Time Quota Record (for Mendix proof-of-concept). Complete
  • HR Timesheet - Insert/change/delete Vacation Time entry (for Mendix proof-of-concept). Complete
  • HR Timesheet - List vacation timesheet record(s) (for Mendix proof-of-concept). Complete
  • HR Timesheet - Submit timesheet (for student system proof-of-concept). Complete
  • GRC Simulation API - Used by Roles DB. Complete
  • Receipt Application APIs used by CSAIL receipt application. Complete
• Implement SAP Netweaver Gateway. Complete

Timeline: This proof-of-concept was completed in October 2014.

Outcome: 

SAP APIs were created and exposed without implementing SAP's Netweaver Gateway product. Authentication, management, and support needs were better understood as a result of this proof-of-concept. Initiatives addressing these topics will become more and more critical as APIs are consumed more widely.

Lessons Learned

Technology and architecture

• Exposing existing SAP remote function calls (RFC), as APIs can be relatively straightforward when the RFC closely matches the desired API function. Most do not as they were designed to interact with the web components of a tightly integrated application.
• Design decisions about how to safely expose data and functions proved to be complex and challenging.
• The lack of a platform to manage, monitor, publish, etc. is being addressed by the MuleSoft initiative.

Skills

• SAP programmers with little or no API experience were able to create APIs with no additional tools or training. SAP expertise and understanding of MIT’s SAP implementation is critical.
• API design for public use or for use across multiple systems differs significantly from API/RFC design for closed, self-contained applications. API design for project-specific functions differs from the design of a library of more general, commonly needed APIs. This proof-of-concept highlighted gaps in this area.

Process

• The process to engage business owners, audit, and other stakeholders is not mature. Stakeholders are at a very early stage of understanding the implications of exposing SAP data and functions.  
• This proof-of-concept demonstrated tangible examples of how APIs would have benefitted other application development work – for example, Atlas Release 4 would have required significantly less time and effort if APIs existed for some of the functions that rely on non-SAP data.

Goals: 

The goal of this project was to demonstrate a fully functional self-service private cloud offering hosted via MIT’s data center infrastructure. This service would build upon our existing data center architecture in the form of software licensing and support, staff training and expertise, and existing infrastructure, while providing an open application programming interface (API) for provisioning and managing virtual machines in the form of Openstack, an open-source, implementation-agnostic cloud management platform that has been embraced by most major vendors (VMware, EMC, Cisco, Red Hat, Oracle). The resulting environment would:

• Leverage IS&T’s existing investment in VMware vSphere as our virtualization platform of choice.
• Introduce software defined networking (SDN) and software defined storage (SDS) capabilities to our data center architecture, greatly increasing future flexibility.
• Provide the MIT community with a self-service hosting platform similar to public cloud service offerings such as Amazon EC2, Microsoft Azure, or Google Compute Engine.

Provide an infrastructure-neutral API that does not expose the underlying implementation technologies, allowing IS&T to more easily change component vendors in the future without user visibility.

Deliverables: 

Phase 1 deliverables: (July-September 2014) Complete

• Successful implementation of a demonstration deployment of a vendor-supported Openstack release integrated with our existing infrastructure (VMware vSphere, Cisco UCS, EMC storage), utilizing VMware NSX for SDN capabilities.
• Partner with a pilot customer (MITx) to demonstrate that they can successfully deploy an instance of their application to the Openstack environment in a similar manner to how they deploy to Amazon EC2 today.
• Successful implementation of a MySQL-based Relational Database Service (RDS) to support the application database needs of customers.
• Complete vendor negotiations and add all necessary software components to MIT’s existing VMware Enterprise License Agreement.

Phase 2 deliverables: (October-December 2014)

• Deployment of Openstack / NSX components to a second data center for geographical redundancy. Complete
• Deployment of a production MITx environment used by students to Openstack environment.
• Deployment of a production MySQL RDS service in two data center facilities.
• Introduction of VMware VSAN for software-defined storage capabilities. Complete

Phase 3 deliverables: (April-June 2015)

• Deployment of Openstack environment at MGHPCC for research computing use.
• Development of user-facing documentation and support model for Openstack service.

Timeline: This proof-of-concept has been transitioned to a regular project and is scheduled to be completed by June 2015.

Outcome: 

Due to challenges encountered during the proof-of-concept, IS&T is focusing on internal use and staff training of the Openstack environment that has been built. Ongoing work continues with ODL / MITx on exploring the use of Rackspace’s private cloud platform for their deployments.

Community Partners: Phases 1 and 2: Office of Digital Learning / MITx. Phase 3: Research computing users on campus.

Goals: 

The goal of this proof-of-concept was to demonstrate an authentication model for web services (application programming interfaces [APIs] using an HTTP transport) operated by IS&T that is suitable for making those services available to the larger MIT community. In particular, the result needed to:

• Leverage IS&T’s existing investment in the Internet2 Shibboleth protocol as the standard for web single sign-on (SSO) at MIT.
• Not assume a trust relationship between the underlying service and its consumers; a service provider must be able to verify the identity of the user who initiated the request.
• Expose the authenticated identity of both the initiating user and the mid-tier application making the request upon the user’s behalf to the service provider; this is required for authorization and auditing purposes.
• Provide a facility for users to review and approve what information about themselves, i.e., Kerberos name, full name, MIT ID, is being exposed to applications not operated by IS&T.
• Be easily accessible to developers working in a variety of popular languages and frameworks.

Deliverables: 

Phase 1 deliverables: Complete

• Successful implementation of a demonstration application stack in a non-production environment: web service, mid-tier application, and Shibboleth Identity Provider (IdP) with appropriate modifications.
• “Expert-level” documentation of steps required to reproduce setup described above.

Phase 2 deliverables: Complete

• Deployment of necessary IdP modifications in a production environment.
• Modification of existing Education Systems application (Advisor Selection) to make use of delegated Shibboleth authentication model.
• Development of a new Shibboleth-authenticated backend web service for Advisor Selection application, replacing legacy data exchange model.
• Delivery of Java language bindings / class library suitable for use by all IS&T java development projects that wish to make use of delegated Shibboleth authentication.

Phase 3 deliverables: Complete

• Implementation of user interface for end user information disclosure review and approval.
• Review of existing IS&T web services and modification to support Shibboleth authentication and delegation as appropriate.
• Development of documentation suitable for use by external developers / consumers of IS&T web services.
• Proposal for support model and associated required resources for long-term developer support.
• Identify partner in MIT community to build service-consuming application using delegated authentication model.

Phase 4 deliverables: (April-June 2015)

• Development of support libraries for additional key languages and application platforms, i.e., PHP / Drupal, Python / Django.

Timeline: This proof-of-concept is complete and has been transitioned to a regular project that is scheduled to be completed in June 2015.

Outcome: 

The 2 phases expected to be complete by the end of September 2014 have been completed, and have successfully demonstrated use of Shibboleth delegation for integrating both a locally written and hosted application with an API to a system of record as well as integration of a Mendix cloud application with on-premises infrastructure. Remaining deliverables from phases 3 and 4 of the original project plan include conversion of existing IS&T web services to use Shibboleth-delegated authentication, authoring comprehensive documentation, and providing better support for non-Java applications to make use of this authentication mechanism. These will be treated as regular projects.

Community Partners: Phase 2: The business application owners participated in user acceptance testing and production deployment scheduling.