1. Presentation to CIO Council
10/30/2017
CIO Initiative #6: Access to Institutional Data and Systems Integration Launch Proposal
Presentation to CIO Council
May 15, 2017

2. Agenda The Future of Data@Harvard Pre-Launch: How did we get here?
CIO Council Initiative 6: Access to Institutional Data and Systems Integration
Vision and Strategic Objectives
Common API Platform Project
Deliverable
Next steps
It’s very exciting to be here to launch this CIO Council strategic initiative
Here’s the agenda for today:
The content has been changed a bit from what you received on Friday, but not so much that you won’t be able to follow along
We’re going to get through this content in 20 minutes so that we have 10 minutes for discussion at the end

3. Future State of Data @ Harvard
12/1/16
We all know that the problem of providing access to institutional data and simplifying systems integration is complex and pervasive, and we’ve spent a lot of time trying to simplify the messaging so that it’s easier to understand. At the end of the day, the outcomes that we’re looking to drive are:
to reduce the costs associated with data management,
and improve the quality and velocity of decision making.
___________________________
So what is this common need? What is the impetus for change?
As we have talked to people across the University, the problem sometimes gets stated in slightly different, nuanced ways but the themes are clear:
We have an overly complex and unwieldy data integration architecture
The data we do have is exteremly hard to find, get access to, and combine in ways that make sense
And when we do find it, we aren’t sure what it means or where it came from.
These themes have been repeated to us consistently, and the results are this:
It takes us too much time and costs too much to connect our systems
Staff don’t have the data they need to do their jobs
And because data is the modern day language of business, not having a shared understanding of our data makes it hard to communicate with each other.
Simplification leads to faster delivery and streamlined operations: reduced costs
Easy to find, trustworthy data leads to increased workforce productivity and improved collaboration: better decision making

4. And I want to spend a few minutes providing a recap on how we got to this point where we’re confident enough to come here today and say that we have a great plan to begin to make meaningful progress for you and the broader community of stakeholders across Harvard.
___________________
This need has been sorely recognized for quite some time
In fact the need for more maturity in the way we manage our data assets has been a discussion point with the IT Visiting
The team began working on this challenge almost three years ago, even before it was connected to a CIO Council strategic initiative
It’s important to recap the journey, because while the messaging, packaging has evolved along the way, what’s remained consistent is the common need for better management of our institutional data assets
And you’ll get a sense of that common thread as we walk through the build-up to this launch
How did we get here?

5. Pre-Launch: Planning Summary
Created initial long-term vision for Data Management
Created logical future state architecture, and identified key gaps
Evaluated tools for API platform and Business Glossary to fill the gaps
Completed PoC’s with MuleSoft and Collibra that covered multiple use cases ?
Business Glossary
The work began in Since then, there has been significant analysis that has included consultation with internal stakeholders and our peers. Our planning deliverables included an initial vision, a future-state architectural plan that identified current gaps, and tools assessments that eventually led to Proof-of-Concept work that helped the team prove out ideas and assumptions.
Our planning deliverables have laid an excellent foundation of knowledge that provides a robust vision, architectural plan, and knowledge of current industry tools and best practices that positions us well to make targeted investment that
In FY16 and FY17:
Created an initial long-term vision and strategic objectives.
Convened a small group including Ellen Gulachenski, Jason Snyder, Mitch Rogers, and Steve King
Consulted with HBS, as they had already embarked on this journey
We also identfied key gaps, key tools and processes that were missing or inadequate
As a part of our process, we brought in a partner – Centric Consulting – to validate the approach that we were taking
We evaluated tools for key areas – specifically, API platforms and Data Governance toolsets, and then selected tools for a seriec of PoCs
We completed these PoCs with MuleSoft and Collibra
Along the way we also created a logical future state architecture that included these tools as well as systems in our existing portfolio
When these PoC’s were complete, we purchased MuleSoft’s AnyPoint Platform and Collibra’s Data Governance Center.
In FY17, we then began building out the AWS infrastructure for these environments and initiated a more robust Pilot with SalesForce for their HILT tenant ?
API
Platform
Sponsored Research
Human Resources
Finance
Salesforce

