Medieval Art,
Collective Intelligence,
& Language Abuse
tyler hannan
http://tylerhannan.com
platform evangelist, ip commer...
today we will discuss
- briefly -
medieval art,
collective intelligence,
language abuse,
network effects,
the definition of a
platform,
and
enabling innovation
through
open APIs.
actually,
this is,
in fact,
a medieval art
free
presentation.
you may thank me later.
(although i’m happy to discuss
Brunelleschi’s approach to
perspective,
at length,
whenever you desire.)
let’s begin
at the beginning.
(often a good idea)
provides a
managed commerce services
platform
& APIs
to enable
innovation
in
payments
by obscuring the
“messy plumbing”
associated with
traditional payment services.
developers can
integrate with
one set of open APIs
for all services they require.
payment
services
data
services
value-added
services
&
federated identity
services…
while,
importantly,
making money.
some examples:
unattended parking
&
ticketing
movie theater
reservations
PoS
concessions
mobile payments
as the
platform evangelist
for a company
delivering
open APIs
for
payments
i have learned
some
important
lessons.
- language abuse -
the year
was
1873.
a young college student
was appointed
as
the assistant librarian
at
Amherst College.
this man
Melville
Louis
Kossuth
Dewey
became frustrated with
categorization
inside the library.
in an attempt to
increase
the
utility
of the library,
without
increasing expenditure,
he created
a method of
classification.
the
Dewey Decimal System.
the system
was
devised
solely for
cataloguing
and
indexing
purposes.
but,
he found it
to be equally valuable
for
arranging books on shelves.
interestingly,
or perhaps
frighteningly,
he also became
enamoured
with the concept of
“Simplr Spellin”,
or
english language spelling reform.
which is responsible
for
the spelling of
catalog
instead of
catalogue.
this also prompted
a desire to change his name
to
melvil dui.
and,
most disturbingly,
responsible
for
menus,
in the local area,
reading:
hadok,
poted beef with noodls
parsli
or
masht potato,
butr,
steamed rys,
letis,
and
ys cream.
NOTE:
powerpoint hates those spelling
errors. red lines under all the
text.
a
hierarchical system
of categorization
that
led to a
measure of insanity
and
language abuse.
at an event,
in NYC
2 weeks ago,
billed as
“Financial Innovation”
for
banks,
the term
“platform”
was used
47 times
in the first
8 hours
of presentations.
most of these
were not,
in fact,
platforms.
*nerd rage*
why is this?
why platforms?
what drives the
“me too”
effect?
1906
London
Francis Galton
visited
a
livestock fair
where
a
contest
would demonstrate
collective intelligence.
an ox was on display
and
villagers,
farmers,
ranchers,
doctors,
women,
children,
professionals,
labourers,
basically...
all townspeople...
were invited to guess
the
weight
after slaughter.
787 guesses.
none right.
however,
the mean of the guesses,
was
1,197 pounds.
actual weight...
weight for it...
(boo. hiss.)
1,198 pounds.
“The results seems more
creditable to the trustworthiness
of a democratic judgement...”
with that said,
this came from
a
man
earlier steeped in the study
of
anthropometry.
“The systematic quantitative
representation of the human
body for use in classification
and comparison.”
in which the sum of his
research
indicated that
people
are
idiots
and
only the
“select, well bred few”
should control society.
collective intelligence.
the
network
effect.
platforms
&
open APIs
matter
because of
the
work
that
you
are doing…
are thinking about…
are planning…
will do in the future.
platforms
succeed
because of the
enabled innovation
represented by
your work.
in this enablement,
there is
an
inherent
tension.
for example,
commerce web services,
the ip commerce
web service
API,
we faced the choice
yes,
“THE CHOICE”
REST
vs.
SOAP
and,
while we can debate
theoretical implementation,
the answer
(for us)
was
both are necessary.
but
we
made
the
decision
to begin with
SOAP.
why?
when building
an
abstracted message interface
that obscures the
fixed bit length,
ISO 8583,
name::value pair,
painfully legacy,
payment interfaces
things change.
and if
“things change”
in a new
REST interface
things fail.
remember,
it’s not the verbing that weirds
the language,
it’s the
renounification.
by delaying the
REST
implementation
we had a
“known good”
underlying
data
structure
and our
REST
developers are
thrilled.
a,
seemingly,
strange
technical decision
made based on
developer needs.
a tension.
a healthy tension.
or,
consider a
relatively major problem
in traditional payments…
“transaction
originator
authentication”.
the majority of
payment services,
in market today,
do not implement
any
form of originator
authentication when processing
transactions.
instead,
they simply pass
identity data
unprotected
in the transaction body.
strong authentication,
of the originator,
is a requirement.
and there may be
“easy” fixes…
ip commerce
built a
holistic
federated identity
implementation.
SAML 2.0 compliant
supports all authentication
methodologies
issues identity tokens
(long-lived)
coupled with
session tokens
(short-lived)
to enable
SSO,
claims-based authentication,
policy management,
etc.
overkill
when only
authenticating a
transaction originator.
but,
wildly necessary,
when enabling
developers to
build
add-ins,
workflow,
stand-alone solutions…
commerce
modules
for
merchants...
that other developers
can simply
“plug-in”.
the tension
between
today’s needs
and
future requirements
is what makes
a platform
grow.
why do platforms matter?
because of
your work.
how does API quality
improve?
through
your work.
in
any
platform
the most important partner
is the one with pain…
the one being enabled…
the one who can innovate…
It
Is
Us.
when building a platform
when offering APIs
recognize the nature
of this
tension.
embrace the discomfort
and let the
developer community
drive the innovation
others cannot.
recognize your contribution.
own your value.
slide #279
With thanks, and apologies,to:
Lawrence Lessig
Rolf Skyberg
Written while listening to:
Bombazine Black, Here Their Dreams
.::more resources::.
http://commercelab.ipcommerce.com
http://www.paymentsapi.com
http://www.tylerhannan.com
medieval art, collective intelligence, & language abuse - a story of APIs
medieval art, collective intelligence, & language abuse - a story of APIs
medieval art, collective intelligence, & language abuse - a story of APIs
medieval art, collective intelligence, & language abuse - a story of APIs
medieval art, collective intelligence, & language abuse - a story of APIs
medieval art, collective intelligence, & language abuse - a story of APIs
Upcoming SlideShare
Loading in …5
×

