Value Proposition of Salesforce & Force.com at Yale University Yale University Office of the CTO Value Proposition of Salesforce & Force.com at Yale University Andrew Newman 11-September-2014

Salesforce – The Dream Rapidly Developed, Inexpensive Customized Applications Low Cost Product Lifecycle Performance, Reliability, Availability – Someone Else’s Problem Zero Capital Footprint Upgrades, New Features, Keeping up with Modern Application Expectations – Someone Else’s Problem

Early Explorations The Totally Custom Small Footprint Application. The Tailored Sales/Service (CRM-ish) Business Need. The Rise of the “Citizen Developer” Should Optimizing Subscription Costs Unduly Influence Application Design / Architecture? Are we OK With “Citizen Data Architects?”

Recommendations – 1 Year Ago Recommendations for “Org” Structure Recommendations for Development Platforms Use the technology that the anchor product uses …Or Use the technology that the anchor product vendor recommends… so with Workday that would be??? How much of our expertise / standards can we preserve? Version Control? Continuous Integration? Migration / Backout methodologies?

Present Day – Time for Analysis Examining Three Models Pure Configuration of ServiceDesk or CRM Application Greenfield Force.com Application Hybrid Model – Professional Engineer Partners with Citizen Developer Need Case Studies for Hybrid Model What approaches / division of labor works? Who can document the efficiency gains and/or savings? What does a hybrid developer contract look like? SoW items? Warranty?

Present Day – Looking at Demand Applicability Triage for Salesforce or Force.com New Application Requests Existing Applications Slated for Migration Score

Looking at Demand – The Questions Does the candidate solution “look” like: A service desk? A CRM? A generic intake queue? A small departmental application with little need for institutional data? A small focused user base? “Something” that is amenable to a hybrid development approach?

What Can Central IT Provide the Community Common Core SF Org With Subset Warehouse Data Satellite Org #1 Satellite Org #2 Satellite Org #3 Satellite Org #4 Few Users in More Than 1 Org Common Implementation of Roles & Entitlements Each Satellite Supports Applications Common to a Constituent Group

Hey! What About Workday Anyway? So… Is Force.com ultimately the extension platform for Workday? How do we capture the benefits of Force.com without obliging the data to be co-located in the Salesforce ecosystem? What does a Force.com set of Workday extensions look like from a development lifecycle efficiency point of view?

The Development Model Reconsidered … Let’s not celebrate quite yet! Relational Data Store Application Business Logic UI / UX External App JDBC / ODBC / SQLnet etc… Relational Data Store Application Business Logic UI / UX External App WSDL / REST Web Svcs I the bad old days we thought that to write an external app what we needed was a data dictionary and a database schema and we were good to go…until either of these things changed… With a service oriented point of view, we abstract away the physical structure of the data and loosely couple the application by way of business functions. In Practice Does this Make Writing the External App Easier? ORM Mappings

“Good / Better / Best” for Integration Libraries Good – Core Workday objects available via Web Services and “Wrapped” Better – Salesforce Customizable UI Components Extended to Use Wrapped Workday Object/Services Best – Core Workday objects Appear (as if by magic) As Though the Data is Local to Workday