6. Pre-Launch: What We’ve Delivered
Selected and procured MuleSoft AnyPoint Platform and Collibra Data Governance Center
Built multi-tier AWS architecture and deployed MuleSoft and Collibra
Delivered Person Data Service (PDS) pilot for Salesforce (HILT)
Piloted a new governance process for data access (PDS)
After completing these PoCs, we purchased MuleSoft and Collibra and implemented them in a multi-tier AWS architecture. Along the way, in conjunction with the HUIT Salesforce team we have built our first API on this platform -- the Person Data Service, which goes live tomorrow! Also, importantly, we’ve piloted a new governance process for requesting and approving data access.
In FY16 and FY17:
Created an initial long-term vision and strategic objectives.
Convened a small group including Ellen Gulachenski, Jason Snyder, Mitch Rogers, and Steve King
Consulted with HBS, as they had already embarked on this journey
We also identfied key gaps, key tools and processes that were missing or inadequate
As a part of our process, we brought in a partner – Centric Consulting – to validate the approach that we were taking
We evaluated tools for key areas – specifically, API platforms and Data Governance toolsets, and then selected tools for a seriec of PoCs
We completed these PoCs with MuleSoft and Collibra
Along the way we also created a logical future state architecture that included these tools as well as systems in our existing portfolio
When these PoC’s were complete, we purchased MuleSoft’s AnyPoint Platform and Collibra’s Data Governance Center.
In FY17, we then began building out the AWS infrastructure for these environments and initiated a more robust Pilot with SalesForce for their HILT tenant

7. Pre-Launch: What We’ve Learned
CIOs and peer outreach has validated and helped refine our vision and strategic objectives
But… don’t try to boil the ocean! Prioritized, incremental delivery is key
Simplifying how we connect our systems is a top priority for all
Access to data, reporting, and analytics is inadequate, but clearer problem definition, ROI, and sponsorship is needed
Data governance is important, but implementation must be practical and targeted
Continuing to engage and educate the broader community is critical for initial and subsequent efforts on this initiative
And we’ve learned a lot from many of you and your teams along the way – what not to do (“don’t try to boil the ocean”), as well as what is most important to do now (“simplify how our systems talk to each other!”). We’ve also gotten some meaningful guidance from our peers. One of the clearest statements I’ve heard that outlines the importance of data management came at an Ivy+ meeting I attended last week at MIT, from a colleague at Princeton, who said:
“At it’s essence, sound data management has two primary objectives: 1, protect the institution from harm that can arise from the mis-use of data, and 2, protect the institution from the competitive disadvantage certainly arises from the under-use of it’s data assets.”
It’s certainly crucial that we continue this outreach and engagement.
Ongoing internal outreach and engagement with our peers

8. Common API Platform Project
CIO Council Strategic Initiative 6: Access to Institutional Data and System Integration
Vision
To harness the significant value of Harvard’s data assets:
We strive to reduce costs and enable improved decision-making for our staff, faculty, and students through the effective use of data management services.
Strategic Objectives
Simplify the way we exchange data between our systems
Provide people with better reporting tools and access to data models
Deliver accurate, well-defined administrative data that are easy to find, understand, and use
All of this planning, proof-of-concept, pilot and outreach work enabled us to validate and refine the vision and strategic objectives for CIO Council Strategic Initiative 6: Access to Institutional Data and System Integration.
And it has allowed us to hone in on the most important place to start: by Implementing a Common API Platform that over time will help us simplify the way we connect our systems and drive down the cost of projects and support.
Before we discuss the Common API Platform project, this seems like a good place to pause for comments…
FY18 ITCRB funding for our first deliverable:
Common API Platform Project

9. Common API Platform Project

