On October 28th, 2010 Apigee held an Open API Economy Meetup at the Mashery offices... This deck is a brief (15 minute) emphasis on the importance of the developer in innovation through APIs and positioning your API for future success (examples from specific learnings with IP Commerce).

1. Medieval Art,
Collective Intelligence,
& Language Abuse
tyler hannan
http://tylerhannan.com
platform evangelist, ip commerce
thursday, 28 october 2010

2. today we will discuss

3. - briefly -

4. medieval art,

5. collective intelligence,

6. language abuse,

7. network effects,

8. the definition of a
platform,

9. and

10. enabling innovation
through
open APIs.

11. actually,

12. this is,
in fact,

13. a medieval art

14. free

15. presentation.

16. you may thank me later.

17. (although i’m happy to discuss
Brunelleschi’s approach to
perspective,
at length,
whenever you desire.)

18. let’s begin

19. at the beginning.

20. (often a good idea)

22. provides a

23. managed commerce services
platform

24. & APIs

26. to enable

27. innovation
in
payments

28. by obscuring the

29. “messy plumbing”

31. associated with
traditional payment services.

32. developers can

33. integrate with

34. one set of open APIs

35. for all services they require.

36. payment
services

37. data
services

38. value-added
services

39. &
federated identity
services…

40. while,

41. importantly,

42. making money.

43. some examples:

44. unattended parking
&
ticketing

45. movie theater
reservations
PoS
concessions

46. mobile payments

47. as the

48. platform evangelist

50. for a company
delivering

51. open APIs
for
payments

52. i have learned

53. some
important
lessons.

54. - language abuse -

55. the year
was
1873.

56. a young college student

57. was appointed
as

58. the assistant librarian
at

59. Amherst College.

60. this man

62. Melville
Louis
Kossuth
Dewey

63. became frustrated with

64. categorization
inside the library.

65. in an attempt to

66. increase
the
utility

67. of the library,

68. without
increasing expenditure,

69. he created

70. a method of
classification.

71. the
Dewey Decimal System.

72. the system
was
devised

73. solely for

74. cataloguing

75. and
indexing

76. purposes.

77. but,
he found it

78. to be equally valuable

79. for
arranging books on shelves.

80. interestingly,

81. or perhaps
frighteningly,

82. he also became
enamoured

83. with the concept of

84. “Simplr Spellin”,

85. or

86. english language spelling reform.

87. which is responsible
for
the spelling of

88. catalog

89. instead of

90. catalogue.

91. this also prompted

92. a desire to change his name
to

93. melvil dui.

94. and,
most disturbingly,

95. responsible
for
menus,

96. in the local area,
reading:

97. hadok,
poted beef with noodls

98. parsli
or
masht potato,

99. butr,
steamed rys,
letis,

100. and
ys cream.

101. NOTE:
powerpoint hates those spelling
errors. red lines under all the
text.

102. a
hierarchical system

103. of categorization
that

104. led to a

105. measure of insanity

106. and
language abuse.

107. at an event,

108. in NYC

109. 2 weeks ago,

110. billed as
“Financial Innovation”

111. for
banks,

112. the term

113. “platform”

114. was used
47 times
in the first

115. 8 hours

116. of presentations.

117. most of these

118. were not,

119. in fact,

120. platforms.

121. *nerd rage*

122. why is this?

123. why platforms?

124. what drives the

125. “me too”

126. effect?

127. 1906
London

129. Francis Galton

130. visited
a
livestock fair

131. where
a
contest

132. would demonstrate

133. collective intelligence.

134. an ox was on display

135. and
villagers,

136. farmers,

137. ranchers,

138. doctors,

139. women,

140. children,

141. professionals,

142. labourers,

143. basically...
all townspeople...

144. were invited to guess
the
weight

145. after slaughter.

146. 787 guesses.

147. none right.

148. however,
the mean of the guesses,
was

149. 1,197 pounds.

150. actual weight...

151. weight for it...
(boo. hiss.)

152. 1,198 pounds.

153. “The results seems more
creditable to the trustworthiness
of a democratic judgement...”

154. with that said,

155. this came from
a
man

156. earlier steeped in the study
of

157. anthropometry.

158. “The systematic quantitative
representation of the human
body for use in classification
and comparison.”

159. in which the sum of his
research

160. indicated that

161. people
are
idiots

162. and
only the
“select, well bred few”
should control society.

163. collective intelligence.

164. the
network
effect.

165. platforms
&
open APIs

166. matter

167. because of
the
work
that

168. you

169. are doing…

170. are thinking about…

171. are planning…

172. will do in the future.

173. platforms
succeed

174. because of the

175. enabled innovation

176. represented by
your work.

177. in this enablement,

178. there is
an
inherent

179. tension.

180. for example,

181. commerce web services,

182. the ip commerce
web service
API,

183. we faced the choice

184. yes,
“THE CHOICE”

185. REST
vs.
SOAP

186. and,

187. while we can debate

188. theoretical implementation,

189. the answer

190. (for us)

191. was

192. both are necessary.

193. but
we
made
the
decision

194. to begin with
SOAP.

195. why?

196. when building
an

197. abstracted message interface

198. that obscures the

199. fixed bit length,

200. ISO 8583,

201. name::value pair,

202. painfully legacy,
payment interfaces

203. things change.

204. and if
“things change”

205. in a new
REST interface

206. things fail.

207. remember,

208. it’s not the verbing that weirds
the language,

209. it’s the
renounification.

210. by delaying the
REST
implementation

211. we had a

212. “known good”

213. underlying
data
structure

214. and our
REST
developers are

215. thrilled.

216. a,
seemingly,
strange

217. technical decision

218. made based on
developer needs.

219. a tension.

220. a healthy tension.

221. or,
consider a

222. relatively major problem

223. in traditional payments…

224. “transaction
originator
authentication”.

225. the majority of
payment services,

226. in market today,

227. do not implement
any
form of originator
authentication when processing
transactions.

228. instead,

229. they simply pass
identity data

230. unprotected

231. in the transaction body.

232. strong authentication,
of the originator,

233. is a requirement.

234. and there may be

235. “easy” fixes…

236. ip commerce

237. built a
holistic

238. federated identity
implementation.

239. SAML 2.0 compliant

240. supports all authentication
methodologies

241. issues identity tokens
(long-lived)

242. coupled with
session tokens
(short-lived)

243. to enable

244. SSO,
claims-based authentication,
policy management,
etc.

245. overkill
when only
authenticating a
transaction originator.

246. but,
wildly necessary,

247. when enabling

248. developers to
build

249. add-ins,
workflow,
stand-alone solutions…

250. commerce
modules
for
merchants...

251. that other developers

252. can simply
“plug-in”.

253. the tension

254. between

255. today’s needs

256. and

257. future requirements

258. is what makes
a platform
grow.

259. why do platforms matter?

260. because of
your work.

261. how does API quality
improve?

262. through
your work.

263. in
any
platform

264. the most important partner

265. is the one with pain…

266. the one being enabled…

267. the one who can innovate…

268. It
Is
Us.

269. when building a platform

270. when offering APIs

271. recognize the nature
of this

272. tension.

273. embrace the discomfort

274. and let the
developer community

275. drive the innovation

276. others cannot.

277. recognize your contribution.

278. own your value.

279. slide #279

280. With thanks, and apologies,to:
Lawrence Lessig
Rolf Skyberg
Written while listening to:
Bombazine Black, Here Their Dreams

281. .::more resources::.
http://commercelab.ipcommerce.com
http://www.paymentsapi.com
http://www.tylerhannan.com