medieval art, collective intelligence, & language abuse - a story of APIs

800 views

Published on

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

Published in: Technology, Economy & Finance
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
800
On SlideShare
0
From Embeds
0
Number of Embeds
53
Actions
Shares
0
Downloads
6
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

medieval art, collective intelligence, & language abuse - a story of APIs

  1. 1. Medieval Art, Collective Intelligence, & Language Abuse tyler hannan http://tylerhannan.com platform evangelist, ip commerce thursday, 28 october 2010
  2. 2. today we will discuss
  3. 3. - briefly -
  4. 4. medieval art,
  5. 5. collective intelligence,
  6. 6. language abuse,
  7. 7. network effects,
  8. 8. the definition of a platform,
  9. 9. and
  10. 10. enabling innovation through open APIs.
  11. 11. actually,
  12. 12. this is, in fact,
  13. 13. a medieval art
  14. 14. free
  15. 15. presentation.
  16. 16. you may thank me later.
  17. 17. (although i’m happy to discuss Brunelleschi’s approach to perspective, at length, whenever you desire.)
  18. 18. let’s begin
  19. 19. at the beginning.
  20. 20. (often a good idea)
  21. 21. provides a
  22. 22. managed commerce services platform
  23. 23. & APIs
  24. 24. to enable
  25. 25. innovation in payments
  26. 26. by obscuring the
  27. 27. “messy plumbing”
  28. 28. associated with traditional payment services.
  29. 29. developers can
  30. 30. integrate with
  31. 31. one set of open APIs
  32. 32. for all services they require.
  33. 33. payment services
  34. 34. data services
  35. 35. value-added services
  36. 36. & federated identity services…
  37. 37. while,
  38. 38. importantly,
  39. 39. making money.
  40. 40. some examples:
  41. 41. unattended parking & ticketing
  42. 42. movie theater reservations PoS concessions
  43. 43. mobile payments
  44. 44. as the
  45. 45. platform evangelist
  46. 46. for a company delivering
  47. 47. open APIs for payments
  48. 48. i have learned
  49. 49. some important lessons.
  50. 50. - language abuse -
  51. 51. the year was 1873.
  52. 52. a young college student
  53. 53. was appointed as
  54. 54. the assistant librarian at
  55. 55. Amherst College.
  56. 56. this man
  57. 57. Melville Louis Kossuth Dewey
  58. 58. became frustrated with
  59. 59. categorization inside the library.
  60. 60. in an attempt to
  61. 61. increase the utility
  62. 62. of the library,
  63. 63. without increasing expenditure,
  64. 64. he created
  65. 65. a method of classification.
  66. 66. the Dewey Decimal System.
  67. 67. the system was devised
  68. 68. solely for
  69. 69. cataloguing
  70. 70. and indexing
  71. 71. purposes.
  72. 72. but, he found it
  73. 73. to be equally valuable
  74. 74. for arranging books on shelves.
  75. 75. interestingly,
  76. 76. or perhaps frighteningly,
  77. 77. he also became enamoured
  78. 78. with the concept of
  79. 79. “Simplr Spellin”,
  80. 80. or
  81. 81. english language spelling reform.
  82. 82. which is responsible for the spelling of
  83. 83. catalog
  84. 84. instead of
  85. 85. catalogue.
  86. 86. this also prompted
  87. 87. a desire to change his name to
  88. 88. melvil dui.
  89. 89. and, most disturbingly,
  90. 90. responsible for menus,
  91. 91. in the local area, reading:
  92. 92. hadok, poted beef with noodls
  93. 93. parsli or masht potato,
  94. 94. butr, steamed rys, letis,
  95. 95. and ys cream.
  96. 96. NOTE: powerpoint hates those spelling errors. red lines under all the text.
  97. 97. a hierarchical system
  98. 98. of categorization that
  99. 99. led to a
  100. 100. measure of insanity
  101. 101. and language abuse.
  102. 102. at an event,
  103. 103. in NYC
  104. 104. 2 weeks ago,
  105. 105. billed as “Financial Innovation”
  106. 106. for banks,
  107. 107. the term
  108. 108. “platform”
  109. 109. was used 47 times in the first
  110. 110. 8 hours
  111. 111. of presentations.
  112. 112. most of these
  113. 113. were not,
  114. 114. in fact,
  115. 115. platforms.
  116. 116. *nerd rage*
  117. 117. why is this?
  118. 118. why platforms?
  119. 119. what drives the
  120. 120. “me too”
  121. 121. effect?
  122. 122. 1906 London
  123. 123. Francis Galton
  124. 124. visited a livestock fair
  125. 125. where a contest
  126. 126. would demonstrate
  127. 127. collective intelligence.
  128. 128. an ox was on display
  129. 129. and villagers,
  130. 130. farmers,
  131. 131. ranchers,
  132. 132. doctors,
  133. 133. women,
  134. 134. children,
  135. 135. professionals,
  136. 136. labourers,
  137. 137. basically... all townspeople...
  138. 138. were invited to guess the weight
  139. 139. after slaughter.
  140. 140. 787 guesses.
  141. 141. none right.
  142. 142. however, the mean of the guesses, was
  143. 143. 1,197 pounds.
  144. 144. actual weight...
  145. 145. weight for it... (boo. hiss.)
  146. 146. 1,198 pounds.
  147. 147. “The results seems more creditable to the trustworthiness of a democratic judgement...”
  148. 148. with that said,
  149. 149. this came from a man
  150. 150. earlier steeped in the study of
  151. 151. anthropometry.
  152. 152. “The systematic quantitative representation of the human body for use in classification and comparison.”
  153. 153. in which the sum of his research
  154. 154. indicated that
  155. 155. people are idiots
  156. 156. and only the “select, well bred few” should control society.
  157. 157. collective intelligence.
  158. 158. the network effect.
  159. 159. platforms & open APIs
  160. 160. matter
  161. 161. because of the work that
  162. 162. you
  163. 163. are doing…
  164. 164. are thinking about…
  165. 165. are planning…
  166. 166. will do in the future.
  167. 167. platforms succeed
  168. 168. because of the
  169. 169. enabled innovation
  170. 170. represented by your work.
  171. 171. in this enablement,
  172. 172. there is an inherent
  173. 173. tension.
  174. 174. for example,
  175. 175. commerce web services,
  176. 176. the ip commerce web service API,
  177. 177. we faced the choice
  178. 178. yes, “THE CHOICE”
  179. 179. REST vs. SOAP
  180. 180. and,
  181. 181. while we can debate
  182. 182. theoretical implementation,
  183. 183. the answer
  184. 184. (for us)
  185. 185. was
  186. 186. both are necessary.
  187. 187. but we made the decision
  188. 188. to begin with SOAP.
  189. 189. why?
  190. 190. when building an
  191. 191. abstracted message interface
  192. 192. that obscures the
  193. 193. fixed bit length,
  194. 194. ISO 8583,
  195. 195. name::value pair,
  196. 196. painfully legacy, payment interfaces
  197. 197. things change.
  198. 198. and if “things change”
  199. 199. in a new REST interface
  200. 200. things fail.
  201. 201. remember,
  202. 202. it’s not the verbing that weirds the language,
  203. 203. it’s the renounification.
  204. 204. by delaying the REST implementation
  205. 205. we had a
  206. 206. “known good”
  207. 207. underlying data structure
  208. 208. and our REST developers are
  209. 209. thrilled.
  210. 210. a, seemingly, strange
  211. 211. technical decision
  212. 212. made based on developer needs.
  213. 213. a tension.
  214. 214. a healthy tension.
  215. 215. or, consider a
  216. 216. relatively major problem
  217. 217. in traditional payments…
  218. 218. “transaction originator authentication”.
  219. 219. the majority of payment services,
  220. 220. in market today,
  221. 221. do not implement any form of originator authentication when processing transactions.
  222. 222. instead,
  223. 223. they simply pass identity data
  224. 224. unprotected
  225. 225. in the transaction body.
  226. 226. strong authentication, of the originator,
  227. 227. is a requirement.
  228. 228. and there may be
  229. 229. “easy” fixes…
  230. 230. ip commerce
  231. 231. built a holistic
  232. 232. federated identity implementation.
  233. 233. SAML 2.0 compliant
  234. 234. supports all authentication methodologies
  235. 235. issues identity tokens (long-lived)
  236. 236. coupled with session tokens (short-lived)
  237. 237. to enable
  238. 238. SSO, claims-based authentication, policy management, etc.
  239. 239. overkill when only authenticating a transaction originator.
  240. 240. but, wildly necessary,
  241. 241. when enabling
  242. 242. developers to build
  243. 243. add-ins, workflow, stand-alone solutions…
  244. 244. commerce modules for merchants...
  245. 245. that other developers
  246. 246. can simply “plug-in”.
  247. 247. the tension
  248. 248. between
  249. 249. today’s needs
  250. 250. and
  251. 251. future requirements
  252. 252. is what makes a platform grow.
  253. 253. why do platforms matter?
  254. 254. because of your work.
  255. 255. how does API quality improve?
  256. 256. through your work.
  257. 257. in any platform
  258. 258. the most important partner
  259. 259. is the one with pain…
  260. 260. the one being enabled…
  261. 261. the one who can innovate…
  262. 262. It Is Us.
  263. 263. when building a platform
  264. 264. when offering APIs
  265. 265. recognize the nature of this
  266. 266. tension.
  267. 267. embrace the discomfort
  268. 268. and let the developer community
  269. 269. drive the innovation
  270. 270. others cannot.
  271. 271. recognize your contribution.
  272. 272. own your value.
  273. 273. slide #279
  274. 274. With thanks, and apologies,to: Lawrence Lessig Rolf Skyberg Written while listening to: Bombazine Black, Here Their Dreams
  275. 275. .::more resources::. http://commercelab.ipcommerce.com http://www.paymentsapi.com http://www.tylerhannan.com

×