10. Common API Platform: Vision, Objectives, Strategy
Project Vision
Reduce integration cost, time, and effort by simplifying the way schools
and central units exchange data between our systems.
Project Objectives
Key Performance Indicators
Simplify our data exchange architecture
Reduce cost of exchanging data between our systems
Improve consistency of projects delivering data exchange solutions
Reduce operational capacity required to support data exchange solutions
Improve staff competency and productivity.
Common API platform is implemented
Number of APIs documented and registered
Percentage of new projects leveraging API platform for data exchange
Number of legacy point-to-point integrations retired
Staff in central departments and each school trained on developing APIs using the common platform
Implementation Strategy
Implement Common API Platform
Build, Document & Catalog APIs
Create prioritized backlog of APIs to build and/or register
Develop new APIs per prioritized backlog
Extend the Person Data Service (new attributes)
Engage with Contingent Workforce, Broadcast Communications, Buy-to-Pay, and others
Replace existing point-to-point interfaces
Engage API Community
Train cross-department staff on API Development
Form an API Community of Practice
This project vision slide is largely the same as a version you saw in February. As you can see, our objective is to simplify, reduce cost, improve consistency, reduce support burden, and improve staff competency and productivity. We’ll do this by completing the implementation of the platform, Building, Documenting, and Cataloging APIs, and creating and training a distributed development community of API developers.

11. Common API Platform: High Level Work Plan
FY18
FY19 Q1 Q2 Q3 Q4
Implement
Common API Platform
Build, Document & Catalog APIs
Engage API Community
API Platform Implementation
Data Access Provisioning for APIs
Launch
Person Data Service
Extend
Person Data Service
API Backlog
Register & Document
Existing APIs
Develop New API
(ie. Cross-Reg, Course, Enrollment)
Develop New API
(ie. Grouper/IAM)
Support for 7+ ITCRB
Projects and Initiatives
This high-level plan includes a number of work streams to achieve those goals. As described earlier there has been a lot of progress made on laying the foundation. One of the initial areas of focus will be building a backlog of work that will be used to prioritize how we allocate project resources.
Decom. Backlog
Retire Central & School Point-to-Point Feeds
Establish/Operate CoP
Training for Staff

12. Common API Platform: Governance
Executive Committee
Executive Sponsor(s)
Anne Margulies
Steve Gallagher
Jason Snyder
HUIT CTO
Jim Waldo,
SEAS CTO
Jason Shaffner ,
HUIT MD
Info Security Oversight Cmte
Access to Elec Information Cmte
Pratike Patel,
HLS CIO
Ellen Gulachenski, HUIT PMO
Harvard Academic Comp Cmte
Steering Committee
Sponsor /
Project Director
Mitch Rogers
Dave Aznavoorian, HBS
Julie Broad, AA&D T&SS
Mike Landino, ATS Ent. Apps
John Scanlon, OPP, IR
Alan Wolfe, AcTS
Carolyn Brzezinski, Ent. Student Sys.
Ana Bard, HHR
Katherine Gates, FAS
Jane Hill, IAM
Dianne Stronach, ATS FAS
Project Team
Workgroups
Project Manager
Erin Gregory
Data Access Ad-Hoc
Sub-Committee
API Platform Service
Sub-Committee
Mulesoft
User Group
We’ve created an engagement approach that helps us pull together the people and expertise we need to make progress. Our objective here is to not over- or under- complicate the project governance structure, and we’ll continually assess and adjust to try and get that right.
There are some folks on here that are proposed, but have not been formally asked to participate as of yet.
Hopefully this structure will be helpful as you look to where you would want to plug into this initiative – either personally or your teams.
Tech Lead
BA / Change Manager
Communications Sub-Committee
Documentation Platform Service
Sub-Committee
Collibra
User Group
Mulesoft Product Owner
Collibra Product Owner
Application Architect
Application Architect
School Engagement Council(s)
As Needed
Faculty Engagement Council(s)
As Needed
Developers
Business/Data Analysts
Operational FTE
Term-to-Perm
Contractor

13. Common API Platform: Needed from the schools
Engagement to help plug your school into the Governance process where appropriate
Helping us build and prioritize the API backlog
In some cases, providing resources to help us address items in the API backlog
Help with testing for your school on APIs for initiatives such as BuyToPay, Contingent Workforce
Help identify candidates for training, and involvement in the Community-of-Practice
More to come on specifics in the coming weeks
Which brings us to “what is needed from the schools”.
As mentioned – engagement in the governance process where desired.
We want to build an “API Backlog” that is as comprehensive as possible.
Allow us to get the big picture and better understand where the value is
Possibly help with some testing at the local level for APIs for these bigger initiatives that we expect to be supporting
Candidates to get MuleSoft training and/or participate in the community-of-practice.
More to come soon…

