1. 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

2. 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

3. 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?”

4. 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?

5. 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?

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

7. 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?

8. 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

9. 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?

10. 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

11. “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