This document discusses lessons learned for achieving interoperability. It recommends having a clear purpose, starting with basic conventions like identifiers, monitoring commitments to build trust, and focusing on outward-facing interoperability through simple APIs and platforms rather than full software stacks. Observance of industry practices like authentication methods and cloud-based platforms is also advised to promote rapid development and distribution of applications.

1. Thoughts on interoperability
Ian Foster
Team Argon/University of Chicago

2. We are all interoperating here today ...
Due to a few simple conventions
● Identifiers
● Language
● Manners
We have not (yet) standardized on many other things:
● Terminology
● Ontologies
The first conventions are a platform that enable discussion of others

4. Lessons learned: Have a clear purpose
● Be clear about why we want to interoperate
● The best reasons are those that are easily expressed and that
satisfy important needs for participants
● E.g., “to solve problem X, we must access resources X and Y”
● Link the purpose to quantifiable goals
○ E.g., data exchanged, computations performed
○ (LHC Computing Grid: “Data Challenges” sought to analyze
1%, 10%, … of expected LHC data)

5. Crawl before you walk
● Start with the things that may seem so trivial that no-one wants to
be bothered with them
● For example:
○ Identifiers
○ Data access
● Get that working while the fun stuff, like ontologies and machine-
readable access policies, gets sorted out

6. Trust but verify
Commitment: Resource X is accessible via method Y. Great!
Is it accessible at 2am? By 1000 people at once?
Monitor commitments to learn whether to trust

7. Some conventions are better than others
Standard protocols are better than standard APIs
Standard software has advantages over standard protocols
Standard APIs and protocols are needed to enable different software to
interoperate
If everyone runs the same software, the interoperation part is trivial
Rhys Francis: “All software should be global software”

8. Observe carefully what industry is doing
For example, authentication:
● X.509 credentials
 SAML (InCommon)
 OAuth2, OpenID
Amazon S3 as an object store interface

9. Inward-facing vs. outward-facing interoperability

10. Inward-facing vs. outward-facing interoperability

11. Outwards-facing interoperability is what really matters
How do we enable a community of “app developers” for the Commons?
Not by making our full stacks interoperable (what do users care?)
Not simply by adopting “standards” (quality not quantity)
 Simple REST APIs, universally available
 Ultra-reliable, scalable implementations
 Address the simplest things (identifiers, data access)
 Achieve broad adoption of a platform

12. The importance of platforms
12
A good platform reduces costs and promotes usability, extensibility, interoperability
Apple iOS and app store:
• Rapid app development
• Common user experience
• Global distribution and
monetization
How do we do the same for science?

13. Cloud has transformed platforms and how software is
delivered
13
Infrastructure as a service: IaaS
Platform as a service: PaaS
Software as a service: SaaS
PaaS enables more rapid, cheap, and
scalable delivery of powerful apps—as SaaS
(web & mobile apps)

14. My experience: The Globus platform
Auth & Groups
…
Globus Toolkit
GlobusAPIs
GlobusConnect
Data Publication & Discovery
File Sharing
File Transfer & Replication
14
75,000 registered users, billions of operations performed, dozens of applications

15. Summary
● Have a clear purpose
● Crawl before you try to walk
● Trust but verify
● Some conventions are better than others
● Observe carefully what industry is doing
● Interoperability out is more important than interoperability in
● Data Commons needs to become a platform