Api strategy and practice

Editor's Notes

• #2: Thanks for the introduction, and thanks to the organizers for having me on the panel.Today I’m going to be talking about API Automation as Craft and how the pieces are coming in in place for a major disruption in how we develop business applications.
• #3: My name is Dave Goldberg and I’m the co-founder of Ritc. Ritc stands for Rules in the cloud and it is a rule engine platform exposed as a RESTful API. If you want to find me, I am on Twitter, where I gain followers frequently by being mistaken for other David Goldbergs. You can also just email me.
• #4: Code as craft. What a beautiful concept and precept to follow. Programmers and software engineers generally subscribe to the idea of “code as craft” in one form or another. Take pride in your work. APICraft, Etsy Blog, The Pragmatic Programmer.
• #5: I subscribe to this as a personal philosophy as well. My personal dream – be like Jake von Slatt (Steampunk Workshop).
• #6: Platforms (specifically software platforms) can scale. This is wonderful and is the reason that many people at this conference have jobs. It is the defining reason why small tech startups get funded by venture capitalists.
• #7: The problem is that craft doesn’t scale. What do I mean by this? It’s obvious that these huge platforms were built by people who subscribe to code as craft. But the writing of the code itself doesn’t scale. I mean this more in the famous “Mythical Man Month” sense. Is everyone familiar with that paradigm?
• #8: So what? What’s the problem? Software developers are protective of this idea, as well they should be. You can’t just start writing great software without training, apprenticeship, and care. When you treat code as craft, you can build a platform that scales. So it is as it should be, no? No. The opportunity isn’t necessarily more services that have massive scaleNot everything of value needs to cater to millions of people. It’s great if you want to build the next big thing, but today I’m talking about a different opportunity. {To be clear, I’m not talking about writing crappy code. }
• #9: As a massive API ecosystem emerges, it is changing the paradigm of what it means to develop an application. It is lowering the bar for speed and efficiency of application development. This entire conference is dedicated to these emerging opportunities. However, by and large it is still only open to developers.
• #10: So this leaves us with a resource bottleneck for application development. It’s important that we can scale application development to address the opportunities for the next generation of businesses. I should be clearon this for because it is important. I’m talking about leveraging this emerging ecosystem in a fundamentally different way. In the last 20 years of the 20th century, the spreadsheet emerged as a tool. And it revolutionized businesses. Sure, you had the occasional spreadsheet ninjas or finance gurus using it, but you also had just about everyone else using it as well. It increased productivity, and was the lingua franca of business tools. Send me the spreadsheet. A shared model. A common tool. With the emergence of the API ecosystem, the opportunity is there to create a shared model for leveraging cloud services not limited to developers. You will still have your experts and SMEs who will go deeper and do more, but everyone should be able to leverage the entire ecosystem of cloud services to create “applications” that suit their needs. As Jeff Lawson mentioned in his keynote, software developers aren’t the only ones who think in terms of software, in terms of what can be built. I’m one of them. So how do we do that?
• #11: Do we just automate interactions? Well, automation certainly has some benefits. It scales nicely, It eliminates the resource bottleneck. And we’ve seen it be successful in certain areas. Marketing automation tools have made great strides over the last few years. But….
• #12: All too often automation fails. We create stupid bots without context. We create agents without agency, with nothing to guide them. Auto-dialers gone mad, automated email and more. Up until now automation has worked best if two key conditions were met:Controlled environmentRelevant and valuable inputStupid bots fail because they don’t have handle relevant input to add value to the output handler (often people). So the answer is simple right? Add intelligence to the automation and bam! Problem solved. Yes. There are examples of this working, but by and large these have been limited to areas where the intelligence is gathered from siloed databases. This makes the automation of little use and can hardly be used to create new real applications.
• #13: Rules are the perfect way to flexibly feed and manage context into automation.
• #14: The amusement park is actually a great analogy. You can think of each ride as both an example of craft, and also as a resource, in the RESTful API sense. That ferris wheel is a beautiful piece of machinery, and so is the log flume, the flying chairs, the roller coaster, and the carousel. Some of these rides are for children, some for adults, some will get you wet, some will make you sick. If you put all these rides together but didn’t provide any rules, you may experience a little bit of chaos. At the very least, you would not be optimizing your park for the best experiences. Having rules allows you to create great applications out of individual craft.
• #15: And because we’re talking about code, APIs, automation and interoperability, we can introduce rules in a dynamic way. The addition of a rule engine that sits on top of your stack can open the door to a lot of innovation, both for internally and externally facing functionality and applications.