14. Next Steps Executive Committee Kickoff (June)
Prepare for Project Launch
Continued Outreach
CIOs and Staff
Institutional Research
Business Leadership – Schools and Center
Faculty Advisory Committee
Peers and other HE Institutions
Strategic Plan CIO Summer Retreat
Prioritize Additional Work

15. Appendix

16. CIOC Initiative 6: Milestones
Deploy production-ready API Platform
Create patterns and standards
Establish API backlog
Continue PDS pilot
Begin Course/Enrollment pilot
Service transition
Establish distributed development framework
Ensure ongoing governance
FY18
FY19+
Implement Common
API Platform
Engage API Community
Pre-Launch
Build, Document, Catalog APIs
FY15-17
FY18-19
Productionalize PDS and improve/extend
Develop new APIs, i.e. Cross-registration, Grouper/IAM (per backlog)
Support initiatives, ie. B2P, Position Management, Contingent Workforce
Replace and retire existing feeds (per backlog)
Begin training staff
Establish community-of-practice
Created strategy, future-state architecture
Selected tools, delivered PoCs
Built-out MuleSoft, Collibra environments in AWS
Delivered Person Data Service (PDS) pilot for Salesforce (HILT)
Developed prototype for new data access process
Completed
Planned

17. CIOC Initiative 6: CIO Outreach Highlights
Simplified Data Exchange Architecture
SEAS most pressing request to HUIT is access to central data
HLS, HBS, SEAS may be able to use existing Student APIs, but it is not clear what data is available and if it meets the needs
GSE, SEAS identified a big opportunity with improving the Onboarding/ Offboarding of Faculty by providing central data to school systems
HMS pulls data into its own data warehouse, process takes hours to run each day
All schools have acknowledged how time consuming and expensive it is to connect our systems
“Secret APIs” might as well not exist – they must be discoverable to be valuable
Reporting Tools & Access to Data Models
HLS uses Business Objects, would consider OBI/QlikView if SLAs and access to local data can be achieved
HMS, GSE, GSAS have made or are considering investments in Tableau
HLS, HKS, HMS identified access to consistent local and central/administrative data as a priority
Accurate, Well-Defined Administrative Data
GSD and HKS expressed that many schools use the same data differently, impacting productivity and efficiency
HMS would like to better understand Faculty data and where it is sourced from to better manage data quality
No group wants to see data in the same way, so they need to understand the context of where it came from in order to use it for their distinct needs

18. Common API Platform: Budget Breakdown
FY18
FY19
Total
Operating Tail Q1 Q2 Q3 Q4
Existing Staff – Project Dedicated
$1,196,000 $0
Capital Resources
$573,395
(Term Resources)
$2,259,400
(Contractors)
$3,173,298
$404,000
(Term to Perm Employees)
Licenses
$190,000
Hosting
$20,000
$10,000
Consulting/ Misc
$400,000
$1,975,000
$1,808,000
$3,783,000
$604,000
Project Director
Engineering Manager – Technical Team Lead
Business/Data Analyst
Business/Data Analyst
API Developer
API Developer
Application Developer
$589,000
$607,000
TERM
Mulesoft Product Owner
Collibra Product Owner
Project Manager
Business Analyst - Training
Application Architect
Application Architect
Business/Data Analyst
$1,715,000
$1,458,272
Mulesoft/Collibra Licenses
(Paid out of Operating Budget)
Mulesoft Enterprise Licensing
Collibra Enterprise Licensing
$420,000
$190,000
AWS Incremental Hosting
AWS Incremental Hosting
$10,000
$10,000
Operational Backfill
Operational Backfill
Consulting
Consulting
$250,000
$150,000
$$ = Operational Budget
$$ = Capital Budget